Erweiterte AD-Funktionen

Active Directory ist nicht nur für die Verwaltung von Benutzern und Gruppen da.
In großen oder komplexen Netzwerken sind weitere Funktionen entscheidend, damit das System skalierbar, sicher und verlässlich bleibt.
Wir schauen uns diese Funktionen einzeln an.

1) Vertrauensstellungen (Trusts)

Ein Trust ist eine Vertrauensbeziehung zwischen zwei Domänen oder Forests.
Er bedeutet: „Die Benutzer der anderen Domäne dürfen – wenn berechtigt – auch auf meine Ressourcen zugreifen.“

Beispiel:

firma.local hat eine eigene Domäne.
partner.local ist eine andere Domäne.
Durch eine Vertrauensstellung können Benutzer von partner.local auf Freigaben in firma.local zugreifen, ohne dass man in beiden Systemen zwei Benutzerkonten pflegen muss.

Domäne: firma.local
   │
   └── Trust (zweiseitig)
         │
         └── Domäne: partner.local

Arten von Trusts:
- Einseitig: Nur A vertraut B. Benutzer von B können in A arbeiten, aber nicht umgekehrt.
- Zweiseitig: Beide Seiten vertrauen einander.
- Innerhalb eines Forests: Automatisch vorhanden.
- Zwischen Forests: Muss von Admins eingerichtet werden.
Wofür wichtig?
- Kooperation mit Partnerfirmen.
- Migrationen von einer alten in eine neue Domäne.
- Konzerne mit mehreren Tochterfirmen.
2) Replikation
Ein einzelner Domänencontroller wäre ein Single Point of Failure: Wenn er ausfällt, funktioniert keine Anmeldung mehr.
Darum gibt es in AD immer mehrere Domänencontroller (DCs).
Replikation bedeutet:
Alle DCs gleichen ihre Datenbestände regelmäßig miteinander ab.
Wenn sich ein Benutzer an DC-01 ein neues Passwort setzt, weiß auch DC-02 kurze Zeit später davon.

   DC-01  ←→  DC-02  ←→  DC-03
       ↖──────────────↗

Eigenschaften der Replikation:
- Multimaster-Prinzip: Jeder DC kann Änderungen annehmen.
- Konfliktlösung: Wenn zwei Änderungen gleichzeitig auftreten, entscheidet ein Zeitstempel.
- Innerhalb einer Site: Sehr häufig (fast in Echtzeit).
- Zwischen Sites: Zeitgesteuert oder über geplante Replikationspläne.
Praxisbeispiel:
- Standort Berlin: Benutzer ändert Passwort → Änderung landet sofort auf Berliner DCs.
- Replikation nach München: erfolgt z. B. alle 15 Minuten über WAN-Link.
- Ergebnis: Der Benutzer kann sich auch in München anmelden, weil die Änderung synchronisiert wurde.
Warum wichtig?
- Ausfallsicherheit (wenn ein DC ausfällt, übernimmt ein anderer).
- Lastverteilung (Anmeldungen werden auf mehrere DCs verteilt).
- Weltweite Verfügbarkeit von Benutzerinformationen.
3) Sites
Sites beschreiben die geografische Struktur eines Unternehmens.
Sie werden über IP-Subnetze definiert.
Funktion:
- Clients melden sich beim DC ihrer Site an → schnellerer Login.
- Replikation zwischen Sites wird optimiert, um WAN-Leitungen nicht unnötig zu belasten.

Forest: firma.local
│
├─ Site: Berlin
│   ├─ DC-Berlin01
│   └─ DC-Berlin02
│
└─ Site: München
    └─ DC-Muc01

Praxis:
Ein Mitarbeiter in München meldet sich am PC an.
→ PC fragt: „Welcher DC gehört zu meinem Subnetz?“
→ Ergebnis: Anmeldung erfolgt bei DC-Muc01 (lokal, schnell).

Ohne Sites könnte es passieren, dass sich ein Münchener PC am Berliner DC anmeldet → langsamer, unnötige WAN-Belastung.

4) Fine-Grained Password Policies (FGPP)

Früher galt in einer Domäne nur eine Kennwortrichtlinie.
Das Problem: Admins und normale User hatten dieselben Regeln.

Mit FGPP kann man mehrere Passwort-Richtlinien parallel nutzen.

Gruppe	Regel
Normale User	min. 8 Zeichen, Ablauf nach 90 Tagen
Administratoren	min. 14 Zeichen, Ablauf nach 30 Tagen

Technisch:

Umsetzung über Password Settings Objects (PSO).
PSOs werden Gruppen oder einzelnen Benutzern zugewiesen.

Praxis:
Admins müssen deutlich strengere Regeln befolgen als normale Anwender.

5) Active Directory Zertifikatsdienste (AD CS)

AD kann als interne Zertifizierungsstelle (CA) betrieben werden.
Damit lassen sich Zertifikate automatisch an Benutzer und Computer ausstellen.

Einsatzmöglichkeiten:

Smartcard-Login: Benutzer meldet sich mit Chipkarte an.
WLAN (802.1X): Nur Geräte mit Zertifikat dürfen ins Netz.
E-Mail-Verschlüsselung/Signatur: Kommunikation absichern.
BitLocker / EFS: Festplattenverschlüsselung mit AD-Integration.

