Active Directory + PKI

Active Directory, das wirklich passt — von Migration bis Zertifikate

Active Directory ist das Rückgrat der meisten Firmen-IT — und gleichzeitig oft der unaufgeräumteste Bereich. Wildwuchs bei Benutzernamen, NTFS-Berechtigungen, die niemand mehr durchblickt, Domain Controller, die seit Jahren keiner mehr angefasst hat. Hier räume ich auf.

Was du bei mir bekommst: Migration auf Windows Server 2025, eine klare Namenskonvention, ein sauberes NTFS-Berechtigungskonzept nach AGDLP — und obendrauf eine eigene PKI (Public Key Infrastructure) für passwortfreies WLAN, VPN ohne Stress und signierte E-Mails. Alles dokumentiert, alles nachvollziehbar, alles auditfähig.

🔑

Was du am Ende hast

  • Saubere AD-Struktur & Namenskonvention
  • Migration auf Windows Server 2025
  • NTFS-Berechtigungskonzept (AGDLP)
  • Eigene CA für WLAN, VPN, S/MIME
  • Auto-Enrollment via GPO & Intune
  • SCEP/PKCS für mobile Geräte
  • Komplette Doku als PDF
Die Bausteine deiner PKI

Was zur kompletten PKI dazugehört

Eine PKI ist mehr als nur ein Server. Es ist ein System aus mehreren Komponenten, die sauber zusammenspielen müssen. Hier die wichtigsten:

👑

Root-CA

Der Vertrauensanker — eine offline-CA, die nur die Issuing-CA signiert. Wird im Tresor verstaut.

📜

Issuing-CA

Die Online-CA, die im AD läuft und die täglichen Zertifikate ausstellt. Auf einem dedizierten Server.

📋

Zertifikatstemplates

Vorlagen für verschiedene Anwendungen: Geräte-Zertifikate, Benutzer-Zertifikate, Webserver, S/MIME.

🌐

NDES für SCEP

Ein Webservice, über den Intune Zertifikate für mobile Geräte beantragen kann (SCEP-Protokoll).

🔄

Auto-Enrollment

Domain-Mitglieder bekommen Zertifikate automatisch per Gruppenrichtlinie. Erneuerung läuft selbstständig.

📡

CRL & OCSP

Sperrlisten — damit kompromittierte Zertifikate sofort ungültig werden. Erreichbarkeit ist Pflicht.

Praxisbeispiel

So sieht die Einrichtung in der Praxis aus

Hier ein paar typische PowerShell-Befehle, die ich beim Aufbau einer PKI verwende. Keine Sorge — das musst du nicht selbst können. Das ist nur, damit du siehst, dass es keine Magie ist, sondern saubere Standards.

Beispiel 1: Issuing-CA installieren
# Zertifikatsdienst-Rolle installieren
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

# Enterprise Subordinate-CA konfigurieren
Install-AdcsCertificationAuthority `
    -CAType "EnterpriseSubordinateCA" `
    -CACommonName "HUGETEC Issuing CA" `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName "SHA256" `
    -ValidityPeriod Years -ValidityPeriodUnits 10
Beispiel 2: NDES-Connector für Intune installieren
# NDES-Rolle installieren
Install-WindowsFeature ADCS-Device-Enrollment, Web-Server `
    -IncludeManagementTools

# NDES konfigurieren mit dediziertem Service-Konto
Install-AdcsNetworkDeviceEnrollmentService `
    -ServiceAccountName "HUGETEC\svc_ndes" `
    -ServiceAccountPassword (Read-Host -AsSecureString) `
    -CAConfig "ca01.hugetec.local\HUGETEC Issuing CA"
Domain Controller Migration

Von Windows Server 2016/2019/2022 auf Windows Server 2025

Windows Server 2016 läuft 2027 aus dem Extended Support. Server 2019 und 2022 sind noch jahrelang sicher — aber wenn sowieso ein Hardware-Wechsel oder eine größere Umstellung ansteht, lohnt sich der Sprung auf Windows Server 2025 jetzt: Mehr Sicherheit out-of-the-box, bessere Hybrid-Anbindung an Entra ID, deutlich bessere Performance bei Hyper-V.

Mein DC-Migrations-Vorgehen — sauber, ohne Datenverlust

