NTLM Trusts between 2003 and NT4

This post includes a few notes and example on an NTLM trust between two domains in a scenario I was working on - creating a trust between a 2003 user domin and an NT4 resource domain.

I realise NT4 was a long time ago, but NT 4.0 was one end of a trust I set up earlier this year (2008), so other people might be in a similar situation. Note that to have a forest trust - even if it's only a one way trust - both the domain and the forest have to be in Windows 2003 functional mode, so whenever you're talking about trusts between external domains/forests, if one side is NT4 or 2000 then it's an NTLM trust.

The types of access through the trust that will need to be considered:

• Cross-domain resource access, including pass-through authentication, Trusted Client->Trusting Server->Trusting DC->Trusted DC
• Authenticating access requests for a cross-domain object, Trusting DC -> Trusted DC
• Using the object picker and retrieving a list of trusted domains and trusted accounts also results in PDC->PDC communication between trusting and trusted.
• Establishing the trust, the PDC of the trusting NT4 domain will try and resolve and then query the PDC of the trusted domain. TCP and NetBIOS sessions will be established, with named pipes, SMB and RPC. A combination of LSA RPC and Netlogon RPC
• Sometimes there may be a need to control the DC Locator process on the NT4 DCs to ensure that only the single DC is contacted to authenticate cross-domain access requests. This will be a local lmhosts #PRE #DOM: entry, or a static WINS record, but this would only work when controlling authentication, some other operations require PDC emulator connectivity.

How pass-through authentication across domains between 2003 and NT4 typically works:

1. Client from 2003 sends a request to the resource server in the NT4 domain
2. NT4 resource domain server passes the request to a NT4 DC in the local trusting domain
3. The NT4 DC checks the request is from a trusted domain, then establishes NetBIOS/SMB sessions with a DC in the trusted domain
4. Netr netlogon RPCs to create a secure channel and authenticate the samlogon request

If you need network security between the trusts, I recommend this be completed in a lab first. Otherwise you will probably end up with the connection between here and there looking like swiss cheese, or at the very least having larger holes than really required. VMware is great for creating a test-lab for this type of exercise, you could reproduce your existing production configuration and monitor the traffic going between various locations - this also requires something of a test network though.

Note that this information can also be used in concert with the 'Replica Domain for Authentication' post to create a trust with a replica of your production domain, reducing the risk of exposing your domain.

Both the RPC and SMB will be over NetBIOS when coming from NT4:

nbname 137/UDP
nbname 137/TCP
nbdatagram
138/UDP
nbsession 139/TCP

In the scenario I was working on, the applications in the resource domain were either accessed via windows authenticated HTTP or direct SQL connectivity. Two examples below show the conversation in authenticating over the trust, between an XP member of the 2003 domain to a member server in the NT4 domain.

Assuming there’s a 2003 member server running IIS using windows authentication in the NT 4.0 resource domain, and XP clients from the corporate forest are accessing the application directly:

1. Internet Explorer from the workstation initiates a HTTP session with the web server
2. HTTP 401 is returned by the web server, indicating that authentication is required, with the WWW-Authenticate response headers indicating Negotiate and NTLM are the available schemes.
3. NTLM Negotiate (0x00000001) is then sent from the client to the server indicating supported NTLM options
4. The web server responds with a challenge message (0x00000002) for the client to prove their identity
5. The workstation responds with an authenticate message (0x00000003) – an encrypted challenge response based on the logged on users’ password hash
6. A Netlogon RPC call is initiated from the web server to the NT 4.0 DC the server has its secure channel with to initiate the samlogon request, providing the username, domain name, challenge, and challenge-response.
7. The NT 4.0 DC checks the information and determines that it has a trust with the named domain.
8. The NT 4.0 DC establishes a secure channel with the trusted replica domain (or uses the existing channel)
9. A second Netlogon RPC call is then passed through to the replica 2003 domain using the same information as the first call (wrapped in NetBIOS in this case)
10. The replica DC retrieves the hash of the specified user’s password, the original challenge is then encrypted using this hash and compared to the challenge-response provided with the request.
11. Assuming passwords are synchronised, the hashes match and the trusted netlogon call is successful
12. The Netlogon call from the web server is also returned as successful
13. The web page is served to the XP workstation

Connecting across domains to SQL in NT4 from an XP workstation in 2003:

1. The user starts the local MDE (which has an embedded connection to remote SQL)
2. The workstation initiates a connection over TCP 1433 to the SQL server
3. The workstation tries to verify the name/IP of the SQL server, with a reverse lookup DNS query and a NetBIOS Adapter Status Request to the IP over UDP 137 NBNS.
4. The local Active Directory KDS is queried to see if there is a matching SPN for the requested SQL service. This is unsuccessful and the authentication protocol falls back to NTLM.
5. A TDS NTLMSSP challenge/response occurs between the workstation and the cross-domain SQL server, including:
   a. The negotiate response from the workstation contains the client name and the database (0x1)
   b. The NT4 challenge from the SQL server (0x2)
   c. The authenticate response messages, containing response to the challenge using the currently logged in credentials (of the XP workstation)
6. A Netlogon RPC call is initiated from the SQL server to the NT4 DC the server has its secure channel with to initiate the samlogon request, providing the username, challenge, and challenge-response.
7. The NT4 DC checks the information and determines that it has a trust with the named domain (the 2003 user domain)
8. The NT4 DC establishes a secure channel with the trusted domain
9. A second Netlogon RPC call is then passed through to a trusted DC using the same information as the first call
10. The NT4 DC retrieves the hash of the specified user’s password, the original challenge is then encrypted using this hash and compared to the hash provided with the request.
11. Assuming the password is correct, the hashes match and the trusted netlogon call is successful across the trust.
12. The Netlogon call between workstation SQL server is also returned as successful

References

Replica Domain for Authentication
http://waynes-world-it.blogspot.com/2008/08/replica-domain-for-authentication.html

How Domain and Forest Trusts Work
http://technet2.microsoft.com/windowsserver/en/library/f5c70774-25cd-4481-8b7a-3d65c86e69b11033.mspx?mfr=true

Trust Technologies
http://technet2.microsoft.com/windowsserver/en/library/9d688a18-15c7-4d4e-9d34-7a763baa50a11033.mspx?mfr=true

Establishing Trust Relationships
http://www.microsoft.com/technet/archive/winntas/plan/capacityplanning/a03_trst.mspx?mfr=true

NTLM user authentication in Windows
http://support.microsoft.com/kb/102716

Direct hosting of SMB over TCP/IP
http://support.microsoft.com/KB/204279

How to configure a firewall for domains and trusts
http://support.microsoft.com/kb/179442

Windows NT 4.0 tries to resolve manually-typed names by contacting the PDC for the remote user's domain (UDP 138). If that communication fails, a Windows NT 4.0-based computer contacts its own PDC, and then asks for resolution of the name.

Describes some of the network traffic between 2003 trusts, including methods of setting the LSA and Network RPC ports used for various operations.
http://technet2.microsoft.com/windowsserver/en/library/108124dd-31b1-4c2c-9421-6adbc1ebceca1033.mspx?mfr=true

I've also used this document in the past, touching on some topics such as DNS, netlogon optimisation/site synchronisation
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/mtfstwp.mspx

Forest trust information – the flow and types of traffic for cross-forest authentication, which shows the workstation from the account domain (trusted), contacting a KDC in the resource domain (trusting) for kerberos authentication, often overlooked - this means traffic goes directly from all workstation endpoints to DCs in the resource domain, as opposed to an NTLM trust where DCs normally talk to each other)
http://technet2.microsoft.com/windowsserver/en/library/517b4fa4-5266-419c-9791-6fb56fabb85e1033.mspx?mfr=true

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

2003 Servers with Hibernation enabled

How many of your 2003 servers have hibernation enabled and you never realised? If you're like me, possibly a few, and I can't think of a scenario where I would want to hibernate a server.

This post provides a simple method of detecting whether hibernation is enabled, and then a command to remotely disable hibernation on each server. It works based on the premise that if hibernation is enabled, you'll have a file called hiberfil.sys on the root of your system drive.

1. Create a text file called servers.txt listing one server per-line and then run the following command
2. for /f %i in (servers.txt) do @if exist \\%~i\c$\hiberfil.sys (echo %~i,Enabled) else (echo %~i,Disabled)
3. Save the output filterd by Disabled (find /i "Disabled" results.txt) and run the following command to disable on each (assuming you have psexec)
4. for /f %i in (servers_hibernate.txt) do psexec \\%i powercfg /HIBERNATE off

This should automatically delete the hibernation file, reclaiming the hard disk space equal to the RAM of the machine.

Note that this assumes your systemdrive is C: and that you have administrative shares enabled (C$). To accurately distinguish between servers that don't have C:/C$. you could also run a nested if command (which assumes an installation directory of Windows):
for /f %i in (servers.txt) do @if exist \\%~i\c$\windows (if exist \\%~i\c$\hiberfil.sys (echo %~i,Enabled) else (echo %~i,Disabled)) else echo %~i,Not Found

You can also manually run the command to disable hibernation against one server:
psexec \\%server% powercfg /HIBERNATE off

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