Praxisbeispiel:
Alle Firmen-Laptops erhalten automatisch ein Zertifikat aus AD.
→ Nur diese Geräte kommen ins WLAN. Ein privater Laptop ohne Zertifikat wird blockiert.

6) Federation & AD FS

Active Directory Federation Services (AD FS) erweitern AD in Richtung Cloud/Partnerfirmen.

Aufgabe:
Ein Benutzer meldet sich bei der Domäne an und ist automatisch auch bei externen Diensten angemeldet → Single Sign-On (SSO).

7) Single Sign-On (SSO) & SAML

SSO im Überblick

Ziel: Ein Benutzer meldet sich einmal an und kann dann mehrere Systeme nutzen, ohne ständig Benutzername/Passwort neu einzugeben.
Im AD intern: Kerberos erledigt SSO automatisch (Dateiserver, Drucker, Exchange).
In Cloud/Web-Apps: Standards wie SAML oder OpenID Connect übernehmen das.

SAML – wie funktioniert das?

Identity Provider (IdP): z. B. AD FS oder Azure AD.
Service Provider (SP): z. B. Salesforce, Teams, Google Workspace.

Ablauf (vereinfacht):

1) Benutzer meldet sich in der Domäne an.
2) Er öffnet eine Cloud-App (z. B. Salesforce).
3) Salesforce fragt den IdP (AD FS/Azure AD): "Ist der Benutzer echt?"
4) IdP sendet ein SAML-Token zurück.
5) Salesforce vertraut dem Token → Benutzer ist eingeloggt.

Vergleich Kerberos vs. SAML

Merkmal	Kerberos (intern)	SAML (Cloud/Web)
Einsatz	Windows-Domäne	Cloud-/Web-Apps
Technik	Tickets, symm. Verschlüsselung	XML-Assertions
IdP	Domänencontroller (KDC)	AD FS, Azure AD
Beispiel	Dateiserver, Drucker	Microsoft 365, Salesforce

Praxis:

Mitarbeiter meldet sich am PC an.
Mit demselben Login ist er sofort in Teams, SharePoint und Salesforce → dank SSO über Azure AD mit SAML.

8) Read-Only Domain Controller (RODC)

Ein RODC ist ein Domänencontroller, der nur lesen, aber nicht schreiben darf.
Er wird eingesetzt in unsicheren oder entfernten Standorten (z. B. Filialen, die leicht gestohlen oder gehackt werden könnten).

Vorteile:

Keine Passwortänderungen oder Schema-Änderungen vor Ort möglich.
Wenn der Server gestohlen wird, ist das Risiko begrenzt.
Anmeldung lokal trotzdem möglich (Caching bestimmter Konten).

9) Delegation & Servicekonten

In großen Netzwerken gibt es viele Dienste, die eigene Konten brauchen:
z. B. SQL-Server, Exchange, Webserver.

Servicekonto: Ein Konto, das speziell für einen Dienst angelegt wird.
Delegation: Steuert, welche Dienste im Auftrag eines Benutzers handeln dürfen.

Beispiel:
Ein Webserver soll sich bei einem SQL-Server anmelden – aber im Namen des angemeldeten Benutzers.
→ Mit Kerberos-Delegation kann der Webserver „das Ticket weiterreichen“.

10) Sicherheitsfunktionen im AD

Gruppenrichtlinien für Sicherheit: Sperrbildschirm, Passwortregeln, USB-Ports deaktivieren.
Auditierung: Wer hat sich wann angemeldet? Wer hat welche Datei geöffnet?
Mehrstufige Administration: Trennung zwischen normalem Benutzerkonto und Admin-Konto.
MFA (Multi-Faktor-Authentifizierung): Über Azure AD leicht integrierbar.

11) Praxis-Szenario (alles zusammengeführt)

Unternehmen „Beispiel GmbH“ hat:

Forest firma.local mit Sites Berlin und München.
Replikation: Berliner DCs ↔ Münchener DC über WAN-Link.
Fine-Grained Password Policies: Admins mit 14 Zeichen, Benutzer mit 8 Zeichen.
AD CS stellt Zertifikate für WLAN und E-Mail aus.
Trust mit Partnerfirma partner.local für Projektzusammenarbeit.
AD FS + SAML für SSO mit Microsoft 365 und Salesforce.
Niederlassung in Polen nutzt RODC → lokal schneller Login, wenig Risiko.

Merksätze

Trusts verbinden Domänen oder Forests.
Replikation = Abgleich der AD-Datenbank zwischen DCs (multimaster).
Sites steuern, welcher DC für welchen Standort zuständig ist.
FGPP erlauben mehrere Kennwortrichtlinien in einer Domäne.
AD CS = Zertifikatsdienste (WLAN, Smartcards, E-Mail).
SSO & SAML = Einmal anmelden, Cloud-Apps ohne erneute Login-Daten nutzen.
RODC = Sicherer DC für unsichere Standorte.
Delegation = Kontrolle über Servicekonten und Dienste.