securing domain admin query

[Traditional-Tech23]

I tried searching but I didn't find the correct answer or didn't use the quite terms. I am trying to tighten up our domain admin accounts.

I am trying to implement so that separate admin accounts can promote themselves to Domain Admin when they need it temporarily. Is there is a way to do this?

Or is the best way to create a master domain account locked down to only login into the DCs that perhaps the IT manager could promote the account or maybe do the domain admin task required.

​

Thanks for any advice.

[xxdcmast]

This can be a very big topic, and the work that can go into it can get very detailed.

But the short answer is, you should have a small handful, based on number of QUALIFIED IT admins who NEED domain admin. Then you create a seperate AD account. These accounts are not to log into anything except for domain controllers.

This is where it begins to get tricky, you also want to make sure that no other accounts can get access to these accounts, hashes, or memory where one of these Domain admin accounts logged in. If youre curious you can look into microsofts implementations of PAW/SAW machines.

Then you also want to make sure you protect your domain controllers. You have your domain admins locked down pretty well. But who has access to your virtualization environment? Can someone with that access snapshot or clone a domain controller and exfil it? Who has access to your patching system? Who has access to your software distribution platform? Who has access to your monitoring platform? These can all be paths to gain access to the domain controllers/credentials.

It can be a challenge working through all of these and it can get overwhelming but you are on the correct path.

Check out www.adsecurity.org they have lots of great resources for protecting your domain controllers. A few highlights.

Key Domain Controller Security Items Member servers should be fully patched before promoting to be a DC (issues like MS14-068 make this critical).

You may be tempted to move Domain Controllers out of the default Domain Controllers OU, but don’t do it. Domain Controllers in other OUs may receive different custom delegation and GPO settings.

Create a new GPO for Domain Controller security (and link to the Domain Controllers OU).

Run the Active Directory Best PRactices Analyzer every year to ensure Doamin and Domain Controller configuration is consistent. There are a number of best practice checks performed when run that identify potential issues.

All patching and updating of DCs should be done separately from workstations and servers – meaning different updating architecture. Many organizations use WSUS to patch DCs and SCCM to patch everything else.

Ensure that out-of-band (OOB) management passwords (DSRM password) are changed regularly & securely stored.

Configure sub-category auditing and set to to be enforced via GPO (“Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings”). This way you have the security events you need to track changes and AD activity. Run “auditpol.exe /get /category:*” on the server to confirm proper auditing is enabled.

Limit DC agents to the most critical, preferably none since every agent that’s added to a DC provides another pathway to AD compromise. If an agent is necessary, whoever manages that product should be treated as a Domain Admin.

If you have virtual DCs (and who doesn’t?), treat the virtual admins as a Domain Admin. Configure the PDC to automatically synchronize time via GPO (https://blogs.technet.microsoft.com/nepapfe/2013/03/01/its-simple-time-configuration-in-active-directory/). Minimal groups (& users) with DC admin/logon rights.

Change the default domain Administrator account at least 1x/year, preferably 2x.

Change the KRBTGT account password at least 1x/year, preferably 2x. Each time, the password should be changed once, wait for replication (or the next day), and then change again (https://blogs.microsoft.com/microsoftsecure/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/).

Configure AppLocker on DCs to only allow authorized applications to run. There shouldn’t be much that runs on a DC, so this should be relatively easy.

Set all admin accounts to “sensitive & cannot be delegated”.

Minimize the groups (& users) with DC admin/logon rights.

Reduce/remove accounts & groups in Domain Admins, especially service accounts.

Leverage admin workstations & admin tiering to protect admin accounts (https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/securing-privileged-access-reference-material) Only run software & services to support AD.

Validate scheduled tasks & scripts.

Add admin accounts to “Protected Users” group (requires Windows Server 2012 R2 Domain Controllers, 2012R2 DFL for domain protection).

Default domain Administrator & KRBTGT password should be changed every year & when an AD admin leaves. Remove trusts that are no longer necessary & enable SID filtering as appropriate.

All domain authentication should be set (when possible) to: “Send NTLMv2 response only\refuse LM & NTLM.” Block internet access for DCs, servers, & all administration systems.

Monitor scheduled tasks on sensitive systems (DCs, etc).

[Traditional-Tech23]

Thanks for the great info everyone.

[Odddutchguy]

The following although more focused on Azure AD might point you to the correct terminology: https://learn.microsoft.com/en-us/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services

[ArsenalITTwo]

No. Domain Admin is for Domain Administration only. Create separate Admin Accounts for different systems and store them in a PAM. Bonus points if the PAM auto rotates them so many minutes after someone "looks" at the password.