Grouppolicy probleem met gebruikers onder een Terminalserver

[Verwijderd]

Ik wil graag voor verschillende groepen gebruikers verschillende grouppolicies hanteren op mijn terminalserver, maar heb hierbij nog een gecompliceerde factor: een verwijderde OU met een policy die ook weg is!
1. Hoe kan ik mijn verwijderde policy en OU (Organizational Unit) weer ´resetten´of de gebruikers die hieronder vielen weer terugzetten op mijn "oude" policy?
2. Hoe definieer ik op een juiste manier twee policies voor twee groepen gebruikers?

Situatieschets:
Naast mijn OU ´terminalserver´ heb ik een andere OU aangemaakt. Hierin heb ik een aantal gebruikers geplaatst. Dit heb ik gedaan omdat het schijnbaar niet mogelijk is meerdere policies juist te laten werken onder één OU. Ook niet na diverse opties, zoals block inheritance van andere policies en overrule opties uitgezet te hebben em de policy opnieuw te editten.
In de gebruiker wordt verwezen naar een andere primaire groep dan de gebruikers die in de oude OU ´terminalserver´ zitten

Vreemd genoeg kwamen er geleidelijk steeds meer gebruikers onder mijn (kleine) aangemaakte OU te zitten, terwijl ik NIET meer gebruikers eronder zette. Ook werd de policy van deze nieuwe groep (logischerwijs) toegepast op deze steeds groter wordende groep. De aangemaakte groep is vandaag helaas verwijderd. Nu zit die grouppolicy nog op deze oude instellingen vast en zitten bijna alle gebruikers (allemaal weer onder de originele OU ´terminalserver´) vast op een policy die niet aan te passen of te vinden is! Als ik in de grouppolicy van de OU ´terminalserver´ opties enable of disable heeft dit totaal geen effect.

Onder een gebruiker is duidelijk gedefinieerd dat deze niet als primaire groep Domain Users mag hebben (indien hij een andere policy moet hebben). Ik heb dus onder ´builtin´ een andere groep aan gemaakt en de gebruikers die een afwijkende policy moeten krijgen hieraan gekoppeld. Waar kan ik in mijn policy naar deze groep verwijzen? En moet ik onder ´Users´ ook een groep aanmaken. Voor Domain Users is namelijk onder Users een groep aangemaakt die member of een groep onder builtin is. Ik snap de toepassing van deze groepen niet helemaal.

[sanfranjake]

Een backup terugzetten ? Kijk anders in de Lost&Found OU, misschiendat daar toevallig nog iets staat

Dit soort dingen vindt Active Directory niet zo leuk ....

[edit]
Linkje naar Technet : Backing up, Restoring, Migrating, and Copying GPOs

One Of your Administrators has accidentally deleted an OU

[ Voor 55% gewijzigd door sanfranjake op 29-12-2003 23:05 . Reden: link toegevoegd ]

[StevenK]

Verwijderd schreef op 29 december 2003 @ 22:46:

2. Hoe definieer ik op een juiste manier twee policies voor twee groepen gebruikers?

Om een policy specifiek toe te passen wanneer gebruikers op een specifieke (groep) machine(s) aanloggen, moet je uiteraard die machine(s) in een OU stoppen en daar een policy op zetten.

Dan moet je ook nog eens zorgen dat je 'loopback processing' aanzet. Daarmee zorg je dat op die specifieke machine(s) voor het user gedeelte van de policy niet naar de OU van user maar naar de OU van de machine gekeken wordt.

[Verwijderd]

1. Staat helaas niet in lost and found, zou wel gemakkelijk zijn
Ik zal proberen een juiste back up uit te voeren.

2. Als ik op computerniveau een policy toepas, zal dit dan niet ook effect hebben op gebruikers als admin die op deze pc aanloggen? Dan heb ik nl. geen superuser meer.

3. Zit ik helemaal verkeerd als ik op een OU een policy toepas en daarin een user stop?

[StevenK]

Verwijderd schreef op 30 december 2003 @ 09:28:
2. Als ik op computerniveau een policy toepas, zal dit dan niet ook effect hebben op gebruikers als admin die op deze pc aanloggen? Dan heb ik nl. geen superuser meer.

Ja, dan geldt deze ook voor de admin, behalve als je nu die admin geen rechten geeft op die policy, of je voor de admin een andere policy maakt.

3. Zit ik helemaal verkeerd als ik op een OU een policy toepas en daarin een user stop?

Lijkt me onlogisch, want die policy wordt dan voor die gebruiker op alle pc's toegepast.

[Verwijderd]

StevenK schreef op 30 december 2003 @ 11:10:
[...]

Lijkt me onlogisch, want die policy wordt dan voor die gebruiker op alle pc's toegepast.

