Active Directory: Mehrere Firmen teilen sich ein Active Directory

Ich habe nun schon häufiger Anfragen bekommen, in denen die Frage gestellt wurde, wie sich mehrere Firmen ein Active Directory teilen können. In der letzten Anfrage ging es um eine Firma die eine andere Firma aufgekauft hatte. Die Firmen sollten sich nun die Infrastruktur teilen. In der Standardeinstellung eines Active Directory haben allerdings alle Benutzer Leserechte, dies war nun nicht mehr gewünscht, die Firmen sollten nur die jeweils eigenen Benutzer sehen, trotzdem aber im gleichen AD verwaltet werden.

Ich habe dazu einmal die Umgebung aus der Anfrage nachgebaut um es etwas deutlicher zu machen. Es gibt ein Active Directory mit dem Namen “cloud.frankysweb.de” (War eigentlich dazu gedacht ein bisschen mit Azure zu spielen..). Für die aufgekauften Firmen (FirmaA und FirmaB) gibt es jeweils separate Organisationseinheiten in denen die jeweiligen Objekte der Firmen verwaltet werden:

Das Ziel ist, dass Benutzer der FirmaA auch nur ihre Objekte sehen und ggf. verwalten können, aber nicht die Objekte der FirmaB. Gleiches gilt auch für FirmaB.

Wie im Screenshot zu erkennen ist, habe ich eine OU “Firmen” erstellt, darin befindet sich jeweils eine OU für FirmaA und FirmaB. Zusätzlich habe ich eine OU “Shadow Groups” erstellt. Dazu aber später mehr.

Hinweis: Die Umsetzung ist nicht ganz trivial und sollte daher unbedingt vorher getestet werden. Dieser Artikel geht auch nicht auf alle Details ein, um die man sich noch Gedanken machen muss. Ich möchte an dieser Stelle nur einen möglichen Weg zur Umsetzung aufzeigen. Es geht hier nicht darum eine Hosting-Umgebung aufzubauen.

Vorbereitung

Damit der hier beschriebene Weg funktioniert, muss sich zunächst einer “Altlast” entledigt werden. Im Active Directory findet sich in der OU “Builtin” eine Gruppe mit dem Namen “Prä-Windows 2000 kompatibler Zugriff”, diese Gruppe enthält als Mitglieder “Authentifizierte Benutzer”. Wie der Name schon sagt: Prä-Windows 2000 war die NT4 Zeit (Klick, Reboot, Klick, Reboot). Um die Umsetzung etwas einfacher zu gestalten, habe ich “Authentifizierte Benutzer” aus der Gruppe entfernt, die Gruppe ist also leer:

Das eigentliche Active Directory Feature, welches es ermöglicht die Lese-Rechte für Benutzer einzuschränken, nennt sich “dSHeuristics”. Dieses Feature muss zunächst eingeschaltet werden. Die aktivierte dSHeuristics-Funktion bewirkt, dass die Rechte “Objekt auflisten” und “Inhalt auflisten” auf jeder OU ausgewertet werden. Mittels dSHeuristics ist es also möglich bestimmte OUs und Objekte für Benutzer auszublenden, wenn sie keine Rechte auf der entsprechenden OU haben.

Via ADSIEdit kann dSHeuristics in der Active Directory Konfigurationspartition aktiviert werden (Deaktiviert = Nicht festgelegt, Aktiviert = 001):

Im Active Diretcory habe ich zusätzlich eine OU mit dem Namen “Shadow Groups” angelegt. In der OU gibt es jeweils eine Gruppe für FirmaA und eine Gruppe für FirmaB. Die Gruppe SG-FirmaA enthält alle Benutzerkonten von FirmaA. SG-FirmaB enthält alle Benutzerkonten der FirmaB. Diese Gruppen werden später für die Berechtigungen der OUs verwendet. Hier muss sichergestellt werden, dass die Gruppen immer alle Benutzerkonten der jeweiligen Firmen enthalten. Mit einem kleinen Script ist dies aber einfach zu machen.

Damit sind auch schon die Voraussetzungen erfüllt. Dies war der einfache Teil.

