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:

Mehrere Firmen teilen sich ein Active Directory

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:

Altlasten

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):

dsHeuristics

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:

Erweiterte Features

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

AD Berechtigungen

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

Vererbung

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

AD Berechtigungen

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

AD Berechtigungen

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

AD Berechtigungen

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

AD Berechtigungen

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

AD Berechtigungen

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

AD Berechtigungen

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

AD Berechtigungen

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:

AD Berechtigungen

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:

AD Berechtigungen

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

AD Berechtigungen

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

Register Schema MMC

Die DLL der Schema Konsole wurde erfolgreich geladen:

Register Schema MMC

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:

Schema Berechtigungen

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

Schema Berechtigungen

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:

UPN anpassen

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

UPN anpassen

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:

Admin Aufgaben delegieren

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

Admin Aufgaben delegieren

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

Admin Aufgaben delegieren

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

Admin Aufgaben delegieren

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

Admin Aufgaben delegieren

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:

Anmeldung Test

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

Anmeldung Test

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:

Anmeldung Test

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.

4 Replies to “Active Directory: Mehrere Firmen teilen sich ein Active Directory”

  1. Schön geschrieben und erläutert, der Artikel. Ich hätte mir jedoch gewünscht, dass beim dsHeuristics zumindest ein link ins MS TechNet ist. Zum einen, weil einfach mal 001 einstellen u.U das falsche vorgehen ist (falls da schon etwas drin steht), zum anderen weil gerade der Object List Mode extrem auf die DC CPU schlägt – Testen! (ähnlich wie ABE bei DFS und FileAccess). Einen Satz dazu hätte ich erwartet.

  2. Moin Franky,
    sehr interessanter Artikel, weil genau so etwas benötige ich. Habe deine komplette Anleitung detailgenau in unserer Testdomäne befolgt, aber die Tests waren leider nicht positiv: Das AD-Modul von RSAT auf dem Test-Client mit W10 zeigt zwar nur die richtige OUs wie beschrieben, aber über die Suche kann ich immer noch die anderen Benutzer finden. Ebenfalls als User über Powershell (get-aduser) sowie über cmd (dsquery) listet er mir ALLE Benutzer der Domäne auf. Ich kann sogar den kompletten User mit Mitgliedschaften einsehen, nur beim Reiter „Konto“, meldet er „Ein solches Objekt ist auf dem Server nicht vorhanden“. Habe daraufhin die Berechtigungen weiter heruntergeschraubt und zurzeit sogar „Authentifizierte Benutzer“ komplett verweigert, was dazu führt das er in der GUI nicht mehr die OU anzeigt, aber ansonsten bei der Suche etc. hat sich nichts verändert. Neustart ist gemacht worden. Domäne ist auf WS12R2
    Hatte vermutet, ob es mit dem Computer Objekt zusammenhängt, aber auch wenn ich diesen in die Firma A OU mit verschiebe, verändert das nichts. Jemand noch ne Idee?

  3. ## Für alle die nach dieser Anleitung Probleme mit den GPO’s haben ##

    Wie Franky am Ende des Artikels erwähnt hat, muss dies noch extra beachtet werden.
    Ereignis Protokoll Eintrag 1101 (Am Client) ist hier das Stichwort.

    habe neulich eine Ähnliche Einrichtung gemacht und das GPO Problem wiefolgt gelöst:

    1. Die Computerkonten/Server des betreffenden Mandanten werden in eine ou unterhalb von „FirmaA“ verschoben“
    2. Die Computerkonten/Server werden Mitglied der Gruppe „SG_FirmaA“

    Dadurch ist es den Computern wieder möglich das AD bis zum eigenen Objekt durchzuforsten und können die GPO anwenden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.