> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/cyber-best-practices/de/leitfaden-zur-behebung-von-schwachstellen/ad-scan-vulnerability-remediation-guide.md).

# Leitfaden zur Behebung von Active-Directory-Scans

Jeder Schwachstellenabschnitt enthält:

* **Was es bedeutet:** eine Erklärung des Risikos in einfacher Sprache
* **Was der Scan prüft:** die spezifischen Bedingungen, die den Alarm auslösen
* **Warum der Alarm bestehen bleiben kann:** häufige Teilbehebungen, die nicht ausreichen
* **Wie man diagnostiziert:** PowerShell-Befehle, um betroffene Objekte zu identifizieren
* **Wie man behebt:** schrittweise Behebung

> **Voraussetzungen:** Alle PowerShell-Befehle erfordern das `ActiveDirectory` -Modul und sollten als Domänenadministrator auf einem Domänencontroller ausgeführt werden.
>
> ```powershell
> Import-Module ActiveDirectory
> ```

## A-LAPS-Not-Installed

#### Was das bedeutet

Jeder Windows-Computer hat ein **integriertes lokales Administratorkonto**. Standardmäßig hat dieses Konto oft auf allen Maschinen dasselbe Kennwort oder ein Kennwort, das sich nie ändert. Wenn ein Angreifer eine Maschine kompromittiert, kann er dieses Kennwort wiederverwenden, um auf alle anderen zuzugreifen.

**LAPS** (Local Administrator Password Solution) löst dies, indem für jeden Computer automatisch ein eindeutiges, zufällig generiertes Kennwort festgelegt und sicher in Active Directory gespeichert wird. Nur autorisierte Administratoren können es abrufen.

#### Was der Scan prüft

Der AD-Scan sucht nach Hinweisen darauf, dass LAPS in Ihrem Active Directory eingerichtet wurde. Konkret prüft er, ob die erforderlichen LAPS-Datenfelder in Ihrer AD-Konfiguration vorhanden sind. Wenn sie fehlen, bedeutet das, dass LAPS nie installiert wurde.

#### Warum der Alarm bestehen bleiben kann

* **LAPS nur über Intune verwaltet:** Wenn Sie Microsoft Intune verwenden, um LAPS-Kennwörter in der Cloud zu verwalten (ohne das lokale AD zu konfigurieren), kann der AD-Scan dies nicht erkennen. Der Scan prüft nur Ihr lokales Active Directory.
* **LAPS wurde teilweise installiert:** Die LAPS-Einrichtung wurde möglicherweise begonnen, aber nicht abgeschlossen.

#### Wie man diagnostiziert

```powershell
# Prüfen, ob LAPS in Ihrem Active Directory eingerichtet ist
Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext `
  -Filter "name -like 'ms-Mcs-AdmPwd' -or name -eq 'ms-LAPS-Password'" |
  Select-Object Name, whenCreated
```

Wenn dies keine Ergebnisse zurückgibt, ist LAPS nicht installiert.

#### So beheben Sie es

**Für Windows Server 2019 und neuer (empfohlen):** Modernes LAPS ist in Windows integriert. Aktivieren Sie es per Gruppenrichtlinie:

1. Öffnen Sie `gpmc.msc` (Gruppenrichtlinienverwaltung)
2. Bearbeiten oder erstellen Sie eine GPO, die mit Ihren Computer-OUs verknüpft ist
3. Navigieren Sie zu: `Computerkonfiguration > Administrative Vorlagen > System > LAPS`
4. Konfigurieren Sie die LAPS-Einstellungen (aktivieren, Kennwortkomplexität festlegen usw.)

**Für ältere Umgebungen:** Laden Sie Legacy LAPS von Microsoft herunter und führen Sie die Schemaerweiterung aus:

```powershell
Update-LapsADSchema
```

> **Hinweis:** Wenn Sie lokale Administratorkennwörter über ein anderes Tool verwalten (CyberArk, nur Intune-LAPS usw.), wenden Sie sich an den Stoïk-Support, um dies als akzeptierte Ausnahme zu dokumentieren.

## A-LAPS-Joined-Computers

#### Was das bedeutet

Wenn jemand einen Computer zur Active Directory-Domäne hinzufügt ("joint"), wird diese Person zum **Ersteller** des Computerobjekts in AD. Standardmäßig erhält der Ersteller spezielle Berechtigungen für dieses Objekt.

Das Problem ist: Wenn LAPS installiert ist, wird das lokale Administratorkennwort auf genau diesem Computerobjekt gespeichert. Wenn der Ersteller noch über die entsprechenden Berechtigungen verfügt, kann er **das LAPS-Kennwort lesen**, selbst wenn er kein Administrator ist. Das bedeutet, dass ein normaler Benutzer, der einmal einen PC zur Domäne hinzugefügt hat, das lokale Administratorkennwort für diese Maschine abrufen könnte.

#### Was der Scan prüft

Für jeden aktivierten Computer mit bereitgestelltem LAPS prüft der AD-Scan **zwei Dinge**:

1. **Ist die Person, die den Computer hinzugefügt hat, noch der "Eigentümer" des Computerobjekts?** Eigentümer können sich jede Berechtigung selbst erteilen, einschließlich des Lesens des LAPS-Kennworts.
2. **Hat der Ersteller noch explizite Berechtigungen** für das Computerobjekt, wie z. B. `Alle erweiterten Rechte` (was das Lesen des LAPS-Kennworts erlaubt), `WriteDacl` (was das Ändern von Berechtigungen erlaubt), `WriteOwner` (was das Zurückübernehmen des Eigentums erlaubt), oder `GenericWrite`?

Der Alarm wird ausgelöst, wenn **entweder** eine Bedingung wahr ist.

#### Warum der Alarm bestehen bleiben kann

Dies ist die häufigste Ursache für Verwirrung: **Das Ändern des Eigentümers ist nur die halbe Lösung.**

Viele Administratoren ändern den Eigentümer zu "Domain Admins" und erwarten, dass der Alarm verschwindet. Der AD-Scan prüft jedoch auch auf verbleibende Berechtigungen (genannt ACEs oder Access Control Entries), die dem ursprünglichen Ersteller gewährt wurden. Diese Berechtigungen bleiben auch nach dem Ändern des Eigentümers bestehen und müssen separat entfernt werden.

#### Wie man diagnostiziert

```powershell
# Computer auflisten, bei denen der Ersteller noch riskante Berechtigungen hat
Get-ADComputer -Filter "Enabled -eq `$true" `
  -Properties "mS-DS-CreatorSID", "nTSecurityDescriptor" |
  Where-Object { $_."mS-DS-CreatorSID" -ne $null } |
  ForEach-Object {
    $comp = $_
    $acl = $comp.nTSecurityDescriptor
    $creatorSid = $comp."mS-DS-CreatorSID"
    $owner = $acl.GetOwner([System.Security.Principal.SecurityIdentifier])

    $isOwner = ($owner.Value -eq $creatorSid.Value)

    $riskyAces = $acl.Access | Where-Object {
      -not $_.IsInherited -and
      $_.IdentityReference.Value -eq $creatorSid.Value -and
      ($_.ActiveDirectoryRights -match 'WriteDacl|WriteOwner|GenericWrite|ExtendedRight')
    }

    if ($isOwner -or $riskyAces) {
      [PSCustomObject]@{
        Computer       = $comp.Name
        CreatorIsOwner = $isOwner
        RiskyRights    = ($riskyAces | ForEach-Object { $_.ActiveDirectoryRights }) -join ", "
      }
    }
  } | Format-Table -AutoSize
```

