Join and Authentication Issues

Previous Topic Next Topic

Join and Authentication Issues

If you can't join a computer to an Active Directory domain, or if a computer can't communicate with any other computer in the network, the situation might be the result of join and authentication problems.

This section discusses diagnostic tools and gives examples of possible authentication problems, along with suggested solutions. The first step toward identifying and diagnosing Active Directory join and authentication problems is to review how a Windows 2000–based computer joins a domain, what permissions are required by a user, and how a secure channel is established.

Joining a Computer to a Domain

To review, when you join either a Windows NT 4.0–based or a Windows 2000–based client to a domain, the following occurs:


note-icon

Note

For a Windows 2000–based client only, the LSA policy consists of the domain name, domain SID, DNS domain name, DNS forest name, and domain GUID.

Changes Occurring on Domain Controllers in the Domain That the Client is Joining

When a client joins a domain, the following changes occur on Windows NT 4.0–based and Windows 2000–based domain controllers:

Identifying Whether You Have a Problem Authenticating

You can identify whether you have a problem authenticating (or joining) a computer to a domain by verifying that the local workstation is working. Do this by running the Netdiag tool. Read the output from the top, and look for the words "ERROR" or "FATAL." (Many failures are not relevant to the domain itself; but you should follow up on them because they involve network connectivity issues.) If you don't find these words in the output, continue as follows:


note-icon

Note

If the local workstation is functional, examine the Netsetup.log file that is located in the %SystemRoot%\debug folder. (This is where the join process is logged.) Are any specific error messages logged?

Format of Netsetup.log File

A typical line in Netsetup.log is formatted as follows:

<time-stamp> <function-name>: <description of operation>: <status code in hexadecimal code>.

An example is the following:

08/11 14:08:29 NetpJoinDomain: status of connecting to dc '\\DC9': 0x0


The description of the join operation is usually self-explanatory. The status code is NET API_STATUS or a Win32 error code. A "0x0" code indicates success; any other code indicates an error.

Specific Join Issues

You might encounter problems when you join your computer to a domain. Even though these problems are reported as join problems, some of the most frequently reported ones are not related to the join process. Looking at the Netsetup.log is sufficient to quickly spot such cases.

The following are some of the most common errors that relate to join issues:

The error code shown in Table 10.6 comes under this category.

Table 10.6 "Failure to find a domain controller" Error Code

Description Actual Error Error Code
Failure to find or connect to a domain controller. ERROR NO SUCH DOMAIN 1355

The following is an example of this error:

07/20 16:51:10 NetpDsGetDcName: trying to find DC in domain 'verylongdomain1', flags: 0x1020

07/20 16:51:11 NetpDsGetDcName: failed to find a DC having account 'A-USHAS2-80C$': 0x525

07/20 16:51:11 NetpDsGetDcName: failed to find a DC in the specified domain: 0x54b

07/20 16:51:11 NetpDoDomainJoin: status: 0x54b


The join process usually tries to find a domain controller that already has a computer account for the computer that is currently being joined to the domain. If such a domain controller is not found, it tries to find another domain controller. The preceding example shows that the join domain operation failed because a domain controller was not located for the specified domain.

To investigate further, run nltest /dsgetdc:<domain-name> and examine the output. If you still receive errors, either the domain really does not exist or there is a transient net error that is preventing domain controller discovery. By running Netdiag.exe and examining the output, you usually can determine the cause. A "Failure to connect to a domain controller" message usually means that transient net errors or insufficient credentials are the cause. Table 10.7 shows some error codes that come under this category.

Table 10.7 "Failure to connect to a domain controller" Error Codes

Description Actual Error Error Code
Bad credentials. ERROR_LOGON_FAILURE 1326
Time skew that can cause failure of Kerberos authentication. ERROR_TIME_SKEW 1398
Failure to connect to a domain controller. ERROR_ACESS_DENIED 5
No domain controller found. ERROR_NO_LOGON_SERVERS 1311

