Policies toepassen op Windows 2003, SteadyState-uitwerking.

[DJVG]

Hallo jongens.


Ik zit met het volgende:
Ik heb een computer (Win2003) waar ik diverse policies wil toepassen. Andere gebruikers mogen maar zeer weinig zaken doen, waar ik als admin uiteraard niet beperkt mag worden. Wanneer ik gpedit.msc gebruik dan worden die instellingen voor alle gebruikers toegepast, inclusief het admin-account.
Wanneer ik de group policy snap-in installeer (omdat ik weet dat ik hiermee aan kan geven voor welke groepen de policy moet gelden) krijg ik de mededeling dat ik deze moet openen via een domein-logon, wat hier niet van toepassing is.

Nu weet ik dat er voor XP SteadyState beschikbaar is om deze policies te leggen. Het aanmaken van een account op XP en vervolgens kopieëren naar 2003 werkt niet, maar ook binnen XP valt dit niet te kopieëren naar een andere account (wat ik wel had verwacht. Mogelijk omdat SteadyState toch nog anders werkt dan SCTK). Ik kan deze dus ook niet gebruiken voor de default user.

Wat ik eigenlijk wil is de accounts dichtzetten en vervolgens zo'n beperkt account kopieëreren. Eventueel per gebruiker de policy uitgevoerd, of de gebruiker kopieëren naar default.

Een alternatief is een AD opzetten maar aangezien deze AD óók een TS zou zijn, brengt dit een aanzienlijk risico met zich mee.

Met vriendelijke groet,
DJVG

[alt-92]

HOW TO: Apply Local Policies to All Users Except Administrators on Windows Server 2003 in a Workgroup Setting

[google=group policies workgroup 2003 server]

Goed startpunt lijkt me - overigens blijf je met steadystate nog met een host aan andere problemen zitten (tijd, applicatiepatches).

[ Voor 7% gewijzigd door alt-92 op 08-03-2009 22:08 ]

[DJVG]

Nu kan ik handmatig bij alle gebruikers een .man-profiel instellen waardoor ik maar één profiel hoef in te stellen. Maar dan nog moet ik op een of andere manier één profiel in kunnen stellen. En of ik die dan naar de default verplaats, of allemaal naar één verwijs, maakt dan ook niet zoveel meer uit.

Kortom: als ik maar de gewenste instellingen kan maken aan een gebruikersprofiel ben ik happy.


Ik ga jouw link zeker even doornemen. Ik vraag me ook af of dat in een XP-omgeving geldt maar dat ga ik doorlezen.

Wat bedoel je precies met "andere problemen"? Ik snap je andere voorbeelden niet helemaal.

[DJVG]

Hi,

Heb het doorgenomen en vind het nogal een complexe procedure.. Daar komt bij dat ik ook gebruikers overtijd zal toevoegen en dat ik, zo te zien, elke keer deze hele procedure opnieuw zal moeten doorlopen, inclusief het eerst herstellen van de policies.

Eigenlijk mag dit wel een manco genoemd worden vind ik. Ik begrijp dat policies voornamelijk in domeinen worden toegepast maar het is wel degelijk mogelijk om policies snel een eenvoudig aan te passen op een stand-alone machine. Dat hier vervolgens geen lokale gebruikers en groepen gekozen kunnen worden lijkt me een ernstige tekortkoming.

Ik ga ervan uit dat dezelfde procedure toegepast kan worden op workstations.

Wat ik mij dan wel afvraag: binnen Windows worden veel (zoniet alle) policies opgeslagen in het register. Je zou dan toch zeggen dat je deze informatie op de een of andere manier kan exporteren/importeren. SteadyState maakt namelijk een locked-down profiel aan en het zou zeer prettig zijn als je dit kon kopieëren naar andere profielen, of de default user, zoals je dat met andere instellingen probleemloos kunt doen.

[Question Mark]

DJVG schreef op zondag 08 maart 2009 @ 22:34:
Wat ik mij dan wel afvraag: binnen Windows worden veel (zoniet alle) policies opgeslagen in het register.

