RDP werkt niet bij gebruik van Nested groupen

[Chris-1992]

Goedemiddag,

Als ik een gebruiker toevoeg aan de lokale groep "Remote Desktop Users" heeft deze gebruiker rechten om een RDP te starten naar deze server.
(Zie printscreen)



Als ik een domein groep aanmaak, deze domein groep toevoeg aan de lokale groep "Remote Desktop Users" en de gebruiker enkel toevoeg aan deze nested domein groep heeft deze user geen rechten om in te loggen op de server met RDP.
(Zie printscreen)






Wat doe ik fout?

[Voor 8% gewijzigd door Chris-1992 op 14-06-2022 12:47]

[nextware]

Nested groups werken zonder problemen voor het toevoegen aan de Remote Desktop User group van een server.

Domme vraag: staan remote connections uberhaupt wel aan op deze server ?

[loewie1984]

Daarnaast als je dit meteen test nadat je de medewerker in de nested group hebt geplaatst, neem dan ook de replicatietijd van je domein controllers in acht. Vaak wordt dit vergeten en staat dit standaard op 60 minuten. Je kan dit wijzigen naar 45, 30 en 15 minuten.

Als je namelijk 2 domeincontrollers hebt (niet ongebruikelijk in een productie netwerk) en je doet de mutatie tegen de domeincontroller aan welke niet de actieve domeincontroller is, dient er eerst replicatie plaats te vinden tussen de DC's, voordat de authenticatie van de nested group succesvol is, die gebeurt namelijk tegen de actieve / logon domein controller aan.

Dus of je replicatie tijd verkorten, of eens even een half uurtje tot een uurtje geduld hebben. Eventueel kun je de sync ook forceren, handmatig via commandline.

[Chris-1992]

@nextware Ja, dat is wel in orde (Als ik de persoon rechtstreeks toevoeg werkt het wel)

@loewie1984 Dit is een omgeving met maar één DC.

-> 60min wachten heb ik getest
-> gpudpate /force
-> repadmin /syncall /AdeP
Zijn de zaken dat ik uit gevoerd en heb opnieuw getest.

[Hann1BaL]

Waarom een nested group en niet gewoon een 2e group?

Nested groups zijn bijna altijd een niet zo goed idee. Het zou moeten werken, dat wel, maar ik zou jezelf eens motiveren een goed antwoord te verzinnen waarom je het met nested group wilt doen.

[Yukkie]

@Hann1BaL Om het RBAC model van Microsoft te implementeren met de I-G-DL-A methode. Een Identity (user) zit in een Global Group, deze is lid van een Domain Local group, welke toegang geeft (Access) tot een resource.

@Chris-1992 zijn de domain groups van het juiste type? ( zie het I-G-DL-A voorbeeldje hierboven)

[Voor 19% gewijzigd door Yukkie op 14-06-2022 14:44]

[Chris-1992]

Hann1BaL schreef op dinsdag 14 juni 2022 @ 14:37:
Waarom een nested group en niet gewoon een 2e group?

Nested groups zijn bijna altijd een niet zo goed idee. Het zou moeten werken, dat wel, maar ik zou jezelf eens motiveren een goed antwoord te verzinnen waarom je het met nested group wilt doen.

Wat bedoel je met 2e groep?

-

Ik maak per server een security groep aan op domein niveau, deze security groep heeft dan local admin en RDP rechten.
Zodat ik een gebruiker tijdelijk in deze groep kan plaatsen als hij/zij een update moet doen van bepaalde software en admin rechten nodig heeft.

Op deze manier kan ik het makkelijk beheren vanuit de DC.

-

@Yukkie
Standaard settings,

[Voor 14% gewijzigd door Chris-1992 op 14-06-2022 14:54]

[loewie1984]

Wat je wilt werkt normaal gesproken.

In het verleden heb ik ook via AGDLP medewerkers via RDP ontsloten op servers. Dit zag er zo uit:

medewerker was lid van een global security group. De global security group was lid van een domain local group, deze group hing aan de resource, in dit geval de local admin group of de remote desktop user group.

Je volgt hiermee (naar mijn weten) een best practice die vooral relevant is bij meerdere domains in een forest, of wanneer je domein migreert naar een ander domein er een scheiding optreed juist vanwege de domain local group die vast hangt aan de resource in dat domein.

Er moet een andere oorzaak zijn. Ik heb wel eens gehad dat servers RDP ingeschakeld kregen via GPO, dus het moet werken, waar het niet dat deze server bijv. in een OU stond met inheritance disabled. Dan komt zo'n policy nooit aan.

Je kan eveneens dezelfde groep eens proberen op een andere server. Je kan eveneens dezelfde groep eens proberen te hangen aan de local admins groep om te kijken of het werkt.

Dan heb je al 2 of 3 scenario's die je mogelijk een aanleiding geven van wat er mis is.

[Chris-1992]

@Yukkie @loewie1984
De groep die ik aangemaakt had was een domain global en dan op de resources.

Nu heb ik een nieuwe groep aangemaakt (Domain Local) en deze gehangen aan de resources (remote desktop users) en het werkt!

[Voor 64% gewijzigd door Chris-1992 op 14-06-2022 15:18]

[loewie1984]

Juist, dat is precies mijn betoog. Alleen zelf nooit geweten dat dit een probleem kon geven. Ik heb altijd de best practice gevolgd.

[Hann1BaL]

@Yukkie gaf het antwoord.

(Waarom kies je niet Universal group? Ben je toch meteen van het gedoe af?)

[Voor 41% gewijzigd door Hann1BaL op 14-06-2022 15:50]

[Yukkie]

@Hann1BaL Is dat een vraag aan mij? Dan is mijn antwoord dat dat incorrect gebruik is van een universal group. Die is alleen bedoeld voor domain of zelfs forrest overstijgende groep nesting. Ik geloof dat je daar ook geen users aan kan hangen en niet kunt gebruiken in local groups op een server (maar het is lang geleden dat ik de theorie bestudeerd heb).

[Question Mark]

Hann1BaL schreef op dinsdag 14 juni 2022 @ 15:49:
(Waarom kies je niet Universal group? Ben je toch meteen van het gedoe af?)

Omdat die gerepliceerd worden naar alle Global Catalogs in je Forest. Da's niet zo heel spannend voor een kleine omgeving, maar wordt al vervelend en waarschijnlijk ongewenst in grotere omgevingen met meerdere domeinen in een forest.

Het is inderdaad makkelijk om mee te beginnen, maar een crime om daar ooit weer vanaf te komen. Niets voor niets dat MS hier een RBAC best practise voor heeft.