Proper Use of Administrative Privileges for System Administrators in Windows Domains
One of the weaknesses in Active Directory and Windows environments that has been widely discussed but often overlooked in practice is the handling of System Administrator users and passwords. The short story is: For a compromised computer, we can essentially assume that an attacker can steal password credentials and hashes which is sufficient to remotely control other machines (pass the hash weakness in Windows). Thus for example, if a Domain Admin logs into a compromised conference computer, the attacker can easily collect the password hash and use to access any other computer on the network, including other computers.
What can we do about this?
We need to set the following policies:
- Each System Administrator should have separate Workstation Admin, Server Admin, and Domain Admin accounts, in addition to their regular user account
- Only use Domain Admin account on Domain Controllers
- Only use Workstation Admin account to access Desktop computers
- Only use Server Admin account to access Servers
- Never use Admin account for web browing or reading email, use a regular account for that
- Only give Domain Administrator privilege to users who need to manage Domain Controllers.
Not all system administrators should get Domain Admin by default, unless they actually need to manage the domain controllers. And if they get access, they definitely should not be logging onto non-domain controllers with them.
How does this work in practice?
For example, let’s consider Joe the Sysadmin. Joe has a regular user account joseph323, workstation admin account desk-joseph323, server admin account server-joseph323 and domain admin account da-joseph323. (Naming convention should be decided by the organization).
For most of the time Joe is logged in as joseph323 while he is browsing, replying to emails or looking up information. When he gets a service call or ticket regarding user problems, he Remote Desktops using his workstation admin account (desk-joseph323). If an attacker compromises his account, they are limited on the workstation admin credentials, which is bad, but not as bad as if they could capture server or domain admin credentials.
What if Joe makes a mistake, and accidentally uses the Domain Admin da-joseph323 on a conference machine? Well, not good. Since the password hash will be stored in memory there and likely to be cached (depending on configuratoion), so the user profile should be removed, machine rebooted and the password should be changed for the account.
How do we prevent accidental logons of Domain Admins to Non-DCs?
Can we do anything to prevent such mistakes? Yes, turns out we can as pointed out in Microsoft’s recommendations: Securing Domain Admin Groups in Active Directory. This can be done by creating a Group Policy to avoid accidental logons by Domain Admin onto Workstations and non-domain controller.
As always take care when applying those and make sure not to link it to Domain Controllers. A good starting point could be to apply to a single user first to make sure it works properly.
Steps:
- Create a New Group Policy, and call it something like “Non-DC: Domain Admin Access Restrictions”
- Navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies, and click User Rights Assignment.
- Configure the user rights to prevent members of the Domain Admins group from accessing members servers and workstations over the network by doing the following:
- Double-click Deny access to this computer from the network and select Define these policy settings.
- Click Add User or Group and click Browse.
- Type Domain Admins, click Check Names, and click OK.
- Click OK, and OK again.
4. Configure the user rights to prevent members of the DA group from logging on as a batch job by doing the following:
- Double-click Deny log on as a batch job and select Define these policy settings.
- Click Add User or Group and click Browse.
- Type Domain Admins, click Check Names, and click OK.
- Click OK, and OK again.
5. Configure the user rights to prevent members of the DA group from logging on as a service by doing the following:
- Double-click Deny log on as a service and select Define these policy settings.
- Click Add User or Group and click Browse.
- Type Domain Admins, click Check Names, and click OK.
- Click OK, and OK again.
6. Configure the user rights to prevent members of the Domain Admins group from logging on locally to member servers and workstations by doing the following:
- Double-click Deny log on locally and select Define these policy settings.
- Click Add User or Group and click Browse.
- Type Domain Admins, click Check Names, and click OK.
- Click OK, and OK again.
7. Configure the user rights to prevent members of the Domain Admins group from accessing member servers and workstations via Remote Desktop Services by doing the following:
- Double-click Deny log on through Remote Desktop Services and select Define these policy settings.
- Click Add User or Group and click Browse.
- Type Domain Admins, click Check Names, and click OK.
- Click OK, and OK again.
8. Exit Group Policy Management Editor, click File, and click Exit.
9. In Group Policy Management, link the GPO to the member server and workstation OUs.
- Create links to all other OUs that contain workstations only.
- Create links to all other OUs that contain member servers only.
As always, take care where you apply the policy to avoid making mistakes, for example would be a disaster to forbid domain admins from logging into domain controllers.
Does this guarantee that there are no Domain Admin profiles lying around?
It should work for future mistakes as long as the GPO is linked and applied (which sometimes can be a headache). Thus, it is recommended to monitor for these events in addition.
Each login leaves a profile on the logged in account, and the credentials/hash is stored in memory, which is rather easily retrieved with open source tools that most hackers have access to.
This can persist for some time, unless we take action. So, ideally we should be watching logins on machine and keeping track centrally and if a domain admin logs in, we can be notified and then go ahead and clean it up. This can be done by Powershell scripts, or tools that collect this information automatically and provide remediation.
What else can we do?
This Policy should be part of a Basic Policy in any Organization. There are more policies that can help and further reduce risk.
1. It would be even better if Joe had two separate workstations, one for accessing the internet and email, and a separate one for performing administrator work, where he would connect with Remote desktop etc. (with proper network segmentation in place as well). Many compromises are due to user clicking on a bad link, opening a bad attachment, or other user errors and it is slightly better if this is limited to the web surfing machine rather than the administration machine.
2. Other approaches can also help, such as using dedicated jump machines between environments and such. However, this one is a basic control that everyone should implement.
3. Credential Guard in Windows 10 can also reduce risk of credential theft significantly.
How does Nanitor help ?
The Nanitor User Audit Report provides an overview of all Domain Admins and what assets they have logged in to. For example from our Demo environment:
And the User Profile gives the detail about where the user has been logged in:
Next we can set our policy in User Issue Settings:
This will create User issues for any Domain Admin account on a non-domain controller, so we can take action on it.
Conclusion
In summary, the recommended steps are to:
- Get visibility of Domain Admin accounts on Non-DCs. Check where you have Domain Admin profiles logged in. The results can and will be surprising.
- Implement policies to prevent mistakes
- Clean up profiles where mistakes have occurred and monitor to keep track.Set GPOs to prevent this from happening as discussed above
- Monitor for deviations and set up alerts
Last but not least: Take action.