#### So beheben Sie es

Sie müssen **beides** für jeden betroffenen Computer tun:

1. **Eigentümer ändern** zu Domain Admins
2. **Explizite Berechtigungen des Erstellers entfernen**

Das folgende Skript erledigt beides automatisch:

```powershell
#Requires -Modules ActiveDirectory

$affectedComputers = Get-ADComputer -Filter "Enabled -eq `$true" `
  -Properties "mS-DS-CreatorSID", "nTSecurityDescriptor" |
  Where-Object { $_."mS-DS-CreatorSID" -ne $null }

foreach ($comp in $affectedComputers) {
  $path = "AD:$($comp.DistinguishedName)"
  $acl = Get-Acl -Path $path
  $creatorSid = $comp."mS-DS-CreatorSID"
  $modified = $false

  # Schritt 1: Eigentümer auf Domain Admins ändern
  $domainAdmins = New-Object System.Security.Principal.NTAccount("$env:USERDOMAIN", "Domain Admins")
  $acl.SetOwner($domainAdmins)
  $modified = $true

  # Schritt 2: Explizite Berechtigungen entfernen, die dem Ersteller gewährt wurden (und verwaiste SIDs)
  $toRemove = @($acl.Access | Where-Object {
    -not $_.IsInherited -and
    ($_.IdentityReference.Value -eq $creatorSid.Value -or
     $_.IdentityReference.Value -match '^S-1-5-21-')  # Verwaiste SIDs (gelöschte Konten)
  })

  foreach ($ace in $toRemove) {
    $acl.RemoveAccessRuleSpecific($ace)
    Write-Host "$($comp.Name): [$($ace.ActiveDirectoryRights)] für $($ace.IdentityReference) entfernt"
  }

  if ($modified) {
    Set-Acl -Path $path -AclObject $acl
    Write-Host "$($comp.Name): Behoben" -ForegroundColor Green
  }
}
```

> **Tipp:** Führen Sie zuerst den Diagnosebefehl aus, um die Liste der betroffenen Computer zu prüfen, bevor Sie die Behebung anwenden.

## A-NoServicePolicy

#### Was das bedeutet

**Dienstkonten** sind Konten, die von Anwendungen und Diensten verwendet werden (z. B. SQL Server, Backup-Agents), um sich in Active Directory zu authentifizieren. Anders als normale Benutzerkonten sind Dienstkonten hochwertige Ziele: Sie haben oft erhöhte Berechtigungen und ihre Kennwörter werden selten geändert.

Eine **Feingranulare Kennwortrichtlinie (PSO)** ist eine spezielle Kennwortrichtlinie, die Sie auf bestimmte Kontogruppen anwenden können. Der AD-Scan erwartet, dass Ihre Dienstkonten durch eine PSO abgedeckt sind, die Kennwörter mit mindestens **20 Zeichen**erfordert, wodurch sie deutlich schwerer zu knacken sind.

#### Was der Scan prüft

Der AD-Scan sucht nach mindestens einer Kennwortrichtlinie (GPO oder PSO), die eine Mindestkennwortlänge von **20 Zeichen oder mehr**.

#### Warum der Alarm bestehen bleiben kann

1. **Das Scan-Konto hat keine Berechtigung, die PSO zu lesen.** Kennwortrichtlinien werden in einem geschützten Bereich von AD gespeichert, den standardmäßig nur Domänenadministratoren lesen können. Wenn der Scan mit einem weniger privilegierten Konto ausgeführt wird, kann er die PSO einfach nicht sehen, auch wenn sie existiert.
2. **Die PSO existiert, aber die Mindestlänge liegt unter 20** (z. B. 12 oder 15 Zeichen).
3. **Die PSO existiert, ist aber keiner Gruppe oder keinem Benutzer zugewiesen.**

#### Wie man diagnostiziert

```powershell
# Alle feingranularen Kennwortrichtlinien und ihre Einstellungen auflisten
Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, MinPasswordLength, @{N="AppliedTo"; E={$_.AppliesTo -join ", "}}, Precedence
```

Wenn dies nichts zurückgibt, existiert entweder keine PSO oder das Konto, das den Befehl ausführt, hat keine Berechtigung, sie zu sehen. Versuchen Sie es mit einem Domänenadministratorkonto.

#### So beheben Sie es

**Wenn die PSO existiert, der Scan sie aber nicht sehen kann:** Führen Sie den AD-Scan mit einem Domänenadministratorkonto aus.

**Wenn keine PSO existiert:** Erstellen Sie eine und weisen Sie sie Ihren Dienstkonten zu:

```powershell
# Kennwortrichtlinie für Dienstkonten erstellen
New-ADFineGrainedPasswordPolicy -Name "Service Accounts - Strong Password" `
  -Precedence 10 `
  -MinPasswordLength 20 `
  -MaxPasswordAge "90.00:00:00" `
  -MinPasswordAge "1.00:00:00" `
  -PasswordHistoryCount 24 `
  -ComplexityEnabled $true `
  -ReversibleEncryptionEnabled $false `
  -LockoutDuration "00:30:00" `
  -LockoutObservationWindow "00:30:00" `
  -LockoutThreshold 5

