TIPS & TRICKS FOR COMPUTER USERS

Logging into a computer is such a routine part of the day that it is easy to not even think about the login process. Even so, things can and occasionally do go wrong when users log into Windows. In this article, I will talk about some of the things that can cause logon failures, and show you how to get around those problems.

Before I Begin

Before I get started, I just want to quickly mention that in order to provide as much useful information as possible, I am going to avoid talking about the most obvious causes of logon failures. This article assumes that before you begin the troubleshooting process, you have checked to make sure that the user is entering the correct password, the user's password has not expired, and that there are no basic communications problems between the workstation and the domain controller.

The System Clock

It may seem odd, but a workstation's clock can actually be the cause of a logon failure. If the clock is more than five minutes different from the time on your domain controllers, then the logon will fail.

In case you are wondering, the reason for this has to do with the Kerberos authentication protocol. At the beginning of the authentication process, the user enters their username and password. The workstation then sends a Kerberos Authentication Server Request to a the Key Distribution Server. This Kerberos Authentication Server Request contains several different pieces of information, including:

• The user’s identification
• The name of the service that the user is requesting (in this case it’s the Ticket Getting Service)
• An authenticator that is encrypted with the user’s master key. The user’s master key is derived by encrypting the user’s password using a one way function.

When the Key Distribution Server receives the request, it looks up the user’s Active Directory account. It then calculates the user’s master key and uses it to decrypt the authenticator (also known as pre authentication data).

When the user’s workstation created the authenticator, it placed a time stamp within the encrypted file. Once the Key Distribution Server decrypts this file, it compares the time stamp to the current time on its own clock. If the time stamp and the current time are within five minutes of each other, then the Kerberos Authentication Server Request is assumed to be valid, and the authentication process continues. If the time stamp and the current time are more than five minutes apart, then Kerberos assumes that the request is a replay of a previously captured packet, and therefore denies the logon request. When this happens, the following message is displayed:

The system cannot log you on due to the following error: There is a time difference between the client and server. Please try again or consult your system administrator.

The solution to the problem is simple; just set the workstation’s clock to match the domain controller’s clock.

Global Catalog Server Failures

Another major cause of logon problems is a global catalog server failure. A global catalog server is a domain controller that has been configured to act as a global catalog server. Global catalog servers contain a searchable representation of every object in every domain of the entire forest.

When the forest is initially created, the first domain controller that you bring online is automatically configured to act as a global catalog server. The problem is that this server can become a single point of failure, because Windows does not automatically designate any other domain controllers to act as global catalog servers. If the global catalog server fails, then only domain administrators will be able to log into the Active Directory.

Given the global catalog server’s importance, you should work to prevent global catalog server failures. Fortunately, you can designate any or all of your domain controllers to act as global catalog servers. Keep in mind though that you should only configure all of your domain controllers to act as global catalog servers if your forest consists of a single domain. Having multiple global catalog servers is a good idea even for forests with multiple domains, but figuring out which domain controllers should act as global catalog servers is something of an art form. You can find Microsoft’s recommendations here.

If your global catalog server has already failed, and nobody can log in, then the best thing that you can do is work to return the global catalog server to a functional state. There is a way of allowing users to log in even though the global catalog server is down, but there are security risks associated with doing so.

If the Active Directory is running in native mode, then the global catalog server is responsible for checking user’s universal group memberships. If you choose to allow users to logon during the failure, then universal group memberships will not be checked. If you have assigned explicit denials to members of certain universal groups, then those denials will not be in effect until the global catalog server is brought back online.

If you decide that you must allow users to log on, then you will have to edit the registry on each of your domain controllers. Keep in mind that editing the registry is dangerous, and that making a mistake can destroy Windows. I therefore recommend making a full system backup before continuing.

With that said, open the Registry Editor and navigate through the registry tree to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. Now, create a new DWORD value named IgnoreGCFailures, and set the value to 1. You will have to restart the domain controller after making this change.

DNS Server Failure

If you suddenly find that none of your users can log into the network, and your domain controllers and global catalog servers seem to be functional, then a DNS server failure might have occurred. The Active Directory is completely dependent on the DNS services.

The DNS server contains host records for each computer on your network. The computers on your network use these host records to resolve computer names to IP addresses. If a DNS server failure occurs, then host name resolution will also fail, eventually impacting the logon process.

There are two things that you need to know about DNS failures in regard to troubleshooting logon problems. First, the logon failures may not happen immediately. The Windows operating system maintains a DNS cache, which includes the results of previous DNS queries. This cache prevents workstations from flooding DNS servers with name resolution requests for the same objects over and over.

In many cases, workstations will have cached the IP addresses of domain controllers and global catalog servers. Even so, items in the DNS cache do eventually expire and will need to be refreshed. You will most likely start noticing logon problems when cached host records begin to expire.

The other thing that you need to know about DNS server failures is that often times there are plenty of other symptoms besides logon failures. Unless machines on your network are configured to use a secondary DNS server in the event that the primary DNS server fails, the entire Active Directory environment will eventually come to a grinding halt. Although there are exceptions, generally speaking, the absence of a DNS server on an Active Directory network basically amounts to a total communications breakdown.

Conclusion

Although I have discussed some of the major causes of logon failures on Active Directory networks, an important part of the troubleshooting process is to look at how widespread the problem is. For example, if only a single host on a large network is having logon problems, then you can probably rule out DNS or global catalog failures. If a DNS or a global catalog failure were to blame, then the problem would most likely be much more wide spread. If the problem is isolated to a single machine, then the problem is most likely related to the machine’s configuration, connectivity, or to the user’s account.

Data Collected from Web http://www.windowsnetworking.com/

