now, before start, let in on secret: this on domain controller.*
*the above statement stricken due irrelevance significant change occurs local administrator account , local administrator group (within context , scope of question) minimal , doesn't alter outcome enough require differentiation.
i didn't have kind of trouble on of other servers , i willing bet reason behind because on dc.*
*same reason stated above. accepted answer explains inconsistency , oversight on part, not architecture (read features) of windows security or domain controllers.
i have been playing around few ideas on how check if script has been called account either local administrator or, @ least, called account part of local administrators group.
i have renamed local admin account, however, know can see if script has been called local admin account typing:
(new-object system.security.principal.ntaccount('reserved')).translate([system.security.principal.securityidentifier]).value
and can see if sid ends in -500
.
the problem occurs when run condition see if calling account part of administrators group (which larger scope) typing:
ps> [bool](([system.security.principal.windowsidentity]::getcurrent()).groups -match "s-1-5-32-544") ps> false
a quick check see account using:
ps> $env:username ps> reserved
or needlessly complicated way (though prefer sometimes):
ps> write-host ((get-wmiobject win32_account | ?{$_.sid.substring($_.sid.length-4,4) -eq '-500'}).caption).split("\",2)[1] -fore green ps> reserved
and type:
ps> net user reserved
where tells me local group memberships *administrators
.
i pull aduc (dsa.msc
) , in builtin
container , double-click on administrators group. select members tag , lo, , behold, reserved
member!
so, recap:
by typing
net user reserved
, able verify part of local administrators groupi looked in aduc , verified reserved member of builtin administrators group
i ensured reserved indeed local administrator account verifying sid started
s-1-5...
, ended...-500
to take step further, made sure sid matched active directory group named "administrators" typing
get-adgroup -identity "administrators"
. typedget-adgroupmember -identity "administrators"
, made surereserved
listed (it , sid matched!).when check see if well-known administrators group sid found in groups of account (by getting current windows identity), says isn't.
what gives?
why every indication member of local administrators group sid isn't found in account's groups?
when computer promoted domain controller, there no more local users or groups on machine. member computers have local users , groups, , can use domain users , groups authentication, on dc, there domain objects.
see also: https://serverfault.com/a/264327/236470
Comments
Post a Comment