[W2K3] Group Policy blijft toegepast na verwijdering

[EBOOZ]

Mensen,

Ik heb even jullie hulp nodig, want volgens mij zit ik met een tunneleffect na te denken over een oplossing.

Wij hebben hier een standaard beleid draaien die gebruikers bijvoorbeeld niet in staat stelt om "Uitvoeren" te gebruiken. Dit beleid wordt toegepast op de container met onze bedrijfsnaam. Hieronder zijn alle afdelingen in containers aangemaakt en deze containers bevatten weer alle gebruikers en computers van de betreffende afdeling. Een voorbeeldje:

- Bedrijf
+ Administratie
- Administratie
- Automatisering
- Controller
- Debiteuren beheer
+ Productie
- Extrusie
- Plak afdeling
- Snij afdeling
+ etc.

Het standaard beleid wordt geblokkeerd op de container Automatisering. In deze container zit ik zelf ook . Door deze blokkade was ikzelf altijd in staat om te kunnen werken zonder enige beperkingen.

Afgelopen vrijdag was ik wat aan het aanpassen in het programma "Group Policy Management" en zonder na te denken koos ik bij het standaard beleid op "Enforce". Vervolgens gold het beleid dus ook voor de afdeling Automatisering. Daarna heb ik Enforce maar weer uitgezet, maar de policy bleef toegepast worden!!

Hierna heb ik verschillende commando's/programma's/aanpassingen gedaan om de policy er uit te slopen. Allereerst begon ik met het uit zetten van de blokkade op de map Automatisering. Vervolgens een gpupdate /force er achteraan en daarna de stappen herhaalt met als uitzonderiing dat ik de blokkade nu weer had aangezet. Dit gaf geen resultaat.

Na een gpresult te hebben gedraaid zag ik dat er zowel als op mij als persoontje, als op mijn computer geen policy's werden toegepast.

Vervolgens maar eens bekeken met het commando SET of ik me wel bij een domeincontroller aanmeld... en ook dit was het geval.

Uit pure wanhoop heb ik toen het algemene beleid verwijderd. Na dit te hebben gedaan ging ik er vanuit dat alles was opgelost, maar neen... ik was nog steeds beperkt in mijn mogelijkheden. Naar aanleiding hiervan ben ik eens opzoek gegaan in de SYSVOL shares op de (3) domeincontrollers en het viel me op dat de policy hier nog wel stond. Deze heb ik toen ook maar verwijderd. Daarna maar weer een reboot van de server waar ik me standaard aanmeld en ook mijn computer weer opnieuw opgestart... maar wederom geen resultaat.

Kortom: er wordt geen policy toegepast volgens gpresult, maar ik wordt nog wel steeds beperkt! Ik merk aan gebruikers dat zij wel veranderingen zien qua beleidsinstellingen (door telefoontjes die ik heb gekregen), maar bij mijzelf veranderd er helemaal niets!

Ik kan me nog één oplossing bedenken en dat is het maken van een policy die voor de container Automatisering alle beperkingen opheft, maar ten eerste weet ik niet precies wat er door het algemene beleid werd geblokkeerd en ten tweede is dit zoveel werk dat ik dit echt als aller-aller-laatste optie wil doen.

Daarom de vraag... heeft iemand suggesties?

Alvast bedankt!

[Wimlem]

is het niet zo dat als de policy op enabled gestaan heeft, dat je dan weer het tegenover gestelde moet kiezen om de wijzingen ongedaan te maken ?

[mookie]

als je de policy niet meer gelinked hebt moet het al goed zijn.
Wel moet je b.v. op je PC even GPUPDATE /FORCE draaien.
Dan weet je zeker dat je cleane policies hebt.

Overigens blijven die policies altijd in de netlogon staan.
Als ze niet gelinked zijn moet dat niet uitmaken.

[mookie]

en doe eens een gpresult in een command prompt.
Post de uitvoer maar eens, dan zie je gelijk of de policy nog actief is en zo ja van waaruit.

[sanfranjake]

Wat is er allemaal te vinden in je eventlogs, en userenv.log? En hebben alle users uit die Automatisering-OU dit probleem?
En geeft rsop.msc nog aan dat de settings uit een policy komen, zoja welke? En heeft een nieuwe user in die OU dit ook, en jij met een schoon profiel?

[EBOOZ]

sanfranjake schreef op maandag 20 november 2006 @ 22:20:
Wat is er allemaal te vinden in je eventlogs, en userenv.log? En hebben alle users uit die Automatisering-OU dit probleem?
En geeft rsop.msc nog aan dat de settings uit een policy komen, zoja welke? En heeft een nieuwe user in die OU dit ook, en jij met een schoon profiel?

Alleen de Automatisering-OU heeft er last van! De overige gebruikers (waar de policy voorheen wel op werd toegepast) merken juist dan de policy niet meer werkt. RSoP geeft helemaal niets aan. Alles wijst erop dat er geen policy wordt toegepast

Dat met die nieuwe gebruiker moet ik morgenochtend even gaan testen. Daar was ik nog niet opgekomen.

EbOoZ schreef op maandag 20 november 2006 @ 16:25:
Hierna heb ik verschillende commando's/programma's/aanpassingen gedaan om de policy er uit te slopen. Allereerst begon ik met het uit zetten van de blokkade op de map Automatisering. Vervolgens een gpupdate /force er achteraan en daarna de stappen herhaalt met als uitzonderiing dat ik de blokkade nu weer had aangezet. Dit gaf geen resultaat.

