Securing Domain Admins Groups in Active Directory

This is just a quick post to raise awareness of one way we can help protect our Domain Admins Group in Active Directory. I have talked previously about privilege separation and the need within the Enterprise to reduce the credential foot print of high privilege accounts. As Microsoft describes in this particular article discussing best practices, Domain Admin accounts should only be used for build and disaster recovery scenarios and should not be used for day to day activities. By following this simple rule you are mitigating against having Domain Admin credentials being cached on workstations or member servers, and therefore less likely to be dumped out of memory should the box become compromised.

We can secure the Domain Admins group for both member workstations and member servers with the following Group Policy Objects from the following user rights policy in Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments:

  • Deny access to this computer from the network
  • Deny log on as a batch job
  • Deny log on as a service
  • Deny log on locally
  • Deny log on through Remote Desktop Services user rights

Lets take a closer look and create the policy:

In our Group Policy Management console we will start off with a new policy:

Right click on the policy and click edit. Find the first policy ‘Deny access to this computer from the network’. Open it up and add the Domain Admins group to the list. Click ‘OK’.

Rinse and Repeat for the remaining policies:

Link the policy through to your computers and member workstations. Remember if your using ‘Jump boxes’ to administer your domain controllers you will need to create an exception for these and  with a different policy.

This is one small piece in a massive jigsaw of securing AD. However I hope this helps, for further reading visit–securing-domain-admins-groups-in-active-directory .


Disable Domain Users from Enumerating other Domain Users, Domain Admins and other objects!

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!!).

disable domain enumeration

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:

create disable domain read 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 group to ACL OU HR

Add ‘bob’ to the group and then lets try and enumerate the domain again. Lets see what happens:

disable domain enumeration

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:

Add group to ACL for the domain

Lets reboot our domain computer and test again:

disable domain enumeration

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.

Windows Security

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!