Anmeldung Domäne

Domain-Anmeldung

Anmeldung des Benutzers an einem Mandanten einer anderen Domäne und GPO-Filterung an lokalen Domänengruppen Hier sind also ein paar Linien dazu; der Schwerpunkt liegt auf dem Umfang der domain-lokalen Gruppierungen. In diesem speziellen Anwendungsfall wurde eine Konzernrichtlinie angelegt, die nur von Teilnehmern (oder geschachtelten Teilnehmern) einer zu diesem Zweck eingerichteten lokalen Domänengruppe über einen Sicherheitsfilter auf der Konzernrichtlinie angenommen werden konnte.

Die lokale Domänengruppe, wir bezeichnen sie an dieser Stellen als "DomainLocal_Grp_GPO1", enthält dann eine allgemeine Domänengruppe "Global_Grp_GPO1", der die Nutzer zugewiesen wurden, die die Policy annehmen sollten: Bisher kein Hindernis - nur haben wir festgestellt, dass die Konzernrichtlinie nach der Anmeldung an einem Testmandanten nicht für das User-Objekt gilt.

Über die Ausgaben von "GPRESULT /Z" haben wir festgestellt, dass der Nutzer als Glied der Weltgruppe "Global_Grp_GPO1" spezifiziert wurde, aber die (verschachtelte) Zugehörigkeit zur Gesamtgruppe "DomainLocal_Grp_GPO1" nicht im Anmelde-Token des Nutzers gefunden werden konnte. Nach dem Ausschluss möglicher Problemstellen wie "MaxTokenSize" etc. haben wir uns die Aufstellung näher angesehen: Der Nutzer war an der Domäne, in der sich die Gruppenrichtlinien und die lokale Domänengruppe "DomainLocal_Grp_GPO1" befanden, richtig eingeloggt.

Allerdings stellte sich heraus, dass sich der Kunde in einer anderen Domäne befand - und hierin besteht das eigentliche Problems. Lokale Domänengruppen sind per definitionem nur in der Domäne vorhanden, in der sie erstellt wurden. Wenn bei der Anmeldung ein Anmelde-Token für einen Nutzer erstellt wird, gibt der authentisierende Domain Controller in der Response nur die globale und universelle Gruppenzugehörigkeit (oder die entsprechenden SIDs) zurück, nicht die lokale Domänengruppenzugehörigkeit.

Aus diesen zurückgelieferten Anmeldedaten der Global- und Universalgruppen sowie der vom Kunden gelesenen "lokalen" Gruppierungen stellt der Kunde nun selbst das Anmelde-Token des Anwenders zusammen. Beim Anmelden wird der Domain-Controller der Kundendomäne auch nach den Gruppenzugehörigkeiten des Nutzers durchsucht. Ab dem nativen Modus von Microsoft 2000 werden hier die Domänenlokalgruppen hinzugefügt, in denen der Nutzer ein Mitglied ist - entweder auf direktem Wege oder durch Schachtelung (in Global- und Universalgruppen).

Auf dem Ressourcencomputer (von der Local Security Authority, kurz LSA) wird die komplette Anzahl der Suchmaschinen-IDs gegen die Benutzer der jeweiligen Lokalgruppen überprüft, und es kommt auch dazu, dass die Lokalmitglieder im Logon-Token des Anwenders enden. Nur wenn versucht wird, auf eine Ressourcen zuzugreifen, die sich in einer anderen Domäne als der Client-Domäne befinden, wird ein Access-Token für die Ziel-Quelle generiert - und hier werden die in der Domäne befindlichen Identifikatoren der Domänen-Lokalgruppe von der Local Security Authority zu dem Access-Token hinzugefüg....

Sie können dies ganz unkompliziert tun, indem Sie sich mit einem Nutzer einmal auf einem Mandanten Ihrer eigenen Domäne und einmal auf einem Mandanten, der Teil einer anderen Domäne ist (z.B. einer Unterdomäne), anmelden und sich den Anmelde-Token mit dem Windows Server 2003 Support-Tool "whoami" ansehen (in Windows Vista / 2008 ist "whoami" als Standard-Werkzeug enthalten und muss nicht installiert sein):

Anmelde-Token des Nutzers "testuser" auf einem Mandanten derselben Domäne (DOMAIN1): Anmelde-Token des Nutzers "testuser" auf einem Mandanten einer anderen Domäne (CHILD1): Die oben gezeigte Domänenlokalgruppe "DomainLocal_Grp_GPO1" ist im Anmelde-Token des Probebenutzers nicht enthalten, so dass die Richtlinie auch nicht angewandt wird - im Falle der Richtlinienverarbeitung wird das Anmelde-Token des Nutzers auf dem Mandanten mit der ACL der Richtlinie (Attribut "nTSecurityDescriptor") vor dem Zugriff auf das Filesystem des SYSVOL-Servers verglichen.

Dadurch entfällt der ressourcenbasierte Zugriff auf die Freigabe von SYSVOL, um das Access-Token des Anwenders um die Domänenlokalgruppe seiner eigenen Domäne zu ergänzen. Bei der Group Policy Engines ist die Zusatzprüfung notwendig, da die Engines das Zugriffs-Kennzeichen "Gruppenrichtlinie anwenden" bewerten müssen.

Weil es also keine Übereinstimmung zwischen der erforderlichen SID im Anmelde-Token des angemeldeten Nutzers am Kunden in einer anderen Domäne und der ACL des Group Policies-Objekts "GPO1" gibt, gilt auch diese Richtlinie nicht: In einigen (multidomänen-)Konstellationen kann es daher sinnvoll sein, Richtlinien nicht über Sicherheitsfilter auf domain-lokale Gruppierungen zu begrenzen.

Universalgruppen sind in diesem Fall die beste Lösung - wie in allen FÃ?llen, in denen Rechte nicht auf Resourcen wie Printer oder Shares, sondern unmittelbar auf "AD-Objekte" wie Gruppenrichtlinien verteilt werden. Generell sollten Sie prüfen, ob sich die Nutzer eines AD-Waldes an Rechnern unterschiedlicher Domains innerhalb des Waldes angemeldet haben, da die hier beschriebene Problematik bei der Verwendung von DOM-Lokalgruppen auftreten kann.

Seien Sie ehrlich: Wenn sich ein Nutzer einloggt, denken Sie kaum darüber nach, ob sich der aktuell von Ihnen betreute Kunde in der selben Domäne wie der eingeloggte Nutzer aufhält.

Mehr zum Thema