Nee, een policy is een combinatie van files.

De client side extensions (soort agents) op een werkplek lezen deze files in en afhankelijk van de instellingen in deze policy worden rechten op filesystem, aanpassingen in local groups of registryaanpassingen doorgevoerd.

Het is dus niet zo dat de policy in de registry opgeslagen is.

Ben het overigens wel met je eens dat standalone servers slecht in te richten zijn middels Policy's.

[alt-92]

DJVG schreef op zondag 08 maart 2009 @ 22:34:
Hi,

Heb het doorgenomen en vind het nogal een complexe procedure.. Daar komt bij dat ik ook gebruikers overtijd zal toevoegen en dat ik, zo te zien, elke keer deze hele procedure opnieuw zal moeten doorlopen, inclusief het eerst herstellen van de policies.

Euh?
Filteren op basis van security groepen is ook op een workgroup install mogelijk.

Dat lijkt me juist dé manier om het vervolgens makkelijker te beheren bij ontbreken van een DC/Domain.

Ik ga ervan uit dat dezelfde procedure toegepast kan worden op workstations.

correct.

SteadyState maakt namelijk een locked-down profiel aan en het zou zeer prettig zijn als je dit kon kopieëren naar andere profielen, of de default user, zoals je dat met andere instellingen probleemloos kunt doen.

Wat Question Mark al zegt, maar: wat let je om een standaard user(profile) te maken, die met de bovenstaande local GPO techniek dicht te zetten, en vervolgens als default profile te gebruiken?

Zelfs logonscripts kun je met een NETLOGON share emuleren als je dat wil

[Eagle Creek]

Filteren op basis van security groepen is ook op een workgroup install mogelijk.

Ik zoek ook al een tijdje zo'n dergelijke mogelijkheid. Kun je mij aanwijzen waar dit zit? De gpedit-console biedt hier, voor zover ik weet, geen mogelijkheid voor, maar ik zou het graag van je vernemen.

[ Voor 84% gewijzigd door Eagle Creek op 09-03-2009 10:53 ]

[alt-92]

Zit daar ook niet in, maar wie niet sterk is moet slim zijn:
Local policies (de .ini files en applied ADM templates) staan in C:\WINDOWS\system32\GroupPolicy .

Als je daar met NTFS Acls gaat filteren (read/execute) kom je ook een heel eind.
En met het bovenstaande artikel heb je sowieso een Admin account zonder policies, dus dat scheelt je dan ook al werk.

[Eagle Creek]

Hmm, slimmigheidjes houd ik wel van .

Als ik het goed begrijp zou dit kunnen werken:
- Wijzig de policies zoals gewenst.
- Zet de admin-account op deny op de policybestanden (dit kun je altijd herstellen mocht je wijzigingen willen aanbrengen)
- Laat gewone gebruikers inloggen.

Als dit correct is ga ik zodra ik thuis ben weer eens even rondneuzen. Ben niet geheel onbekend met dit soort zaken maar alles weten is voor niemand weggelegd . Ik neem aan dat DJVG hier ook mee geholpen is (want ik doe een beetje aan topictheft natuurlijk ).

[Question Mark]

Bovenstaande werkt (is exact wat ik ook ooit eens gebruikt heb), maar heeft twee beperkingen:

• Aangezien ook de Administrator niet bij de bestanden kan, kan hij ook geen policy-settings meer aanpassingen.
• Het is niet mogelijk om verschillende gebruikers(groepen) verschillende policy's mee te geven

.
Vandaar ook mijn eerdere opmerking dat policy's niet handig werken zonder domain

[Eagle Creek]

Question Mark schreef op maandag 09 maart 2009 @ 11:35:
Bovenstaande werkt (is exact wat ik ook ooit eens gebruikt heb), maar heeft twee beperkingen:

• Aangezien ook de Administrator niet bij de bestanden kan, kan hij ook geen policy-settings meer aanpassingen.
• Het is niet mogelijk om verschillende gebruikers(groepen) verschillende policy's mee te geven

