Troubleshooting Logon Failures In Active Directory Environments

 Log in to the computer is a routine part of the day that is easy to not think about the login process. However, things can and sometimes go wrong when users log on to Windows. In this article, I will talk about some of the things that can cause logon failures, and show you how to get around the problem.

Troubleshooting Logon Failures in Active Directory

Before I begin, I just want to quickly mention that in order to provide as much useful information as possible, I would avoid talking about the most obvious cause of the logon failure. This article assumes that before you begin the process of solving a problem, you've checked to make sure that the user enters the correct password, the user's password has not expired, and that there is no basic communication problems between the workstation and the domain controller.

It may seem strange, but true workstation at logon failure may be the cause. If the clock more than five minutes different from the time on your domain controller, 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. Workstation then sends a Kerberos Authentication Server to Server Request Distribution Key. This Kerberos Authentication Server Request contains several different pieces of information, including:• Identify users• The name of the service that the user requested (in this case the ticket Acquiring Services)• An authenticator encrypted with the user's master key. This user's master key to encrypt user passwords obtained by using one-way function. 

When the Key Distribution Server receives the request, looks Active Directory user account. It then calculates the user's master key and uses it to decrypt the authenticator (also known as pre-authentication data).When a workstation user created authenticator, it puts the time stamp in an encrypted file. Once the Key Distribution Server decrypts files, it compares the timestamp to the current time on the clock itself. If the time stamp and the current time is within five minutes of each other, then the Kerberos Authentication Server Request assumed to apply, and the authentication process continues. If the time stamp and the current time is more than five minutes, then Kerberos assumes that the request is a replay of previously captured packet, and therefore rejected the logon request. When this occurs, the following message appears:The system can not log on due to the following error: There is a time difference between the client and the server. Please try again or consult your system administrator.The solution to this problem is simple, just set the clock to match the workstation controller clock domain.
The main cause of the problem is the failure of logon global catalog server. A global catalog server is a domain controller that has been configured to act as a global catalog server. Global catalog server contains a searchable representation of every object in every domain of the entire forest.When the forest was originally created, the first domain controller that you bring it online 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 controller to act as a global catalog server. If the global catalog server fails, then the only domain administrators will be able to log into Active Directory.Given the importance of a global catalog server, you must work to prevent the failure of a global catalog server. Luckily, you can assign any or all of your domain controllers to act as a global catalog server. Keep in mind though that you only have to configure all of your domain controllers to act as a global catalog server if the forest is made up of a single domain. Have some global catalog server is a good idea even for forests with multiple domains, but figuring out which domain controller to act as a global catalog server is something of an art form.If your global catalog server has failed, and nobody can get in, then the best thing you can do is to work to restore the global catalog server to a functional state. There is a way to allow users to log in even if the global catalog server is down, but there are security risks associated with doing so.If Active Directory is running in native mode, the global catalog server is responsible for checking the user's universal group memberships. If you choose to allow users to log on for the failure, then the universal group membership will not be checked. If you have been assigned to members of the explicit rejection of certain universal, then they will not take effect until the rejection of a global catalog server is brought back online.If you decide that you need to 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. Therefore, I suggest making a full system backup before proceeding.

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.
If you suddenly discover that no user can log into the network, and your domain controllers and global catalog servers seem functional, the DNS server failure may occur. Active Directory is completely dependent on the DNS service.DNS server contains host records for each computer in your network. Computers in your network using host records to resolve computer names to IP addresses. If the DNS server failure occurs, then the host name resolution will fail, ultimately affects the logon process.There are two things you need to know about DNS failure in relation to logon problem solving. First, the logon failure may not happen immediately. The Windows operating system maintains a cache DNS, which includes the results of previous DNS queries. This prevents the workstation cache of DNS servers by flooding name resolution requests for the same thing over and over again.In many cases, the workstation will have cached the IP address of the domain controllers and global catalog servers. However, items in the cache DNS do eventually come to an end and will need to be refreshed. You will most likely begin to see the problem when the logon cache host records start over.Another thing you need to know about the DNS server failure is that often there are many other symptoms besides logon failure. Unless the machine on your network is configured to use a secondary DNS server in case the primary DNS server fails, the entire Active Directory environment will eventually come to a grinding halt. Although there are exceptions, in general, the absence of DNS servers on the network Active Directory basically amounted to a total communication breakdown.
Although I have discussed some of the major causes of failure in the network logon Active Directory, an essential part of the process of solving the problem is to see how widespread the problem is. For example, if only a single host on a large network logon problems, then you may be able to get rid of the DNS or global catalog failure. If DNS or global catalog failure is to blame, then the problem is likely to spread more widely. If the problem is isolated to a single machine, then the problem is most likely related to connectivity, the machine configuration, or the user account.