If you use DHCP servers to automatically configure the TCP/IP settings for workstations in your organization, a DHCP failure can lead to a major disruption in service. After all, if a workstation is not able to acquire an IP address, then it will have no way of accessing any of the resources on your private network or on the Internet. In this article, I will discuss some techniques that you can use to troubleshoot DHCP server failures.

Inappropriate Address Assignment

One very common DHCP related issue is the assignment of an unexpected IP address. For example, suppose that your DHCP server was configured with an IP address scope of 192.168.0.1 to 192.1680.50. You would expect network hosts to be assigned IP addresses in this range. Now, suppose that a workstation on your network appeared to be having problems communicating with network servers. You issue an IPCONFIG /ALL command to view the workstation’s IP address configuration. Instead of the expected address range, the workstation has been assigned an address beginning with 169.254.

So what happened? If a host on your network is unexpectedly assigned an address beginning with 169.254, you can rest assured that the address was not assigned by your DHCP server. What actually has happened, is that the workstation has failed to contact a DHCP server. When this occurs, the workstation will assign itself an IP address using a Windows feature known as Automatic Private IP Addressing (APIPA).

Microsoft built Automatic Private IP Addressing into Windows as a way of helping those who have very small networks. For example, if you were to create a small Windows network, you would not have to manually configure IP addresses even if there were no DHCP server on the network. APIPA would automatically assign a unique class B IP address to each machine on the network. This is great for small home networks but completely inappropriate for larger networks.

If a workstation resorts to using an APIPA assigned address, it is because its requests for an IP address have gone unanswered. There are several possible causes for this problem. Assuming that the other computers on the network are able to acquire an IP address from your DHCP server, you can rule out the DHCP server as the cause of the problem.

More than likely, the issue is related to the networking hardware installed in the workstation that is having the problem. For example, the Network Interface Card might be assigned an incorrect driver. Another possible cause of the problem is that the patch cable is not plugged into the Network Interface Card, or is not connected to a switch on the other end.

Of course, just because only one computer on the network is having trouble obtaining an IP address doesn’t completely rule out the server as the cause of the problem. If other workstations are successfully obtaining IP addresses, then you can be sure that the server is working properly. However, it could be that the server has run out of IP addresses that it can assign to clients. You can easily tell if this is the problem by comparing the size of the DHCP address scope to the number of devices on your network that request IP addresses from the DHCP server.

Common DHCP Server Problems

If multiple workstations are experiencing problems with leasing IP addresses, then the problem is most likely related to the DHCP server itself. If you suspect that the DHCP server is the cause of the problem, then you might start off by doing some ping tests to verify that the DHCP server is able to communicate across the network.

If the DHCP server is able to communicate with other computers on the network, then I recommend verifying that the DHCP server has an IP address that is compatible with the scope that the server is configured to assign addresses from. For example, if the DHCP server’s scope consists of addresses from 192.168.0.1 to 192.168.0.50, then the server will not actually be able to assign those addresses unless the server itself has been assigned a static address in the same subnet range, such as 192.168.0.0 or 192.168.0.51.

If this still doesn’t solve the problem, then I recommend checking the basics. For example, you should make sure that the DHCP server is still authorized by the Active Directory to lease IP addresses. You should also check to verify that the scope is active, and that the necessary services are running on the DHCP server.

IP Address Conflicts

Another problem that I have seen on occasions involves IP address conflicts among dynamically configured addresses. When you create a DHCP scope, it is the DHCP server’s responsibility to make sure that addresses within the scope are only leased to one client at a time. If that’s the case, then how is it possible to have an IP address conflict for dynamically assigned addresses?

There are two situations that I’ve run into that can cause this problem. The first time that I ever ran into this problem, I was able to determine which PCs had been assigned at the duplicate addresses. When I checked the TCP/IP configuration on those machines, I found that one of the machine’s IP addresses had been manually configured. It’s kind of a long story, but that machine’s user was running an unauthorized application that required a static IP address. The user got tired of having to reconfigure the application every time they used it, so they took the address that had been dynamically assigned to them, and entered it as a static address.

The likelihood of this happening today is fairly slim. When a particular situation occurred, Windows 98 was the current operating system. Windows 98 lacks many of the security features that we take for granted today. A properly secured workstation running Windows XP or Windows Vista should be resistant to end user reconfigurations. Even so, I wanted to at least mention this issue because it gives you something to look for if you have trouble solving the problem.

A much more common cause of this problem is that multiple DHCP servers are in use, and those DHCP servers have overlapping scopes. If you only have a single DHCP server on your network, do not make the mistake of immediately dismissing this idea as a possible cause of your problem. In all likelihood, there is probably a rogue DHCP server that is conflicting with your primary DHCP server.

Windows 2000 Server and Windows Server 2003 are both designed in such a way to prevent rogue DHCP servers from causing problems. A DHCP server can only issue IP addresses after it has been authorized by the Active Directory. The problem is that this only applies to Windows-based DHCP servers. DHCP servers running other operating systems are free to lease IP addresses to clients without having to be authorized by the Active Directory.

So has a user really gone through the trouble of installing a rogue, Linux based DHCP server? Probably not. A much more likely explanation is that a wireless access point, or a router intended for cable or DSL Internet connections is causing your problem. Such devices almost always have DHCP server’s built in. These devices typically use a scope range of 192.168.0.x or 192.168.1.x. If this happens to be the same IP address scope that your primary DHCP server uses, then you may run into a situation in which both DHCP servers are issuing addresses from the same address pool.

Conclusion

In this article, I’ve explained that there are a number of potential causes for DHCP failures. In most cases, these failures are related to simple communications problems between the DHCP server and the workstations that are trying to lease addresses.

Data Collected from Web http://www.windowsnetworking.com/