I’ve had lousy apps that need local admin perms on specific servers, but unless they need to do something on a domain controller, I just create AD groups that allow local admin perms on specific servers. (LocalAdmin_Server1 or LocalAdmin_SQLServers or LocalAdmin_ExchangeServers if there’s a group of servers). If it doesn’t need to do special stuff to a DC, I’ve been able to get by with non DA-accounts.
“We have been able to give them what they need in these cases without adding any more DA accounts. Most of the time it’s just a matter of making sure your AD objects are organized into the proper OUs.” <-- That. I’ve reorganized OU’s at various jobs for exactly this reason. Also, my Enterprise Admin and Schema admin groups are empty unless we have a specific need at the time. From: [email protected] [mailto:[email protected]] On Behalf Of Charles F Sullivan Sent: Thursday, June 30, 2016 7:02 AM To: [email protected] Subject: RE: [NTSysADM] Enterprise Admin best practice I don’t think we’ve come across such applications, fortunately for us. We have had IT folks say *they* need DA rights because they need to be in the Administrators group on a whole lot of computers or need to control a large number of AD objects. Or they want a *service account* to have DA rights. We have been able to give them what they need in these cases without adding any more DA accounts. Most of the time it’s just a matter of making sure your AD objects are organized into the proper OUs. We come across third party apps that need to use AD auth, but that generally just requires a regular domain user account with no rights other than the usual read-only rights that all AD users have. Of course your scenario may be entirely different than anything we’ve had to deal with. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Heaton, Joseph@Wildlife Sent: Wednesday, June 29, 2016 6:06 PM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Enterprise Admin best practice What do you do about applications that “need” domain admin rights? I think this is simply lazy coding on the vendors’ part, but sometimes we just can’t get the dang things working without DA. That’s our weakest point, we have a ton of service accounts in the DA group. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Charles F Sullivan Sent: Wednesday, June 29, 2016 7:22 AM To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Enterprise Admin best practice That’s more generous than what we do. The Enterprise and Schema Admins groups are empty, enforced by a Restricted Groups GPO setting. There is another one of these that limits membership in Domain Admins to just the 5 of us who are supposed to be. In the rare case where something needs Enterprise or Schema Admin rights, we temporarily add one of the domain admins via the respective Restricted Group setting. We only have one large domain, which makes this quite feasible. Possibly a more complex forest wouldn’t be. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Heaton, Joseph@Wildlife Sent: Tuesday, June 28, 2016 5:49 PM To: 'NT System Admin Issues Discussion list' <[email protected]<mailto:[email protected]>> Subject: [NTSysADM] Enterprise Admin best practice I remember hearing, I believe on this list, that the best practice for the Enterprise Admin role was to only have a service account in that role, with a very complex password, that is written down and locked in a file cabinet. I’ve just implemented that, but now I’m getting blowback. Does anyone have anything in writing that talks about this process, and that yes, this is best practice? Thanks, Joe Heaton Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to [email protected], delete this email and destroy all copies.