# Einer Sicherheitsgruppe zuweisen, die Ihre Dienstkonten enthält
Add-ADFineGrainedPasswordPolicySubject `
  -Identity "Service Accounts - Strong Password" `
  -Subjects "SG_ServiceAccounts"
```

> **Hinweis:** Das Erstellen einer PSO erzwingt nicht sofort Kennwortänderungen. Vorhandene Kennwörter funktionieren weiter, bis sie ablaufen oder manuell zurückgesetzt werden. Danach gilt die neue Mindestlänge von 20 Zeichen.

## A-AuditDC

#### Was das bedeutet

**Überwachungsrichtlinien** legen fest, welche Ereignisse auf Ihren Domänencontrollern protokolliert werden. Ohne ordnungsgemäße Überwachung können Angriffe wie Diebstahl von Anmeldeinformationen, unbefugte Gruppenänderungen oder Replikationsmissbrauch (DCSync) ohne jede Spur in den Protokollen stattfinden.

Der AD-Scan überprüft, ob Ihre Domänencontroller so konfiguriert sind, dass die wichtigsten Sicherheitsereignisse protokolliert werden.

#### Was der Scan prüft

Der Scan sucht nach **13 spezifischen Überwachungskategorien** die per Gruppenrichtlinie auf allen Domänencontrollern aktiviert sein sollten:

| Kategorie                                 | Was es protokolliert                                               |
| ----------------------------------------- | ------------------------------------------------------------------ |
| Kerberos-Authentifizierungsdienst         | Anmeldeversuche per Kerberos                                       |
| Kerberos-Dienstticketvorgänge             | Anforderungen für Diensttickets (erkennt Kerberoasting)            |
| Verwaltung von Computerkonten             | Computerbeitritte/-änderungen in AD                                |
| Verwaltung von Sicherheitsgruppen         | Änderungen der Gruppenmitgliedschaft                               |
| Verwaltung von Benutzerkonten             | Erstellung, Löschung und Zurücksetzen von Kennwörtern              |
| DPAPI-Aktivität                           | Nutzung der Data Protection API (Zugriff auf Anmeldeinformationen) |
| Prozesserstellung                         | Neu gestartete Prozesse (erkennt schädliche Tools)                 |
| Anmeldung/Abmeldung                       | Interaktive und Remote-Anmeldungen                                 |
| Besondere Anmeldung                       | Anmeldungen mit erhöhten Rechten                                   |
| Änderung der Authentifizierungsrichtlinie | Änderungen an Authentifizierungseinstellungen                      |
| Nutzung sensibler Berechtigungen          | Verwendung sensibler Berechtigungen                                |
| Erweiterung des Sicherheitssystems        | Änderungen am Sicherheitssubsystem                                 |

#### Warum der Alarm bestehen bleiben kann

1. **Einstellungen, die über `auditpol` direkt auf dem DC** angewendet werden, werden nicht erkannt. Der AD-Scan liest Gruppenrichtliniendateien, nicht die lokale DC-Konfiguration. Sie müssen eine GPO verwenden.
2. **Konfliktierende GPOs:** Eine GPO aktiviert die Einstellung, aber eine andere GPO mit höherer Priorität deaktiviert sie.
3. **GPO nicht mit der OU der Domänencontroller verknüpft:** Die GPO existiert, ist aber mit einer anderen OU verknüpft.

#### Wie man diagnostiziert

```powershell
# Die effektive Überwachungsrichtlinie auf einem Domänencontroller prüfen
auditpol /get /category:*
```

Wenn die lokalen Einstellungen korrekt aussehen, der Alarm aber bestehen bleibt, prüfen Sie, ob die Einstellungen aus einer GPO stammen (nicht aus einer lokalen Überschreibung):

```powershell
# Prüfen, welche GPOs mit der OU der Domänencontroller verknüpft sind
Get-GPInheritance -Target "OU=Domain Controllers,$($(Get-ADDomain).DistinguishedName)"
```

#### So beheben Sie es

1. Öffnen Sie `gpmc.msc` (Gruppenrichtlinienverwaltungs-Konsole)
2. Erstellen oder bearbeiten Sie eine GPO, die verknüpft ist mit `OU=Domain Controllers`
3. Navigieren Sie zu: `Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration > Überwachungsrichtlinien`
4. Aktivieren **Erfolg und Fehler** für alle oben aufgeführten Unterkategorien
5. Führen Sie `gpupdate /force` auf allen Domänencontrollern aus

Überprüfen Sie die Behebung:

```powershell
auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Logon/Logoff"
```

## A-BadSuccessor

#### Was das bedeutet

Windows Server 2025 führte einen neuen Typ von Dienstkonto ein, genannt **dMSA** (Delegated Managed Service Account). Es wurde eine Sicherheitslücke entdeckt, bei der ein normaler Benutzer mit bestimmten Berechtigungen für einen Active-Directory-Ordner (genannt Organizational Unit oder OU) eine dMSA erstellen und damit vollen Administratorzugriff auf die Domäne erlangen konnte.

Dieser Angriff ist nur möglich, wenn:

* Sie mindestens einen **Windows Server 2025** Domänencontroller
* Eine **KDS Root Key** vorhanden ist (erforderlich für verwaltete Dienstkonten)
* Ein Nicht-Administrator-Benutzer hat das Recht, Objekte in einer OU zu erstellen

#### Was der Scan prüft

Der AD-Scan sucht nach nicht privilegierten Benutzern oder Gruppen, die Berechtigungen haben, dMSA-Objekte in einer beliebigen OU zu erstellen oder zu steuern, z. B. `CreateChild`, `GenericAll`, `WriteDacl`, oder `WriteOwner`.

#### Warum der Alarm bestehen bleiben kann

* Die Behebung muss angewendet werden auf **jede** betroffene OU, nicht nur auf eine.
* Von übergeordneten OUs geerbte Berechtigungen gelten weiterhin für untergeordnete OUs.
* Benutzerdefinierte Administratorgruppen werden vom Scan möglicherweise nicht als "privilegiert" erkannt.

#### Wie man diagnostiziert

```powershell
# Voraussetzungen prüfen
Get-KdsRootKey  # KDS Root Key muss vorhanden sein, damit der Angriff möglich ist