Voor mijn organisatie gaat dit wel op; wij willen in de fabriek op gebruikersniveau weten wanneer een werknemer iets meldt. Als er een pc defect raakt, moet een andere pc in te loggen zijn voor werknemer bij diverse pc's.

Ik maak nu een nieuwe OU aan. Het originele probleem waarbij er 'opeens' gebruikers onder de policy van deze OU vallen terwijl ze niet onder de OU vallen wil ik graag voorkomen. Dit doe ik door "block policy inheritance" en "no overide aan te vinken. Als ik hierna gebruikers in de nieuwe OU plaats, zou het moeten werken toch? Of is er nog een groep onder builtin of users nodig? Een nieuw aangemaakte gebruiker valt namelijk standaard onder de groep Domain Users ( onder domain-->users) welke op zijn beurt weer valt onder Users (domain-->builtin).

[Verwijderd]

sanfranjake schreef op 29 december 2003 @ 23:01:
Een backup terugzetten ? Kijk anders in de Lost&Found OU, misschiendat daar toevallig nog iets staat

Backups terugzetten e.d. is niet mogelijk door een fout in de backup software (verholpen ondertussen). Door jou tip van lost and found heb ik even wat verder gekeken dan mijn neus lang is en in de active directory de nieuw aangepaste en gemaakte policys gevonden. Vervolgens verwijderd (onder system-->policies). Nu ben ik weer terug bij af , maar dat is beter dan niet kunnen doen in je TS

[StevenK]

Verwijderd schreef op 30 december 2003 @ 11:34:
[...]


Voor mijn organisatie gaat dit wel op; wij willen in de fabriek op gebruikersniveau weten wanneer een werknemer iets meldt. Als er een pc defect raakt, moet een andere pc in te loggen zijn voor werknemer bij diverse pc's.

Je hebt 't nu weer over pc's, net had je het over een terminal server ?

[Verwijderd]

StevenK schreef op 30 december 2003 @ 13:42:
[...]

Je hebt 't nu weer over pc's, net had je het over een terminal server ?

In de fabriek gaan we werken op de terminalserver. Een aantal modules van de te gebruiken software is afhankelijk van de gebruikersaccount op de terminalserver. Als wij dus willen weten wie welke actie pleegt, is er een login op de terminalserver v/e unieke gebruiker vereist.
PC kapot betekend dat een gebruiker ook ergens anders moet kunnen inloggen, en omdat afhankelijk van de loginnaam soms een andere lay-out (desktop, rechten, etc) vereist is, kunnen de rechten beter niet aan een pc gekoppeld worden, maar aan een gebruiker.

[SED]

Verwijderd schreef op 31 december 2003 @ 16:59:
[...]


In de fabriek gaan we werken op de terminalserver. Een aantal modules van de te gebruiken software is afhankelijk van de gebruikersaccount op de terminalserver. Als wij dus willen weten wie welke actie pleegt, is er een login op de terminalserver v/e unieke gebruiker vereist.
PC kapot betekend dat een gebruiker ook ergens anders moet kunnen inloggen, en omdat afhankelijk van de loginnaam soms een andere lay-out (desktop, rechten, etc) vereist is, kunnen de rechten beter niet aan een pc gekoppeld worden, maar aan een gebruiker.

Bij een terminal server is in principe niets gebonden aan een pc maar juist aan je eigen settings op de TS. Ongeacht van de plaats waar je inlogd krijg je de eigen instellingen mee.
Het lijkt me dat je xaken door elkaar haalt hier.
Verduidelijk eens wat nu eigenlijk het probleem is en wat je wilt oplossen.

[mutsje]

Het is mischien handig om op een WindowsXP_SP1 machine GPMC te installeren en hier heb je dan een handig overzicht van al jou policies en OU's. Ook kun je op een heel eenvoudige manier dan een backup van je policies maken. Ook heb je nog [rml][ windows 2003]Howto: policies en tools[/rml] misschien dat je hier nog tools uit kunt gebruiken. RSOP heb je bijvoorbeeld ook voor windows 2000 (command line only).

Kijk wel uit met het terug zetten van een backup dat je alleen de OU terug zet en niet je hele AD terug rolt.. dan heb je nog veel meer ellende.

[Verwijderd]

SED schreef op 31 december 2003 @ 20:12:
[...]


Het lijkt me dat je xaken door elkaar haalt hier.
Verduidelijk eens wat nu eigenlijk het probleem is en wat je wilt oplossen.

Dit komt voort uit een voorstel van StevenK; ipv van een policy op gebruikers toe te passen, dit op pc's te doen. Ik heb slechts uitgelijnt waarom dat geen optie is....

