Managing and securing the Domain Administrator ?

[albertwt]

Hi People,

I'd like to know what's your suggestion or the practice in your organization about the usage of DOMAIN\Administrator account ?

At the moment my Windows servers in the domain can all be accessed by this domain administrator and do everything, however this is not the best practice according to the Security Auditor and my Risk manager.

Please share your experience and thoughts here.

Thanks.

[pete]

edit: Dammit - you mean THE "Administrator" domain admin account don't you?

Yeah, they're right - you shouldn't be using it except in situations (certain domain actions) that depend on it. We disable the account and set a complex password.

Every Admin should have their own appropriately named Domain Admin account - i.e "Bob-NCA"*

-------- Original response ---------

That's kind of the idea behind the Domain Admin accounts. If your security auditor / risk manager doesn't understand that they need beating / replacing. There's no point attempting to limit/cripple Domain Admin accounts because a) they can undo it trivially and b) you will break poorly written / documented software c) you will be considered "unsupported' by Microsoft. See an AD Team blog that rants about this here:

Forcing Domain Admins to use AGPM (but not really) - Ask the Directory Services Team - Site Home - TechNet Blogs

What you can do is employ good admins, don't treat them like slaves and ensure Domain Admin accounts are used appropriately and audit that use. Trust, but verify.

i.e it's simple to create differentiated accounts. If all I need to do is update $driver on a local machine / server I don't need domain admin access to do it - local admin access will be fine. Adding a domain group (say "workstations admins") to local administrators on workstations and making your trainee tech a member of workstation admins allows him to do his work, but not inadvertantly mess up a server. Making a "Server admins" group members of the local admins group on certain servers accomplishes the same thing.

Smaller shops tend not to have differentiated permission groups at the admin level, bigger shops do.

Shipping event logs (via Windows event forwarding, Splunk, snare, Ossec) also ensures that deleting logs on the workstation / server won't cover tracks. Using a host-based IDS (I use Ossec - s' cross-platform) also details modified files according to rules you set up.

You simply need to show that a) that's the purpose of domain admin accounts b) domain admin access is limited to trusted and qualified people c) how you audit and log that access d) how you ensure it's not used by lazy admins rather than setting up proper permissions.

*Firstname-Nil Coitus Alto

[sdc]

As a very simple start, renaming the account to something other than 'administrator' isn't a bad a idea. We also don't use accounts with domain admin rights unless we specifically need to.

[albertwt]

edit: Dammit - you mean THE "Administrator" domain admin account don't you?

Yeah, they're right - you shouldn't be using it except in situations (certain domain actions) that depend on it. We disable the account and set a complex password.

Every Admin should have their own appropriately named Domain Admin account - i.e "Bob-NCA"*

-------- Original response ---------

That's kind of the idea behind the Domain Admin accounts. If your security auditor / risk manager doesn't understand that they need beating / replacing. There's no point attempting to limit/cripple Domain Admin accounts because a) they can undo it trivially and b) you will break poorly written / documented software c) you will be considered "unsupported' by Microsoft. See an AD Team blog that rants about this here:

Forcing Domain Admins to use AGPM (but not really) - Ask the Directory Services Team - Site Home - TechNet Blogs

What you can do is employ good admins, don't treat them like slaves and ensure Domain Admin accounts are used appropriately and audit that use. Trust, but verify.

i.e it's simple to create differentiated accounts. If all I need to do is update $driver on a local machine / server I don't need domain admin access to do it - local admin access will be fine. Adding a domain group (say "workstations admins") to local administrators on workstations and making your trainee tech a member of workstation admins allows him to do his work, but not inadvertantly mess up a server. Making a "Server admins" group members of the local admins group on certain servers accomplishes the same thing.

Smaller shops tend not to have differentiated permission groups at the admin level, bigger shops do.

Shipping event logs (via Windows event forwarding, Splunk, snare, Ossec) also ensures that deleting logs on the workstation / server won't cover tracks. Using a host-based IDS (I use Ossec - s' cross-platform) also details modified files according to rules you set up.

You simply need to show that a) that's the purpose of domain admin accounts b) domain admin access is limited to trusted and qualified people c) how you audit and log that access d) how you ensure it's not used by lazy admins rather than setting up proper permissions.

*Firstname-Nil Coitus Alto

yes that's what I'm talking about, the Enterprise Administrator account.

I agree, what I should do is to securely keep and manage the usage of that account, we have rename it to something else but of course the SID stays the same -500 which means that this is still the super admin account if the attacker knows it.

log shipping into dedicated syslog server ? how can we do that on the desktop and Windows server 2003/2008 ?
for Linux and CISCO devices yes, we've been using that and I know how to set it up.

[Admiral208]

you shouldnt be using the domain administrator account. create a new account with a different name and give it the rights to perform administrator actions, then disable the administrator account. If you need to do anything with this account, you can use Run As...