.
Vandaar ook mijn eerdere opmerking dat policy's niet handig werken zonder domain

Dat eerste begrijp ik maar dat zal je niet regelmatig doen. Mocht je dit wel willen doen kun je met m.b.v. "owner" weer permissies instellen.

Maar vooralsnog lijkt het een aardige oplossing te zijn :thumb:.
Nu is Windows SteadyState wel een stuk sneller qua toepassen maar die is natuurlijk niet ontworpen voor Win 2003.

Wat mij betreft, bedankt!

(Klopt het dat jij je MSCA mist?)

[Question Mark]

Eagle Creek schreef op maandag 09 maart 2009 @ 11:44:
[...]
Dat eerste begrijp ik maar dat zal je niet regelmatig doen. Mocht je dit wel willen doen kun je met m.b.v. "owner" weer permissies instellen.

Tenzij je in de policy ingesteld hebt dat users geen toegang tot de C-schijf hebben. Op het moment dat de administrator weer rechten heeft op de policy geld deze instelling ook voor hem....

Heb je toevallig de policy-setting "run only allowed windows applications" ingesteld en ben je vergeten om "gpedit.msc" hier ook in te zetten, dan heb je ook een probleem...

Zo zijn er wel veel meer settings te verzinnen die toegang tot de policy files in theorie kunnen verhinderen. Via een andere machine is daar allemaal wel omheen te werken, maar het maakt het er niet beheersbaarder op.

[Eagle Creek]

Question Mark schreef op maandag 09 maart 2009 @ 11:55:

Tenzij je in de policy ingesteld hebt dat users geen toegang tot de C-schijf hebben. Op het moment dat de administrator weer rechten heeft op de policy geld deze instelling ook voor hem....

Snap ik maar wanneer je:
Log-in als admin.
Geeft rechten op policy.
Wijzigt instellingen.
Haalt rechten weg.
Log-off doet.

Moet het goed gaan, lijkt me?
Is wel een truukje van goed opletten want als je de admin uitsluit kan het nog interessant worden natuurlijk.

[Question Mark]

Klopt, maar ik heb één keer meegemaakt dat de policy weer toegepast werd op het moment dat ik deze aan het editten was (hoe groot is de kans...). Het kan allemaal wel, en het werkt ook wel maar het is inderdaad een truukje waarbij je goed moet weten wat je doet.

Question Mark was al MCSE2000 voordat MS startte met het MCSA traject. Dat traject is pas later opgezet.

[ Voor 5% gewijzigd door Question Mark op 09-03-2009 12:21 ]

[alt-92]

Question Mark schreef op maandag 09 maart 2009 @ 11:35:
Bovenstaande werkt (is exact wat ik ook ooit eens gebruikt heb), maar heeft twee beperkingen:


• Aangezien ook de Administrator niet bij de bestanden kan, kan hij ook geen policy-settings meer aanpassingen.

Runas met een 2e account die wel de GPO's kan editten

[Question Mark]

Dat zou een optie zijn, maar werkt "gpedit.msc" als de policy-setting "prevent access to local drives" enabled is?

Die setting wil je eigenlijk wel enabled hebben. Als de user de policy mag editten, betekend dat hij rechten op de files heeft en dat dus ook de policy enforced wordt.

[alt-92]

je hebt een admin account die er wel bij kan, en die (desnoods tijdelijk) ACLs op de GPO folder kan editten.
overigens trekt een non-Shell integrated applicatie zich alsnog niks van die policy aan (genoeg apps die hun eigen file/folder-open dialoogje maken) dus zo heilig is ie ook weer niet...

[Question Mark]

alt-92 schreef op maandag 09 maart 2009 @ 12:53:
overigens trekt een non-Shell integrated applicatie zich alsnog niks van die policy aan (genoeg apps die hun eigen file/folder-open dialoogje maken) dus zo heilig is ie ook weer niet...

MS Office icm de "hide drive option"

[ Voor 5% gewijzigd door Question Mark op 09-03-2009 12:58 ]