Eine Domain-Controller-Migration ist kein In-Place-Upgrade. Wer das macht, handelt sich oft Probleme mit Sysvol-Replikation, alten DFSR-Beständen oder beschädigten Schemata ein. Mein Weg: parallel migrieren.

  1. Schema-Erweiterung auf Server 2025 (adprep /forestprep, adprep /domainprep)
  2. Neue DCs mit Server 2025 zur bestehenden Domain hinzufügen
  3. FSMO-Rollen einzeln und kontrolliert auf neue DCs übertragen
  4. SYSVOL-Replikation von DFSR auf modernen Stand bringen, falls nötig
  5. DNS & DHCP auf neue Server umziehen, alte Einträge bereinigen
  6. Erst nach mehreren Tagen Stabilitätsphase: alte DCs herabstufen und entfernen
  7. Domain Functional Level auf 2025 anheben — schaltet neue Sicherheitsfeatures frei

Was du davon hast: Du kannst zu jedem Zeitpunkt zurück. Wenn etwas nicht passt, sind die alten DCs noch da. Erst wenn alles stabil läuft, gehen sie offline.

🆕

Was Server 2025 bringt

Hotpatching für DCs (Reboots seltener), Delegated Managed Service Accounts (dMSA), bessere SMB-Verschlüsselung, modernere Kerberos-Defaults.

🔁

Hybrid-Vorteil

Server 2025 spielt deutlich besser mit Entra ID zusammen — Conditional Access bis ins lokale AD, Cloud-Kerberos für Hybrid-Anmeldungen.

Migrationszeit

Für 2 DCs in einer Domain plane 1-2 Wochen mit Pilot, Cutover am Wochenende, danach Stabilitätsphase. Ohne Downtime im Tagesgeschäft.

AD-Beratung

Namenskonvention — die unsichtbare Basis für jedes saubere AD

In den meisten gewachsenen AD-Umgebungen finde ich Konten wie Mueller_M, m.mueller, MMUELLER1 und muellermarcus2 — alles ist ein und dieselbe Person, von verschiedenen Admins angelegt. Das Ergebnis: Niemand findet etwas, Berechtigungen sind ein Albtraum, GPOs treffen die falschen Objekte. Eine klare Namenskonvention räumt damit auf — ein für alle Mal.

👤

Benutzerkonten

Vorname.Nachname für reguläre Benutzer (z. B. marcus.mueller).

Bei Namensgleichheit: Mittelinitiale oder Datum dazu. Niemals fortlaufende Nummern wie mmueller2.

🛡️

Admin-Konten (Tier-Modell)

Eigene Konten pro Tier mit klarem Präfix:

  • t0-marcus.mueller Domain-Admin
  • t1-marcus.mueller Server-Admin
  • t2-marcus.mueller Helpdesk
🖥️

Computer & Server

3-Buchstaben-Kürzel + Funktion + laufende Nummer:

  • MUC-DC01 Domain Controller München
  • MUC-FS01 File Server
  • MUC-CA01 Issuing-CA
  • NB-MM-001 Notebook von Marcus
👥

Gruppen — AGDLP-Schema

Account → Global → DomainLocal → Permission. Microsoft-Best-Practice für saubere Berechtigungen:

  • G-Buchhaltung globale Rollen-Gruppe
  • DL-Buchhaltung-FS01-RX Lese-Rechte auf Share
  • DL-Buchhaltung-FS01-RW Schreib-Rechte

Warum das wichtig ist: Eine konsequente Namenskonvention macht Audits, Onboarding, Offboarding und Berechtigungsanalysen um den Faktor 10 schneller. Wenn ein neuer Mitarbeiter kommt, gibt's eine Vorlage. Wenn jemand geht, weißt du sofort, was zu sperren ist.

Berechtigungskonzept

NTFS-Berechtigungen — sauber, dokumentiert, auditierbar

„Jeder darf alles, weil sonst ständig Tickets kommen" — das ist der häufigste Zustand, den ich auf File-Servern finde. Die Folgen: Datenleaks, Compliance-Verstöße, im Ransomware-Fall verschlüsselt der Angreifer einfach alles, weil ein einziges Konto Zugriff auf jeden Ordner hat. Ein gutes Berechtigungskonzept verhindert das.

