Kann man Sicherheitsgruppen exportieren und in anderer Domäne mit neuer SID importieren?

[tesso 373]

Probier es doch aus. 
Ich habe die GPO mal mit Variablen und mal mit SID erstellt und verglichen. 

[daabm 1.334]

XML läßt sich recht gut skripten. Das XML-Schema der Group Policy Preferences ist gut dokumentiert. Das läßt sich also prima skripten, wenn man den Bedarf hat

 

bearbeitet 1. Oktober 2019 von daabm

[MurdocX 933]

Am 1.10.2019 um 23:44 schrieb daabm:

XML läßt sich recht gut skripten. Das XML-Schema der Group Policy Preferences ist gut dokumentiert. Das läßt sich also prima skripten, wenn man den Bedarf hat 

An dem Thema war ich mal dran. Die Zielgruppenadressierung ein riesiges Thema. 

 

Dann lieber als XML exportieren, mit Notepad++ die Einträge ersetzen und wieder via Copy&Paste einfügen.

[daabm 1.334]

Mark Heitbrink hatte da mal ein Tool dafür. Die Firma hat aber leider zugemacht und das Tool ist nicht mehr zu finden...

 

Und ich brauch's nicht, sonst hätte ich schon längst ein Skript gebaut, das den Export und Import übernimmt und dabei on the fly gleich passende Migtables inkl. GPP erstellt. Aber es gibt bei GPP genügend Möglichkeiten, mit Variablen zu arbeiten, so daß man gut ohne Migtables auskommt.

[kaineanung 14]

Leider funktioniert das mit den Variablen nicht.

 

Ich habe jetzt eine TEST-GPO erstellt in der folgendes (nur zum Testen) eingestellt ist:

 

Benutzerkonfiguration\Einstellungen\Windows-Einstellungen\Verknüpfungen

 

Reiter 'Allgemein':

Verknüpfung hinzufügen

Aktion: Aktualisieren

Name: Test-Link

Zieltyp: Dateisystemobjekt

Speicherort: Desktop

Zielpfad: C:\Windows\notepad.exe

Starten in: C:\Windows

Tastenkombination: Keine

Ausführen: Normales Fenster

 

Reiter 'Gemeinsame Optionen':

- Haken bei 'Im Sicherheitskontext des angemeldeten Benutzers ausführen (Benutzerrichtlinienoption)

- Haken bei 'Zielgruppenadressierung auf Elementebene'

Zielgruppenadressierung:

%LogonDomain%\HBA

 

(HBA ist eine Sicherheitsgruppe in der Domäne)

 

So, wenn ich das jetzt teste (schon in der ursprünglichen Domäne ohne es erst noch zu migrieren) wird KEINE Notepad-Verknüpfung auf dem Desktop erstellt.

Benutze ich den Picker und picke mir die Gruppe 'HBA' aus, so wird die Verknüpfung erstellt.

 

Somit ist klar: irgendwas läuft schief.

 

Hilfeee?

[Sunny61 806]

vor 7 Stunden schrieb kaineanung:

Zielgruppenadressierung:

%LogonDomain%\HBA

Gibt es denn die Variable %LogonDomain% in der Commandline, wenn Du ein SET [ENTER] eingibst? Woher hast Du die Variable?

[kaineanung 14]

vor 11 Stunden schrieb Sunny61:

vor 18 Stunden schrieb kaineanung:

Zielgruppenadressierung:

%LogonDomain%\HBA

Gibt es denn die Variable %LogonDomain% in der Commandline, wenn Du ein SET [ENTER] eingibst? Woher hast Du die Variable?

Wenn ich im Feld 'Gruppe' der Zielgruppenadressierung bin und F3 drücke, werden alle Variablen aufgelistet. U.a. eben diese %LogonDomain% und eben auch genauso wie die zwei Vorposter es auch erwähnt hatten.

In der Zielgruppenadressierung sieht es dann wie folgt aus:

 

Benutzer ist Mitglied der Sicherheitsgruppe "%LogonDomain%\HBA"

 

Und das es diese Variable gibt und die auch in den GPOs 'gültig' ist und aufgelöst wird, habe ich getestet indem ich statt eines fixen Namen für diesen Link diese %LogonDomain%-Variable benutze.

