Fortunately I never really have to demonstrate these kinds of things - if I can show documentation that it's not a best practice and I can validate it with some "examples" (blogs, etc) then that's all they need.
Dave -----Original Message----- From: Kurt Buff [mailto:[email protected]] Sent: Friday, March 05, 2010 10:03 AM To: NT System Admin Issues Subject: Re: BuiltIn\Administrators group on a DC Actually, I'm not really satisfied, but it's not his job to tell me if I can find out on my own. The reason I want to know is that if I can't demonstrate it to a manager, preferably in a test environment, they will most likely make a stupid decision at some point. Kinda like what you're going through now. Kurt On Fri, Mar 5, 2010 at 09:41, David Lum <[email protected]> wrote: > I'm actually fine with his answer (I'm sure you are too actually ). I don't > want to know how to do this, but I am glad to know that it's a consideration. > > I found this on an Expert's Exchange post and like it a lot: "The difference > between making a user a member of Administrators on a DC versus making them a > Domain Admin is an implementation detail - for example, Domain Admins are > members of the local Administrators group on each domain-joined workstation > and member server, BUILTIN\Administrators are not, and BUILTIN\Administrators > is a Domain Local group whereas Domain Admins is a global group. So making a > user a Domain Admin will automatically profer certain rights to domain-joined > workstations and servers that BUILTIN\Administrators does not...but at the > end of the day a member of BUILTIN\Administrators on a DC still has the > effective rights of a Domain Admin, and so a determined user could figure out > how to grant themselves whatever rights they don't have by default on > workstations/member servers. > > From a security perspective, BUILTIN\Administrators membership should be > treated as the security equivalent of Domain Admins, even though there are > certain implementation details that may differ.” > > Ultimately, it *is* about what I expected to hear about that account. > > Dave > > -----Original Message----- > From: Kurt Buff [mailto:[email protected]] > Sent: Friday, March 05, 2010 9:21 AM > To: NT System Admin Issues > Subject: Re: BuiltIn\Administrators group on a DC > > Spoilsport! > > Heh. > > On Fri, Mar 5, 2010 at 08:41, Michael B. Smith <[email protected]> wrote: >> Builtin\administrators require one step – which I’m not going to document >> here – to make themselves a domain admin. >> >> >> >> Regards, >> >> >> >> Michael B. Smith >> >> Consultant and Exchange MVP >> >> http://TheEssentialExchange.com >> >> >> >> From: David Lum [mailto:[email protected]] >> Sent: Friday, March 05, 2010 11:39 AM >> To: NT System Admin Issues >> Subject: BuiltIn\Administrators group on a DC >> >> >> >> Is it true that just because a normal domain account is a member of this >> group on a DC that they do *not* have the same permissions as a domain >> admin? >> >> >> >> I want to know of this statement is correct: >> >> ---------------------------------------------------- >> >> “If this service account could log on to the DC locally or via RDP (it can’t >> due to a GPO we have for service accounts) then it could (in theory) access >> the ADUC console but even then it cannot do anything because since it’s not >> a member of Domain Admins or any group allowed delegation. >> >> >> >> Example, adding a user account, the ADUC console tests <domain>\<service >> account> against the “allowed to create user account in the domain” ACL, and >> BuiltIn\Administrators isn’t on that list. >> >> ---------------------------------------------------- >> >> >> >> What we’re trying to do is allow a program that requires local admin rights >> to install a program on a 2003 DC w/out making it a domain admin, and my >> understanding is BuiltIn\Administrators can do this. >> >> David Lum // SYSTEMS ENGINEER >> NORTHWEST EVALUATION ASSOCIATION >> (Desk) 971.222.1025 // (Cell) 503.267.9764 >> >> >> >> >> >> >> >> >> >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