Get-ADDomainController -Filter * |
  Where-Object { $_.OperatingSystem -like "*2025*" } |
  Select-Object Name, OperatingSystem  # Mindestens ein Win2025-DC

# OUs mit riskanten Delegierungen finden
Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor |
  ForEach-Object {
    $ou = $_
    $ou.nTSecurityDescriptor.Access |
      Where-Object {
        -not $_.IsInherited -and
        $_.ActiveDirectoryRights -match 'GenericAll|CreateChild|WriteDacl|WriteOwner'
      } | ForEach-Object {
        [PSCustomObject]@{
          OU        = $ou.Name
          Principal = $_.IdentityReference
          Rechte    = $_.ActiveDirectoryRights
        }
      }
  } | Format-Table -AutoSize
```

#### So beheben Sie es

Für jede markierte OU entfernen Sie die riskanten Berechtigungen von Nicht-Administrator-Benutzern:

```powershell
$ouDN = "OU=Servers,DC=yourdomain,DC=com"  # Ersetzen Sie dies durch Ihre OU
$path = "AD:$ouDN"
$acl = Get-Acl -Path $path

# Riskante Rechte für eine bestimmte Gruppe entfernen
$identity = New-Object System.Security.Principal.NTAccount("YOURDOMAIN", "HelpDeskTeam")
$toRemove = $acl.Access | Where-Object {
  $_.IdentityReference -eq $identity -and
  $_.ActiveDirectoryRights -match 'CreateChild|GenericAll'
}

foreach ($ace in $toRemove) {
  $acl.RemoveAccessRuleSpecific($ace)
}
Set-Acl -Path $path -AclObject $acl
```

## A-AdminSDHolder

#### Was das bedeutet

Wenn ein Benutzer zu einer privilegierten Gruppe in Active Directory hinzugefügt wird (wie Domain Admins), markiert das System sein Konto automatisch mit einem Flag namens `adminCount = 1`. Dieses Flag ist Teil eines integrierten Schutzmechanismus.

Das Problem ist: **Wenn Sie diesen Benutzer aus der Administratorengruppe entfernen, wird das Flag NICHT automatisch zurückgesetzt.** Es bleibt für immer bestehen, sofern Sie es nicht explizit entfernen.

Der AD-Scan markiert Konten, die dieses übrig gebliebene `adminCount` -Kennzeichen haben, aber keine tatsächlichen Administratoren mehr sind. Dies kann darauf hinweisen:

* Ein Benutzer, der vorübergehend zum Administrator gemacht wurde und dessen Bereinigung unvollständig war
* Ein mögliches Sicherheitsproblem: Diese Konten können in bestimmten Bereichen immer noch erhöhte Berechtigungen haben

#### Was der Scan prüft

Der Scan findet aktivierte Benutzerkonten, bei denen `adminCount = 1` das Konto aber derzeit kein Mitglied einer privilegierten Gruppe ist.

#### Wie man diagnostiziert

```powershell
# Eine Liste aller aktuellen privilegierten Benutzer erstellen
$privilegedMembers = @()
@("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators",
  "Account Operators", "Server Operators", "Backup Operators", "Print Operators"
) | ForEach-Object {
  try { $privilegedMembers += (Get-ADGroupMember $_ -Recursive).DistinguishedName } catch {}
}

# Konten mit dem übrig gebliebenen adminCount-Flag finden
Get-ADUser -LDAPFilter "(&(admincount=1)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" `
  -Properties adminCount |
  Where-Object { $_.DistinguishedName -notin $privilegedMembers } |
  Select-Object SamAccountName, Name
```

#### So beheben Sie es

Nachdem bestätigt wurde, dass diese Konten keine Administratoren mehr sein sollten, setzen Sie das Flag zurück:

```powershell
# adminCount für einen einzelnen Benutzer löschen
Set-ADUser -Identity "username" -Clear adminCount

# Oder es für alle nicht privilegierten Benutzer auf einmal löschen
Get-ADUser -LDAPFilter "(&(admincount=1)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" |
  Where-Object { $_.DistinguishedName -notin $privilegedMembers } |
  ForEach-Object {
    Set-ADUser -Identity $_ -Clear adminCount
    Write-Host "adminCount für $($_.SamAccountName) gelöscht"
  }
```

## P-Kerberoasting

#### Was das bedeutet

In Active Directory sind einige Konten für den Betrieb von Diensten wie einem SQL Server oder einer Webanwendung registriert. Diese Konten haben einen **Service Principal Name (SPN)**, was im Wesentlichen ein Label ist, das sagt: „Dieses Konto betreibt einen Netzwerkdienst.“

Das Sicherheitsrisiko ist: **jeder authentifizierte Benutzer** in der Domäne kann ein Kerberos-Ticket für jedes Konto mit einem SPN anfordern. Dieses Ticket wird mit dem Passwort des Kontos verschlüsselt, und der Angreifer kann es dann offline knacken, ohne einen Alarm auszulösen.

Dies wird als **Kerberoasting** Angriff bezeichnet. Er ist besonders gefährlich, wenn das Konto mit dem SPN auch ein **Domänen-Admin**, denn das Knacken dieses Passworts bedeutet vollständige Kontrolle über die Domäne.

#### Was der Scan prüft

Der AD-Scan markiert Konten, die **alle drei** Bedingungen erfüllen:

1. Das Konto ist Mitglied einer **privilegierten Gruppe** (Domain Admins, Enterprise Admins usw.)
2. Das Konto hat ein **Service Principal Name (SPN)**
3. Das Passwort des Kontos **wurde seit über 40 Tagen nicht geändert** (dadurch haben Angreifer mehr Zeit, es zu knacken)

#### Warum der Alarm bestehen bleiben kann

Sie müssen **alle drei** die Bedingungen beheben. Häufige unvollständige Behebungen:

* **Passwort geändert, aber das SPN beibehalten:** Der Alarm verschwindet vorübergehend, kehrt aber nach 40 Tagen zurück.
* **SPN entfernt, aber das Konto ist immer noch in Domain Admins:** Der Alarm verschwindet, aber das zugrunde liegende Risiko bleibt bestehen.

#### Wie man diagnostiziert

