Aantal policies op domeincontroller niet afgedwongen

[Eagle Creek]

Hi!

Via mijn default DC policy wil ik op mijn DC (Functional level 2008R2, enige DC in domein) 3 zaken bewerkstellingen:
- Het inschakelen van het Administrator-account
- Het uitschakelen van het Gast-account
- Het hernoemen van het Administrator-account

Daar ik de eerste twee policies op mijn DC wil uitvoeren, dwing ik ze dus af op mijn domeinaccounts. Ik vermoed dat deze niet worden uitgevoerd omdat 1) Het Administrator-account beschermd is ([size=1]Sinds Win 2000 SP IV geloof ik[/size]).
2) Het domein geen gast-account kent.

Ik ontvang hier echter geen melding van. Wanneer ik een RSOP opvraag, zie ik dat beide policies niet defined zijn, en wanneer ik de local group policy editor open op de DC, kan ik beide instellingen wijzen. Ik vermoed dus dat de group policy een wijziging wil doorvoeren op domeinniveau (en daarmee de accounts niet kan bewerken), maar de lokale policy de wijzigingen ook lokaal wil doorvoeren. Dit verbaast mij licht, daar op een DC "lokaal" het domein is.

Evenwel heb ik een groter probleem. Het hernoemen van het Administrator-account gaat niet goed. Wanneer ik dit opgeef in de Default DC policy, en mijn DC RSOP krijg ik het volgende te zien:


Na een GPUpdate haal ik de volgende gegevens uit de winlogon.log:

code:

----Configure Security Policy...
    Configure password information.

    System Access configuration was completed successfully.
    Configure machine\software\microsoft\windows\currentversion\policies\system\disablecad.
    Configure machine\software\microsoft\windows\currentversion\policies\system\dontdisplaylastusername.
    Configure machine\system\currentcontrolset\control\lsa\forceguest.
    Configure machine\system\currentcontrolset\control\lsa\limitblankpassworduse.
    Configure machine\system\currentcontrolset\services\lanmanserver\parameters\enablesecuritysignature.
    Configure machine\system\currentcontrolset\services\lanmanserver\parameters\requiresecuritysignature.
    Configure machine\system\currentcontrolset\services\netlogon\parameters\requiresignorseal.
    Configure machine\system\currentcontrolset\services\ntds\parameters\ldapserverintegrity.

    Configuration of Registry Values was completed successfully.

    Audit/Log configuration was completed successfully.

    Kerberos Policy configuration was completed successfully.


----Configure available attachment engines...

    Configuration of attachment engines was completed successfully.


----Un-initialize configuration engine...

- De in- en uitgeschakelde status van Administrator en Guest zie ik hier niet voorkomen.
- De naamswijziging van Administrator zie ik hier niet voorkomen.

Dat laatste kan kloppen, want er is geen eens een poging gedaan om de naam te wijzigen.

Op een site kwam ik tegen dat dit ermee te maken zou kunnen hebben dat de accountnaam al bestaat. Dit is echter niet het geval. Om hier zeker van te zijn heb ik meerdere namen geprobeerd.
Tevens las ik dat Power Users in de weg konden zitten, maar voor zover ik weet zijn die vervallen sinds Windows 2008.

Om e.e.a. uit te proberen heb ik vervolgens in de local policy de naam gewijzigd. Wanneer ik nu kijk bij "control userpasswords2" zie ik twee account: die van mij, en die van een gewijzigde administrator. In de AD is dit echter niet gebeurt, en heet het account nog steeds Administrator. Het lijkt er dus op dat de lokale administrator-account van naam is gewijzigd.

Ik kom daarmee dus bij mijn eindvraag: waarom wordt de policy niet toegepast, en moet moet ik mijn domein-administrator dan wél van naam laten veranderen?

PS: Ik kwam op Tomshardware een topic tegen waarbij een gebruiker in een Windows 2000 - NT 4.0-netwerk, zijn local administrators wilde wijzigen maar zijn domein-administrator (ongewenst) meegewijzigd werd. Dit is dus zeg maar wat ik wil bereiken, maar hij had dit als standaardgedrag. De toelichting die hierop werd gegeven, was dat wanneer je een policy toepast op een DC, de accountpolicies gelden voor de AD. Echter: in Windows NT 4.0, en eerdere versies van 2000 (RTM t/m SP3), was Administrator volgens mij nog niet beschermd, alleen Administrators.

[alt-92]

Denkfout.

Wat heb je nou niet op een DC?

[sanfranjake]

Inderdaad by design..... Administrator is een lokaal account op een domeincontroller, dus een domeinaccount. Ik zou 'm zelf renamen en zorgen dat dit niet teruggedraaid kan worden door met delegation of control te werken, ipv gebruikers Domain Admins te maken als ze enige vorm van beheertoegang nodig hebben tot enig onderdeel van je netwerk

[Eagle Creek]

Denkfout? Ik zie toch écht twee administrators.

Zoals ik zei: administrator op een DC is domain admin. Maarrr.... Als ik in de AD kijk zie ik "administrator", niet hernoemd. Wanneer ik echter "control userpasswords2" uitvoer zie ik twee accounts: die van mij en de hernoemde administrator!

Edit:
Wat ik zojuist ontdek:
Wanneer ik kijk in de AD zie ik "Administrator properties" --> logon name "Admin".
Hij heeft hem dus wél aangepast! Hij behoudt alleen echter wel de objectnaam Administrator.
Dit blijkt ook te werken!

De denkfout zat hem dus ergens anders .
Evenwel loopt de policy nog fout. Dit zal dan wel veroorzaakt worden door het feit dat hij een dergelijke policy niet door kan (mag) voeren op een DC.

Bedankt mensjes .

[Yalopa]

Waarom wil je een dergelijke GPO op een DC (los van het feit dat het logisch gezien niet klopt wat je probeert)

[Eagle Creek]

Yalopa schreef op zaterdag 12 december 2009 @ 11:21:
Waarom wil je een dergelijke GPO op een DC (los van het feit dat het logisch gezien niet klopt wat je probeert)

Licht je vraag eens toe wil je?

[Tags NL]

Ik zou het account gewoon zelf hernoemen en een dummy administrator account zonder rechten aanmaken, maar het blijft mogelijk om te zoeken naar de SID 500 accounts en het is dus alleen maar een kwestie van tijd...

[alt-92]

Sommigen noemen het Defense in depth, sommigen weer niet.
Het voorkomt in ieder geval dat amateurs of baldadige werknemers direct kunnen klooien, die struikelen hier al over (lees: die nemen de moeite niet om de sid eerst te resolven).

[Eagle Creek]

maar het blijft mogelijk om te zoeken naar de SID 500 accounts en het is dus alleen maar een kwestie van tijd...

Was het niet zo dat er in 2008 (or 2008R2) een policy geïntroduceerd was om dit te voorkomen? Ik weet zeker dat ik ergens gelezen heb dat er een policy bestaat die het uitlezen van SID's voorkomt teneinde administratieve accounts te beschermen.

En los daarvan: het is weer een extra drempeltje, geen heilige graal . Zoals alt-92 al zegt houd je hier al weer wat gepeupel mee buiten de deur.

(owja, mocht je het afvragen: nee ik gebruik geen "admin" als hernoeming )

[ Voor 14% gewijzigd door Eagle Creek op 16-12-2009 12:33 ]

[alt-92]

Eagle Creek schreef op woensdag 16 december 2009 @ 12:32:
Was het niet zo dat er in 2008 (or 2008R2) een policy geïntroduceerd was om dit te voorkomen? Ik weet zeker dat ik ergens gelezen heb dat er een policy bestaat die het uitlezen van SID's voorkomt teneinde administratieve accounts te beschermen.

..en de lieve inbrekert luistert daar natuurlijk ook netjes naar

[Eagle Creek]

Zoals gezegd staat mij er alleen iets van bij: als deze policy de uitvraag simpelweg blokkeert dan zal die inbreker wel moeten. Als het net zoiets is als het activeren van een DHCP-server, waar alleen Windows-machines naar luisteren, dan niet natuurlijk .