Menigeen heeft geen idee wat het is, maar als je je erin verdiept,
dan kan dit een boel ‘vreemde zaken’ verklaren.
Zo werd ik betrokken bij een issue van een klant dat al lange tijd speelde.
Op een of andere manier raakten zij steeds rechten ‘kwijt’ op bepaalde accounts.
Zij hadden op een aantal OU’s rechten uitgedeeld (delegation of control) aan een specifiek account.
In dit geval ging het om een SharePoint serviceaccount dat rechten moest krijgen om foto’s
(thumbnailphoto attribute) en andere gegevens bij te werken voor gebruikersaccounts.
Zo kunnen gebruikers op de MySite zelf hun gegevens bijwerken, terwijl deze dan ook netjes in AD worden aangepast.
Echter, bij een aantal accounts ging dit steeds mis.
Bij een groot aantal gebruikers werd steeds het inherit vinkje uitgeschakeld,
waardoor de aangepaste rechten op een bovenliggende OU niet werden toegepast.
Bovendien werden de rechten gereset, zodat ze ook bij handmatig instellen steeds werden gereset.
Resultaat: Delegation of control werkte niet en dus ging de SharePoint synchronisatie ook steeds mis…
Verantwoordelijk hiervoor bleek het AdminSDHolder proces.
Het AdminSDHolder proces:
Binnen AD bestaan zogenaamde ‘Protected Groups’.
(Zie voor een lijst de bijlage onderaan)
Als een account lid is van een dergelijke groep, dan wordt elk uur het AdminSDHolder proces uitgevoerd.
Dit is een proces dat alle objecten beschermt die lid zijn van een ‘protected group’.
Staat het inherit vinkje dan aan, dan wordt dat door dit proces uitgezet en worden de rechten gereset.
Tevens wordt er een AdminCount waarde van 1 gezet (dit is standaard <NOT SET>) ten teken dat dit object ‘protected’ is.
Voor leden van protected groups geldt dat de rechten van de (lege) AdminSDHolder container worden vergeleken met die van het user object.
Zijn ze verschillend, dan worden de rechten van de AdminSDHolder container toegepast op de user.
Het idee achter het adminSDHolder proces is het beschermen van beheeraccounts. Stel immers dat een admin account lid is van
een OU waarop bijvoorbeeld de helpdesk rechten heeft gekregen om userobjecten aan te passen….
De Helpdesk zou dan dit admin account kunnen aanpassen, om dit soort zaken te voorkomen is er het adminSDHolder proces.
Het adminCount attribute:
Een protected object wordt als volgt weergegeven:
NIET protected : adminCount attribuut heeft geen waarde zoals hier te zien:
(<NOT SET> is de standaardwaarde, maar 0 geeft hetzelfde resultaat.)
WEL protected: adminCount attribuut heeft waarde 1:
Om bovenstaande te kunnen zien moet het ADSI view filter worden aangepast:
Klik CLEAR om de waarde te wijzigen. Hij verandert dan naar <NOT SET>.
Als we dit als test doen en apply geven, dan zien we direct dat de rechten van bovenaf keurig doorerven op dit object.
Echter, na een uur wordt dit dus weer ongedaan gemaakt als een object lid is van een protected group.
De AdminCount waarde wordt dan gereset naar 1 en het vinkje inherit wordt weer uitgeschakeld.
De rechten worden weer gereset naar de waarden die op de AdminSDHolder container van toepassing zijn…
De AdminSDHolder container
De standaard rechten op AdminSDHolder (Let Op: Advanced Features view moet aan staan!)
Deze worden dus elk uur toegepast op ‘protected’ objecten.
Standaard loopt dit dus elk uur (3600 seconden),
het kan ingesteld worden tussen 1 minuut (60s) en 2 uur (7200s) via de registry,
maar dit wordt uitdrukkelijk afgeraden en wel om de volgende redenen:
- Het instellen van een kortere interval kan een flinke impact hebben op de performance van AD
- De server (2000/2003) of de AD service (2008(r2))moet herstart worden om de wijziging actief te maken
- Het wijzigen van dit soort waarden is sowieso niet verstandig vanuit beheerperspectief, het kan troubelshooting in de toekomst complexer maken omdat afgeweken worden van standaard waarden die normaliter geen aanpassing behoeven
- De instelling moet per Domain Controller worden gedaan, bij het verplaatsen van de PDC Emulator rol naar een andere DC kan dus een andere interval van toepassing worden, hetgeen verwarrend is.
Is de key niet aanwezig en dus wordt de standardwaarde van 1 uur gebruikt.
LET OP!
Is een gebruiker lid van een protected group (zie bijlage voor de lijst), dan treedt dus dit issue op,
maar ook als hij lid is GEWEEST van een groep, dan blijft het protected kenmerk staan.
Dit wordt dus NIET automatisch teruggezet!
Maar: Welke objecten zijn in mijn AD protected???
Het is handig om een overzicht te hebben van alle protected objecten, ofwel,
objecten waarbij de adminCount waarde op 1 staat.
Van deze objecten worden immers steeds de rechten gereset en het inherit vinkje uitgeschakeld!
Download het gratis programma ADFIND van www.joeware.net en voer het volgende commando in:
Voor het zoeken van protected USERS:
AdFind.exe -b DC=<DOMEIN>,DC=<NAAM> -f "&(objectcategory=person) (samaccountname=*) (admincount=1)" –dn
Met de toevoeging >export.txt exporteer je het resultaat naar een TXT file.
Je kunt dit commando ook gebruiken voor het opvragen van protected GROEPEN:
AdFind.exe -b DC=<DOMEIN>,DC=<NAAM>-f "&(objectcategory=group) (admincount=1)" –dn
Een goed optie is ook het gebruiken van de standaard aanwezige commando's zoals onderstaande voor groepen EN users:
dsquery * -filter
"&(|(objectcategory=user)(objectcategory=group))(admincount=1)"
-l -attr distinguishedname -limit 0
Mocht je de adminCount waarde van objecten willen resetten, dan kan dat met het script op
DEZE pagina. Dit script zet alle adminCount waarden op 0. Als vervolgens het AdminSDHolder
proces weer draait, dan worden alle accounts die lid zijn van een protected group
automatisch weer protected gemaakt (adminCount waarde wordt weer 1).
Gebleken
is dat dit script niet in elke omgeving goed werkt (bij mij werkte het prima), vandaar HIER
een alternatief script.
Je kunt eenvoudig controleren of het adminSDHolder proces draait door enige tijd na het
draaien van het vbscript de adfind commando’s te gebruiken.
Blijft over de vraag waarom het bij deze klant om een groot aantal gebruikers ging die als ‘protected’ werden aangemerkt.
Welnu, men had in het verleden ooit de groep ‘Domain Users’ lid gemaakt van ‘Print Operators’.
Print Operators is protected en aangezien protected groups ‘transitive’ zijn, werd ‘Domain Users’ ook protected
en daarmee dus accounts die weer in ‘Domain Users’ zaten. Dit bleef onopgemerkt, totdat
men ging werken met Delegation of control, ofwel, het toekennen van rechten voor het SharePoint
serviceaccount aan een OU. De oplossing was eenvoudg; het verwijderen van ‘Domain Users’
uit “Print Operators’, het resetten van de adminCount waarde op deze groep en vervolgens middels
het genoemde VBScript het resetten van alle accounts.
Het gaat overigens ook mis als gebruikers lid zijn van admin groepen, terwijl
de gedelegeerde rechten wel op hen van toepassing moeten zijn.
In dit geval: Is een account in gebruik als beheeraccount, terwijl
het SharePoint serviceaccount dit account moet kunnen wijzigen, dan kan dat dus niet…
Zou dit dan een goede reden zijn om beheerders een separaat gebruikers- en beheeraccount te geven 
(en dus niet je beheeraccounts als standaardaccount gebruiken….)
(Nu kun je natuurlijk vast de default rechten van de adminSDHolder container wijzigen, of het serviceaccount domweg lid maken van
domain admins, maar laat ik verder niet ingaan op de wenselijkheid van dat soort ‘oplossingen’…)
Kortom, je bent nu op de hoogte van het bestaan en de werking van het adminSDHolder proces.
Heb je direct een goede reden om beheer- en dagelijks gebruik te scheiden middels separate accounts…
(voor diegenen die dat al deden: Goed bezig!)
BIJLAGE: Lijst protected groepen.
De volgende groepen zijn standaard ‘protected’
In Windows 2000 voor SP4: (Gebruikt iemand dat nog???)
- Enterprise Admins
- Schema Admins
- Domain Admins
- Administrators
Windows Server 2000 SP4 of hoger:
- Enterprise Admins
- Schema Admins
- Domain Admins
- Administrators
- Account Operators
- Server Operators
- Print Operators
- Backup Operators
- Cert Publishers
Voor Windows Server 2008 (R2) extra toegevoegd:
- Read Only Domain Controllers
De volgende gebruikers zijn ook standaard protected.
- Administrator
- Krbtgt (in 2003 geïntroduceerd, in 2008 R2 weer verdwenen.)
NB: Het is (tot op zekere hoogte) mogelijk om te bepalen welke groepen protected zijn.
Kijk HIER voor meer informatie daarover.