Die 7 Regeln meines NTFS-Konzepts

  1. Berechtigungen NUR über Gruppen — niemals direkt an Benutzern. Das ist die wichtigste Regel.
  2. AGDLP-Schema konsequent durchziehen: Benutzer → globale Gruppe (Rolle) → Domain-Local-Gruppe (Berechtigung auf Ressource) → NTFS-Recht.
  3. Vererbung aktiv halten, nur in Ausnahmefällen unterbrechen. Jeder Bruch muss dokumentiert sein.
  4. Lese- und Schreibrechte trennen — eigene DL-...-RX und DL-...-RW Gruppen pro Ordner.
  5. Keine "Vollzugriff"-Rechte für normale Anwender — Vollzugriff bedeutet auch Berechtigungen ändern. Schreiben reicht.
  6. Maximal 3 Ebenen tief Berechtigungen vergeben. Tiefer wird es unwartbar.
  7. Alles dokumentiert in einer einfachen Excel-Tabelle: Welche Gruppe darf wo was — pro Quartal aktualisieren.
📊

IST-Analyse

Ich scanne deinen File-Server mit PowerShell und liste auf: wer hat wo welche Rechte, wo sind direkte Benutzer-Berechtigungen, wo ist Vererbung gebrochen.

📐

Soll-Konzept

Wir definieren Rollen (Buchhaltung, Vertrieb, Geschäftsführung, …) und mappen Ordner-Strukturen auf diese Rollen. Klar, schriftlich, in einer Tabelle.

🔧

Migration

Bestehende Rechte werden Schritt für Schritt auf das neue Schema umgestellt — mit Test-Phase pro Ordner-Bereich, damit niemand plötzlich nicht mehr arbeiten kann.

📋

Dokumentation & Übergabe

Du bekommst die fertige Berechtigungsmatrix als PDF und Excel — damit jeder Admin in deinem Haus selbst nachvollziehen kann, warum etwas wie eingerichtet ist.

Anwendungsfälle

Wofür du deine PKI konkret einsetzt

Use Case 1

Passwordfreies WLAN (EAP-TLS)

Jedes Firmen-Gerät bekommt automatisch ein Zertifikat. Beim WLAN-Login authentifiziert sich das Gerät über das Zertifikat — kein Passwort, keine PSK. Wenn ein Mitarbeiter das Unternehmen verlässt, sperrst du das Zertifikat in der CRL und der Zugang ist weg.

Voraussetzung: NPS/RADIUS-Server, der die Zertifikate prüft. Mehr dazu hier.

Use Case 2

VPN ohne Passwort-Stress

Außendienst-Mitarbeiter verbinden sich per VPN — mit ihrem Geräte-Zertifikat als Authentifizierung. Wenn das Gerät als Intune-konform gilt, gibt's Zugriff. Sonst nicht.

Vorteil: Kein Hardware-Token mehr, keine SMS-Codes, keine vergessenen VPN-Passwörter im Home-Office.

Use Case 3

Signierte und verschlüsselte E-Mails (S/MIME)

Anwälte und Steuerberater wollen, dass Mandantenpost nachweislich von ihnen kommt und nicht unterwegs gelesen werden kann. S/MIME-Zertifikate sind dafür perfekt — und sie kommen automatisch über die PKI auf alle Geräte.

Use Case 4

Interne Webserver mit eigener CA

Intranet, Confluence, Jira, Drucker-Web-Interfaces — alle bekommen interne Zertifikate ohne Browser-Warnung. Statt jährlich von Let's Encrypt extern zu erneuern, kommt alles aus deiner eigenen CA.

Ablauf

In 5 Schritten zur fertigen PKI

Eine PKI baust du nicht in zwei Tagen. Aber mit klarem Plan in 4–6 Wochen. Hier meine Standardvorgehensweise:

1

Analyse

Was brauchst du? WLAN, VPN, S/MIME? Welches AD ist da?

2

Design

Root-CA offline oder online? Welche Templates? CRL-Verteilung?

3

Aufbau

CA installieren, Templates erstellen, NDES für Intune einrichten.

4

Pilot

Erste Geräte bekommen Zertifikate, WLAN/VPN getestet, Feinschliff.

5

Rollout

Auto-Enrollment für alle, Doku, Übergabe und optional Monitoring.