```powershell
$privilegedGroups = @("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators")
$threshold = (Get-Date).AddDays(-40)

foreach ($group in $privilegedGroups) {
  Get-ADGroupMember -Identity $group -Recursive |
    Where-Object { $_.objectClass -eq "user" } |
    ForEach-Object { Get-ADUser $_ -Properties ServicePrincipalName, PasswordLastSet } |
    Where-Object { $_.ServicePrincipalName.Count -gt 0 -and $_.PasswordLastSet -lt $threshold } |
    Select-Object SamAccountName,
      @{N="PasswordAge (days)"; E={[math]::Round(((Get-Date) - $_.PasswordLastSet).TotalDays)}},
      @{N="SPNs"; E={$_.ServicePrincipalName -join "; "}}
}
```

#### So beheben Sie es

**Beste Option: Entfernen Sie das Konto aus den privilegierten Gruppen.** Dienstkonten müssen nur selten Domänen-Admins sein. Erstellen Sie ein dediziertes, nicht privilegiertes Konto mit nur den Berechtigungen, die der Dienst tatsächlich benötigt:

```powershell
Remove-ADGroupMember -Identity "Domain Admins" -Members "svc_account" -Confirm:$false
```

**Wenn Sie es nicht aus der Admin-Gruppe entfernen können:** Setzen Sie zumindest das Passwort regelmäßig zurück (alle 30 Tage oder seltener):

```powershell
Set-ADAccountPassword -Identity "svc_account" `
  -NewPassword (ConvertTo-SecureString "YourNewStr0ngP@ssw0rd!" -AsPlainText -Force) -Reset
```

**Beste langfristige Lösung:** Konvertieren Sie zu einem **Gruppenverwalteten Dienstkonto (gMSA)**, das sein Passwort automatisch alle 30 Tage rotiert:

```powershell
New-ADServiceAccount -Name "gMSA_SQLService" `
  -DNSHostName "gmsa_sqlservice.yourdomain.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "SQLServersGroup"
```

## P-AdminLogin

#### Was das bedeutet

Jede Active-Directory-Domäne hat ein **integriertes Administrator-Konto** das automatisch erstellt wird, wenn die Domäne eingerichtet wird. Dieses Konto hat vollständige Kontrolle über die gesamte Domäne und kann nicht gesperrt werden.

Aufgrund seiner Macht und Vorhersehbarkeit (Angreifer wissen, dass es immer existiert) sollte es reserviert sein für **nur Notfälle**, etwa zur Wiederherstellung nach einer Katastrophe. Die tägliche Verwaltung sollte persönliche Admin-Konten verwenden (z. B. `adm_john`), damit Aktionen einzelnen Personen zugeordnet werden können.

#### Was der Scan prüft

Der AD-Scan prüft, ob sich das integrierte Administrator-Konto auf einem beliebigen Domänencontroller in den **letzten 35 Tagen** angemeldet hat. Wenn ja, wird der Alarm ausgelöst und zeigt an, dass das Konto für Routineaufgaben verwendet wird, statt für Notfälle aufbewahrt zu werden.

#### Warum der Alarm bestehen bleiben kann

* **Das Umbenennen des Kontos hilft nicht.** Der Scan erkennt den integrierten Administrator anhand seiner internen Kennung (RID-500), nicht anhand seines Namens.
* **Das Ändern des Passworts hilft nicht.** Der Scan prüft die Anmeldeaktivität, nicht das Passwortalter.
* **Automatisierte Skripte oder geplante Aufgaben** die als integrierter Administrator ausgeführt werden, lösen den Alarm weiterhin aus.
* **Sie müssen nur warten.** Nachdem Sie das Konto nicht mehr verwenden, verschwindet der Alarm nach 35 Tagen automatisch.

#### Wie man diagnostiziert

```powershell
# Prüfen, wann sich der integrierte Administrator zuletzt auf jedem DC angemeldet hat
$domainSID = (Get-ADDomain).DomainSID
$adminSID = "$domainSID-500"

Get-ADDomainController -Filter * | ForEach-Object {
  $dc = $_
  $admin = Get-ADUser -Identity $adminSID -Server $dc.HostName -Properties LastLogon
  $lastLogon = [DateTime]::FromFileTime($admin.LastLogon)
  $daysAgo = [math]::Round(((Get-Date) - $lastLogon).TotalDays, 1)

  [PSCustomObject]@{
    DC        = $dc.HostName
    LetzteAnmeldung = $lastLogon
    TageSeitdem   = $daysAgo
    Status    = if ($daysAgo -le 35) { "ALARM - Kürzlich verwendet" } else { "OK" }
  }
} | Format-Table -AutoSize
```

Prüfen Sie auch geplante Aufgaben, die möglicherweise den integrierten Administrator verwenden:

```powershell
Get-ADDomainController -Filter * | ForEach-Object {
  Invoke-Command -ComputerName $_.HostName -ScriptBlock {
    Get-ScheduledTask | Where-Object {
      $_.Principal.UserId -match "Administrator"
    } | Select-Object TaskName, @{N="AusführenAls"; E={$_.Principal.UserId}}
  }
}
```

#### So beheben Sie es

1. **Erstellen Sie persönliche Admin-Konten** für jeden Administrator (z. B. `adm_john`, `adm_jane`)
2. **Aktualisieren Sie alle geplanten Aufgaben** sodass sie ein dediziertes Dienstkonto anstelle des integrierten Administrators verwenden
3. **Melden Sie sich nicht mehr an** mit dem integrierten Administrator für Routineaufgaben
4. Der Alarm wird automatisch verschwinden **35 Tage** nach der letzten Anmeldung

## P-AdminNum

#### Was das bedeutet

Je mehr Konten mit Administratorrechten sich in Ihrer Domäne befinden, desto größer ist die Angriffsfläche. Jedes Admin-Konto ist ein potenzieller Einstiegspunkt für einen Angreifer. Viele Organisationen landen im Laufe der Zeit bei zu vielen Admin-Konten: temporärer Zugriff, der nie wieder entzogen wurde, Dienstkonten, die der Bequemlichkeit halber zu Domänen-Admins hinzugefügt wurden, usw.

#### Was der Scan prüft

