This is a short guide on how to create and configure some essentials GPO (and other stuff) to secure an Active Directory domain from the inside. This has become one of my basic setup when I start working on an AD domain. Most of the time, all of these GPO won’t disrupt anything but it’s always important to understand the environment and what the AD domain is hosting for the organization with all the softwares, to make sure that those security setting won’t break any old legacy applications. As always, do your homework before doing any changes in a production env.

This is not a complete guide by itself. It’s a quick and dirty patched up documentation for setting up basic security for an Active Directory domain. If you are into this kind of subject, look into Ping Castle or Purple Knight as a start, these are very usefull tools to help you make your AD more secure. There are so much more available for free!

Disable Debug Mode

Disable debug mode in Windows right from the start, on all servers and most importantly, on all the clients devices. A lot of hacking tools, like mimikatz, will almost be useless with this since you are preventing users from accessing all the cool features of the debug mode, like reading the content of the RAM. Only developers should have access to this mode and the GPO will let you select a security group that members of the groups can have access to the debug mode. Do note however that in order to install MS SQL server, you’ll need to have the debug mode enabled just for the installation process. Once the installation of MS SQL is finished, you can remove your account from that security group. You’ll find this GPO under:

Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – User Right Assignment – Debug Programs

Adding Workstations to the domain

Did you know that by default, any domain users account can add up to 10 workstation to the Active Directory domain? Not on my watch! The domain admin account has no such limitation, but I highly recommend that you create a security group that only members of that group can add computer account to the domain. The domain admin group is not affected by that. By defining a group, you will remove the ability for any domain users account to add a computer to the domain. Neat!

Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – User Right Assignment – Add workstation to the domain

Do not allow anonymous enumeration of SAM accounts and shares

By default any computers connected to an AD domain can get a list of all the usernames and shares names, all without logging to the AD domain and being anonymous. This is not acceptable you should disable this be defaut. Take note that this setting could affect one-way domain trust relationship, but honestly, this kind configuration should not be.

Computer Configuration – Policies – Windows Settings – Local Policies – Security Options – Network access: Do not allow anonymous enumeration of SAM accounts and shares

Turn off multicast name resolution (LLMNR)

Again, another setting that can break communication for legacy application, but it should definitively be in your top list to disable this settings. Multicast name resolution or LLMNR can be easily exploited with mitm attack. The main argument for using this is that you don’t need an internal DNS because you have LLMNR instead. I mean, who doesn’t run an internal DNS inside any organization today?

Computer Configuration – Policies – Administrative Templates – Network – DNS Client – Turn Off Multicast Name Resolution

Hardening UNC Paths

Still using shared folders or printers? Even if not, you must have the default ones from the AD domain of NETLOGON and SYSVOL. You should enable the hardening of UNC path per share, this will prevent, again, mitm for accessing those shares. Be careful tough, test it on a lab or a not critical folder share before putting this setting. Yet again, it’s a must to have for your shares. Clients and servers must be at minimum version of Windows 8.0 and Server 2012 for this setting. Several CVEs are listed because of this. This GPO is a little bit more complicated to configure because it’s not just an on/off switch. You gotta specify the the UNC path and the settings with it. Your choices are:

• Requires Mutual Authentication
• Requires Integrity
• Require Privacy

If it’s 1, it’s enabled (on), if it’s 0, it’s disable (off), simple as that. For all the details for those 3 settings, read it all here. As an example, if I would like to turn on all 3 settings for the NETLOGON share, I would put for the Value name the UNC path of the share itself like:
\\ad.contoso.com\NETLOGON

And for the value itself it would be:
RequiresMutualAuthentication=1,RequiresIntegrity=1,RequirePrivacy=1

Notice the missing space between each word and the comma between the 3 values in the GPO.

Computer Configuration – Policies – Administrative Templates – Network – Network Provider – Hardened UNC Paths

LDAP client signing requirements

Be very carefull with this one. This configuration will affect any clients making LDAP request to the servers/DC. This setting can be set to negotiate or required signing. The difference is important here, when it’s set to negotiate, a client making an LDAP request to a server will ask that the connection is done using TLS/SSL, if the server can support it (meaning you have deployed a PKI correctly for your servers and client – AND you also configured the setting for this on the server side), then the connection is encrypted. If it’s not supported, then the connection is still allowed without encryption available. When set to required, then the connection is only allowed with TLS/SSL, if it’s not supported, then it’s droped. Note also that if you set this to required, you must enforce it to required with another GPO for the server itself (next section). If you are aiming for required for the client and server, I suggest that you deploy this in steps, go with negotiate first, test all your app that use LDAP auth to confirm that TLS/SSL is working. Then afterward, change the GPO to required. Much safer this way.

Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – Security Options – Network security: LDAP client signing requirements

LDAP server signing requirements

If you configured the LDAP client to make the request signed, then, you gotta make sure that the LDAP signing on the server will also be enabled. You will usually configured this under the Domain Controller policy or create a new policy just for that, it’s up to you. If you set this up to required, all the client making a connection must be done using TLS/SSL. Be carefull with Linux or Mac doing authentication with your AD, you’ll need to make sure that your CA certificate is installed/recognized by those system to make sure it works flawlessly.

Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – Security Options – Domain controller: LDAP server signing requirements

Disable LM and NTLMv1 auth protocol

Or simply put; enforcing NTLMv2. Honestly, choosing NTLMv2 is the lesser evil because what you should really be aiming for is using Kerberos only! But this is a real challenge! Instead, if you want to reach it in small step, start by disabling these old authentication protocols of Lan Manager (LM) and New Technology Lan Manager version 1 (NTLMv1). NTLM version 2 is, unfortunately, still being used a lot. But it will help you getting more confidence that one day, you will have Kerberos only that will be used internally. Before disabling LM and NTLMv1 tough, you should review your security logs to see if you have any authentication using those legacy auth protocols. Again, this GPO will be set on the domain controllers. I highly suggest you read the link before and to push it in multiple (baby) steps.

Computer Configuration – Policies – Windows Settings – Security Settings – Local Policies – Security Options – Network security: LAN Manager authentication level

Using Protected Users Security Group

Ok, that one is not a GPO but it uses one of the builtin AD security group that has been available since Windows Server 2012 R2. Any AD user that is a member of that security group can only authenticate using Kerberos – and the ticket life time is good for 4 hours only. All the privileged accounts for doing any administrative tasks in your AD should be a member of that group. The drawback? If you use your admin account for any application that use your internal AD for SSO, then that application has to be configured to let the auth process be done using Kerberos. More easily being said than done since a lot of software out there will be using NTLM instead. As an example, if you have MS Exchange on-prem, Kerberos is available but not configured as the default auth protocol. You’ll have to do it yourself to make sure it’s working. Still you should really be looking into that one. It can help from preventing your admin creds being stolen.

Kerberos Golden Ticket

Did I mention mimikatz earlier? Well, you gotta be aware of this exploit to make sure you are ramping up your protection againt it. Ever heard of the Kerberos Golden Ticket Exploit? For protection against this exploit, you won’t use a GPO but a powershell script instead. You should definitively run it to reset the password for the Kerberos service account that is builtin for the Active Directory. A lot has already been written about this topic. You can do the password reset yourself, but honestly, it’s much safer to use the script itself. You can run it in simulation mode before changing it live. Also, make sure that you understand the synch time if you have multiple DC.