Hinweis: Alle Änderungen am Active Directory sollten genau dokumentiert werden, im weiteren Verlauf wird dies umso wichtiger.

Für die bestehenden OUs

Damit Benutzer nur noch ihre jeweils eigene OU sehen, müssen die Berechtigungen der OUs verändert werden. Damit dies in der Konsole Active Directory Computer und Benutzer möglich ist, müssen die “Erweiterten Features” angezeigt werden:

Auf der OU “Firmen” wird nun zunächst die Vererbung unterbrochen:

Die vererbten Berechtigungen werden dabei in explizite Berechtigungen konvertiert und können dann verändert werden:

Für die OU Firmen kann nun die Berechtigung für die Gruppe “Authentifizierte Benutzer” geändert werden:

Der Gruppe “Authentifizierte Benutzer” wird das Recht “Inhalt auflisten” auf der OU “Firmen” entzogen:

Weiter geht es mit der OU “FirmaA”. Auch hier werden die Rechte der Gruppe “Authentifizierte Benutzer” verändert:

In diesem Fall werden die Rechte “Inhalt auflisten” und “Objekt auflisten” entfernt:

Für die OU FirmaA kommt nun die Schattengruppe “SG-FirmaA” zum Einsatz. Für die OU FirmaA wird eine Berechtigung hinzugefügt:

Die Gruppe “SG-FirmaA” erhält nun die Rechte “Inhalt auflisten” und “Objekt auflisten”:

Die Benutzer der FirmaA werden nun der Gruppe “SG-FirmaA” hinzugefügt:

Wichtig ist, dass immer alle Benutzer der jeweiligen Firmen, Mitglieder ihrer Schattengruppe sind. Alle Benutzer von FirmaA müssen Mitglieder der Gruppe “SG-FirmaA” sein:

Für FirmaA ist die Konfiguration nun abgeschlossen. Die jeweiligen Schritte müssen nun für FirmaB wiederholt werden. Es bietet sich hier an entsprechende Scripte vorzubereiten.

Für spezielle OUs

Der Inhalt der OU Shadow Groups kann ebenfalls vor den Augen der Benutzer verborgen werden, auf die gleiche WEise wie hier beschrieben funktioniert dies auch mit anderen OUs. Die Rechte auf Domain Level anzupassen wird nicht empfohlen. Um den Inhalt der OU “Shadow Groups” zu vergeben, werden wieder die Berechtigungen angepasst:

Der Gruppe “Authentifizierte Benutzer” werden hier die Rechte “Inhalt auflisten” und “Objekt auflisten” entzogen:

Für neue / zukünftige OUs

Damit neue Organisationseinheiten nicht direkt für alle Benutzer sichtbar sind, können die Berechtigungen im Active Directory Schema angepasst werden. Dazu muss zunächst die DLL der Konsole “Active Directory-Schema” registriert werden:

regsvr32 schmmgmt.dll

Die DLL der Schema Konsole wurde erfolgreich geladen:

Im MMC SnapIn “Active Directory-Schema” lassen sich nun die Standardberechtigungen für neu erstellte OUs anpassen. Dazu muss die Klasse “organizationalUnit” ausgewählt werden:

Hier wird der Gruppe “Authentifizierte Benutzer” ebenfalls das Recht “Inhalt auflisten” entzogen:

Neue OUs werden somit ohne Leseberechtigung für alle Benutzer angelegt.

Optional: UPN anpassen

Das Anpassen des UPNs ist optional, aber für die Benutzer meistens einfacher und leichter nachvollziehbar. Ein Benutzer der Firma A muss sich nicht mit username@cloud.frankysweb.de anmelden, sondern beispielweise mit username@firmaa.de. Idealerweise entspricht der Benutzername dadurch der E-Mail Adresse des Benutzers. Die Anmeldung mit “E-Mail Adresse und Passwort” ist für Benutzer meistens intuitiver als “Windows Benutzername und Passwort”.

Alternative UPNs lassen sich in der Konsole “Active Directory-Domänen und Vertrauensstellungen” hinzufügen. In diesem Fall wird “firmaa.de” und “firmab.de” hinzugefügt:

Die Benutzer von FirmaA bekommen nun den Suffix “firmaa.de” zugewiesen. Benutzer von FirmaB bekommen “firmab.de” als Suffix zugewiesen:

Der Anmeldename für den Benutzer Frank ist in diesem Fall “frank@firmaa.de”.

Optional: Administration delegieren

Einfache administrative Aufgaben lassen sich an andere Personen delegieren. Gibt es zum Beispiel einen First Level Support in den jeweiligen Firmen, kann dieser Person (oder Gruppe) das Recht eingeräumt werden, bestimmte Aufgaben im Active Directory zu übernehmen. Dazu kann das Feature “Objektverwaltung zuweisen” verwendet werden:

Hier wird die Gruppe “FirmaA-Admins” ausgewählt:

Im nächsten Schritt wird festgelegt, was die Mitglieder der Gruppe “FirmaA-Admins” dürfen:

Nachdem der Assistent abgeschlossen wurde, darf ein Mitglied der Gruppe “FirmaA-Admins” einfache Aufgaben im Active Directory erledigen:

Für spätere Tests habe ich das Konto “AdminFirmaA” der Gruppe “FirmaA-Admins” zugeordnet.

Auch diese Aufgaben lassen sich wunderbar per PowerShell Script automatisieren.

Tests

Interessant wird es aus Benutzersicht. Hier einmal die Anmeldung mit dem Benutzer “Frank aus FirmaA” mit alternativen UPN. Frank meldet sich mit seinem Benutzernamen “frank@firmaa.de” an einem Rechner an:

Wenn Frank nun Das Active Directory durchsucht, sieht er die OU Firmen und FirmaA. Die OU FirmaB wird nicht angezeigt:

Frank kann nun auch keine Benutzer aus FirmaB auflösen. Eine Suche nach “Hans aus FirmaB” im Active Directory liefert keine Ergebnisse.

Ähnlich sieht es in der Konsole “Active Directory-Benutzer und Computer” aus. Der “Administrator der FirmaA” (AdminFirmaA) sieht nur seine jeweilige Firma und kann dort einfache Aufgaben übernehmen. Benutzer aus FirmaB werden nicht angezeigt. Der Admin kann nun zwar Gruppenmitgliedschaften anpassen, bewegt sich dabei aber in “seiner Firma”, er kann also keine Konten aus FirmaB zu Gruppen in FirmaA zuordnen:

Hinweise

Diese Vorgehensweise für das Trennen von Firmen oder Abteilungen ist, wie man aus dem Artikel entnehmen kann, kein triviales Setup. Eine ordentliche Dokumentation über die Berechtigungen, Schattengruppen, Vererbung etc. ist hier ein MUSS. Damit Berechtigungen und Gruppen einheitliche Namen haben, empfiehlt es sich direkt entsprechende Scripte zu erstellen, die neue Firmen, OUs, Gruppen und Berechtigungen automatisiert nach Standard anlegen. Ein Identity Manager wäre hier sicherlich von Vorteil.

Die globalen Administratoren sollten immer im Hinterkopf behalten, dass die Vererbung an den “Firmen OUs” unterbrochen wurde. Dienste und Anwendungen, die entsprechende Berechtigungen auf Domain Level vergeben, können diese Berechtigungen nicht mehr an die “Firmen OUs” vererben. Ein nachträglich installierter Exchange Server, kann also seine nötigen Berechtigungen nicht auf die “Firmen-OUs” vererben, hier muss es dann manuell angepasst werden.

Es gibt hier auch noch weitere Punkte zu beachten, die dieser Artikel nicht behandelt. Zum Beispiel:

• Wie und in welcher OU werden Computer Konten angelegt?
• Wie wird mit Gruppenrichtlinien verfahren?
• Wie stellt sich der Zugriff auf weitere gemeinsam benutzte Dienste dar?
• …

Der hier beschriebene Weg wäre ggf. ein Ansatz wie sich derartige Anforderungen umsetzen lassen.