Situatie: voor een x aantal gebruikers een apart beleid toepassen mbt hun rechten; dit moet aan de ene kant in een groupspolicy gebeuren (wat mag wel en wat mag niet) en een deel in de profielen (exact definieren; dit pictogram wel, die programma's onder start-programma's, etc....)

Probleem: policies worden op een verkeerde manier toegepast in een OU, een nieuw gedefinieerde policy heeft effect op gebruikers die zich in een andere OU bevinden. Volgens mij komt dit door de "inheritance optie", deze staat ondertussen uit.
- Maar hoef ik niets met groepen onder Users en Builtin te doen?
- Aangezien deze structuur wordt toegepast voor een nieuwe gebruiker lijkt me dit relevant. Als dit niet het geval is betekend dat dan dat diverse gebruikers in 'Domain Users' (onder de groep Users) verschillende policies kunnen hebben, zolang ze zich maar in een andere OU bevinden?


Mutsje,
GPMC zal ik vandaag overleggen, dit schaft inderdaad een veel duidelijker overzicht van de policies en het is gemakkelijker te beheren.

[StevenK]

Verwijderd schreef op 02 januari 2004 @ 08:52:
[...]


Dit komt voort uit een voorstel van StevenK; ipv van een policy op gebruikers toe te passen, dit op pc's te doen. Ik heb slechts uitgelijnt waarom dat geen optie is....

Volgens mij heb je alleen laten zien dat je een ander idee hebt over wat er bedoeld wordt. Ik heb alleen gezegd dat je gebruikers policy's op een terminal server het beste via loopback-processing via de systeempolicy van de OU waar de terminal servers in zitten kunt toepassen, omdat je op de terminal server andere instellingen nodig hebt dan op lokale pc's. Op die manier is de OU waar de gebruiker in zit dus niet meer van toepassing voor de toegepaste policy's binnen de terminal server, maar alleen de groep(en) waar de gebruiker in zit.

[Verwijderd]

StevenK schreef op 02 januari 2004 @ 10:55:
[...]

Volgens mij heb je alleen laten zien dat je een ander idee hebt over wat er bedoeld wordt. Ik heb alleen gezegd dat je gebruikers policy's op een terminal server het beste via loopback-processing via de systeempolicy van de OU waar de terminal servers in zitten kunt toepassen, omdat je op de terminal server andere instellingen nodig hebt dan op lokale pc's. Op die manier is de OU waar de gebruiker in zit dus niet meer van toepassing voor de toegepaste policy's binnen de terminal server, maar alleen de groep(en) waar de gebruiker in zit.

Dan heb ik dat inderdaad verkeerd geinterpreteerd.
Ik ben er nu achter dat je
1. eerst een OU moet maken,
2. vervolgens de opties "Block Policy inheritance" en "No overide" moet activeren (in de grouppolicy van de OU)
3. Gebruikers in de OU plaatsen / maken
Dan pas werkt de policy helemaal correct, andere volgorde levert wanorde op.

Ik ben er ook achtergekomen dat je in de groupolicies slechts beperkte mogelijkheden kan doorvoeren, het gaat alleen maar om beveiliging. Zo kun je bijvoorbeeld je desktop of startmenu behoorlijk beperken. Maar wil je nou alles weg hebben en onder start--> programma's 3 programma's plaatsen, dan is er geen andere keus om met profielen te werken...?? (zeg ik dat goed?)

In profielen kun je verwijzen naar een loginscript, maar schijnbaar kloppen mijn verwijzingen niet:

Ik heb "c:\winnt\system32\UsrLogon.cmd" geopend en gekopieerd, deze wordt toch aangeroepen als de TS opstart? In deze kopie (fabriek.cmd) heb ik naar een ander profiel verwezen dan de standaard (setpaths.cmd), namelijk "loginscript fabriek.cmd". In dit script heb ik de verwijzing naar een mapje op de c schijf in 'Documents and settings' van de TS gemaakt, genaamd Fabriek Users (ipv 'All Users'). Dit zou in mjin ogen dus automatisch de verwijzingen in dit nieuwe mapje mbt desktop en start menu moeten overnemen. In de gebruikers onder de nieuwe OU heb ik naar dit nieuwe profielpath verwezen, dit werkte niet en dus heb ik ook "c:\winnt\system32\fabriek.cmd" geprobeerd, wederom geen resultaat.
Wat doe ik hier verkeerd? Of ben ik überhaubt verkeerd bezig door profielen én grouppolicies te gebruiken? Als ik alleen profielen gebruik kan ik veel beveiligingen niet doorvoeren. Maar zonder profielen kan ik niet de juiste configuratie voor gebruikers definiëren....

[ Voor 4% gewijzigd door Verwijderd op 03-01-2004 11:12 ]

[Jiboom]

