Replica Domain for Authentication

This post describes a solution I implemented to create a relatively secure risk-free external trust between a 2003 and legacy NT4.0 domain to access IIS-based web applications. Normally this scenario has many drawbacks across two 'secure' networks and I ended up provisioning a replica of our corporate 2003 forest trusted by the NT 4.0 domain, and used an identity management solution to synchronise accounts/passwords.

Serveral hundred people happily use pass-through authentication to access web applications, and for authentication we only had to poke a hole in the network for one port in one direction (the replica domain is being hosted on the resource network). There would have to be more ports open for the actual application between workstation and resource server, eg HTTP or MSQL-1433.

The solution is described below and an example of how this sleight of hand works from an NTLM authentication perspective to provide pass-through authentication originating from one domain but authenticating with another.

Supposing you have a corporate domain name PROD (prod.com) and a foreign resource domain named NT4. Users from PROD need to access SQL and IIS web-based applications in the NT4 resource domain, and pass-through authentication is a requirement.

If you are fortunate enough to have an identity management solution in place, then what you could do is:

1. Create a new forest not on your production network, called prod.local with a NetBIOS domain name of PROD. The NetBIOS domain name must be the same, but the FQDN can be different.
2. Place the new forest in a DMZ with the required access to the foreign network (being the trusted domain has this domain initiating the outbound TCP/UDP connections). If the trusting company is amenable, you could also host this replica domain on their network, making network security VERY simple.
3. Create the trust, following http://support.microsoft.com/kb/325874. Note that there are NetBIOS name resolution requirements, using either lmhosts or WINS.
4. Using your identity management solution, synchronise accounts and passwords from prod.com to prod.local
5. Enable netlogon debugging on prod.local (nltest /dbflag:0x2080FFFF) so that you can see authentication attempts
6. Using a workstation that is a member of the prod.com domain, try and authenticate to the resource server in the NT4 domain.
7. All going well you should see authentication attempts from the NT4 DC to your replica prod.local DC, even though the attempt originated from a domain member of prod.com

Notes:

1. If this was trusted by an NT 4.0 domain luckily pretty much everything will be wrapped in NetBIOS rather than direct SMB or RPC. it’s still an ephemeral source port though for the TCP 138 endpoint.
2. Note that even though one side of the trust is an NT 4.0 domain, as long as this is an external NTLM trust (as opposed to a 2003 forest trust), then this should still work (depending on SID filtering). Being NT 4.0 in this case made it even more unworkable to trust the 2003 domain, as it would require access to the 2003 PDC emulator – not something you typically want to host in your DMZ.
3. Having a second replica DC is always a good idea for redundancy.
4. If anything to do with SIDs was involved this would NOT work, it’s only because the NTLM authentication model doesn’t use the SID in the challenge-response that this pass-through authentication works.

Example – simple web access

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

References:

Trust between a Windows NT domain and an Active Directory domain cannot be established or it does not work as expected
http://support.microsoft.com/kb/889030

How to establish trusts with a Windows NT-based domain in Windows Server 2003
http://support.microsoft.com/kb/325874

LMHOSTS File Information and Predefined Keywords
http://support.microsoft.com/kb/102725/

How to establish trusts with a Windows NT-based domain in Windows 2000
http://support.microsoft.com/kb/308195

Network access validation algorithms and examples for Windows Server 2003, Windows XP, and Windows 2000
http://support.microsoft.com/kb/103390

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

NTLM specification
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NLMP%5D.pdf

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