Der AD-Scan zählt die Gesamtzahl der **eindeutigen Benutzer** über alle privilegierten Gruppen hinweg (Domain Admins, Enterprise Admins, Administrators, Account Operators, Server Operators, Backup Operators usw.). Wenn derselbe Benutzer in mehreren Gruppen ist, wird er nur einmal gezählt.

Der Alarm wird ausgelöst, wenn:

* Mehr als **10%** der aktiven Benutzer privilegiert sind, ODER
* Mehr als **50** privilegierte Konten vorhanden sind

> Diese Prüfung wird für kleine Organisationen mit weniger als 100 aktiven Benutzern übersprungen.

#### Wie man diagnostiziert

```powershell
$privilegedGroups = @(
  "Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators",
  "Account Operators", "Server Operators", "Backup Operators", "Print Operators"
)

$uniqueMembers = @{}
foreach ($group in $privilegedGroups) {
  try {
    Get-ADGroupMember -Identity $group -Recursive |
      Where-Object { $_.objectClass -eq "user" } |
      ForEach-Object { $uniqueMembers[$_.DistinguishedName] = $_.SamAccountName }
  } catch {}
}

$activeUsers = (Get-ADUser -Filter "Enabled -eq `$true" | Measure-Object).Count
$pct = [math]::Round(($uniqueMembers.Count / $activeUsers) * 100, 1)

Write-Host "Privilegierte Konten: $($uniqueMembers.Count)"
Write-Host "Aktive Benutzer: $activeUsers"
Write-Host "Verhältnis: $pct% (Alarm bei >10 % oder >50 Konten)"
Write-Host ""
$uniqueMembers.Values | Sort-Object | ForEach-Object { Write-Host "  - $_" }
```

#### So beheben Sie es

Überprüfen Sie die Liste und entfernen Sie Konten, die keinen echten Admin-Zugriff benötigen:

```powershell
Remove-ADGroupMember -Identity "Domain Admins" -Members "username" -Confirm:$false
```

Bewährte Vorgehensweisen:

* Verwenden Sie **separate Admin-Konten** (`adm_john`) die sich von den Konten für die tägliche Nutzung unterscheiden
* **Entfernen Sie Dienstkonten** aus Admin-Gruppen und gewähren Sie nur die spezifischen Berechtigungen, die sie benötigen
* **Überprüfen Sie die Mitgliedschaft in privilegierten Gruppen** regelmäßig

## P-ProtectedUsers

#### Was das bedeutet

Die **Gruppe „Protected Users“** ist eine spezielle Sicherheitsgruppe, die in Windows Server 2012 R2 eingeführt wurde. Mitglieder dieser Gruppe erhalten zusätzlichen Schutz:

* Sie können **sich nur mit Kerberos authentifizieren** (dem sichereren Protokoll), nicht mit dem älteren NTLM-Protokoll
* Ihre **Anmeldedaten werden nicht zwischengespeichert** auf den Maschinen, auf denen sie sich anmelden: Ein Angreifer, der eine Workstation kompromittiert, kann ihre Anmeldedaten nicht aus dem Speicher stehlen
* **Delegierung ist deaktiviert:** ihr Konto kann nicht von Diensten vorgetäuscht werden

Diese Schutzmaßnahmen sind für Administratorkonten entscheidend, die bei den meisten Angriffen die primären Ziele sind.

#### Was der Scan prüft

Der AD-Scan überprüft, ob alle **aktivierten Admin-Konten** (Mitglieder von Domain Admins, Enterprise Admins usw.) auch Mitglieder der **Gruppe „Protected Users“** Gruppe sind.

#### Warum der Alarm bestehen bleiben kann

* **Benutzer, die über verschachtelte Gruppen hinzugefügt wurden** werden möglicherweise nicht erkannt. Fügen Sie Benutzer **direkt** zur Gruppe „Protected Users“ hinzu.
* **Replikationsverzögerungen** zwischen Domänencontrollern können vorübergehende Inkonsistenzen verursachen.
* **Verwaltete Dienstkonten (gMSA)** werden von dieser Prüfung ausgeschlossen: Sie müssen nicht in „Protected Users“ sein.

#### Wie man diagnostiziert

```powershell
$protectedUsers = (Get-ADGroupMember -Identity "Protected Users").DistinguishedName
$privilegedGroups = @("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators")

$notProtected = foreach ($group in $privilegedGroups) {
  Get-ADGroupMember -Identity $group -Recursive |
    Where-Object { $_.objectClass -eq "user" } |
    ForEach-Object { Get-ADUser $_ -Properties Enabled } |
    Where-Object { $_.Enabled -and $_.DistinguishedName -notin $protectedUsers }
}

