--- id: ki4ad-tier-schutz type: knowledge-entry language: de updated: 2026-10-10 status: freigegeben --- # Dienstkonten, lokale Administratoren und geschützte Identitäten. Übernommen von [KI4AD.de](), Quellenstand: 2026-10-10. 06 / ERGÄNZENDE SCHUTZMASSNAHMEN ### Dienstkonten, lokale Administratoren und geschützte Identitäten. Kontentrennung, Authentifizierungsregeln und Schutz im Arbeitsspeicher erfüllen unterschiedliche Aufgaben\. Erst ihr abgestimmtes Zusammenspiel stärkt die vorgesehenen Vertrauensgrenzen\. #### gMSA für geeignete Dienste Group Managed Service Accounts ermöglichen eine durch Windows verwaltete Kennwortpflege\. Anwendungsunterstützung, berechtigte Abrufsysteme und Rechte des Dienstes werden vorab geprüft\. Automatische Kennwortwechsel beseitigen keine überhöhten Berechtigungen\. **Ein Konto, eine Ebene\.** Administrative Konten, Dienstkonten und Gruppen arbeiten in genau einer Ebene\. Ein auf Tier 0 und Tier 1 genutztes Dienstkonto eröffnet auf jedem beteiligten Tier-1-Server einen möglichen Weg zum Diebstahl von Tier-0-Anmeldedaten\. Vor der Umstellung werden solche Konten nach Ebene und Aufgabe aufgeteilt\. [Microsoft Learn: gMSA verwalten ↗]() #### Windows LAPS Individuelle, verwaltete Kennwörter begrenzen die Risiken gemeinsam genutzter lokaler Administrationskonten\. Lese- und Rücksetzrechte, Sicherungsort und Rotation gehören zum Konzept\. DSRM-Kennwortverwaltung für Domain Controller ist ein eigener Anwendungsfall; die Sicherung erfolgt in Windows Server AD, nicht in Entra ID\. [Microsoft Learn: Windows LAPS ↗]() #### Protected Users Die Gruppe kann sensible Benutzerkonten gegen bestimmte unsichere Authentifizierungswege absichern\. Einschränkungen bei NTLM, Delegation und Anmeldung müssen zu den Aufgaben und der Domänenfunktionsebene passen\. Dienst- und Computerkonten werden nicht aufgenommen: Ihre Authentifizierung würde beeinträchtigt\. [Microsoft Learn: Protected Users und Authentifizierungsrichtlinien ↗]() 06\.1 / AUTHENTIFIZIERUNG BEGRENZEN #### Authentication Policies und Silos: Tier 0 technisch eingrenzen. Authentifizierungsrichtlinien können unter anderem zulässige Anmeldequellen, Authentifizierungsziele und die Lebensdauer von Kerberos-TGTs begrenzen\. Ein Authentication Policy Silo bündelt dafür ausgewählte Benutzer-, Computer- und Dienstkonten\. So lässt sich beispielsweise die Verwendung privilegierter Identitäten an freigegebene Tier-0-Administrationsgeräte binden\. 1. **Voraussetzungen prüfen:** Domänenfunktionsebene mindestens Windows Server 2012 R2, unterstützte Systeme und erforderliche Kerberos-Funktionen\. Für gerätebezogene Quellbedingungen ist Kerberos Armoring relevant; NTLM- und Anwendungsabhängigkeiten gesondert untersuchen\. 2. **Im Audit-Modus beginnen:** Erwartete Verstöße protokollieren und legitime Abläufe identifizieren\. Audit allein blockiert keine Anmeldung und ist noch keine durchgesetzte Schutzgrenze\. 3. **Kontrolliert erzwingen:** Konten korrekt zuweisen, Mitgliedschaften autorisieren, Notfallzugang testen und erst nach positivem Pilot in den Enforcement-Modus wechseln\. Erlaubte und unerlaubte Wege erneut prüfen\. Ein Silo ersetzt weder minimale Rechte noch eine sichere PAW\. Seine Audit-Funktion simuliert nicht automatisch die Wirkung sämtlicher GPO-Anmeldeverbote\. Der eingebaute Domänen-Administrator (RID 500) ist von Authentication Policies ausgenommen und benötigt gesonderte Schutz- und Notfallregeln\. [Microsoft Learn: Authentication Policies und Authentication Policy Silos ↗]() [Microsoft Learn: Voraussetzungen und Konfiguration geschützter Konten ↗]() 06\.2 / ANMELDEDATEN AUF DEM GERÄT SCHÜTZEN #### Credential Guard und LSA-Schutz für PAWs und geeignete Server. #### Credential Guard Virtualisierungsbasierte Sicherheit isoliert bestimmte Anmeldegeheimnisse wie NTLM-Hashes und Kerberos-TGTs vom normalen Betriebssystem\. Hardware, Firmware, Edition und Anwendungsabhängigkeiten werden vor einer Aktivierung geprüft\. Der tatsächliche Schutzstatus zählt, nicht nur der gesetzte Richtlinienwert\. Credential Guard ist nicht Remote Credential Guard\. Es schützt weder die AD-Datenbank eines DCs noch vor Keyloggern oder jedem Missbrauch einer laufenden Sitzung\. Microsoft empfiehlt die Aktivierung auf Domain Controllern nicht; PAWs und geeignete Mitgliedsserver werden gesondert bewertet\. [Microsoft Learn: Funktionsweise und Grenzen ↗]() [Microsoft Learn: Voraussetzungen und DC-Einschränkung ↗]() #### LSA-Schutz / RunAsPPL LSASS läuft als geschützter Prozess\. Das erschwert ungeschützten Prozessen das Auslesen seines Speichers und das Einschleusen von Code\. LSA-Schutz und Credential Guard ergänzen einander, statt austauschbare Schalter zu sein\. Vor dem Rollout werden Smartcard-Treiber, Kennwortfilter und weitere LSA-Erweiterungen auf Kompatibilität geprüft\. Audit- und Code-Integrity-Ereignisse unterstützen den Pilot\. Eine UEFI-Sperre braucht einen ausdrücklich vorbereiteten Rückweg; ein Registry-Rollback reicht dann nicht\. [Microsoft Learn: Zusätzlicher LSA-Schutz und Kompatibilitätsprüfung ↗]() Zusätzlich bleiben Protokollhärtung, LDAP-Signing, geeignete SMB-Einstellungen, Updates, Überwachung und Schutz von Domain Controllern eigenständige Prüffelder\. Tiering ersetzt diese Maßnahmen nicht\. --- [Datensatz (JSON)]() · [Katalog]()