So, it's essentially the same as a power user on a regular machine - they only reason they're not an administrator is because they don't want to be, or haven't done the research.
Kurt On Sun, Mar 7, 2010 at 00:56, Ken Schaefer <[email protected]> wrote: > An account that is in the BUILTIN\Administrators group on a DC has full > control over that DC, including the ability to run things as LocalSystem. > LSASS (which hosts the AD runs as LocalSystem) - so, effectively you have > control over that process. I'm sure you can know figure out a number of ways, > of varying amounts of effort, to have an account in the Administrators group > alter or update the directory so that they are now also in the Domain Admins > group (or any other group for that matter) > > Cheers > Ken > > -----Original Message----- > From: Kurt Buff [mailto:[email protected]] > Sent: Saturday, 6 March 2010 2: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” >>> account> 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/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
