Troubleshooting "Interactive Logon Isn't Allowed" Error on Windows Server

Table of Contents

This article addresses a specific error encountered on Windows Server Domain Controllers where interactive logon attempts fail. The issue is often accompanied by messages indicating a problem with the computer account’s trust relationship or Kerberos authentication failures. Understanding the root cause and the authentication process is key to resolving this critical problem that prevents administrators from accessing the server interactively.

The problem typically manifests immediately after a server restart. Administrators attempting to log on locally via the console or remotely using Remote Desktop Connection are presented with an error message. This prevents any administrative interaction with the server through standard graphical or console means, severely impacting server availability and manageability. The specific error message seen by the user attempting to log on is quite descriptive: “The security database on the server does not have a computer account for this workstation trust relationship.” While this message points towards an account issue, the underlying cause is more specific to the authentication mechanism.

Further investigation is necessary to diagnose the issue, and this often requires booting the Domain Controller into Directory Services Restore Mode (DSRM). DSRM is a special boot mode that allows administrators to perform maintenance tasks on the Active Directory database, including resetting passwords and troubleshooting replication issues. It is the primary method for accessing a Domain Controller when normal logon fails. Once in DSRM, examining the server’s event logs provides crucial insights into the nature of the logon failure.

The System event log is one of the first places to look. A common event associated with this problem is Event ID 5721 from the NETLOGON source. This event signifies a failure to establish a secure channel (also known as a trust relationship) between the computer and a Domain Controller for its own domain. The message explicitly states that the session setup failed because the target Domain Controller did not have the necessary computer account for the source computer. On a Domain Controller, this indicates an internal issue with its own ability to authenticate itself within the domain.

Another critical event found in the System log is Event ID 3 from the Microsoft-Windows-Security-Kerberos source. This event indicates a Kerberos authentication error. The details within this event are particularly telling, often showing an Error Code of 0x7 (KDC_ERR_S_PRINCIPAL_UNKNOWN) and an Extended Error of 0xc0000035 (KLIN(0)). The KDC_ERR_S_PRINCIPAL_UNKNOWN error means the Key Distribution Center (KDC) could not find the requested service principal. The event data will typically show the Server Name as host/<computername>.<domainname>, pointing directly to a problem with the computer’s own Service Principal Name (SPN).

Beyond the System log, the Security event log captures detailed audit failures. Every failed logon attempt generates Event ID 4625 (Audit Failure). Examining the details of this event for logon type 2 (interactive logon) reveals the subject account attempting the logon and the account it was trying to log on as. Crucially, it includes “Failure Information” with a “Failure Reason” of “An Error occurred during Logon” and a “Status” code, often 0xc000018b. This status code translates to STATUS_NO_LOGON_SERVERS, reinforcing the idea that the system is unable to find a suitable logon server, which, in the case of a DC, means it cannot authenticate itself using Kerberos. The detailed authentication information confirms the logon process (User32) and authentication package (Negotiate, which attempts Kerberos first).

Finally, in some cases, the System event log might also show Event ID 11 from the Microsoft-Windows-Kerberos-Key-Distribution-Center source. This event is a direct warning from the KDC service running on the Domain Controller itself. It reports that the KDC encountered duplicate names while processing a Kerberos authentication request. The message specifically calls out the duplicate name, often the host/<computername>.<domainname> SPN, and warns that this may result in authentication failures or downgrades to NTLM. While the event description mentions NTLM downgrade, the interactive logon issue specifically occurs because newer Windows versions prevent this downgrade for interactive sessions when Kerberos authentication fails in this manner.

The root cause of the “Interactive Logon Isn’t Allowed” error, particularly when accompanied by the described Kerberos and Netlogon events, is a duplicate Service Principal Name (SPN). An SPN is a unique identifier for a service instance that is used by Kerberos authentication to associate a service instance with a service logon account. For a Domain Controller, the HOST/<computername> and HOST/<fully_qualified_domain_name> SPNs are crucial for interactive logons, as the logon process itself uses Kerberos to authenticate the computer account against the domain services running on the DC (which is itself).

When the KDC receives a Kerberos service ticket request for a service identified by an SPN, it looks up that SPN in Active Directory. If it finds the same SPN registered on more than one object (user or computer account), the lookup is ambiguous. Kerberos requires unique SPNs to function correctly. An ambiguous SPN lookup results in a Kerberos authentication failure (KDC_ERR_S_PRINCIPAL_UNKNOWN). This failure prevents the critical Kerberos exchange needed for the DC to establish its secure channel and authenticate interactive logon attempts.

In Windows Vista and later operating systems, including Windows Server 2012 R2 and newer, a security change was introduced that disallows failover from Kerberos to NTLM authentication for interactive logons when the Kerberos authentication fails due to issues like a duplicate SPN. This is a security feature designed to prevent malicious actors from deliberately breaking Kerberos (e.g., by creating duplicate SPNs) to force clients to use the less secure NTLM protocol. While NTLM failover might still occur for network logons (Logon Type 3), it is explicitly blocked for interactive logons (Logon Type 2), leading directly to the “Interactive Logon Isn’t Allowed” error.

The resolution involves identifying and removing the duplicate Service Principal Name (SPN) from the object(s) where it has been incorrectly registered. The duplicate SPN in question is typically the DC’s own HOST SPN. This process must be performed while logged into the Domain Controller in DSRM, as normal logon is not possible. Several tools can be used to find duplicate SPNs in Active Directory, most notably setspn.exe and ldifde.exe.

The setspn.exe command-line tool is part of the Windows Support Tools or Remote Server Administration Tools (RSAT). It is specifically designed for managing SPNs. To find duplicate SPNs across the entire forest, the command setspn -x is invaluable. Running this command will query Active Directory for all registered SPNs and report any instances where the same SPN is registered on more than one object. This is often the quickest way to pinpoint the duplicate. The output will list the duplicate SPN and the distinguished names of the objects it is registered on.

Alternatively, if you suspect the duplicate SPN is related to the affected server’s name, you can use setspn -q <SPN_pattern>. For instance, if the affected DC is named DC01.contoso.com, you might search for related SPNs using setspn -q host/dc01* or setspn -q host/dc01.contoso.com*. This command searches for all SPNs matching the pattern and lists the objects they are associated with. You would then examine the output to see if the crucial HOST/DC01 or HOST/DC01.contoso.com SPNs appear on more than one object.

Another powerful tool is ldifde.exe, which can export Active Directory data to an LDIF file. This tool is useful for performing detailed searches based on LDAP filters. To search for objects containing a specific SPN pattern, you can use a command like:
ldifde.exe -f spn_search.txt -d "<RootDSE>" -l serviceprincipalname -r "(serviceprincipalname=*<SPN_pattern>*)" -p subtree
Replace <RootDSE> with the distinguished name of your domain (e.g., DC=contoso,DC=com). Replace <SPN_pattern> with the relevant part of the SPN, like the computer name (2008r2spn-02 in the example). This command exports all objects within the subtree that have a serviceprincipalname attribute matching the filter to the file spn_search.txt. You can then open the text file and search for the specific duplicate SPN to identify the objects.

Once the duplicate SPN and the objects holding it are identified, the next step is to remove the duplicate SPN from the incorrect object. The SPN should remain on the legitimate Domain Controller object. It is crucial to be careful when removing SPNs. Removing the correct SPN from the correct object will break legitimate services. The duplicate will typically be on a user account, a different computer account, or potentially even a defunct or lingering object.

To remove an SPN using setspn.exe, use the command:
setspn -D <SPN_to_delete> <DistinguishedName_of_object>
For example, if the duplicate SPN HOST/2008r2spn-02.northwindtraders.com is found on a user account named UserA located at CN=UserA,OU=Users,DC=northwindtraders,DC=com, the command would be:
setspn -D HOST/2008r2spn-02.northwindtraders.com CN=UserA,OU=Users,DC=northwindtraders,DC=com
After successfully removing the duplicate SPN, you may need to wait for Active Directory replication to occur (if multiple DCs are involved, although troubleshooting is usually done on the affected DC itself) and potentially restart the NETLOGON service or reboot the server to ensure the change takes effect.

It is important to understand why this issue is handled differently in newer Windows versions compared to Windows Server 2003 or Windows 2000. Older operating systems were more permissive and might allow NTLM failover for interactive logons even if Kerberos failed due to a duplicate SPN. This behavior, while seemingly more resilient in the face of SPN misconfigurations, posed a security risk. An attacker who could create a duplicate SPN might force clients to use the weaker NTLM protocol, making them potentially vulnerable to eavesdropping or relay attacks. By preventing NTLM failover for interactive logons, Windows Vista and later versions prioritize security over backward compatibility in this specific scenario.

Creating or modifying Service Principal Names requires elevated privileges in Active Directory. A standard user cannot simply create an SPN on an object, not even on their own user account or on computer accounts they have added to the domain. Permissions to modify the servicePrincipalName attribute are typically restricted to members of highly privileged groups such as Administrators, Domain Admins, or Enterprise Admins, or specific users or groups who have been explicitly granted the “Write servicePrincipalName” permission on target objects. This means that a duplicate SPN, especially one for a Domain Controller’s HOST service, is usually the result of an action performed by an administrator or a script running with administrative privileges. Common scenarios include manual SPN registration errors, issues during domain migrations, or problems with third-party applications that manage service accounts and their SPNs.

In conclusion, the “Interactive Logon Isn’t Allowed” error on a Windows Server Domain Controller, accompanied by specific NETLOGON 5721, Kerberos 3, Security 4625, and potentially KDC 11 events, is a strong indicator of a duplicate Service Principal Name for the DC’s HOST service. This prevents Kerberos authentication, and newer Windows versions block NTLM failover for interactive logons as a security measure. Resolving the issue requires logging into DSRM, using tools like setspn.exe or ldifde.exe to find the duplicate SPN, and then using setspn -D to remove the duplicate from the incorrect object. This process restores the uniqueness of the SPN, allowing Kerberos authentication and interactive logon to function correctly.

Have you encountered this specific error on your Windows Server Domain Controllers? What tools or methods did you find most effective in identifying and resolving the duplicate SPN? Share your experiences and tips in the comments below.