Was Kunden sagen

Stimme aus der Praxis

★★★★★

„Super Zusammenarbeit, geht auf Wünsche und Vorstellungen ein, hat viele gute Ideen, großes Fachwissen, sehr modern, sehr freundlich, immer wieder gerne…"

Susanne GatzenGoogle-Rezension · 5/5

Alle Bewertungen auf Google ansehen →

Ali Sasanipour, IT-Berater aus München

PKI ist eines der spannendsten und gleichzeitig komplexesten Themen in der Microsoft-Welt. Ich habe in den letzten Jahren mehrere PKI-Umgebungen für Münchner Unternehmen aufgebaut — von der kleinen Anwaltskanzlei bis zum Mittelständler mit mehreren Standorten. Die größte Falle: zu früh zu komplex werden. Ich starte immer mit einem schlanken Setup, das wir bei Bedarf erweitern. Sprich mich gerne an, wenn du dir nicht sicher bist, was du brauchst.

Häufige Fragen

Was Kunden zu PKI fragen

Brauche ich wirklich eine eigene PKI oder reicht Let's Encrypt?
Let's Encrypt funktioniert nur für öffentlich erreichbare Webserver — also deine Webseite. Für interne Geräte (WLAN, VPN, interne Server, Drucker) und Benutzer (S/MIME) brauchst du eine eigene CA. Beides hat seine Berechtigung — Let's Encrypt extern, eigene PKI intern.
Wie lange dauert die Einrichtung?
Für eine schlanke PKI (Root-CA offline, Issuing-CA online, NDES für Intune, ein paar Templates) rechne 4–6 Wochen mit Pilotphase. Die reine Installation ist schneller — aber gerade die Templates und Auto-Enrollment-Tests brauchen Zeit, damit später nichts schiefgeht.
Was passiert, wenn die CA ausfällt?
Bestehende Zertifikate funktionieren weiter — die werden nicht ständig überprüft. Nur die Erneuerung und Neuausstellung von Zertifikaten geht nicht mehr. Deshalb plane ich immer Backup und idealerweise eine zweite Issuing-CA. Bei kleinen Umgebungen reicht ein Snapshot-Backup mit dokumentiertem Wiederherstellungs-Verfahren.
Funktioniert das auch ohne lokales AD, nur mit Entra ID?
Microsoft hat Entra Cloud PKI als Cloud-Lösung — das ist eine Alternative für Cloud-only-Umgebungen ohne lokales AD. Funktioniert sehr gut für Geräte-Zertifikate via Intune. Wenn du eine Hybrid-Umgebung mit lokalem AD hast, ist die klassische AD CS oft die bessere Wahl. Ich empfehle dir das Passende im Erstgespräch.
Kann ich später noch erweitern (z.B. von WLAN auf VPN)?
Ja, problemlos. Die PKI ist eine Plattform — einmal aufgebaut, kommen neue Anwendungsfälle einfach dazu. Du startest mit WLAN, fügst später VPN dazu, dann S/MIME — alles über dieselbe CA, mit zusätzlichen Templates.
Soll ich von Windows Server 2016/2019 auf 2025 migrieren — oder reicht 2022?
Server 2016 läuft 2027 aus dem Extended Support — da musst du sowieso bald migrieren. Server 2019 und 2022 sind noch Jahre sicher. Wenn aber demnächst Hardware getauscht wird oder eine größere Umstellung ansteht (z. B. Hybrid mit Entra ID, Conditional Access bis ins lokale AD), lohnt sich der direkte Sprung auf Server 2025: Hotpatching für DCs, Delegated Managed Service Accounts, modernere Kerberos-Defaults, bessere Integration mit Microsoft Cloud. Migration läuft parallel — kein In-Place-Upgrade, sondern neue DCs daneben, dann FSMO-Rollen rüber, dann alte abbauen.
Lohnt sich eine Namenskonvention auch im kleinen Unternehmen mit 15 Leuten?
Ja — gerade da. Bei 15 Leuten kennt der Inhaber heute noch jeden Account. Aber spätestens wenn der Steuerprüfer, der Datenschutzbeauftragte oder ein neuer Admin reinguckt, soll alles auf einen Blick klar sein. Eine saubere Konvention einmal definiert kostet wenig Zeit und spart später Stunden bei jedem Onboarding, Offboarding oder Audit. Mein Aufwand für ein 15-Personen-Unternehmen: typischerweise 1–2 Tage Konzept und Umsetzung.
Was ist AGDLP und warum verwenden alle das?
AGDLP = Account → Global → DomainLocal → Permission. Microsoft-Best-Practice für saubere Berechtigungen: Du steckst Benutzer in globale Rollen-Gruppen („G-Buchhaltung"), diese in Domain-Local-Berechtigungs-Gruppen („DL-Buchhaltung-Lesen") und vergibst die NTFS-Rechte nur an die Domain-Local-Gruppen. Vorteil: Berechtigungen ändern sich nicht, wenn jemand das Team wechselt — du tauschst nur die Mitgliedschaft in der Rollen-Gruppe. Skaliert auch über Forest-Grenzen hinweg.
Wir haben ein chaotisches NTFS-Berechtigungssystem. Wie räume ich auf, ohne den Betrieb lahmzulegen?
Schritt für Schritt — und nur ein Bereich nach dem anderen. Mein Vorgehen: (1) IST-Analyse mit PowerShell (wer hat wo welche Rechte, wo sind direkte User-Berechtigungen, wo gebrochene Vererbung), (2) Soll-Konzept erstellen (Rollen → Gruppen → Ordner-Struktur), (3) Bereich für Bereich migrieren mit Test-Phase pro Abteilung, (4) parallele alte Rechte zunächst nicht entfernen — nur ergänzen, dann nach 2 Wochen Stabilität bereinigen. So merkt das Tagesgeschäft nichts. Für ein typisches KMU rechne 5–8 Beratertage.
Fachbegriffe