$notProtected | Select-Object -Unique SamAccountName, Name | Format-Table -AutoSize
```

#### So beheben Sie es

```powershell
Add-ADGroupMember -Identity "Protected Users" -Members "adm_john", "adm_jane"
```

> **Wichtig:** Das Hinzufügen von Konten zu „Protected Users“ erzwingt **Kerberos-only-Authentifizierung**. Einige ältere Anwendungen, die NTLM erfordern, funktionieren für diese Konten möglicherweise nicht mehr. **Testen Sie zuerst mit einem Konto** bevor Sie alle Administratoren hinzufügen.
>
> Bewährte Praxis: Admin-Konten sollten verwendet werden **nur für Verwaltungsaufgaben** (nicht für E-Mails, Web-Browsing oder das Ausführen von Geschäftsanwendungen), daher ist NTLM-Kompatibilität selten ein Problem.

## S-OldNtlm

#### Was das bedeutet

Windows unterstützt mehrere Authentifizierungsprotokolle, von sehr alten und unsicheren (LM, NTLMv1) bis hin zu modernen und sicheren (NTLMv2, Kerberos). Die älteren Protokolle haben bekannte Schwachstellen, die Angreifer ausnutzen können, um Passwörter im Netzwerk abzufangen und zu knacken.

Die **LAN-Manager-Authentifizierungsstufe** steuert, welche Protokolle erlaubt sind. Sie sollte auf **Stufe 5** gesetzt werden, was bedeutet: „nur NTLMv2 akzeptieren, alle älteren Protokolle ablehnen.“

#### Was der Scan prüft

Der AD-Scan liest Gruppenrichtlinienobjekte (GPOs), um zu überprüfen, dass die `LmCompatibilityLevel` Einstellung auf **5**. Wenn keine GPO diese Einstellung definiert, verwendet Windows standardmäßig **Stufe 3**, die immer noch einige schwächere Protokolle akzeptiert.

| Stufe | Was es erlaubt                                   | Sicher? |
| ----- | ------------------------------------------------ | ------- |
| 0-2   | LM und/oder NTLMv1                               | Nein    |
| 3     | NTLMv2 (lehnt ältere Protokolle jedoch nicht ab) | Nein    |
| **5** | **Nur NTLMv2, LM & NTLMv1 ablehnen**             | **Ja**  |

#### Warum der Alarm bestehen bleiben kann

1. **Sie haben die Registry direkt geändert** anstatt eine GPO zu verwenden. Der AD-Scan liest GPO-Dateien, nicht lokale Registry-Einstellungen. Selbst wenn der DC den richtigen Wert in der Registry hat, bleibt der Alarm bestehen, wenn er nicht über Gruppenrichtlinien gesetzt wurde.
2. **Konfliktierende GPOs:** Eine GPO setzt Stufe 5, aber eine andere GPO überschreibt sie mit einer niedrigeren Stufe.
3. **Keine GPO vorhanden:** Ohne irgendeine GPO ist der Standard Stufe 3 (unsicher).

#### Wie man diagnostiziert

```powershell
# Prüfen Sie die effektive Einstellung auf jedem DC
Get-ADDomainController -Filter * | ForEach-Object {
  $level = Invoke-Command -ComputerName $_.HostName -ScriptBlock {
    (Get-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa" `
      -Name LmCompatibilityLevel -ErrorAction SilentlyContinue).LmCompatibilityLevel
  }
  Write-Host "$($_.HostName): LmCompatibilityLevel = $level"
}

# Prüfen Sie, welche GPOs diese Einstellung definieren
Import-Module GroupPolicy
Get-GPO -All | ForEach-Object {
  [xml]$r = Get-GPOReport -Guid $_.Id -ReportType Xml
  if ($r.InnerXml -match "LmCompatibilityLevel") {
    Write-Host "GPO: $($_.DisplayName)"
  }
}
```

#### So beheben Sie es

**Über die Gruppenrichtlinienverwaltungskonsole (empfohlen):**

1. Öffnen Sie `gpmc.msc`
2. Bearbeiten Sie die mit `OU=Domain Controllers`
3. Navigieren Sie zu: `Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen`
4. Setzen Sie **"Netzwerksicherheit: LAN-Manager-Authentifizierungsstufe"** auf `Nur NTLMv2-Antwort senden. LM & NTLM ablehnen`
5. Setzen Sie **"Netzwerksicherheit: Den LAN-Manager-Hashwert beim nächsten Passwortwechsel nicht speichern"** auf `Aktiviert`
6. Führen Sie `gpupdate /force` auf allen Domänencontrollern aus

**Über PowerShell:**

```powershell
$gpoName = "DC - NTLMv2 erzwingen"
$gpo = Get-GPO -Name $gpoName -ErrorAction SilentlyContinue
if (-not $gpo) { $gpo = New-GPO -Name $gpoName }

Set-GPRegistryValue -Name $gpoName `
  -Key "HKLM\System\CurrentControlSet\Control\Lsa" `
  -ValueName "LmCompatibilityLevel" -Type DWord -Value 5

Set-GPRegistryValue -Name $gpoName `
  -Key "HKLM\System\CurrentControlSet\Control\Lsa" `
  -ValueName "NoLMHash" -Type DWord -Value 1

New-GPLink -Name $gpoName `
  -Target "OU=Domain Controllers,$($(Get-ADDomain).DistinguishedName)" `
  -LinkEnabled Yes
```

## S-AesNotEnabled

#### Was das bedeutet

Wenn Sie sich in Active Directory authentifizieren, wird Ihr Passwort verwendet, um die Kommunikation mit einem bestimmten Algorithmus zu verschlüsseln. Ältere Algorithmen (**DES**, **RC4**) sind schwach und können relativ leicht geknackt werden. Moderne Algorithmen (**AES-128**, **AES-256**) sind deutlich stärker.

AES-Unterstützung wurde mit Windows Server 2008 eingeführt. Konten, die jedoch vor dem Upgrade existierten, oder Konten mit bestimmten Konfigurationen, verwenden möglicherweise weiterhin die alte, schwächere Verschlüsselung.

#### Was der Scan prüft

Ein Konto wird in zwei Situationen markiert:

1. **Das Passwort des Kontos wurde gesetzt, bevor Ihre Domäne auf Server 2008 aktualisiert wurde.** Da AES-Verschlüsselungsschlüssel nur erzeugt werden, wenn auf einem modernen DC ein Passwort gesetzt wird, verfügen diese alten Passwörter nur über schwache RC4/DES-Schlüssel.
2. **Das Konto hat einen Service Principal Name (SPN)** und seine Verschlüsselungseinstellungen enthalten kein AES (die `msDS-SupportedEncryptionTypes` Attribute enthalten keine AES-Flags).

#### Wie man diagnostiziert

```powershell
# Dienstkonten ohne AES-Unterstützung finden
Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
  -Properties ServicePrincipalName, "msDS-SupportedEncryptionTypes", PasswordLastSet |
  Where-Object { ([int]$_."msDS-SupportedEncryptionTypes" -band 24) -eq 0 } |
  Select-Object SamAccountName,
    @{N="Verschlüsselungstypen"; E={$_."msDS-SupportedEncryptionTypes"}},
    PasswordLastSet

# Dasselbe für Computerkonten
Get-ADComputer -Filter 'ServicePrincipalName -like "*"' `
  -Properties "msDS-SupportedEncryptionTypes" |
  Where-Object { ([int]$_."msDS-SupportedEncryptionTypes" -band 24) -eq 0 } |
  Select-Object Name, @{N="Verschlüsselungstypen"; E={$_."msDS-SupportedEncryptionTypes"}}
```

#### So beheben Sie es

**Für Konten mit alten Passwörtern:** Setzen Sie einfach das Passwort zurück. Dadurch werden neue AES-Schlüssel erzeugt:

```powershell
Set-ADAccountPassword -Identity "svc_account" `
  -NewPassword (ConvertTo-SecureString "YourNewStr0ngP@ssw0rd!" -AsPlainText -Force) -Reset
