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:

• The domain name is validated.
• A domain controller in the domain is located through a call to DsGetDcName.
• A session is established with the domain controller under the security context of the passed-in credentials that are supplied in the Network Identification tab under System Properties in Control Panel.
• The computer account is enabled. If the flags are so specified (NETSETUP_ACCT_CREATE), the APIs create the computer account on the domain controller.
• The local password for this account is created in the Local Security Authority (LSA).
• The local primary domain information LSA policy is set to refer to the new domain. This includes the domain name and the domain SID.

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.

• The name of the DNS name assigned to the local computer is updated.
• The local group membership is changed to add members of the Domain Admins group to the Local Accounts Administrators group.
• The Net Logon trusted domain cache is initialized to the trusted domains domain list.
• For Windows 2000–based clients only, the Windows Time Service is enabled and started.
• The Net Logon service is started.

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:

• A computer object is created. The name of this object is generated by appending a dollar sign ($) to the name (uppercase letters) of the client.
• On Windows 2000–based domain controllers only, the Net Logon service creates Service Principle Names (SPNs) on the computer object.

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:

• Run netdiag /v (verbose mode). Do you receive any specific error messages or FATAL errors?
• If the answer to the preceding question is "No," run netdiag /debug. Do you receive any specific error messages or FATAL errors?
• If Netdiag displays an error or failure with the domain itself, check the %SystemRoot%\debug\netsetup.log file for join errors.

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:

• Failure to find or to connect to a domain controller.
• Transient network conditions or having specified an incorrect domain name.
• Failure to create a computer account.

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

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

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

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

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

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

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.
   • To connect, on the Connection menu, click Connect, and then type a server name.
   • To bind, on the Connection menu, click Bind, and then type an account name, password, and domain if you want to connect to a domain other than the domain to which you are currently logged on.
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:

• A computer account object is created in the default Computers container. The original owner (for example, administrator) of the computer account remains the same. The privileges that the original owner had on the computer object in Windows NT 4.0 are retained as part of the upgrade.
• The DACL on the computer account is reset to the default that is defined for objects of the computer class in the schema. This DACL includes an entry for Creator Owner and, when viewed with ACL Editor, displays the name of the appropriate user.

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.

• The following default DACLs apply to new computer accounts:
• Self:
  • Create All Child Objects
  • Delete All Child Objects
• Authenticated Users:
  • Read
  • Read Public Information
• System:
  • (Full Control)
• Creator Owner:
  • (Full Control)
• Domain Administrators:
  • (Full Control)
• Cert Publishers:
  • (no permissions)
• Enterprise Administrators (inherited permissions):
  • Read
  • Write
  • Create All Child Objects
  • Change Password
  • Receive As
  • Reset Password
  • Send As
  • Read Public Information
  • Write Public Information
• Account Operators:
  • (Full Control)
• Print Operators:
  • (no permissions)
• Everyone:
  • Change Password

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:

• Resource Kit tools:
  • Netdom.exe
  • Nltest.exe
• Active Directory Users and Computers console

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

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

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:

• 0=Disabled
• 1=Inbound (Trusting domain)
• 2=Outbound (Trusted domain)
• 3=Both (Trusted and trusting domains)

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.

• 1=A trust relationship between a Windows 2000 domain and a Windows NT 4.0 or earlier domain.
• 2=A Windows 2000 trust relationship.
• 3=A trust relationship between a Windows 2000 domain and a non-Windows Kerberos realm.

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:

• Trust Index (a number that identifies an entry in the enumerated list of trusts).
• NetBIOS domain name of the trusted domain (for example, reskit).
• DNS domain name of the trusted domain (for example, reskit.com).
• Trust type (NT 4 for trust relationship with a Windows NT domain), NT 5 (for a trust relationship with a Windows 2000 domain), or MIT (for a trust relationship with a non-Windows Kerberos realm). For more information about types of trust relationships, see "Active Directory Logical Structure" in this book.
• In addition, the following values are reported where applicable:
  • Forest Tree Root: Identifies the forest root domain.
  • Forest Trust Index: Indicates the domain that is the forest root.
  • Primary Domain: Identifies the domain in which the contacted server is located.
  • Direct Outbound: Identifies the domain as being directly trusted by the primary domain.
  • Direct Inbound: Identifies the domain as directly trusting the primary domain.
  • Attr: Returns the bits specifying the value in the trustAttributes attribute on the trustedDomain object. This value determines, for example, whether the trust relationship is transitive or nontransitive.
  • Native: Identifies a primary domain that is running in native mode. Where no value is displayed for primary domain, the primary domain is running in mixed mode.

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:

• Reskit.com is the forest root domain.
• All of the domains are in the same forest as reskit.com (identified by the index number 0).
• All of the trust relationships are Windows 2000 trust relationships (indicated by "NT 5").
• Noam.reskit.com is the domain of the server that is running Nltest.
• Noam.reskit.com, which is a primary domain, is running in native mode.

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

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

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

The above command will verify the following:

• The trust passwords are correct (for example, determine if the passwords match).
• The users can be located in Active Directory.
• The users can be authenticated through the issuance of Kerberos v5 tickets.

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.