3
Ressourcenzugriff bei Domän-Trust
Hallochen Gemeinde,
gegeben sind zwei Domänen (DomAlt und DomNeu), die für die Migration über einen bidirektionalem transitiven Trust miteinander verbunden sind. Die DNS-Auflösung funktioniert in beiden Domänen betreffend die jeweils andere ordnungsgemäß. Der Trust ist beidseitig überprüft und auf den DC's kann jeweils auf die Verzeichnisstruktur der vertrauten Domäne zugriffen werden. Per ADMT-/PES-Tool wurde zunächst ein Benutzer aus DomAlt nach DomNeu einschließlich SIDHistory migriert. In DomAlt ist eine domänenlokale Gruppe erstellt, in der der migrierte Account DomNeu\Benutzer sowie der weitere (originäre) Account DomNeu\Admin als Mitglieder aufgenommen sind. Ferner ist eine domänenlokale Gruppe in DomNeu mit dem (originären) Account DomAlt\Admin als Mitglied vorhanden. Aufgrund dieser domänenlokalen Gruppe(n), kann sich das jeweilige Gruppenmitglied in der vertrauenden Domäne an Clients / Servern anmelden.
Dazu gibt es folgende Fragestellung:
Auf einem Windows Client existiert für den Ursprungsaccount DomAlt\Benutzer bereits ein Profil. Bei der Anmeldung als DomNeu\Benutzer wird jedoch ein neues Profil angelegt. Wünschenswert wäre natürlich, wenn der Windows Client die beiden Anmeldungen einem einzigen Profil zuordnen würde. Gibt es hierfür eine Möglichkeit?
Das war jedenfalls meine Erwartungshaltung mit Blick auf die SIDHistory, zumal das SID Filtering in beiden Domänen über netdom trust /enableSIDhistory:yes deaktiviert wurde.
Vielen Dank im Voraus
HansDampf06
UPDATE:
Hinsichtlich der Lösung der Fragestellung neben dem Beitrag von Peter bitte auch meinen Beitrag vom 19. März 2021 berücksichtigen.
gegeben sind zwei Domänen (DomAlt und DomNeu), die für die Migration über einen bidirektionalem transitiven Trust miteinander verbunden sind. Die DNS-Auflösung funktioniert in beiden Domänen betreffend die jeweils andere ordnungsgemäß. Der Trust ist beidseitig überprüft und auf den DC's kann jeweils auf die Verzeichnisstruktur der vertrauten Domäne zugriffen werden. Per ADMT-/PES-Tool wurde zunächst ein Benutzer aus DomAlt nach DomNeu einschließlich SIDHistory migriert. In DomAlt ist eine domänenlokale Gruppe erstellt, in der der migrierte Account DomNeu\Benutzer sowie der weitere (originäre) Account DomNeu\Admin als Mitglieder aufgenommen sind. Ferner ist eine domänenlokale Gruppe in DomNeu mit dem (originären) Account DomAlt\Admin als Mitglied vorhanden. Aufgrund dieser domänenlokalen Gruppe(n), kann sich das jeweilige Gruppenmitglied in der vertrauenden Domäne an Clients / Servern anmelden.
Dazu gibt es folgende Fragestellung:
Auf einem Windows Client existiert für den Ursprungsaccount DomAlt\Benutzer bereits ein Profil. Bei der Anmeldung als DomNeu\Benutzer wird jedoch ein neues Profil angelegt. Wünschenswert wäre natürlich, wenn der Windows Client die beiden Anmeldungen einem einzigen Profil zuordnen würde. Gibt es hierfür eine Möglichkeit?
Das war jedenfalls meine Erwartungshaltung mit Blick auf die SIDHistory, zumal das SID Filtering in beiden Domänen über netdom trust /enableSIDhistory:yes deaktiviert wurde.
Vielen Dank im Voraus
HansDampf06
UPDATE:
Hinsichtlich der Lösung der Fragestellung neben dem Beitrag von Peter bitte auch meinen Beitrag vom 19. März 2021 berücksichtigen.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 662780
Url: https://administrator.de/forum/ressourcenzugriff-bei-domaen-trust-662780.html
Ausgedruckt am: 31.03.2025 um 14:03 Uhr
3 Kommentare
Neuester Kommentar
Hallo,
https://social.technet.microsoft.com/Forums/en-US/41ebf561-afb7-4e10-ab9 ...
Nur ein umbenennen der Neuen Domäne hilft dir nicht, da auch der Client (PC) nur nach der SID geht, also neues Profil.
Vielleicht findest du hier etwas was dir helfen kann. https://www.forensit.com/
Gruß,
Peter
Zitat von @HansDampf06:
Das war jedenfalls meine Erwartungshaltung mit Blick auf die SIDHistory, zumal das SID Filtering in beiden Domänen über netdom trust /enableSIDhistory:yes deaktiviert wurde.
Da du schon mehrfach den Begriff SID genommen hast, eine Domäne ist auch nur eine SID, welche beim Erstellen der Domäne generiert wird und einmalih sein sollte. Die chance das 2 SIDs zweier Domänen identisch sind ist eher ausgeschlossen. Der Name der Domäne müsste hierbei auch noch gleich sein - und dann funktioniert auch keine Vertrauensstellung oder sonstiges mehr.Das war jedenfalls meine Erwartungshaltung mit Blick auf die SIDHistory, zumal das SID Filtering in beiden Domänen über netdom trust /enableSIDhistory:yes deaktiviert wurde.
https://social.technet.microsoft.com/Forums/en-US/41ebf561-afb7-4e10-ab9 ...
Nur ein umbenennen der Neuen Domäne hilft dir nicht, da auch der Client (PC) nur nach der SID geht, also neues Profil.
Vielleicht findest du hier etwas was dir helfen kann. https://www.forensit.com/
Gruß,
Peter
Hallo Peter,
nachdem ich erst spät in der Nacht meine Frage abgesetzt hatte, habe ich am Montag tagsüber immer wieder über die Problematik nachgedacht. Bedeutsam waren dabei die folgende Fakten:
- Profilordner beim Client "C:\Benutzer\XYZ" und "C:\Benutzer\XYZ.DomNeu"
- Auflistung in der Systemsteuerung unter Benutzerprofile "DomAlt\XYZ" und "DomNeu\XYZ"
- Zugriff auf einen lokalen Ordner, für den ausschließlich DomAlt\XYZ Rechte besitzt, funktioniert auch für DomNeu\XYZ
- der Remotezugriff von einem Client in DomAlt auf eine Freigabe in DomAlt durch DomNeu\XYZ scheitert, so lange DomNeu\XYZ nicht Mitglied in derselben (oder anderen berechtigten) Zugriffsgruppe wie DomAlt\XYZ ist, wenn kein direkter Zugriff ohne Gruppenmitgliedschaft gewährt wird.
- der Remotezugriff von einem Client in DomNeu auf eine Freigabe in DomAlt durch DomNeu\XYZ steht unter denselben Abhängigkeiten.
Letztlich bin ich dann am Montagabend zu der Schlussfolgerung gelangt, dass die SIDHistory genau dann ausreichend ist, wenn es um einen Remotezugriff aus dem Kontext DomNeu auf eine Ressource wie eine Dateifreigabe in DomAlt geht, bei dem DomAlt\XYZ direkten Zugriff hat. Immerhin ist das auch das grundsätzliche Konzept von Domänen-Trusts, weil hier alle SID von DomNeu\XYZ für die erforderliche Ticketanforderung präsentiert werden.
Hingegen agiert DomNeu\XYZ im unmittelbaren Kontext von DomAlt eben nicht durch die bloße Präsentation aller seiner SID, sondern vielmehr (und möglicherweise ausschließlich) mit seiner primären SID bzw. seinen User-Credentials. Jedenfalls stellt der Windows Client bei einer Konsolen-/RDP-Anmeldung darauf ab. Das erscheint mir auch zwingend notwendig, weil ansonsten keine klare Zuordnung zu einem konkreten Benutzerprofil möglich wäre. Gerade bei der Berücksichtigung von mehreren SID würde ansonsten ein unauflösbarer Zustand entstehen, wenn für mehrere dieser SID jeweils ein Benutzerprofil vorhanden wäre. Überdies sorgt die Angabe der Domäne bei der Konsolenanmeldung bereits für eine zwingende Differenzierung.
Der lokale Zugriff auf zugriffsbeschränkte Ordner scheint dann wiederum auch die SIDHistory zu berücksichtigen, weil für den Nachweis der berechtigten Identität eine der präsentierten SID genügt.
Mithin ist die SID bildhaft so etwas wie eine bloße "Eintrittskarte", während im Verhältnis dazu die User-Credentials eher mit einem "(Personal)Ausweis" vergleichbar sind. Für die Konsolenanmeldung wird eben der "Ausweis" benötigt. Und in diesem Unterschied liegt dann auch die bekannte Sicherheitsproblematik der SID bei Domänen-Trusts.
Im Ergebnis dieser Erkenntnis muss es bei der Konsolenanmeldung zwei Benutzerprofile geben, wenn die Anmeldung parallel entweder mit DomAlt\XYZ oder mit DomNeu\XYZ erfolgt. Die SIDHistory ist insoweit belanglos. Natürlich gilt das genauso für RDP- und sonstige Anmeldungen, bei denen die User-Credentials zu präsentieren sind.
Dein Beitrag unterstreicht das alles noch zusätzlich.
Mithin kann es nur darum gehen, für die Migration das Profil von DomAlt\XYZ auf DomNeu\XYZ zu übertragen, was mit dem Machine-Wizzard des ADMT-Tolls weitestgehend funktionieren soll. In jedem Fall werde ich mir Deinen Tool-Tipp in den nächsten Tagen noch näher anschauen, besten Dank. Im Übrigen hat DomNeu\XYZ vollen Zugriff auf die Dateien des Profils von DomAlt\XYZ und kann entsprechend (re)agieren.
Viele Grüße
HansDampf06
nachdem ich erst spät in der Nacht meine Frage abgesetzt hatte, habe ich am Montag tagsüber immer wieder über die Problematik nachgedacht. Bedeutsam waren dabei die folgende Fakten:
- Profilordner beim Client "C:\Benutzer\XYZ" und "C:\Benutzer\XYZ.DomNeu"
- Auflistung in der Systemsteuerung unter Benutzerprofile "DomAlt\XYZ" und "DomNeu\XYZ"
- Zugriff auf einen lokalen Ordner, für den ausschließlich DomAlt\XYZ Rechte besitzt, funktioniert auch für DomNeu\XYZ
- der Remotezugriff von einem Client in DomAlt auf eine Freigabe in DomAlt durch DomNeu\XYZ scheitert, so lange DomNeu\XYZ nicht Mitglied in derselben (oder anderen berechtigten) Zugriffsgruppe wie DomAlt\XYZ ist, wenn kein direkter Zugriff ohne Gruppenmitgliedschaft gewährt wird.
- der Remotezugriff von einem Client in DomNeu auf eine Freigabe in DomAlt durch DomNeu\XYZ steht unter denselben Abhängigkeiten.
Letztlich bin ich dann am Montagabend zu der Schlussfolgerung gelangt, dass die SIDHistory genau dann ausreichend ist, wenn es um einen Remotezugriff aus dem Kontext DomNeu auf eine Ressource wie eine Dateifreigabe in DomAlt geht, bei dem DomAlt\XYZ direkten Zugriff hat. Immerhin ist das auch das grundsätzliche Konzept von Domänen-Trusts, weil hier alle SID von DomNeu\XYZ für die erforderliche Ticketanforderung präsentiert werden.
Hingegen agiert DomNeu\XYZ im unmittelbaren Kontext von DomAlt eben nicht durch die bloße Präsentation aller seiner SID, sondern vielmehr (und möglicherweise ausschließlich) mit seiner primären SID bzw. seinen User-Credentials. Jedenfalls stellt der Windows Client bei einer Konsolen-/RDP-Anmeldung darauf ab. Das erscheint mir auch zwingend notwendig, weil ansonsten keine klare Zuordnung zu einem konkreten Benutzerprofil möglich wäre. Gerade bei der Berücksichtigung von mehreren SID würde ansonsten ein unauflösbarer Zustand entstehen, wenn für mehrere dieser SID jeweils ein Benutzerprofil vorhanden wäre. Überdies sorgt die Angabe der Domäne bei der Konsolenanmeldung bereits für eine zwingende Differenzierung.
Der lokale Zugriff auf zugriffsbeschränkte Ordner scheint dann wiederum auch die SIDHistory zu berücksichtigen, weil für den Nachweis der berechtigten Identität eine der präsentierten SID genügt.
Mithin ist die SID bildhaft so etwas wie eine bloße "Eintrittskarte", während im Verhältnis dazu die User-Credentials eher mit einem "(Personal)Ausweis" vergleichbar sind. Für die Konsolenanmeldung wird eben der "Ausweis" benötigt. Und in diesem Unterschied liegt dann auch die bekannte Sicherheitsproblematik der SID bei Domänen-Trusts.
Im Ergebnis dieser Erkenntnis muss es bei der Konsolenanmeldung zwei Benutzerprofile geben, wenn die Anmeldung parallel entweder mit DomAlt\XYZ oder mit DomNeu\XYZ erfolgt. Die SIDHistory ist insoweit belanglos. Natürlich gilt das genauso für RDP- und sonstige Anmeldungen, bei denen die User-Credentials zu präsentieren sind.
Dein Beitrag unterstreicht das alles noch zusätzlich.
Mithin kann es nur darum gehen, für die Migration das Profil von DomAlt\XYZ auf DomNeu\XYZ zu übertragen, was mit dem Machine-Wizzard des ADMT-Tolls weitestgehend funktionieren soll. In jedem Fall werde ich mir Deinen Tool-Tipp in den nächsten Tagen noch näher anschauen, besten Dank. Im Übrigen hat DomNeu\XYZ vollen Zugriff auf die Dateien des Profils von DomAlt\XYZ und kann entsprechend (re)agieren.
Viele Grüße
HansDampf06
DIE LÖSUNG für die von mir aufgeworfene Fragestellung - zumindest im hiesigen Migrationskontext - ist noch viel einfacher. Nur war ich zum Zeitpunkt des Postings der Fragestellung noch nicht so weit im Migrationsprozess vorangeschritten, um das erkennen zu können. Auch habe ich den nachstehend genannten Link erst danach entdeckt, so dass ich das hier der Vollständigkeit halber noch ergänzen möchte.
Für eine Domänen-Migration ist das ADMT-Tool von Microsoft eine probate Wahl. Im Anschluss an die User-Migration ist als nächster Schritt der "Security Translation Wizard" auszuführen. Dabei wird je nach gewählter Ausführungsoption (hier am besten: Add) das Profil des ursprünglichen Users DomAlt\Benutzer zugleich dem migrierten User DomNeu\Benutzer einheitlich zugeordnet. Zwar werden beide User dann in der Auflistung der Benutzerprofile getrennt aufgelistet, aber der Blick in das Verzeichnis C:\Users offenbart, dass es nach wie vor nur das ursprüngliche User-Unterverzeichnis gibt. Auch die Anmeldung mit beiden User-Varianten bestätigt, dass es ein und dasselbe Profil ist. Das ist genau das, was ich erreichen wollte.
Für das bessere Verständnis gibt es ein sehr gutes elfteiliges Tutorial, das im hier relevanten zehnten Teil die verschiedenen Wirkungen mit und ohne diesen Migrationsschritt erläutert: ADMT Series - 10. Security Translation Wizard - Local Profiles.
Diese ADMT-Serie ist vor allem auch insoweit äußerst empfehlenswert, weil sie Details und Hinweise enthält, die ich trotz intensiver vorbereitender Beschäftigung mit dem Microsoft-Handbuch zum ADMT-Tool und einschlägigen Internetbeiträgen verschiedenster Quellen so nicht gefunden habe.
DENNOCH: Die beiden vorhergehenden Beiträge sind gleichwohl zutreffend, weil sie in ihrer Betrachtung über die hiesigen Migrationskontext hinaus bedeutsam bleiben. Der Unterschied zwischen mit und ohne Durchführung des "Security Translation Wizard" macht das sehr deutlich. Außerdem bietet der Empfehlungslink von Peter betreffend forensit.com eine Alternative zum ADMT-Tool für die Migration von lokalen Benutzerprofilen.
Viele Grüße
HansDampf06
Für eine Domänen-Migration ist das ADMT-Tool von Microsoft eine probate Wahl. Im Anschluss an die User-Migration ist als nächster Schritt der "Security Translation Wizard" auszuführen. Dabei wird je nach gewählter Ausführungsoption (hier am besten: Add) das Profil des ursprünglichen Users DomAlt\Benutzer zugleich dem migrierten User DomNeu\Benutzer einheitlich zugeordnet. Zwar werden beide User dann in der Auflistung der Benutzerprofile getrennt aufgelistet, aber der Blick in das Verzeichnis C:\Users offenbart, dass es nach wie vor nur das ursprüngliche User-Unterverzeichnis gibt. Auch die Anmeldung mit beiden User-Varianten bestätigt, dass es ein und dasselbe Profil ist. Das ist genau das, was ich erreichen wollte.
Für das bessere Verständnis gibt es ein sehr gutes elfteiliges Tutorial, das im hier relevanten zehnten Teil die verschiedenen Wirkungen mit und ohne diesen Migrationsschritt erläutert: ADMT Series - 10. Security Translation Wizard - Local Profiles.
Diese ADMT-Serie ist vor allem auch insoweit äußerst empfehlenswert, weil sie Details und Hinweise enthält, die ich trotz intensiver vorbereitender Beschäftigung mit dem Microsoft-Handbuch zum ADMT-Tool und einschlägigen Internetbeiträgen verschiedenster Quellen so nicht gefunden habe.
DENNOCH: Die beiden vorhergehenden Beiträge sind gleichwohl zutreffend, weil sie in ihrer Betrachtung über die hiesigen Migrationskontext hinaus bedeutsam bleiben. Der Unterschied zwischen mit und ohne Durchführung des "Security Translation Wizard" macht das sehr deutlich. Außerdem bietet der Empfehlungslink von Peter betreffend forensit.com eine Alternative zum ADMT-Tool für die Migration von lokalen Benutzerprofilen.
Viele Grüße
HansDampf06