```

**Für Konten, denen AES-Verschlüsselungseinstellungen fehlen:** Aktivieren Sie AES in den Verschlüsselungstypen des Kontos:

```powershell
# AES für ein bestimmtes Konto aktivieren (24 = AES-128 + AES-256)
Set-ADUser -Identity "svc_account" -Replace @{"msDS-SupportedEncryptionTypes" = 24}

# Für ein Computerkonto
Set-ADComputer -Identity "server01" -Replace @{"msDS-SupportedEncryptionTypes" = 24}

# Massenkorrektur für alle Dienstkonten ohne AES
Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
  -Properties "msDS-SupportedEncryptionTypes" |
  Where-Object { ([int]$_."msDS-SupportedEncryptionTypes" -band 24) -eq 0 } |
  ForEach-Object {
    Set-ADUser $_ -Replace @{"msDS-SupportedEncryptionTypes" = 24}
    Write-Host "AES für $($_.SamAccountName) aktiviert"
  }
```

> **Hinweis:** Das Aktivieren von AES ist nicht destruktiv: Die bestehende Authentifizierung funktioniert weiterhin. Testen Sie jedoch kritische Dienste, bevor Sie die Änderung in großem Umfang anwenden.

## A-NoGPOLLMNR

#### Was das bedeutet

**LLMNR** (Link-Local Multicast Name Resolution) ist ein Protokoll, das Windows verwendet, um andere Computer im Netzwerk zu finden, wenn DNS keine Antwort hat. Es funktioniert, indem es eine Frage an alle nahe gelegenen Maschinen sendet: „Weiß jemand, wo `servername` ist?“

Das Problem ist: Ein Angreifer im selben Netzwerk kann **auf diese Broadcasts antworten und sich dabei als der Zielserver ausgeben**, wodurch das Opfer dazu gebracht wird, seine Anmeldedaten an den Angreifer zu senden. Dies wird als **LLMNR-Poisoning** Angriff bezeichnet und ist eine der häufigsten Techniken bei Angriffen auf interne Netzwerke.

LLMNR ist ein Legacy-Protokoll, das moderne Netzwerke nicht brauchen (DNS erledigt alles). Es sollte per Gruppenrichtlinie deaktiviert werden.

#### Was der Scan prüft

Der AD-Scan sucht nach einer **aktivierten und verknüpften GPO** die LLMNR deaktiviert, indem sie den `EnableMulticast` Registrierungswert auf `0`.

#### Warum der Alarm bestehen bleiben kann

1. **GPO existiert, ist aber nicht verknüpft** mit einer OU.
2. **GPO ist deaktiviert**, selbst wenn sie verknüpft ist.
3. **LLMNR wurde manuell deaktiviert** (über Registry oder `netsh`) aber nicht über Gruppenrichtlinien. Der AD-Scan liest GPO-Dateien, nicht die Einstellungen des lokalen Computers.

#### Wie man diagnostiziert

```powershell
Import-Module GroupPolicy
Get-GPO -All | ForEach-Object {
  [xml]$r = Get-GPOReport -Guid $_.Id -ReportType Xml
  if ($r.InnerXml -match "EnableMulticast") {
    Write-Host "GPO '$($_.DisplayName)' - Status: $($_.GpoStatus) - Enthält LLMNR-Einstellung"
  }
}
```

#### So beheben Sie es

```powershell
$gpoName = "LLMNR deaktivieren"
$gpo = Get-GPO -Name $gpoName -ErrorAction SilentlyContinue
if (-not $gpo) { $gpo = New-GPO -Name $gpoName }

Set-GPRegistryValue -Name $gpoName `
  -Key "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" `
  -ValueName "EnableMulticast" -Type DWord -Value 0

# An die Domänenwurzel verknüpfen, damit es für alle Computer gilt
New-GPLink -Name $gpoName `
  -Target (Get-ADDomain).DistinguishedName `
  -LinkEnabled Yes
```

Nachdem Sie die GPO verknüpft haben, führen Sie `gpupdate /force` auf den Maschinen aus oder warten Sie auf den nächsten Gruppenrichtlinien-Aktualisierungszyklus (typischerweise 90 Minuten).

## Häufig gestellte Fragen

#### Der Alarm wird immer noch angezeigt, nachdem ich die Behebung angewendet habe. Warum?

Der AD-Scan wird nicht regelmäßig ausgeführt. Nachdem Sie eine Behebung angewendet haben, müssen Sie **das Skript erneut ausführen** damit der Alarm verschwindet. Wenn der Alarm nach einem neuen Scan bestehen bleibt, war die Behebung wahrscheinlich unvollständig. Lesen Sie den Abschnitt „Warum der Alarm bestehen bleiben kann“ der jeweiligen Schwachstelle. Stellen Sie sicher, dass Sie die Details der Schwachstelle in Ihrem Bericht lesen; er enthält häufig Details zu den betroffenen Assets.

#### Benötige ich Domain-Admin-Rechte, um den Scan auszuführen?

Einige Schwachstellen (z. B. A-NoServicePolicy) erfordern erhöhte Berechtigungen, um bestimmte AD-Objekte zu lesen. Das Ausführen des Scans mit einem **Domain-Admin-Konto** stellt sicher, dass alle Objekte sichtbar sind und vermeidet Fehlalarme, die durch unzureichende Berechtigungen verursacht werden. Wenn das nicht möglich ist, können Sie das Skript dennoch als einfacher Domänenbenutzer ausführen, obwohl einige Schwachstellen aufgrund fehlender Sichtbarkeit von AD-Objekten angezeigt werden können.

#### Ich habe eine Schwachstelle behoben, aber eine neue ist aufgetaucht. Ist das normal?

Ja. Einige Behebungen können andere Probleme aufdecken. Beispielsweise kann die Installation von LAPS (Behebung von A-LAPS-Not-Installed) A-LAPS-Joined-Computers auslösen, wenn Computerobjekte über unzureichende Berechtigungen verfügen. Das ist zu erwarten: Arbeiten Sie die einzelnen Warnmeldungen nach Schweregrad ab.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.stoik.io/cyber-best-practices/de/leitfaden-zur-behebung-von-schwachstellen/ad-scan-vulnerability-remediation-guide.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.