The following is an example of this type of error code:

07/20 14:47:34 NetpDsGetDcName: trying to find DC in domain 'reskit', flags: 0x1020

07/20 14:47:50 NetpDsGetDcName: failed to find a DC having account 'TO_A$': 0x525

07/20 14:47:50 NetpDsGetDcName: found DC '\\reskit' in the specified domain

07/20 14:47:50 NetUseAdd to \\reskit\IPC$ returned 1326

07/20 14:47:50 NetpJoinDomain: status of connecting to dc '\\reskit: 0x52e

07/20 14:47:50 NetpDoDomainJoin: status: 0x52e


The previous example shows a failed attempt to find a domain controller having the account "TO_A$". This is not a fatal error because the code then tries to find any domain controller in the specified domain. After a domain controller is found, an attempt is made to connect to it by using the credentials that are supplied. This attempt failed with error 0x52e (ERROR_LOGON_FAILURE). This indicates that the credentials that were supplied do not have sufficient access rights for connecting to the domain controller.

To investigate the problem of failing to find a domain controller, run an equivalent command from the command prompt to confirm the preceding analysis.

net use \\dcname\ipc$ /u:<domain\user> <password>


note-icon

Note

You need to perform the net use if you failed to connect to the domain controller. If you failed to find the domain controller, you should perform nltest /dsgetdc: to try to locate the domain controller.

If this fails with the same error, a Network Monitor sniffer trace of the join operation would be helpful in diagnosing the failure.

If you receive the error "Failure to create a computer account," it usually means that either the account already exists or that there are insufficient access rights available to the user who is trying to join. Table 10.8 shows the error codes that come under this category.

Table 10.8 "Failure to create a computer account" Error Codes

Description Actual Error Error Code
Computer account usually exists already, and security on that account does not allow you to join — usually because the computer was joined previously by using different computer account credentials. ERROR_ACCESS_DENIED 5
The user has joined so many computers that he has exceeded the default per user computer quota (by default, 10). ERROR_DS_MACHINE_ACCOUNT_QUOTA_EXCEEDED 8557
The specified user already exists. ERROR_USER_EXISTS 2224

The following example indicates an access denied error.

08/11 14:08:30 NetpManageMachineAccountWithSid: NetUserAdd on '\\DC9' for 'A-ERINCO-TBCB$' failed: 0x5


The following example indicates there is no error.

08/11 14:08:30 NetpManageMachineAccountWithSid: NetUserAdd on '\\DC9' for 'A-ERINCO-TBCB$' failed: 0x8b0

08/11 14:08:30 NetpManageMachineAccountWithSid: status of attempting to set password on '\\DC9' for 'A-ERINCO-TBCB$': 0x0


This is not an error because the NetUserAdd operation fails with 0x8b0 (NERR_UserExists), which indicates that the computer account already exists on that domain controller.


note-icon

Note

Failure usually occurs when the account already exists. Error 5 occurs if the user does not have access on the account, in which case an attempt is made to set a new password on the account that succeeds.

To investigate further, you have to acquire the security descriptor and view the permissions on the computer account object. You can use either the Active Directory User and Computers MMC console or the Ldp tool.

For more information about how to view permissions and access control entries on specific objects with the Active Directory User and Computers console, see Windows 2000 Server Help. For more information about access control entries and security descriptors, see "Access Control" in this book.

To investigate further, connect to the domain controller by using the Ldp tool. Acquire the security descriptor on the computer account and determine whether the user trying to join has sufficient permissions to gain access to the computer account.

To use Ldp to acquire the security descriptor

  1. From the Start menu, click Run, and then type the following:

    ldp

  2. Connect and bind to a domain controller in the domain whose security descriptor you are searching for.
  3. On the Browse menu, point to Security, and click Security Descriptor.
  4. Provide distinguished name of the computer object whose security descriptor you are looking for.

Here is a sample output:

Revision:   1

Sbz1:       0

Control:    (0x8c04)

    SE_DACL_PRESENT

    SE_DACL_AUTO_INHERITED

    SE_SACL_AUTO_INHERITED

    SE_SELF_RELATIVE

Owner:

            S-1-0x000005--0x20-0x220

            BUILTIN\Administrators

Group:

            S-1-0x000005--0x20-0x220

            BUILTIN\Administrators

Dacl:

    Revision:   4

    Sbz1:       0

    Size:       972

    No of Aces: 24

    Sbz2:       0

    Ace[0]:

        Type: (0)

            ACCESS_ALLOWED_ACE_TYPE

        AceSize: 0x24

        AceFlags: (0x0)

        Mask: 0x000f01ff

        Sid:

            S-1-0x000005--0x15-0x3bdcf4dc-0x64495118-0x500cebdb-0x200

            DDS\Domain Admins

Ace[1]:

        Type: (5)

            ACCESS_ALLOWED_OBJECT_ACE_TYPE

        AceSize: 0x28

        AceFlags: (0x0)

        Mask: 0x00000010

        Flags: 0x1

        ACE_OBJECT_TYPE_PRESENT

        Object Type:

            (in HEX)(59ba2f42-79a2-11d0-90-20-00-c0-4f-c2-d3-cf)


            GUID_PS_GENERAL_INFO


       Sid:

            S-1-0x000005--0xb

            NT AUTHORITY\Authenticated Users


For more information about interpreting mask, ACE types and flags, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Follow the links to ntsam.h.

The following example shows a successful attempt to join a computer to a domain in the Netsetup.log file:

NETSETUP.log file

07/30 13:58:35 NetpDoDomainJoin

07/30 13:58:35 NetpMachineValidToJoin: 'USER1'

07/30 13:58:35 NetpGetLsaPrimaryDomain: status: 0x0

07/30 13:58:35 NetpMachineValidToJoin: status: 0x0

07/30 13:58:35 NetpJoinDomain

07/30 13:58:35 Machine: USER1

07/30 13:58:35 Domain: RESKIT

07/30 13:58:35 MachineAccountOU: (NULL)

07/30 13:58:35 Account: RESKIT\reskit

07/30 13:58:35 Options: 0x40001

07/30 13:58:35 OS Version: 5.0

07/30 13:58:35 Build number: 2089

07/30 13:58:35 NetpCheckDomainNameIsValid [ Exists ] for 'RESKIT' returned 0x0

07/30 13:58:35 NetpValidateName: name 'RESKIT' is valid for type 3

07/30 13:58:35 NetpDsGetDcName: trying to find DC in domain 'RESKIT', flags: 0x1020

07/30 13:58:50 NetpDsGetDcName: failed to find a DC having account 'USER1$': 0x525

07/30 13:58:50 NetpDsGetDcName: found DC '\\RESKIT-DC-08' in the specified domain

07/30 13:58:51 NetpJoinDomain: status of connecting to dc '\\RESKIT-DC-08': 0x0

07/30 13:58:51 NetpGetLsaPrimaryDomain: status: 0x0

07/30 13:58:51 NetpLsaOpenSecret: status: 0xc0000034

07/30 13:58:52 NetpJoinDomain: status of setting machine password: 0x0

07/30 13:58:52 NetpJoinDomain: status of setting netlogon cache: 0x0

07/30 13:58:52 NetpGetLsaPrimaryDomain: status: 0x0

07/30 13:58:52 NetpSetLsaPrimaryDomain: for 'RESKIT' status: 0x0

07/30 13:58:52 NetpJoinDomain: status of setting LSA pri. domain: 0x0

07/30 13:58:53 NetpJoinDomain: status of managing local groups: 0x0

07/30 13:58:54 NetpJoinDomain: status of starting Netlogon: 0x0

07/30 20:58:55 NetpJoinDomain: status of setting ComputerNamePhysicalDnsDomain 'reskit.reskit.com': 0x0

