In den QuickBiteSeries werden kurze Artikel über wichtige IT-Grundlagen veröffentlicht, mit denen Interessierte ihr Wissen in wenigen Minuten wieder auffrischen können. Zusätzlich bieten sie auch eine kurze Übersicht für diejenigen, welche sich neu in eine Thematik einlesen wollen.

---

Active Directory / Part 2 – Die SID, die FSMOs und die FFL/DFLs

SID – Security Identifier

Die SID (Security Identifier) ist ein essenzielles Element im Microsoft Security Umfeld und somit kein Element welche ausschliesslich unter Active Directory vorkommt. Jedoch ist es solch ein wichtiges Element, dass ich es hier ebenfalls erläutere.

Hinter jedem jedem Active Directory Objekt, jedoch auch hinter jedem Computer lokalen Benutzer oder Gruppe steht eigentlich eine SID, welche auf Objekte wie Gruppen oder NTFS Ordner hinterlegt werden, um einem Objekt Zugriff mittels ACL zu gewähren oder zu verweigern.

Diese SID kann für das User- bzw. Computerobjekt nicht geändert werden. Löscht man beispielsweise einen Benutzer und erstellt ihn neu im AD, erhält er eine neue SID. Der Benutzername kann noch der Identische sein. Jedoch erhält das neue AD Objekt keinen Zugriff mehr auf einen Ordner in derer ACL er mal aufgeführt wurde. Da, der alte Benutzer eine andere SID hatte.

Eine klassische SID sieht wie folgt aus:

S-1-5-21-978695849-1596879203-1784563948-500

S	1	5	21-978695849-1596879203-1784563948	500
Dass es sich hier um eine SID handelt.	Revisionsnummer. Ist seit jeher immer 1.	Identifier Authority (5 ist NT Authority)	Domain oder Local Computer Identifier	Relative ID. Der Part der ID der immer einmalig in der Domäne ist

Die Relative ID wird dabei vom Domain Controller festgesetzt, wenn das Objekt erstellt wird. Die Relative ID erhällt er dabei vom RID Master. siehe weiter unten.

Wenn sich ein Benutzer an einem Computer einloggen will auf dem er Recht dazu hat, wird hierfür ein Access Token erstellt welcher die SID von ihm hinterlegt hat. Ich werde hierzu noch einen eigenen Blog-Post zum Thema Kerberos, Access Tokens und ACLs schreiben.

---

FSMO Roles

Im Active Directory werden fünf sogenannte FSMO Rollen definiert, welchen verschiedene Active Directory bezogene Aufgaben zugewiesen werden. Diese fünf Rollen werden dann an die Domain Controller verteilt, welche dann für diese zuständig sind.

Davon gibt es zwei Rollen nur einmal pro Forest, wobei drei weitere Rollen pro Child Domain neu vorkommen.

Forest wide FSMO Roles

• Schema Master
  Der Schema Master ist Herr über die beschreibbare Version des Active Directory Schema. (Das Thema AD Schema wurde hier in diesem Blogbeitrag bereits beschrieben) Klar wird das Schema, wie alles Andere auch, auf alle Domänenkontroller repliziert. Doch nur beim Schema Master ist es “unlocked” und beschreibbar.
  
• Domain Naming Master
  Der Domain Naming Master stellt sicher, dass der selbe Name in der Domäne nicht ein zweites Mal im Forest benutzt wird. (Was verheerend wäre) Diese FSMO Rolle ist am wenigsten von allen ausgelastet.

Domain wide FSMO Roles

• RID Master
  Der RID Master ist Herr über die Vergabe der SIDs. Er vergibt den verschiedenen Domain Controllers jeweils in 500er Blöcken sogenannte RID-Pools. Also 500 SIDs, welche sie bei Erstellung eines AD-Objekts dem jeweiligen Objekt zuweisen können. SIDs, also Security Identifiers sind wie oben beschrieben, die IDs auf dessen die gesamte Authorisierung und Sicherheit des Active Directory aufgebaut sind. Somit ist der RID Master eine absolut essenzielle Aufgabe, und es können keine Objekte im AD mehr erstellt werden, wenn der RID Master offline ist und die 500er Pools aufgebraucht sind.
  
• PDC Emulator
  Der PDC Emulator ist gleich für drei sehr wichtige Aufgaben im AD zuständig. Er verwaltet Passwort-Änderungen. Alle anderen DCs replizieren ihre Änderungen zu ihm. Auch werden Authentisierungsfehler an einem anderen DC zu ihm weitergeleitet, bevor eine “Wrong Username or Password” Meldung beim Client erscheint. Denn er prüft zuerst, ob er eine neuere Version des Passworts bereit hat. Er verwaltet die Gruppenrichtlinien (GPOs). Die Group Policy Management Konsole verbindet sich mit ihm, wenn sie gestartet wird. Er ist AD Zeitserver. (ohne die richtigen Timestamps funktioniert nichts bei der Kerberos Authentisierung)
  
• Infrastructure Master
  Der Infrastructure Master ist nur wichtig in Cross-Domain Authorisierungen. Wenn ein Benutzer von Domäne A Mitglied in einer Gruppe in Domäne B ist, wird in Domäne B ein Objekt erstellt und auf die Domäne A referenziert. Der Infrastructure Master ist zuständig fürs Update der SID und der DistinguisedNames zwischen den beiden Domänen.

FYI: Falls nicht alle DCs in der Domäne auch GC Holder sind (Das Thema GC wurde hier beschrieben) darf der Infrastructure Master nicht auf einem GC Server liegen, da die Objekt-Referenzen sonst nicht mehr richtig aktualisiert werden. Manuel Walder

Für den aktiven Betrieb der Domäne (welche ja vor allem Authentisierung/Authorisierung durchführt) ist es nicht zwingend immer alle FSMO Holder am Laufen zu haben. Am wichtigsten ist hier der PDC Emulator. Aber auch ohne ihn läuft das Meiste für eine Zeit weiter. Passwort-Aktualisierungen werden beispielsweise synchronisiert sobald er wieder online ist. Gefolgt in der Wichtigkit vom PDC Emulator ist meist der RID Master. Welche FSMOs wie lange offline sein können ist meist pro Netzwerk-Anforderung unterschiedlich, jedoch offensichtlich.

---

Forest Functional Level / Domain Functional Level

Die Forest Functional Levels und Domain Functional Levels oder kurz FFL und DFL bestimmen, welche Funktionen im Forest oder der Domain zur Verfügung stehen. Mit jeder neu veröffentlichen Windows Server Version stellt Microsoft natürlich auch neue Features zur Verfügung, welche im Active Directory benutzt werden können.

Mit neueren Versionen stehen auch wichtige Security Features zur Verfügung und alte werden teils nicht mehr unterstützt. Ein Anheben des Levels macht aus diesen Gründen vielfach Sinn, muss jedoch vorher genau analysiert werden, ob alte Systeme gewisse Features benutzen, welche danach nicht mehr funktionieren (zb. Authenticate with NTLM authentication). Um einen DFL/FFL anzuheben, müssen alle Domänenkontroller auf minimal dem Stand oder höher sein, wie das Level welches man aktivieren will.

Folgende DFL/FFL stehen (Stand Okt. 2019) zur Verfügung: (ja es gibt noch ältere, aber über die redet heute niemand mehr 😉 )
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016

Windows Server 2019 bringt (bis jetzt) keine neue ADDS features mit. Somit steht auch kein neuer DFL/FFL zur Verfügung.

Wer genauer wissen will, welche Features in welchem Level zur Verfügung stehen, empfehle ich folgenden Artikel.