Securing Active Directory When Anonymous Users Must have Access

Allowing unauthorized users to perform actions anonymously in your Active Directory (AD) is not recommended security-wise, but in many cases is mandatory to allow critical network activities. When this is the case there are several steps you can take to increase your network’s security and protect it from the potential threats that anonymous users may impose.

UPDATED BLOG HERE:

Managing Anonymous User Settings on Your Computer to Boost Security

This issue is especially relevant these days due to the recent discovery of the ZeroLogon vulnerability, where only patching is not enough, and hardening actions are also required to ensure protection. Hardening can be a painful procedure. Endless hours, labor, and money are invested in this process, which can often result in production breakdown despite the effort to prevent it. CHS by CalCom automates the entire server hardening process. CHS's unique ability to 'learn' your network eliminates the need to perform lab testing while ensuring zero outages to your production environment. CHS will allow you to implement your policy directly on your production servers, hassle-free. Want to know more? Click here to download the datasheet. 

This blog post is will guide you on what audits and hardening actions you should take in order to increase your network's security when you must allow anonymous access to your Domain Controller and Active Directory.

In this post we’ll explain:

1. AD anonymous best practices
2. How to auditing anonymous activity
3. How to harden the Domain Controller using user rights
4. How to harden the Domain Controller using security settings

Active Directory Anonymous users' best practice:

Set 'Network access: Do not allow anonymous enumeration of SAM accounts and shares' to Enabled.

This rule default setting is 'Disabled'.

The main risks in leaving this value Disabled are allowing an unauthorized user to anonymously list account names and shared resources and use this information to achieve access by guessing passwords or performing social engineering attacks.

If you enable this policy setting, anonymous users will not be able to enumerate domain account usernames and network share names on the workstations in your environment.

It is often when conditions in the production environment can't support enabling this rule and disabling anonymous activity. There are two courses of action when this is the case:

<h3id=audit>Auditing Anonymous activity:

You can discover Anonymous activity in the Domain Controller (DC) by login the following events: 4624, 4768, 5829, 5827.

Hardening the Domain Controller:

It is recommended to set both user rights and security settings in the DC to prevent attacks leveraging anonymous access.

Restrict Anonymous activity- user rights:

1. Set 'Access this computer from the network' in the DCs to: Authenticated Users, Enterprise domain controllers.
   Note: Administrators are part of Authenticated Users.
2. Set 'Bypass traverse checking' in the DCs to: Authenticated Users; Local Service; Network Service.
3. Set 'Deny access to this computer from the network' in the DCs to: ANONYMOUS LOGON; Guests

Restrict Anonymous activity- security settings:

1. Set 'Microsoft network client: Digitally sign communications (always)' to: Not Defined.
2. Set 'Microsoft network client: Digitally sign communications (if server agrees)' to: Enabled.
3. Set 'Microsoft network client: Send unencrypted password to third-party SMB servers' to: Disabled.
4. Set 'Microsoft network server: Digitally sign communications (always)' to: Enabled.
5. Set 'Microsoft network server: Digitally sign communications (if client agrees)' to: Enabled.
6. Set 'Network access: Allow anonymous SID/Name translation' to: Disabled.
7. Set 'Network access: Do not allow anonymous enumeration of SAM accounts' in the DCs to: Enabled.
8. set 'Network access: Do not allow anonymous enumeration of SAM accounts and shares' in the MS to: Enabled and in the DCs to: Enabled or Not Defined when cannot be enabled on DCs due to multiple domains with trusts.
9. Set 'Network access: Let Everyone permissions apply to anonymous users' to: Disabled.
10. Set 'Network access: Named Pipes that can be accessed anonymously' in the DCs to: LSARPC, NETLOGON, SAMR, and (when the legacy Computer Browser service is enabled) BROWSER.
11. Set 'Network access: Restrict anonymous access to Named Pipes and Shares' to: Enabled.
12. Set 'Network access: Restrict clients allowed to make remote calls to SAM' to: Not Defined.
13. Set 'Network access: Shares that can be accessed anonymously' to: None.
14. Set 'Network security: LAN Manager authentication level' to: Send NTLMv2 response only. Refuse LM.
    Note: if set to Send NTLMv2 response only. Refuse LM & NTLM, will not be able to access IIS applications unless the client\workstation is also set with the same configuration. Other applications might not work properly as well.