Der Link wird dann mit dem Domänennamen erstellt wenn ich die Ziegruppenadressierung weglasse oder mit dem Picker die HBA-Gruppe auswähle (und somit die SID dann auch angezeigt und fest hinterlegt wird). Das habei ch nur gemacht um einmalig zu sehen ob die GPO diese Variable überhaupt kennt. Und ja, das tut sie, zumindest in diesem Zusammenhang.. In der Ziegruppenadressierung greift dies so jedoch nicht.. :(

 

[daabm 1.334]

Nimm %DomainName% - ich hab %LogonDomain% noch nie verwendet, bin mir grad unsicher was da drin steht

[kaineanung 14]

Am 9.10.2019 um 20:54 schrieb daabm:

Nimm %DomainName% - ich hab %LogonDomain% noch nie verwendet, bin mir grad unsicher was da drin steht

Also irgendwie mache ich was falsch...

Nehme ich diese 'Variable' dann funktioniert es weder in der Quell-Domäne noch in der Ziel-Domäne. In beiden Domänen steht dann auch brav diese %DomainName% (oder eben %LogonDomain%), aber diese Regel 'greift' gar nicht. Die Sicherheitsgruppe wird nicht erkannt.

 

Ich habe ein Test gemacht:

Ich habe eine Test-GPO in der nur eine Sache eingestellt ist: Eine Verknüpfung auf dem Desktop (der User-Desktop) zu C:\Windows\notepad.exe erstellen.

Wähle ich in der Zielgruppenadressierung das Element 'Sicherheitsgruppe' und über den Picker die Gruppe 'HBA', dann funktioniert es mit meinem U_Txxx-User (so ist der Username des Testusers) welcher Mitglied der Sicherheitsgruppe 'HBA' ist. Es wird also eine Verknüpfung zum Notepad auf dem Desktop erstellt.

Mache ich das wie von euch erklärt mit den Variablen, und ich damit meine ich beide Varianten, also %LogonDomain% und %DomainName%, funktioniert es nicht.

 

%DomainName%\HBA oder %LogonDomain%\HBA werden so nicht aufgelöst und greifen nicht. Die Test-GPO habe ich so natürlich nicht einmal in eine andere Domäne übertragen um zu sehen ob es auch dort läuft (was ja meine Intention ist) da es ja bereits von vornherein nicht funktioniert.

 

An was könnte das liegen?

Ich glaube euch ja das %DomainName% bei euch funktioniert. MS hätte es ja auch nicht implementiert an dieser Stelle würde es nicht funktionieren. Bei mir funktioniert es aber leider nicht.

An anderer Stelle, z.B. wenn ich den Verknüpfungsnamen variabel gestalten möchte nur um zu sehen ob %DomainName% dort aufgelöst wird, so bekomme ich das zu erwartende Ergebnis. Der Verknüpfungsname beinhaltet dann tatsächlich den Domänen-Namen.

[daabm 1.334]

Hm, ok. Ich gebe zu, daß ich im ILT noch nie auf Variablen zurückgreifen mußte...

Hab das grad mal nachvollzogen. Du hast recht: Mit %DomainName%\Group erhalte ich im Debug-Log

 

2019-10-15 21:43:56.210 [pid=0x1708,tid=0x1d60] Starting filter [AND FilterGroup].
2019-10-15 21:43:56.211 [pid=0x1708,tid=0x1d60] Set user security context.
2019-10-15 21:43:56.289 [pid=0x1708,tid=0x1d60] Set system security context.
2019-10-15 21:43:56.290 [pid=0x1708,tid=0x1d60] Failed filter [FilterGroup].
2019-10-15 21:43:56.291 [pid=0x1708,tid=0x1d60] Filters not passed.

Lasse ich %DomainName% weg und nehme nur "Group" (als String, nicht über den Object Picker), geht es. Ich würde sagen "it's a feature, not a bug"

Leider gibt's beim Evaluieren der Filter kein ausführlicheres Logging...

[kaineanung 14]

vor 13 Stunden schrieb daabm:

nehme nur "Group" (als String, nicht über den Object Picker)

Also in meinem Fall nur 'HBA' (Die Sicherheitsgruppe als String eben), oder?

 

 

P.S.

wo finde ich so eine LOG-Datei wie du sie gepostet hast?

Wenn ich in der gpsvc.log unter C:\Windows\debug\usermode\ suche finde ich das so nicht?

Die gpsvc.log ist natürlich vorhanden nachdem ich das in der Registry aktiviert habe

([HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics]
"GPsvcDebugLevel"=dword:00030002)

bearbeitet 16. Oktober 2019 von kaineanung

[daabm 1.334]

Ja, nur "HBA" reinschreiben.

https://blogs.technet.microsoft.com/askds/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat/