Edit

Share via

Event IDs 5788 and 5789 occur on a Windows-based computer

  • Article

This article provides solutions to an issue where event ID 5788 and event ID 5789 are logged when the DNS domain name and the Active Directory domain name differ on a Windows-based computer.

Original KB number:   258503

Symptoms

You may experience one of the following problems:

  • On Windows Vista and later versions, you receive the following error message during interactive logon:

    The security database on the server does not have a computer account for this workstation trust relationship.

  • Interactive logons with domain-based accounts don't work. Only logons with local accounts are functioning.

  • The following event messages are logged in the System log:

    Event Type: Error
    Event Source: NETLOGON
    Event Category: None
    Event ID: 5788
    Computer: ComputerName
    Description:
    Attempt to update Service Principal Name (SPN) of the computer object in Active Directory failed. The following error occurred: <Detailed error message that varies, depending on the cause.>

    Event Type: Error
    Event Source: NETLOGON
    Event Category: None
    Event ID: 5789
    Computer: Computer
    Description:
    Attempt to update DNS Host Name of the computer object in Active Directory failed. The following error occurred: <Detailed error message that varies, depending on the cause.>

    Note

    Detailed error messages for these events are listed in the "Cause" section.

Cause

This behavior occurs when a computer tries but does not write to the dNSHostName and servicePrincipalName attributes for its computer account in an Active Directory Domain Services (AD DS) domain.

A computer tries to update these attributes if the following conditions are true:

  • Immediately after a Windows-based computer joins a domain, the computer tries to set the dNSHostName and servicePrincipalName attributes for its computer account in the new domain.
  • When the security channel is established on a Windows-based computer that is already a member of an AD DS domain, the computer tries to update the dNSHostName and servicePrincipalName attributes for its computer account in the domain.
  • On a Windows-based domain controller, the Netlogon service tries to update the servicePrincipalName attribute every 22 minutes.

There are two possible causes of the update failures:

  • The computer does not have sufficient permission to complete an LDAP modify request of the dNSHostName or servicePrincipalName attributes for its computer account.

    In this case, the error messages that correspond to the events that are described in the "Symptoms" section are as follows:

    • Event 5788

      Access is denied.

    • Event 5789

      The system cannot find the file specified.

  • The primary DNS suffix of the computer does not match the DNS name of the AD DS domain of which the computer is a member. This configuration is known as a "Disjoint namespace."

    For example, the computer is a member of the Active Directory domain contoso.com. However, its DNS FQDN name is member1.nyc.contoso.com. Therefore, the primary DNS suffix does not match the Active Directory domain name.

    The update is blocked in this configuration because the prerequisite write validation of the attribute values fails. The write validation fails because, by default, the Security Accounts Manager (SAM) requires that a computer's primary DNS suffix matches the DNS name of the AD DS domain of which computer is a member.

    In this case, the error messages that correspond to the events that are described in the "Symptoms" section are as follows:

    • Event 5788

      The attribute syntax specified to the directory service is invalid.

    • Event 5789

      The parameter is incorrect.

Resolution

To resolve this problem, find the most likely cause as described in the "Cause" section. Then, use the resolution that is appropriate for the cause.

Resolution for Cause 1

To resolve this issue, you must make sure that the computer account has sufficient permissions to update its own computer object.

In the ACL Editor, make sure that there is an access control entry (ACE) for the trustee account "SELF" and that it has "Allow" access for the following extended rights:

  • Validated write to DNS host name
  • Validated write to service principal name

Then, verify any Deny permissions that may apply. Excluding the group memberships of the computer, the following trustees also apply to the computer:

  • Everyone
  • Authenticated Users
  • SELF

The ACEs that apply to these trustees may also deny access to write to attributes, or they may deny the "Validated write to DNS host name" or "Validated write to service principal name" extended rights.

Resolution for Cause 2

To resolve this issue, use one of the following methods, as appropriate:

Method 1: Correct an unintentional disjoint namespace

If the disjoint configuration is unintentional, and if you want to revert to a contiguous namespace, use this method.

For more information about how to revert to a contiguous namespace on Windows Server 2003, see the following Microsoft TechNet article:
Transition from a Disjoint Namespace to a Contiguous Namespace
For Windows Server 2008 and for Windows Vista and later versions, see the following Microsoft TechNet article:
Reverse an Accidentally Created Disjoint Namespace

Method 2: Verify that the disjoint namespace configuration is working correctly

Use this method, if you want to keep the disjoint namespace. To do this, follow these steps to make some configuration changes to resolve the errors.

For more information about how to verify that the disjoint namespace is working correctly on Windows Server 2003 R2, Windows Server 2003, Windows Server 2003 with Service Pack 1 (SP1), and Windows Server 2003 with Service Pack 2 (SP2), see the following Microsoft TechNet article: Create a Disjoint Namespace
For more information about how to verify that the disjoint namespace is working correctly on Windows Server 2008 R2 and Windows Server 2008, see the following Microsoft TechNet article: Create a Disjoint Namespace

By extending the example that is mentioned in the last major bullet point in the "Cause" section, you would add nyc.contoso.com as an allowed suffix to the attribute.

More information

Older versions of this article mentioned changing the permissions on the computer objects to enable general write access to resolve this problem. This was the only approach that existed in Windows 2000. However, it is less secure than using msDS-AllowedDNSSuffixes.

msDS-AllowedDNSSuffixes restrict the client from writing arbitrary SPNs into Active Directory. The "Windows 2000 method" enables the client to write SPNs that block Kerberos from working with other important servers (create duplicates). When you use msDS-AllowedDNSSuffixes, SPN collisions such as those can occur only when the other server has the same host name as the local computer.

A network trace of the response to the LDAP modify request displays the following information:
win: 17368, src: 389 dst: 1044

LDAP: ProtocolOp: ModifyResponse (7)

LDAP: MessageID

LDAP: ProtocolOp = ModifyResponse

LDAP: Result Code = Constraint Violation

LDAP: Error Message = 0000200B: AtrErr: DSID-03151E6D In this network trace, 200B hexadecimal is equal to 8203 decimal.

The net helpmsg 8203 command returns the following information: The attribute syntax specified to the directory service is invalid." Network Monitor 5.00.943 displays the following result code: "Constraint Violation." Winldap.h maps error 13 to "LDAP_CONSTRAINT_VIOLATION.

The DNS domain name and the Active Directory domain name can differ if one or more of the following conditions are true:

  • The TCP/IP DNS configuration contains a DNS domain that differs from the Active Directory domain of which the computer is a member, and the Change primary DNS suffix when domain membership changes option is disabled. To view this option, right-click My Computer, click Properties, and then click the Network Identification tab.

  • Windows Server 2003-based or Windows XP Professional-based computers may apply a Group Policy setting that sets the primary suffix to a value that differs from the Active Directory domain. The Group Policy setting is as follows: Computer Configuration\Administrative Templates\Network\DNS Client: Primary DNS Suffix

  • The domain controller is located in a domain that was renamed by the Rendom.exe utility. However, the administrator did yet change the DNS suffix from the previous DNS domain name. The domain rename process does not update the primary DNS suffix to match the current DNS domain name following renames of DNS domain names. Domains in an Active Directory forest that do not have the same hierarchical domain name are in a different domain tree. When different domain trees are in a forest, the root domains are not contiguous. However, this configuration does not create a disjoint DNS namespace. You have multiple DNS or even Active Directory DNS root domains. A disjoint namespace is characterized by a difference between the primary DNS suffix and the Active Directory domain name of which the computer is a member.

Disjoint namespace can be used with caution in some scenarios. However, it is not supported in all scenarios.