[2008r2] Desktop redirection op TS die ook DC is*

[Dark Wanderer]

Hallo,

Ik heb bij een klant ivm budget een Domain Controller tevens als TS ingericht, omdat een paar gebruikers toegang met TS moeten kunnen hebben. Ja ik weet het, niet de best practice

Ik heb een policy aangemaakt die allerlei dingen uitschakeld zoals start >run enzovoorts, en tevens de program files en start menu redirect.

De policy hangt aan de Domain Controllers OU, en wordt toegepast op de computer object van de DC, en op een groep "TS users".

Deze config gebruik ik ook bij klanten welke een aparte TS server hebben, alleen in deze config wordt de policy niet toegepast!

Ook als ik als een user inlog op de DC/TS en start > run > cmd > gpresult /user gebruikersnaam /v doe, meld hij dat er geen policies worden toegepast.

Iemand enig idee hoe dit kan?

[Question Mark]

Dark Wanderer schreef op vrijdag 18 maart 2011 @ 10:24:
De policy hangt aan de Domain Controllers OU, en wordt toegepast op de computer object van de DC, en op een groep "TS users".

Of je hebt loopback policy processing niet aangezet, of je gebruikers zitten niet in de "domain controllers OU" (en dat laatste wil je niet).

Oplossing is dus om loopback policy processing aan te zetten.

[Dark Wanderer]

Question Mark schreef op vrijdag 18 maart 2011 @ 12:54:
[...]

Of je hebt loopback policy processing niet aangezet, of je gebruikers zitten niet in de "domain controllers OU" (en dat laatste wil je niet).

Oplossing is dus om loopback policy processing aan te zetten.

Heel raar...
Mijn policy met desktop settings:

- Gelinkt aan OU domain controllers. Eerst wordt de DC policy toegepast, dan de TS policy.
- Security filtering bevat: De SG met TS users, en het computeraccount van de DC.
- Bij computer settings staat de policy "User group policy loopback processing mode" op "replaced".

Heb al een restart van de server gedaan en gpupdate /force, mag niet baten. En nee, "computer settings disabled" staat niet aan

Graag jullie input

[Spectre75]

Een open deur intrappen, maar misschien is dit de reden dat iedereen roept dat je deze combinatie nooit moet doen

Wat krijg je als je een RSOP draait (ook even Policy Events tabje bekijken, staat ook vaak zinnige info) ?

[Dark Wanderer]

Spectre75 schreef op vrijdag 18 maart 2011 @ 14:28:
Een open deur intrappen, maar misschien is dit de reden dat iedereen roept dat je deze combinatie nooit moet doen

Wat krijg je als je een RSOP draait (ook even Policy Events tabje bekijken, staat ook vaak zinnige info) ?

Zoals je ziet, er wordt helemaal geen administrative template settings meegenomen.
Als ik als de user rsop.msc wil draaien, wordt er om credentials gevraagd. Ik moet dan admin credentials opgeven om verder te gaan. Vervolgens doe ik change query en kies de TS user om tot bovenstaande screenshot te komen.

Zou het te maken hebben met de rechten op de GP?
Domain users heeft wel apply policy rechten op de deze GPO.

[Verwijderd]

Ik dacht dat het helemaal niet MS-ondersteund was om een DC in te richten als TS, misschien is dit er een rechtstreeks gevolg van?

[Dirtyrockers]

er is ook een policy die niet toestaat dat een dc als terminal service dient

deze zal je uit moeten zetten

[Spectre75]

Bedenk me opeens dat je User Right Assignment op een DC anders is dan op een Domain Member Server. Verklaart ook waarom je bij het RSOP gedeelte admin credentials moest opgeven.

Ik vrees dat je je DC flink moet gaan uitkleden op securty gebied op dit allemaal goed werkend te krijgen.

Als je dit echt wilt gaan doen, begin dan eens met het local security policy van een domain member server te vergelijken met het security policy voor je DC. Daar zitten de nodige verschillen in. Kan dus zijn dat je users op een DC niet dezelfde lokale rechten hebben als ze lokaal op een domain member server hebben.

[Dark Wanderer]

Spectre75 schreef op zondag 20 maart 2011 @ 11:49:
Bedenk me opeens dat je User Right Assignment op een DC anders is dan op een Domain Member Server. Verklaart ook waarom je bij het RSOP gedeelte admin credentials moest opgeven.

Ik vrees dat je je DC flink moet gaan uitkleden op securty gebied op dit allemaal goed werkend te krijgen.

Als je dit echt wilt gaan doen, begin dan eens met het local security policy van een domain member server te vergelijken met het security policy voor je DC. Daar zitten de nodige verschillen in. Kan dus zijn dat je users op een DC niet dezelfde lokale rechten hebben als ze lokaal op een domain member server hebben.

Oke, dit zal dan in de kosten gaan lopen om het allemaal voor elkaar te krijgen...
Misschien dat ik een VM aan kan maken op de server waar de DC op draait, en dan een TS installatie doe? Heb er geen goede ervaringen mee. De vorige keer dat ik VMware server op een DC installeerde, was spontaan de hele DNS server corrupt enzovoorts. Werkt dit beter met bijvoorbeeld MS Virtual PC?

[arjants]

Dan zou ik nog liever een aparte desktop nemen en deze TS maken.
Een DC is in mijn ogen te belangrijk om mee te "rotzooien".
Een desktop met een bak geheugen is tegenwoordig erg betaalbaar...

[lamko]

Als je dit in de default domain controller policy doet werkt het dan wel evt met enforce ?
heel erg slecht dit maar werkt het

[ Voor 17% gewijzigd door lamko op 21-03-2011 00:53 ]

[alt-92]

Dark Wanderer schreef op zondag 20 maart 2011 @ 22:48:
De vorige keer dat ik VMware server op een DC installeerde, was spontaan de hele DNS server corrupt enzovoorts.

Omdat je twee extra adapters krijgt ja. Als je die disabled houdt en alleen de Bridge actief houdt kan het wel.
Verstandig is deel twee, overigens. Denk aan de lokatie van je VM, die wil je niet op dezelfde disk hebben als je AD (ivm uitschakelen disk caching en dus performancewise geen goed plan).

Werkt dit beter met bijvoorbeeld MS Virtual PC?

Nee. Bovendien kun je dat niet op een Server OS installeren (dat je het uberhaupt bedenkt...)

[wagenveld]

Image trekken van die bak, Hyper V of ESXi installeren en zowel de DC als de TS virtueel draaien. Lijkt me een stuk betere oplossing. Maar goed, je gaat nu waarschijnlijk zeggen dat die server geen virtualisatie doet