Cross-forest authentication and site synchronization

This post describes a few scenarios with cross-forest trusts, and in particular the authentication protocols and DC locator processes that can occur with NTLM trusts between 2000 and 2003 forests. The goal of this post is to provide background information on how this works, and how the process can be improved in an enterprise environment with cross-forest site synchronization.

For the information below, the following test network was used:
- resource.local - resource domain - Windows Server 2003 forest, one domain, RL1 site
- user.com - user domain - Windows 2000 Server forest, one domain, UC1 siet
- resource.local trusts user.com, with an external one-way NTLM trust

Protocols In Use

The following authentication protocols are typically used in a Windows 2000 and Windows 2003 domain environment:

• NTLM - Protocol negotiation and authentication typically results in NTLM when accessing cross-forest resources across NTLM trusts. For example, a workstaiton and user in user.com accessing a resource on a member server in resource.local
• Kerberos - An Interactive logon from a trusted 2000 domain to a trusting 2003 domain across forests can still result is cross-forest Kerberos tickets. For example, an account in the trusted 2000 user domain logging on to the trusting resource forest using terminal services results in tickets for both TGT (Ticket Granting Tickets) for the user forest and LDAP tickets for DC access.

Notes:

1. Kerberos is not documented as normal for cross-forest authentication except with Windows Server 2003 cross-forest trusts. Testing shows that interactive logons using cross-forest accounts across NTLM trusts can still use Kerberos.
2. When using NetBIOS names - the method primarily used within NTLM trusts - the NT4 compatible locator is used, making use of transport-specific mechanisms, mailslots and NETLOGON_SAM_LOGON_REQUEST and responses to locate a Domain Controller and authenticate the request.
3. To understand the Domain Controller locator process, it is important to acknowledge that even though the request may be originating from a client in another domain sent directly to a member server in the resource domain, this resource server then becomes the 'client', using Netlogon RPC calls with its local Domain Controller, submitting and/or proxying the request from the workstation
4. Netlogon debugging can aid the diagnosis of issues with logon from the perspective of clients, Domain Controllers, or both. Nltest can be used to set the level of logging, ranging from 0x0 (no logging) to 0xffffffff (full logging). When using full logging, it is possible to see the detailed (unencrypted) NETLOGON_SAM_LOGON_RESPONSE, showing the domain/forest name, the chosen DC, the site of both the DC and the client (if set).

Query for a DC

For example, the following shows the conversation from the Netlogon perspective of a client workstation in the user.com domain and a DC in the resource.local domain when the workstation queries for a Domain Controller:

Workstation in the user domain:

03/20 07:16:27 [MISC] DsGetDcName function called: Dom:resource.local Acct:(null) Flags: FORCE DSP
03/20 07:16:27 [DNS] Cache: RESOURCE resource.local: Found existing domain cache entry
03/20 07:16:27 [MAILSLOT] NetpDcPingListIp: resource.local: Sent UDP ping to 192.168.0.10
03/20 07:16:27 [MAILSLOT] resource.local: Received 'Sam Logon Response Ex' response.
03/20 07:16:27 [DNS] Cache: RESOURCE resource.local: Ditch existing cache entry 1 (Quality: 13)
03/20 07:16:27 [DNS] Cache: RESOURCE resource.local: Add cache entry 1 (Quality: 13)
03/20 07:16:27 [MISC] DsGetDcName function returns 0: Dom:resource.local Acct:(null) Flags: FORCE DSP

Domain Controller in the resource forest - resource.local

03/20 07:16:27 [MAILSLOT] Received ping from WS01 resource.local (null) on UDP LDAP
03/20 07:16:27 [SITE] 192: Lookup: Doing byte
03/20 07:16:27 [SITE] 168: Lookup: Doing byte
03/20 07:16:27 [SITE] 1: Lookup: Doing byte
03/20 07:16:27 [SITE] 50: Lookup: Doing byte
03/20 07:16:27 RESOURCE: NO_CLIENT_SITE: WS01 192.168.1.50
03/20 07:16:27 [MAILSLOT] RESOURCE: Ping response 'Sam Logon Response Ex' (null) to \\WS01 Site: (null) on UDP LDAP

This conversation is summarised as:

1. The client calls DsGetDcName, with a fully qualified domain name (the FORCE and DSP flags signify cached information to be ignored and prefers a 2000 or 2003 DC, respectively).
2. DNS Cache finds a hit for the FQDN resource.local and the NetBIOS equivalent (RESOURCE). Note that the FORCE switch is documented as ignoring the local cache; this does not appear to be happening.
3. The workstation uses an LDAP UDP ping to find a suitable Domain Controller. The first Domain Controller to respond wins (the preferable list has already been filtered by DNS, eg closest site)
4. The old entry is removed from the cache and the new updated.

An equivalent network trace in a virtual testlab shows the following packets - note that a site-specific DC cannot be found in this instance, cross-forest site links are not configured. From a workstation in the user domain, querying for a Domain Controller in the trusting resource domain

nltest /dsgetdc:resource.local /FORCE

No. Source Destination Protocol Info
1 UserDC01 ResourceDC01 DNS Standard query SRV _ldap._tcp.UC1._sites.dc._msdcs
2 ResourceDC01 UserDC01 DNS Standard query response, No such name
3 UserDC01 ResourceDC01 DNS Standard query SRV _ldap._tcp.dc._msdcs
4 ResourceDC01 UserDC01 DNS Standard query response SRV 0 100 389 ResourceDC01
5 WS01 ResourceDC01 CLDAP MsgId=67 Search Request, Base DN=(null)
6 ResourceDC01 WS01 CLDAP MsgId=67 Search Entry, 1 result

The LDAP ping and reply in frames 5 and 6 query for the capabilities of the server to authenticate for the specified domain. The response is in the form of a SamLogon response, containing Domain, DC and site names, used to compare against the information used in the original DsGetDcName call to verify the DC is correct.

Note that this process simply locates a Domain Controller; with subsequent unshown packets authenticating the request.

Cross-forest Resource Access

For cross-domain/forest resource access, a combination of NTLM referral and the 200x/NT4 locator seems to be used in different scenarios. The following is a summary of a network capture when accessing resources on a member server in the resource.local domain with NTLM authentication:

1. Initiate request from client computer directly to member server, negotiating a protocol
2. Member server contacts resource.local Domain Controller to begin a transitive network logon by the user, from the workstation, proxied through the resource server.
3. The DC uses cached information or the NT4 locator process (the domain is specified as a NetBIOS name) and authenticates the request, sending the request to a Domain Controller in the user domain in a SamLogon mailslot request
4. Authentication is now verified, and resource access is then authorised

Cross-forest interactive logon

An Interactive logon using a user domain account to the resource domain uses a combination of NTLM and Kerberos, with a resultant set of Kerberos tickets on the resource.local member server for the user domain. This capture occurred when there was cross-forest site synchronization in place to optimise the netlogon DC locator process.

An excerpt from the network capture when logging on interactively from a user domain computer and user domain account to a resource.local member server is shown below:

517 "member.resource.local" "resourcedc01.resource.local" "DNS" "Standard query SRV _kerberos._tcp.RL1._sites.dc._msdcs.user.com"
518 "resourcedc01.resource.local" "member.resource.local" "DNS" "Standard query response SRV 0 100 88 "userdc01.user.com
519 "member.resource.local" "resourcedc01.resource.local" "DNS" "Standard query A userdc01.user.com"
520 "resourcedc01.resource.local" "member.resource.local" "DNS" "Standard query response A 192.168.1.10"
521 "member.resource.local" "userdc01.user.com" "CLDAP" "MsgId=1095 Search Request
522 "userdc01.user.com" "member.resource.local" "CLDAP" "MsgId=1095 Search Entry
525 "member.resource.local" "userdc01.user.com" "KRB5" "AS-REQ"

This conversation from the point of view of the member server being logged on to is summarised as:

