Create “Hidden” Active Directory Site for Application Testing Purposes

17/04/2014By , , , ,

The Challenge

Active DirectoryOne of the biggest challenges in Active Directory Domain Controller upgrades are the application member servers, specifically the ones that make use of Active Directory authentication (Ldap). We all know the legacy applications within the organization, they’re still running after ten or more years, nobody knows something about it, there isn’t any documentation left but they are necessary and should not be phased out. Sometimes we don’t even know what application servers are using Active Directory at all.

So, how do we find out if those applications still work after a domain controller upgrade? How to create a safe way to test if your application is compatible with the stronger Windows Server 2012 security settings you want to use.

Here comes the Active Directory “hidden” site in action. You’d like to require a minimal security setting of NTLMv2. The older Lan Manager and NTLM authentication protocols are compromised and easy to sniff to get logon information like usenames and passwords.

Introduction to LanManager & NTLM

LAN Manager (LM) is a family of early Microsoft client/server software that allows users to link personal computers together on a single network. Network capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol is not negotiated for some reason, Active Directory will use LM, NTLM, or NTLMv2.

LAN Manager authentication includes the LM, NTLM, and NTLM version 2 (NTLMv2) variants, and is the protocol that is used to authenticate all Windows clients when they perform the following operations:

  •  Join a domain
  • Authenticate between Active Directory forests
  • Authenticate to down-level domains
  • Authenticate to computers that do not run Windows 2000, Windows Server 2003, or Windows XP)
  • Authenticate to computers that are not in the domain

The possible values for the Network security: LAN Manager authentication level setting are:

  • Send LM & NTLM responses
  • Send LM & NTLM — use NTLMv2 session security if negotiated
  • Send NTLM responses only
  • Send NTLMv2 responses only
  • Send NTLMv2 responses only\refuse LM
  • Send NTLMv2 responses only\refuse LM & NTLM
  • Not Defined

The Network security: LAN Manager authentication level setting determines which challenge/response authentication protocol is used for network logons. This choice affects the authentication protocol level that clients use, the session security level that the computers negotiate, and the authentication level that servers accept as follows:

  • Send LM & NTLM responses. Clients use LM and NTLM authentication and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Send LM & NTLM – use NTLMv2 session security if negotiated. Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Send NTLM response only. Clients use NTLM authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Send NTLMv2 response only. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Send NTLMv2 response only\refuse LM. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM (accept only NTLM and NTLMv2 authentication).
  • Send NTLMv2 response only\refuse LM & NTLM. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM and NTLM (accept only NTLMv2 authentication).

These settings correspond to the levels discussed in other Microsoft documents as follows:

  • Level 0 – Send LM and NTLM response; never use NTLMv2 session security. Clients use LM and NTLM authentication, and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Level 1 – Use NTLMv2 session security if negotiated. Clients use LM and NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Level 2 – Send NTLM response only. Clients use only NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Level 3 – Send NTLMv2 response only. Clients use NTLMv2 authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Level 4 – Domain controllers refuse LM responses. Clients use NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers refuse LM authentication, that is, they accept NTLM and NTLMv2.
  • Level 5 – Domain controllers refuse LM and NTLM responses (accept only NTLMv2). Clients use NTLMv2 authentication, use and NTLMv2 session security if the server supports it. Domain controllers refuse NTLM and LM authentication (they accept only NTLMv2).

Create the “hidden” Active Directory site with “hidden” Domain Controller

You are not restricted to Windows Server 2012 only, it’s possible to create the special hidden site with 2003 and 2008 Active Directory infrastructures as well. The steps below describe how to create a hidden site with 2012 Active Directory and a member server that’s being promoted to Domain Controller afterwards. The steps are more or less the same if you are creating this with Windows Server 2003 of 2008.

Note: It’s also possible to create the hidden site if you’ve already added a 2012 Domain Controller to your domain. The Netlogon service will remove the generic DNS records after the policy is applied to the existing Domain Controller.


1. Open Active Directory Sites and Services and create a new site. Give it some name, like HiddenSite-2012. 

AD Sites and Services

2.  Next, create a new subnet. Specify only the ip address of the Domain Controller you want to isolate, this is important! Select site object created in step 1.

New Subnet

3. Make sure the subnet is connected to your hidden site.

Subnet to Site

4. Check if the hidden site is added to the same site link your other DC’s are in located.

Site Link Check

5. Open adsiedit.msc, browse to Configuration and open CN=yoursitelinkname

adsiedit.msc

6. Check if the attribute “options” is set to value 1. This is Inter-site Change Notification. Inter-site change notification tells the replication engine to treat the link as if it was in the same site. That is, notify the replication partners of the change rather than wait for the replication interval to pass (minimum of 15 minutes). More information on this subject here.

Attribute

7. Start dsa.msc to create a new Active Directory security group and make the computer account of your server, that should become a hidden Domain Controller, member of the group. The server I’m using is named DC02.

AD Group with computer account

8. Start gpmc.msc to create a new GPO. Browse to Computer Configuration > Administrative Templates > System > Net Logon > DC Locator DNS records.

Create new GPO

9. Open the DC Locator DNS records not registered by the DC’s policy setting. 

GPO Setting

DC locator policy

DNS Generic records

Now that we have prepared the site, subnet, group and policy the tricky part starts. We have to fill up the Mnemonics field of the policy with generic DC DNS records.

9. Open dns.msc and collect the data from records in _tcp, _udp. See the highlighted fields. Do not collect from _sites!

DNS data

10. After you’ve copied the data it should look something like this:

Generic Records

11. You can also find these and more records in the netlogon.dns file located at %windir%\system32\config. Because this file contains all records you have to pay attention when you copy the information.

Netlogon.dns

12. Paste the following information to the Mnemonics field of the DC Locator DNS records not registered by the DC’s policy:

Ldap Gc DcByGuid Kdc Dc Rfc1510Kdc GenericGc Rfc1510UdpKdc Rfc1510Kpwd Rfc1510UdpKpwd

Policy

13. Save the policy and check if the settings are applied.

GPO setting

14. Link the GPO to the Domain Controllers OU and edit the Scope by setting the Active Directory security group to Security Filtering.

Set Security on GPO

Results

After the final step you can introduce the new Windows Server 2012 Domain Controller to your domain. What happens next is that after the Domain Controller has been added it will not register the generic records. The Domain Controller will replicate with the other DC’s in your domain but is invisible for member servers and other clients unless they are added to the same hidden site.

The technical application admins in your organisation are now able to test their software against the new hidden Domain Controller with tighter security settings. This can be accomplished by adding the ip address of a Windows application server to the hidden site or the application admin configures his application to point hardcoded to the Domain Controller but this is software depending.