07/30 20:58:55 NetpDsSetSPN: Setting DnsHostName 'USER1.reskit.reskit.com' on 'CN=USER1,CN=Computers,DC=reskit,DC=microsoft,DC=com'

07/30 20:58:55 NetpDsSetSPN: Setting SPN 'HOST/USER1.reskit.reskit.com' on 'CN=USER1,CN=Computers,DC=reskit,DC=microsoft,DC=com'

07/30 20:58:55 NetpJoinDomain: status of disconnecting from '\\RESKIT-DC-08': 0x0

07/30 20:58:55 NetpDoDomainJoin: status: 0x0


Permissions on Computer Account Objects

This section describes the security on domain computer accounts before and after an upgrade to Windows 2000 Server. This information can be used in troubleshooting permissions on computer account objects in Active Directory and in determining which user created the computer account before the upgrade.

The Discretionary ACL (DACL) contains access control entries (ACEs) that define permissions on a specific object. In Windows NT 4.0, when a computer account is created, the Domain Administrators local group becomes the owner of the computer account. The user who created the computer account is stored as part of its data, and the DACL on the computer account includes limited rights for the user (such as deleting the account).

When you upgrade a Windows 2000–based server, the following changes occur on each computer account:


note-icon

Note

Note that other ACEs can be present if users or groups are added or if permissions are changed on parent containers in Active Directory, which results in additional inherited permissions.


note-icon

Note

If the account is created by using the privilege add workstations to the domain, then the rights of the Creator Owner are limited. Specifically, the Creator Owner is not allowed to change the DACL nor to delete the account. In addition, a quota check limits the number of objects that can be created by the person who is using the quota.

For more information about Default DACLs, see "Access Control" in this book.

Secure Channel Issues

For each Windows 2000–based client or server that is a member of a domain, there is a discrete communication channel, known as the secure channel. This secure channel is used by the Net Logon service on the client and on the domain controller to communicate with each other. The Netdom tool is used to reset the secure channel. If the computer account's password and the local password are not synchronized, the Net Logon service logs one or both of the following errors messages:

The session setup from the computer DOMAINMEMBER failed to authenticate. The name of the account referenced in the security database is DOMAINMEMBER$.

 The following error occurred: Access is denied.

   NETLOGON Event ID 3210:

   Failed to authenticate with \\DOMAINDC, a Windows NT domain controller for domain DOMAIN.


The Net Logon service on the domain controller logs the following error message when the password is not synchronized:

NETLOGON Event 5722:

   The session setup from the computer %1 failed to authenticate. The name of the account referenced in the security database is %2. The following error  occurred: %n%3


Resetting Secure Channels and Computer Accounts

The following tools are available to reset the secure channel and the computer account:

Using Netdom to Reset the Secure Channel

By using the Netdom.exe command-line tool, which is provided in the Windows 2000 Resource Kit, you can reset the secure channel between the domain's member workstation and the domain controller. For example, suppose you have a domain member named DOMAINMEMBER. You can reset the member's secure channel by running the following command:

netdom reset member /domain:domain


You can run this command on the member DOMAINMEMBER. To run this command on any other member or domain controller in the domain, you must provide an account that has administrator access to DOMAINMEMBER.

For example:

Netdom reset member /domain:domain /usero:member-admin /passwordo:member-pw


Adding a Workstation or Member Server to a Domain

To add a workstation or member server to a domain, do the following:

  1. Add the workstation Work1 to the Windows NT 4.0 domain Domain1.
  2. Netdom add /d:domain1 work1/ ud:domain1\admin /pd:password.
  3. Add the workstation Work1 to the Windows 2000 domain reskit.com in the organizational unit my-computer, as shown here:

Netdom add /work1 /d:reskit.com /OU:OU=my-computers,DC=reskit,DC=com



note-icon

Note

The /OU parameter requires a complete distinguished name as specified by RFC 1779. If the /OU parameter is not specified, the computer account is created in the Computers container.

Joining a Workstation or Member Server to a Domain

