Managing Windows 7 in a Domain : Identifying and Resolving Logon Issues

Many of the items just require looking at the symptoms. That may seem obvious, but for some end users an error message just indicates that things aren't working, even if a message clearly says the password has expired and needs to be changed. If it's the first time the user has seen the message, it's translated simply as "it's broken."

Here are some of the items to consider when troubleshooting logon issues:

• Hardware versus network problems

• Using cached credentials

• Password expiration

• Determining logon context

• Logon hours compliance

• Time synchronization

1. Hardware vs. Network

If a user is unable to log on to a system using a domain account, one of the first things to do is to ensure that the computer is operational and has connectivity. This can be done by logging on to the local computer using the local administrator account. If you can't log on locally, there's no need to troubleshoot the network—the problem is in the local machine.

Once you log on locally, you can do basic connectivity checks to ensure the client has an IP address on the network and has connectivity with other systems on the network.

2. Using Cached Credentials

Windows 7 will cache the domain credentials of up to 10 users who have logged on to a system. These cached credentials are stored in an encrypted format in a secure area of the Registry, and they can be used by Windows 7 if a domain controller is not available to authenticate a user.

Consider a user named Sally who has a mobile computer. When she's at work, her mobile computer is connected to the domain and she uses her domain account to log on. Her credentials are then cached onto her system. Sally then goes on a business trip. While at the airport, she can still log on to her mobile computer using the same domain account even though a domain controller isn't reachable.

This works the same way in a network if a domain controller is unreachable. The network could have problems preventing the user from accessing a domain controller, but the user can still log on using a domain account. There is no indication to the user that cached credentials are being used, other than the logon seems to take a little longer and network connectivity is prevented after the user is logged on.

Figure 1 shows how the Network and Sharing Center appears when a user is logged on with cached credentials. Notice the warning icon between the computer and the network.

Figure 1. Connectivity affected by cached credentials

Users cannot access any domain resources when authenticated with cached credentials. If a user tries to access a network share, print to a network printer, or use any other network resources that require valid credentials, the attempt will fail with cached credentials.

The reasoning is that the user has not been authenticated by Active Directory, and it's possible the account has been disabled or deleted. Until the account can be authenticated with Active Directory for this session, access is not granted.

When Windows 7 is logged on with cached credentials, it will periodically try to connect to the domain controller and authenticate normally. If the domain controller comes back online or the network is repaired so that the domain controller can be reached, the user's credentials will be authenticated and the user will have access to network resources as normal.

3. Password Expiration

If a user uses the same password for a long period of time, the possibility of the password being discovered and used by an attacker increases. In a domain, Group Policy is commonly used to force users to change their password on a regular basis.

The Default Domain Policy is created when the domain is created, and it includes several settings for the Password Policy, as shown in Figure 2 with Password Policy selected.

Figure 2. Password Policy

When the default policy is used, users are required to change their password every 42 days. Users are given reminders to change their password when it is close to expiring. If the user ignores the warning until the last day, the user will be notified that the password has expired and must be changed.

The user won't be allowed to log on until the password has been changed. Luckily, the solution is simple. The user needs to change their password.

4. Determining Logon Context

Users can log on to the local computer using a local account, or they can log on to the domain using a domain account. Which account a user logs on with determines the logon context, and if a user logs on with a local account, access to domain resources will be limited to permissions granted to the local account.

As an example, imagine that Sally has a domain account in the Wiley.com domain named Sally (Wiley\Sally) and a local computer account on a computer named Win7 (Win7\Sally). She could be granted full control for a share using the Wiley\Sally account but no access using her Win7\Sally account.

If you've verified that Wiley\Sally has full control to the share but she is being denied access, you should check the logon context. One way to do so is by pressing Ctrl+Alt+Del to access the Ctrl+Alt+Del menu. You can then select Change A Password to access the screen shown in Figure 3.

Figure 3. Checking logon context

In the figure, you can see that the account is identified as Win7\Sally, indicating that she is logged on using the local account. If it was the domain account, it would be listed as Wiley\Sally.

You can also use the whoami command from the command line. This will return the username in the format of domain\username for a domain account or computer\username for a local account. The whoami /all command will also list SIDs, group memberships, and privileges for the account.

5. Logon Hours Compliance

By default, users are granted permissions to log on to computers at any hour of the day, any day of the week. However, you can modify the properties of a user account to restrict logon hours.

Figure 4 shows the screen used to change the logon hours. You can access this from Active Directory Users and Computers by right-clicking the user account and selecting Properties. In the figure, the logon hours have been changed to allow a user to log on only between 5:00 AM and 8:00 PM.

Figure 4. Setting logon hours

If a user tries to log on outside of the logon hours, the following message will appear: Your account has time restrictions that prevent you from logging on at this time. Please try again later.

Users will not be logged off if the logon time passes, and if they are connected to any network resources, they won't be disconnected. However, they won't be able to make any new connections.

As an example, imagine that logon times for Sally are set to 5:00 AM to 8:00 PM. One night she stays late working on a critical report stored on a network share. As the clock ticks past 8:00 PM, she is still able to continue working on the report and save it to the network share. However, if she tries to connect to another network resource, she'll see a message like the one shown in Figure 5.

Figure 5. Denied access to a resource after hours

Active Directory Domain Services uses Kerberos as the primary authentication protocol within the domain, and Kerberos requires all computers to be set to within five minutes of each other. If not, the trust relationship with the machine account is lost.

When a computer first authenticates in a domain, it is issued a ticket-granting ticket (TGT) from a Key Distribution Center (KDC). Then when the computer wants to access any resources, it presents the TGT and requests a ticket for the resource. However, if a computer is more than five minutes out of sync, the KDC will no longer issue tickets and the computer will not be able to access resources.

Computers within a domain are synchronized as shown in Figure 6. One domain controller holds the role of a primary domain controller (PDC) emulator. It is commonly configured to synchronize with an external time source.

All domain controllers get their time from the PDC emulator. Then when a domain computer is turned on and authenticates with a domain controller, the client synchronizes its time with the domain controller.

This works great as long as a user doesn't change the time on their computer. If a user does change their time (or date) so that it is more than five minutes off, the computer will effectively be kicked off the domain, at least until it's rebooted and synchronizes with a domain controller.

When the system time is changed and the system is kicked off the network, it's sometimes challenging to identify why. However, this is a great example of how rebooting a system often clears up the problems.

Figure 6. Time synchronization in a domain