1. Query the user.com DNS namespace for Domain Controllers serving the local RL1 site (which uses site coverage based on site link cost to determine the servers are the closest)
2. The list of Domain Controllers in the closest site is returned from DNS
3. An LDAP UDP ping is sent to the Domain Controllers, in a random order (in this case, there's only one)
4. userdc01 responds in a timely fashion and is chosen as the DC to use.
5. A Kerberos authentication request is sent from the resource member server directly to the user.com Domain Controller with UDP 88.

Further traffic shows both Kerberos and NTLM authentication requests/responses, as well as ICMP and SMB directly from the resource member server and user.com Domain Controllers.

Site synchronization

In terms of locating the closest Domain Controller for authentication and Group Policy processing, the following summarises the requirements identified above:

1. To allow efficient interactive logons across forests, the user domain should have knowledge of the resource domain's site. Eg. Having RL1 in user.com with appropriate site links will ensure a close DC/GC is used for authentication, universal group membership and group policy processing.
2. To allow efficient network access to resources on member servers across forests using NTLM trusts, the resource domain controllers should have knowledge of the user domain's DC NetBIOS 1B/1C records. Across forest trusts the user site information should be in the resource domain, allowing the 2003 locator to use SRV records.
3. To allow efficient cross-forest management of resources and querying information, each domain should be aware of cross-forest sites. This is relevant when using scripting or utilities such as nltest, which makes queries directly to objects in the foreign directory. Eg, from the user.com domain, running scripts or utilities against the resource domain may result in unpredictable results if sites/site links are not created.

Note that this is from an Active Directory perspective; often there is network filtering in place providing 'nearest site' functionality by only allowing UDP And ICMP pings to certain hosts between forests.

To further demonstrate cross-forest DC locator with scripting, the following script can be used:

'-- FindClosestDCs.vbs
Const ADS_CLOSEST_FLAG = 128
Const ADS_FORCE = 1
Set objLocator = CreateObject("ADsLocator") ' Requires ADsLocator.dll

strDomainSet = "resource.local,user.com"

on error resume next
For Each strDomain In Split(strDomainSet, ",")
Set objADsDCINFO = objLocator.DsGetDcName(CStr(strDomain), , , ADS_CLOSEST_FLAG AND ADS_FORCE) ' Find the closest Domain Controller
If Err.Number <> 0 Then
wscript.echo "Error: Could not find DC for '" & strDomain & "' - " & err.description & " (" & err.number & ")"
Else
strDC = objADsDCINFO.DomainControllerName ' Extract the name
wscript.echo strDomain & " DC: " & strDC
End If
Next

'--

References

NT4 Locator or 200x locator:
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsbc_nar_lzii.asp

Multiple forest considerations:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/activedirectory/mtfstwp.mspx

Kerberos between forests:
http://www.microsoft.com/technet/itsolutions/wssra/raguide/DirectoryServices/igdrbp_2.mspx

How domains and forest trusts work:
http://technet2.microsoft.com/WindowsServer/en/Library/f5c70774-25cd-4481-8b7a-3d65c86e69b11033.mspx

Nltest syntax:
http://technet2.microsoft.com/WindowsServer/en/Library/c694f7f1-e05a-474c-b02b-19a7575ed8601033.mspx

Debug in nltest:
http://support.microsoft.com/?id=109626

Finding a DC and DC Locators (2000):
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsbc_nar_lzii.asp

Domain Controller Locators (2003):
http://technet2.microsoft.com/WindowsServer/en/Library/9d62e91d-75c3-4a77-ae93-a8804e9ff2a11033.mspx

Authentication and Authorization:
http://technet2.microsoft.com/WindowsServer/en/Library/78cb5d3c-d0b2-4d20-a693-fa66bde1a63b1033.mspx

Domain and forest trusts, Kerberos referral processing vs NTLM:
http://technet2.microsoft.com/WindowsServer/en/Library/3215e730-c1a7-4918-bc9e-67f343f89e611033.mspx

Cross-forest access with WebDAV:
http://support.microsoft.com/?kbid=830576

NTLM authentication for cross-forest trusts in Windows 2000:
http://support.microsoft.com/?kbid=274438

Communication between 2000 and 2003 forests using external trusts:
http://technet2.microsoft.com/WindowsServer/en/Library/436f7ffe-7b26-4650-b532-2a0dfa03f8251033.mspx

Authentication service registry settings:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcesecurity5/html/wce50conAuthenticationServicesRegistrySettings.asp

Detailed example of interactive logon, remote logon (resource access) on Windows 2000 domain:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx

Network ports required for authentication:
http://technet2.microsoft.com/WindowsServer/en/Library/3215e730-c1a7-4918-bc9e-67f343f89e611033.mspx

How Domain Controllers Are Located in Windows XP
http://support.microsoft.com/kb/314861

Wayne's World of IT (WWoIT), Copyright 2008 Wayne Martin.