Verwijderd schreef op 03 januari 2004 @ 11:07:
Dan heb ik dat inderdaad verkeerd geinterpreteerd.
Ik ben er nu achter dat je
1. eerst een OU moet maken,
2. vervolgens de opties "Block Policy inheritance" en "No overide" moet activeren (in de grouppolicy van de OU)
3. Gebruikers in de OU plaatsen / maken
Dan pas werkt de policy helemaal correct, andere volgorde levert wanorde op.

Block inheritance en No override moet je allebei alleen gebruiken als het echt noodzakelijk is, het geeft namelijk sneller de wanorde die je noemt dan wanneer je die opties niet gebruikt en gewoon je GPO's goed opzet. Je moet volgens mij wat gaan lezen op Technet over hoe GPO's precies worden toegepast (volgorde etc.). Je kunt de resultaten van GPO's trouwens controleren met gpresult (of met de GPMC die mutsje al noemde).

Verder krijg ik het idee dat je om gebruikers op de Terminal Server beperkte rechten te geven, je hun rechten op alle pc's aan het beperken bent. Dit komt doordat je op de GPO's waarschijnlijk de standaard security settings toepast (read en apply policy op authenticated users). Als je hiervoor andere groepen neemt speciaal voor de terminal server gaat het beter (vooral handig is de groep Terminal Server User die je trouwens alleen ter beschikking hebt in een win2k ts als de server nog in pre-windows 2000 compatibilty mode draait).

Ik ben er ook achtergekomen dat je in de groupolicies slechts beperkte mogelijkheden kan doorvoeren, het gaat alleen maar om beveiliging. Zo kun je bijvoorbeeld je desktop of startmenu behoorlijk beperken. Maar wil je nou alles weg hebben en onder start--> programma's 3 programma's plaatsen, dan is er geen andere keus om met profielen te werken...?? (zeg ik dat goed?)

In profielen kun je verwijzen naar een loginscript, maar schijnbaar kloppen mijn verwijzingen niet:

Ik heb "c:\winnt\system32\UsrLogon.cmd" geopend en gekopieerd, deze wordt toch aangeroepen als de TS opstart? In deze kopie (fabriek.cmd) heb ik naar een ander profiel verwezen dan de standaard (setpaths.cmd), namelijk "loginscript fabriek.cmd". In dit script heb ik de verwijzing naar een mapje op de c schijf in 'Documents and settings' van de TS gemaakt, genaamd Fabriek Users (ipv 'All Users'). Dit zou in mjin ogen dus automatisch de verwijzingen in dit nieuwe mapje mbt desktop en start menu moeten overnemen. In de gebruikers onder de nieuwe OU heb ik naar dit nieuwe profielpath verwezen, dit werkte niet en dus heb ik ook "c:\winnt\system32\fabriek.cmd" geprobeerd, wederom geen resultaat.
Wat doe ik hier verkeerd? Of ben ik überhaubt verkeerd bezig door profielen én grouppolicies te gebruiken? Als ik alleen profielen gebruik kan ik veel beveiligingen niet doorvoeren. Maar zonder profielen kan ik niet de juiste configuratie voor gebruikers definiëren....

Meestal zul je inderdaad zowel policies als profielen gebruiken. Je moet alleen wel de functie uit elkaar houden: met GPO's kun je dus echt de beveliging instellen (maar ook wel het uiterlijk van de desktop beinvloeden), met profielen kun je geen beveiliging instellen, alleen het uiterlijk van de desktop e.d. aanpassen.

Een loginscript moet je instellen in het user account van de gebruiker of aanroepen m.b.v. een GPO. Maar wederom geldt: voor terminal server heb je andere eisen en wensen dan op andere pc's. Gebruik dus bijv. de aparte tabbladen in het user account om een terminal server profiel in te stellen. En dus niet met Usrlogon.cmd gaan rommelen, heb je hiervoor niet nodig. Verder zou je het default user profiel op terminal server kunnen aanpassen (en ook de all users die je al noemde) om voor alle gebruikers bijv. bepaalde snelkoppelingen weg te halen (wel eerst die default user backuppen voordat je gaat testen/proberen!).

Succes!

[ Voor 3% gewijzigd door Jiboom op 03-01-2004 13:09 ]

[StevenK]

Dingen als 'block inheritance' en 'no override' zijn paardenmiddelen die alleen gebruikt in complexe omgevingen waar je door de OU's de Directory niet meer ziet en dan nog gebruik je ze meestal alleen tijdelijk om te trouble-shooten en zodra je het probleem opgelost hebt haal je ze weer weg.

Vertel eerst eens :
- Hoe je omgeving eruit ziet
- Wat je wil bereiken
- Wat je al gedaan hebt om dat te bereiken

[ Voor 18% gewijzigd door StevenK op 03-01-2004 14:29 ]