Glossar — die wichtigsten Begriffe rund um PKI

CA (Certificate Authority)

Zertifizierungsstelle. Stellt digitale Zertifikate aus und vertraut für deren Echtheit.

CRL (Certificate Revocation List)

Sperrliste mit allen widerrufenen Zertifikaten. Wird regelmäßig aktualisiert und veröffentlicht.

SCEP (Simple Certificate Enrollment Protocol)

Protokoll, mit dem mobile Geräte automatisch Zertifikate beantragen können — z.B. via Intune.

EAP-TLS

WLAN-Authentifizierungsverfahren mit Zertifikaten — sicherer als WPA2-PSK mit Passwort.

Auto-Enrollment

Automatische Zertifikatsausstellung an Geräte/Benutzer per Gruppenrichtlinie. Erneuerung läuft selbstständig.

NDES (Network Device Enrollment Service)

Microsoft-Webdienst, der SCEP-Anfragen entgegennimmt — z.B. von Intune-Geräten.

OCSP (Online Certificate Status Protocol)

Echtzeit-Abfrage, ob ein Zertifikat noch gültig ist — Alternative zur CRL.

S/MIME

Standard zum digitalen Signieren und Verschlüsseln von E-Mails — wichtig für Anwälte und Steuerberater.

AGDLP

Microsoft-Best-Practice für Berechtigungen: Account → Global Group (Rolle) → Domain-Local Group (Berechtigung) → Permission auf Ressource.

FSMO-Rollen

Spezielle AD-Rollen (Schema Master, RID Master, PDC Emulator usw.), die nur ein DC gleichzeitig haben darf — bei Migration kontrolliert übergeben.

SYSVOL / DFSR

Verzeichnis auf jedem DC, das Gruppenrichtlinien und Skripte zwischen DCs repliziert. Ältere Domains nutzen FRS, neuere DFSR.

Domain Functional Level

Bestimmt, welche AD-Features verfügbar sind. Erst nach Abbau aller alten DCs wird der Level angehoben — schaltet neue Sicherheitsfeatures frei.

NTFS-Vererbung

Berechtigungen werden automatisch von übergeordneten Ordnern an Unterordner weitergegeben. Brechen sollte man nur in Ausnahmefällen — und dokumentiert.

Dein nächster Schritt

Lass uns deine PKI sauber aufbauen

Im Erstgespräch klären wir, was du wirklich brauchst — und vor allem, was du nicht brauchst. Ich verkaufe dir keine 5-Server-PKI, wenn ein schlankes Setup reicht.