Na een gpresult te hebben gedraaid zag ik dat er zowel als op mij als persoontje, als op mijn computer geen policy's werden toegepast.

Beide heb ik al meedere keren uitgevoerd, maar ik krijg geen veranderingen in m'n policy.

[DaRealRenzel]

Elke setting in een Policy is in feite een wijziging in de Registry. Als jij dus door iets te 'enablen' aan gezet hebt, staat er bijv. een 1 in de reg key. Om dit weer uit te zetten zal je dus de key ofwel moeten verwijderen, of weer op waarde 0 zetten.

Een hele hoop GPO settings maken reg keys effectief aan, simpelweg omdat ze standaard niet bestaan (omdat ze geen effect hebben op een default systeem). Probleem is nu dat je met jou actie een key hebt gecreeerd, dus die moet je met een omgekeerde policy ook weer uitzetten.

3-position setting: Disabled, Enabled, Not Defined. Not Defined betekend altijd dat de huidige setting gehandhaaft blijft.

[EBOOZ]

Ja precies... dat wordt dus keurig een nieuwe policy aanmaken die alles uit zet

Het is helaas niet anders!

[downtime]

DaRealRenzel schreef op maandag 20 november 2006 @ 23:24:
Elke setting in een Policy is in feite een wijziging in de Registry. Als jij dus door iets te 'enablen' aan gezet hebt, staat er bijv. een 1 in de reg key. Om dit weer uit te zetten zal je dus de key ofwel moeten verwijderen, of weer op waarde 0 zetten.

Een hele hoop GPO settings maken reg keys effectief aan, simpelweg omdat ze standaard niet bestaan (omdat ze geen effect hebben op een default systeem). Probleem is nu dat je met jou actie een key hebt gecreeerd, dus die moet je met een omgekeerde policy ook weer uitzetten.

3-position setting: Disabled, Enabled, Not Defined. Not Defined betekend altijd dat de huidige setting gehandhaaft blijft.

Bijna goed. Als de instelling geregeld wordt in de lokale policy, zal het verwijderen van de domain policy ertoe leiden dat de lokale policy voortaan de instelling bepaald. De facto betekent dat dat de instelling terug gedraaid wordt naar de situatie voordat je een domain policy instelde.
Dit gaat mis als het om een instelling gaat die niet in de lokale policy geregeld is. In dat geval zal het verwijderen van de domain policy niet tot het terug draaien van die instellingen leiden.

[EBOOZ]

Dan wordt het dus een nieuwe anti-policy aanmaken Er wordt bij ons in het netwerk bedrijf helemaal niets lokaal geregeld, alles gaat via de servers.

Bedankt voor de hulp!

[ Voor 4% gewijzigd door EBOOZ op 20-11-2006 23:41 ]

[EBOOZ]

Het is gelukt met een policy die de algemene policy settings ongedaan maakt!

[Verwijderd]

DaRealRenzel schreef op maandag 20 november 2006 @ 23:24:
Elke setting in een Policy is in feite een wijziging in de Registry. Als jij dus door iets te 'enablen' aan gezet hebt, staat er bijv. een 1 in de reg key. Om dit weer uit te zetten zal je dus de key ofwel moeten verwijderen, of weer op waarde 0 zetten.

Een hele hoop GPO settings maken reg keys effectief aan, simpelweg omdat ze standaard niet bestaan (omdat ze geen effect hebben op een default systeem). Probleem is nu dat je met jou actie een key hebt gecreeerd, dus die moet je met een omgekeerde policy ook weer uitzetten.

3-position setting: Disabled, Enabled, Not Defined. Not Defined betekend altijd dat de huidige setting gehandhaaft blijft.

als je het hebt over ntconfig.pol (geloof dat tie zo heette, nt4 is prehistorie ) heb je gelijk.

maar dat policies in het algemeen registry waardes zijn is complete BULLSHIT. registry waarden kunnen gezet worden met policies, maar policies op zich werken juist niet via de registry (simpel bewijs, veel registry settings worden actief bij een boot/opstarten, maar policies worden gerefreshed en worden niet alleen bij opstarten actief. Dit in tegenstelling tot ntconfig.pol).

[Verwijderd]

Elke policy die ge instelt onder 'Administrative Templates' (zou niet weten hoe het in het nederlands noemt), zijn wel degelijk regkeys.

Voor usergebonden policies zit dit onder HKCU/Software/Policies. Deze key wordt elke keer tijdens het aanloggen (en default ook nog om de 90 minuten) opgebouwd. Zogenaamde 'Managed Policy' settings worden dan hierin weggeschreven ipv. onder de normale keys (HKCU/Software/Fabrikant/Pakket/...) Software die met Managed Policy werkt leest zijn waardes dan hieruit, en niet vanuit de normale plaats.

Als je een policy weghaalt, dan wordt deze key niet meer opgebouwd tijdens het aanlogproces en zijn alle settings weg en is je user terug 'policyvrij'.

Als je echter 'niet managed' policies gebruikt dan worden deze hard weggeschreven onder de normale keys en ook niet verwijderd/aangepast bij het verwijderen van de policy.


Voor computerbased policies zit dit onder HKLM/Software/Policies.