To join a workstation or member server to a domain, you can use the Netdom tool. For example, to join a workstation called Work1 to the reskit.com domain in the my-computers organizational unit, carry out the following:

Netdom join /d:reskit.com /OU:OU=my-computers,DC=reskit,DC=com /reboot:120.


In addition to adding the computer account to the domain, the workstation is modified to contain the appropriate shared secret to complete the Join procedure. If the Join procedure can be completed, the /reboot switch causes the computer to be automatically shut down and restarted after giving the user two minutes to save work in progress.

Using Nltest to Reset the Computer Secure Channel

By using the Nltest.exe command-line tool, you can reset secure channels that computers have with domain controllers in their domains. Nltest.exe can be used to test the trust relationship between a computer that is running Windows 2000 and is a member of a domain and a domain controller on which its computer account resides, as shown in the following example:

C:\Ntreskit\Nltest.exe


   Usage: nltest [/OPTIONS]


   /SC_QUERY:<DomainName> - Query secure channel for <domain> on

   <ServerName>


   /SERVER:<ServerName>


   /SC_RESET:<DomainName> - Renegotiates the secure channel in the specified domain for a local or remote workstation, server, or domain controller


An example to reset the secure channel:


nltest /sc_query:reskit /server:Server22

Flags: 30

Connection Status = 0 0x0 NERR_Success

Trusted DC Name \\Server1.reskit.com

Trusted DC Connection Status Status = 0 0x0 NERR_Success

The command completed successfully



nltest /sc_reset:reskit /server:Server2

Flags: 30

Connection Status = 0 0x0 NERR_Success

Flags: 30 HAS_IP HAS_TIMESERV

   Trusted DC Name \\server.reskit.com

   Trusted DC Connection Status Status = 0 0x0 NERR_Success

   The command completed successfully


Using the Active Directory Users and Computers Console to Reset Computer Account Passwords

By using Windows 2000, you can also reset the computer account password in the Active Directory Users and Computers console. Right-click the computer object in the Computers folder or other appropriate container, and then click Reset Account. The Reset Account context menu resets the computer account password back to a starting password. This is used only if the computer has been taken offline and been completely reinstalled. Resetting the account password allows the (rebuilt) computer to rejoin the domain using the same name. If this command is carried out when the computer has not been reinstalled, the computer cannot authenticate in the domain.


note-icon

Note

Resetting the password for domain controllers by using this method is not allowed.

Using Nltest to View Trusted Domains

Different data about the trust relationship is kept in several key attributes of each trustedDomain object. The following are the key attributes:

flatName. Contains the NetBIOS name of the domain for this trust relationship.

trustDirection. Contains the direction of the established trust relationship:

trustPartner. Contains a string that represents the DNS-style name of the domain if it is a Windows 2000 domain or the NetBIOS name of the domain if it is trust relationship between a Windows 2000 domain and a non-Windows 2000 domain.

trustType. Contains the type of trust relationship that has been established to the domain.

By using the Nltest command-line tool, you can display the current list of trusted domains known by a specified server. Nltest.exe is available with Windows 2000 Server Support Tools. (To use Nltest, install the tools that are located in the Support\Tools folder on the Windows 2000 Server operating system CD. To install the tools, double-click the Setup icon in that folder. For more information about using Nltest, see Windows 2000 Support Tools Help.)

Use the /domains_trusts option to list the domains that have trust relationships with the current domain. For each domain listed in the results, the following data is displayed:

For example, the following Nltest command is executed on a computer that is a member of the noam.reskit.com domain returns.

D:\>nltest /domain_trusts

List of domain trusts:

    0: RESKIT reskit.com (NT 5) (Forest Tree Root) (Direct Outbound) (Direct Inbound) ( Attr: 0x400000 )

    1: AVIONICS avionics.reskit.com (NT 5) (Forest: 0)

    2: EUROPE europe.reskit.com (NT 5) (Forest: 0)

    3: NOAM noam.reskit.com (NT 5) (Forest: 0) (Primary Domain) (Native)

The command completed successfully


This output indicates the following:

To run a query on a specific server, type nltest /server:<servername>domain trusts. For example, the "domain that is trusted" list might be displayed if a query is run on a domain controller in the root domain of the forest. (This example shows root.com as the root domain.)

   0: TESTDOMAIN testdomain.root.com (NT 5) (Forest: 3) (Direct Outbound)

   1: CHILD child.root.com (NT 5) (Forest: 3) (Direct Outbound)

   2: GRANDCHILD grandchild.child.root.com (NT 5) (Forest: 1)

   3: ROOT root.com (NT 5) (Forest Tree Root) (Primary Domain)

   4: NT4DOMAIN (NT 4) (Direct Outbound)

   5: NEWROOT newroot.com (NT 5) (Forest Tree Root) (Direct Outbound) ( Attr:

   0x800000 )



note-icon

Note

Note that Nltest shows trusted domains with transitive trust relationships as Windows 2000 trust relationships without the Direct Outbound tag.

Another way to view domains and trust relationships is by using ADSI Edit.

To view trusted domains and trust relationship properties by using ADSI Edit

  1. In ADSI Edit, expand the domain directory partition node and navigate to the System container.
  2. In the console details pane, use the Class column to identify all objects with the type trustedDomain.
  3. To view properties, right-click the trustedDomain object, and then click Properties.
  4. In the Select which properties to view box, click Both to view both optional and mandatory attributes.
  5. In the Select a property to view box, select a property. Its value is displayed in the Value(s) box.

Checking Trust Relationships Authenticated By the Kerberos v5 Protocol

Use the Netdom tool to verify the Kerberos v5 authentication protocol between a client and a target domain. The Netdom tool trust verification option with the /Kerberos switch allows you to obtain a session ticket from the Kerberos authentication service in the target domain. If successful, the conclusion is that Kerberos operations such as Key Distribution Center (KDC) referrals, are operating correctly between the workstation and the target domain. Upon failure, the list of referral tickets currently cached, are displayed..If you do not receive the session ticket, the cause of failure can be determined by tracing the list of referral tickets from the KDCs located on the path toward the target domain.

To verify the Kerberos authentication protocol issue the following command:

NETDOM TRUST <trusting_domain_name> /d: <name of the trusted domain> /Kerberos /UserO:<User account for making the connection with the trusted domain> /PasswordO:<Password of the user account specified by /UserO > /UserD:<User account used to make the connection with the domain specified by the /domain argument > /PasswordD:<trusted_domain_user_password>



note-icon

Note

Both users must be specified because the command will attempt a Kerberos v5 authentication of those users.

The above command will verify the following:

For more information on the Netdom tool, see Windows 2000 Support Tools Help. For more information on Kerberos v5 authentication, see "Authentication" in this book.

Fail Logons in Absence of Global Catalog Servers

For Windows 2000 in native mode a Global Catalog is required for the logon process. If the domain controller cannot contact a Global Catalog server, the user is not be able to log on. An exception is made only for the administrator account in the domain (RID 0x1F4). This account is allowed to log on even without a Global Catalog, so that in an emergency situation a Global Catalog can be configured.

Specifically, group expansion during token creation when the user is logging onto a workstation is as follows:

  1. Add the user's SID in the token.
  2. Add the global groups that the user is part of in the token.
  3. Add the universal groups to which the user's SID and the global groups belong in the token.
  4. Add the domain local groups to which the preceding accounts belong to the token. This step is performed at a domain controller for the domain to which the workstationbelongs.

    Domain local groups are not added to the token, if this domain is in mixed mode.

  5. Add the local and built-in local group memberships for the groups in the workstation of the set computed in steps 1 through 4. If the user is connecting to or logging on to a domain controller, this step addresses only the built-in local groups; if the domain local groups were evaluated in step 4.

© 1985-2000 Microsoft Corporation. All rights reserved.