In this post we will walk through how to disable domain user enumeration. Disabling Domain Users from Enumerating other Domain Users, Domain Admins and other objects in Active Directory. Why might I want to do this? Well, once a domain user account has been compromised through exploitation, sooner or later the attacker is going to want to enumerate the domain further and gather ‘intel’, commonly known as situational awareness. During this process an attacker is going to want enumerate the domain and all its users including high privilege groups such as Domain Admins. This is a gold mine for an attacker as they can launch password spray attacks on those enumerated users. The attacker doesn’t have to guess the usernames as he/she can just query the domain, that’s half the battle won. The attacker will then use a single password such as Password1 against all the accounts, inline with the domain password policy avoiding account lockouts. By default any authenticated domain user can enumerate the entire domain, this is standard out of the box configuration for a domain controller. For example our test user ‘bob’ in our lab is a domain user, he can freely pull up a command prompt and simply enumerate all the domain users, domain admins and other objects such as computers and servers in the domain, just wonderful…(not!!).
Microsoft why on earth would we want our domain users to enumerate our ‘Domain Admins’ group by default??
This just won’t do, so how can we fix it? We can deny read permissions to certain objects in the domain through the use of the access control lists (ACL) in Active Directory. A word of caution here, this is likely to break certain applications so the way we will go about this is in stages. For starters we won’t be modifying any permissions of any users or built-in groups. We will create a new security group called ‘Disable domain read’. We will then add users to this group that we want to deny the read permission for, so when a user of this group tries to read the domain they will get either no results or an ‘access denied’ message. Then add this group at various OU’s in the forest, ticking the deny read permission for that group, this will take affect on all users under that OU. This has the added benefit of simply being able to remove users from the group and also removing the group from any ACLs on OUs, should anything need to be reversed.
An Example
As with the above screen shot we can see that bob is able to enumerate the domain. Lets fix this. First we will create our group:
Now as a simple test we will add this group to the ACL of the HR OU. You can see in the below screenshot there are a list of users in this OU already. By making this change we will be denying the read permission on the OU and its contents for members of the group ‘Disable Domain Read’. So right click on the OU and select properties. Select the ‘Security’ tab, then ‘Add’, add in the security group, then select ‘Deny’ on the ‘read’ permission as highlighted in the red box.
Add ‘bob’ to the group and then lets try and enumerate the domain again. Lets see what happens:
Great… bob has now been denied access to reading the users in the HR OU. However, can still see the ‘Domain Admins’ group. I have purposefully done the the configuration this way to show you how granular we can set the permissions. As the Domain Admins group isn’t in the HR OU it has not applied to that object. Now lets go to the other extreme and set at the top level for the entire domain. Apply the same access control entry (ACE) at the domain level, this will filter down to all objects including ‘Domain Admins’. In reality you would want to be more granular than this, applying the ACE in ACLs within the domain at specific OUs, this will give you more control. However as an example lets proceed:
Lets reboot our domain computer and test again:
Perfect, now our domain user is not able to enumerate other domain user accounts and more importantly the ‘domain admins’ group. This is the other extreme and will likely break things so you should apply at specific OU’s however hopefully this should give you a good idea of how powerful the permissions can be and granularity in which we can apply them.
Using this method you should take into consideration that an implicit deny takes precedent over another ACE with the same permission. For example, if there were another ACE that explicitly was allowing the same action the deny would win and take precedent. This means that delegating rights to an OU after you have used this method to allow reading of permissions (ie the reverse) would not work.
This is why we have used a new separate security group just for domain users. If you were in a position where you needed a specific user or service account to be able to enumerate all domain users due to the way an application worked you could remove the user from the group and set alternative permissions on a new group with just that user in it.
Hope this helps. Remember test out your configuration before moving into production!
