Was ist Kerberos-Delegierung? Ein Überblick über Kerberos-Delegierung

Zweck der Kerberos-Delegation

Kerberos-Delegierung gibt es schon seit langem (seit Windows Server 2000, um genau zu sein). Aber allzu oft sind Ingenieure, die mit Active Directory arbeiten, nicht mit allen verschiedenen Implementierungen der Kerberos-Delegierung, deren Verwendung und den Möglichkeiten, wie sie missbraucht werden können, vertraut. Einige verwechseln sogar Kerberos-Delegierung mit delegierten Berechtigungen.

Der praktische Einsatz der Kerberos-Delegation besteht darin, einer Anwendung zu ermöglichen, auf Ressourcen zuzugreifen, die auf einem anderen Server gehostet werden. Ein Beispiel ist, wenn eine Anwendung, wie ein Webserver, auf Ressourcen für die auf einem anderen Server gehostete Website zugreifen muss, wie etwa eine SQL-Datenbank. Anstatt dem Dienstkonto, das den Webserver betreibt, direkten Zugang zur Datenbank zu gewähren, können Sie dieses Dienstkonto für den SQL-Serverdienst delegieren. Sobald sich ein Benutzer auf der Website anmeldet, wird das Dienstkonto im Namen dieses Benutzers Zugang zum SQL-Serverdienst anfordern. Dies ermöglicht es dem Benutzer, auf die Inhalte in der Datenbank zuzugreifen, für die er berechtigt wurde, ohne dass irgendwelche Zugriffsrechte für das Dienstkonto des Webservers selbst eingerichtet werden müssen.

Arten der Kerberos-Delegation

Im Laufe der Jahre haben sich einige Varianten der Kerberos-Delegation entwickelt. Die ursprüngliche Implementierung aus Windows Server 2000 ist die uneingeschränkte Delegation. Seitdem sind strengere Versionen der Delegation erschienen, die die Sicherheit verbessern: eingeschränkte Delegation und ressourcenbasierte eingeschränkte Delegation. Ich werde weiter unten tiefer in jeden Delegationstyp eintauchen.

Um die Delegierung für ein Computer- oder Benutzerkonto zu konfigurieren, verwenden Sie die Registerkarte Delegation in Active Directory Users and Computers, wie unten dargestellt. Beachten Sie, dass Benutzerkonten einen servicePrincipalName (SPN) gesetzt haben müssen.

Abbildung 1. Registerkarte für Delegation in Active Directory Users and Computers

Die erste Option (in Gelb) ermöglicht es Ihnen, ein Konto so zu konfigurieren, dass es NICHT für die Delegation vertrauenswürdig ist; dies wird am häufigsten für sensible oder administrative Konten verwendet, die niemals für die Delegation verwendet werden sollten. Die zweite Option (in Grün) ermöglicht es Ihnen, ein Konto für uneingeschränkte Delegation zu konfigurieren. Die dritte Option (in Rot) ermöglicht es Ihnen, ein Konto für eingeschränkte Delegation zu konfigurieren.

Unbeschränkte Delegation

Dies ist die ursprüngliche Implementierung der Delegation und zugleich die unsicherste. Was macht eine uneingeschränkte Delegation eigentlich? Im Hintergrund wird, wenn uneingeschränkte Delegation konfiguriert ist, das userAccountControl-Attribut des Objekts aktualisiert, um das „TRUSTED_FOR_DELEGATION“-Kennzeichen einzuschließen. Wenn sich ein Objekt bei einem Host mit uneingeschränkter Delegation authentifiziert, wird das Ticket-Granting Ticket (TGT) für dieses Konto im Speicher abgelegt, sodass der Host mit uneingeschränkter Delegation dieses Benutzer später bei Bedarf impersonalisieren kann.

Stellen Sie sich ein Szenario vor, in dem ein privilegiertes Konto sich an einem Host mit uneingeschränkter Delegierungskonfiguration authentifiziert. Dieses Konto kann auf jeden konfigurierten Dienst innerhalb der Domäne als dieser privilegierte Benutzer zugreifen. Um noch einen Schritt weiter zu gehen, was wäre, wenn es Möglichkeiten gäbe, privilegierte Konten automatisch zur Authentifizierung an Ihrem Host zu zwingen? Mit dem „Druckerfehler“ können Sie einen Domänencontroller dazu bringen, sich an Ihrem Host zu authentifizieren, wobei das TGT für dieses Konto im Speicher hinterlassen wird.

Da Mechanismen wie der „Printer Bug“ existieren, ist eine uneingeschränkte Delegierung sehr unsicher und sollte, wenn überhaupt möglich, nicht verwendet werden. Es ist jedoch zu beachten, dass Domänencontroller standardmäßig mit uneingeschränkter Delegierung konfiguriert sind. Da Ihre Domänencontroller jedoch viel sicherer sein sollten als ein zufälliger Anwendungsserver, der einen Dienst hostet, sollte dies kein Problem darstellen.

Eingeschränkte Delegation

Eingeführt in Windows Server 2003, ermöglicht eingeschränkte Delegierung Ihnen festzulegen, zu welchen Diensten ein Konto delegiert werden kann. Dies begrenzt theoretisch die mögliche Gefährdung, falls ein Kompromiss auftritt.

Abbildung 2. TestUserA kann dem HTTP/test-Dienst zugewiesen werden.

Eine Einschränkung, die bei der eingeschränkten Delegierung zu beachten ist, ist, dass sie nicht forstübergreifend funktioniert.

Wenn eine eingeschränkte Delegierung für ein Konto festgelegt wird, geschehen zwei Dinge im Hintergrund:

• Das userAccountControl-Attribut für das Objekt wird mit dem „TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION“-Kennzeichen aktualisiert.

• Das msDS-AllowedToDelegateTo-Attribut wird mit dem auf dem Delegierungstab konfigurierten SPN gefüllt.

Der Missbrauch von eingeschränkter Delegierung unterscheidet sich vom Missbrauch uneingeschränkter Delegierung. Eine gängige Missbrauchsmethode ist, wenn Angreifer das Klartextpasswort oder den NTLM-Hash eines für eingeschränkte Delegierung konfigurierten Benutzerkontos kompromittieren können. Mit einem Tool wie Kekeo können sie ein TGT für das Konto anfordern, für das sie das Passwort haben, die TGS-Anfrage für einen beliebigen Benutzer ausführen (solange der Benutzer nicht als 'Sensitiv' markiert ist) und dann das Ticket injizieren und den Dienst als dieser Benutzer nutzen.

Ressourcenbasierte eingeschränkte Delegation

Eingeführt in Windows Server 2012, ändert die ressourcenbasierte eingeschränkte Delegierung, wie Sie die eingeschränkte Delegierung konfigurieren können, und sie funktioniert über eine Vertrauensstellung hinweg. Anstatt anzugeben, welches Objekt an welchen Dienst delegieren kann, spezifiziert die Ressource, die den Dienst hostet, welche Objekte an sie delegieren können. Aus administrativer Sicht ermöglicht dies dem Ressourcenbesitzer zu kontrollieren, wer darauf zugreifen kann. Zum Beispiel können Sie statt mit eingeschränkter Delegierung anzugeben, dass das WebServer-Dienstkonto an den SQL-Dienst delegieren kann, um auf die Datenbank zuzugreifen, auf dem SQL-Server-Dienstkonto spezifizieren, dass das WebServer-Dienstkonto Berechtigungen hat, den Zugriff an es zu delegieren.

Die ressourcenbasierte eingeschränkte Delegierung wird konfiguriert, indem das msDS-AllowedToActOnBehalfOfOtherIdentity-Attribut auf der Zielressource mit der SID des Objekts gefüllt wird, das die Berechtigung zur Delegierung an sie hat. Um die ressourcenbasierte eingeschränkte Delegierung zu konfigurieren, müssen Sie PowerShell verwenden; es gibt keine GUI-Komponente innerhalb von Active Directory Users and Computers und die Attribut-Editor-Seite erlaubt keine manuelle Modifikation dieses Attributs.

Sie können mehr über Resource-Based Constrained Delegation und Methoden zu dessen Missbrauch hier lesen.

Identifizierung bestehender Kerberos-Delegation

Jetzt, da Sie einige Grundlagen für die verschiedenen Arten der Delegation und einige Möglichkeiten, wie sie missbraucht werden können, verstehen, möchte ich Ihnen eine Methode vorstellen, mit der Sie erfassen können, welche Arten der Delegation bereits in Ihrer Umgebung konfiguriert sind. Wir werden uns speziell darauf konzentrieren, unsichere Szenarien hervorzuheben, wie zum Beispiel unbeschränkte Delegation, die auf Objekten außerhalb von Domänencontrollern konfiguriert ist.

Hier ist ein Skript, das ursprünglich in der Microsoft Technet-Galerie veröffentlicht wurde, das Konten identifiziert, bei denen uneingeschränkte, eingeschränkte und ressourcenbasiert eingeschränkte Delegierung konfiguriert ist, und Informationen sowie potenzielle Warnungen zu den aufgelisteten Konfigurationen hervorhebt:

      <#.Synopsis    Search the domain for accounts with Kerberos Delegation..DESCRIPTION    Kerberos Delegation is a security sensitive configuration. Especially    full (unconstrained) delegation has significant impact: any service    that is configured with full delegation can take any account that    authenticates to it, and impersonate that account for any other network    service that it likes. So, if a Domain Admin were to use that service,    the service in turn could read the hash of KRBRTG and immediately    effectuate a golden ticket. Etc :)    This script searches AD for regular forms of delegation: full, constrained,    and resource based. It dumps the account names with relevant information (flags)    and adds a comment field for special cases. The output is a PSObject that    you can use for further analysis.    Note regarding resource based delegation: the script dumps the target    services, not the actual service doing the delegation. I did not bother    to parse that out.    Main takeaway: chase all services with unconstrained delegation. If    these are _not_ DC accounts, reconfigure them with constrained delegation,    OR claim them als DCs from a security perspective. Meaning, that the AD    team manages the service and the servers it runs on..EXAMPLE   .Search-KerbDelegatedAccounts.ps1 | out-gridview.EXAMPLE   .Search-KerbDelegatedAccounts.ps1 -DN "ou=myOU,dc=sol,dc=local".NOTES    Version:   0.1 : first version.                    0.2 : expanded LDAP filter and comment field.    Author:         Willem Kasdorp, Microsoft.    Creation Date:  1/10/2016    Last modified:  4/11/2017#>[CmdletBinding()]Param(    # start the search at this DN. Default is to search all of the domain.    [string]$DN = (Get-ADDomain).DistinguishedName)$SERVER_TRUST_ACCOUNT = 0x2000$TRUSTED_FOR_DELEGATION = 0x80000$TRUSTED_TO_AUTH_FOR_DELEGATION= 0x1000000$PARTIAL_SECRETS_ACCOUNT = 0x4000000 $bitmask = $TRUSTED_FOR_DELEGATION -bor $TRUSTED_TO_AUTH_FOR_DELEGATION -bor $PARTIAL_SECRETS_ACCOUNT# LDAP filter to find all accounts having some form of delegation.# 1.2.840.113556.1.4.804 is an OR query.$filter = @"(&  (servicePrincipalname=*)  (|    (msDS-AllowedToActOnBehalfOfOtherIdentity=*)    (msDS-AllowedToDelegateTo=*)    (UserAccountControl:1.2.840.113556.1.4.804:=$bitmask)  )  (|    (objectcategory=computer)    (objectcategory=person)    (objectcategory=msDS-GroupManagedServiceAccount)    (objectcategory=msDS-ManagedServiceAccount)  ))"@ -replace "[sn]", ''$propertylist = @(    "servicePrincipalname",    "useraccountcontrol",    "samaccountname",    "msDS-AllowedToDelegateTo",    "msDS-AllowedToActOnBehalfOfOtherIdentity")Get-ADObject -LDAPFilter $filter -SearchBase $DN -SearchScope Subtree -Properties $propertylist -PipelineVariable account | ForEach-Object {    $isDC = ($account.useraccountcontrol -band $SERVER_TRUST_ACCOUNT) -ne 0    $fullDelegation = ($account.useraccountcontrol -band $TRUSTED_FOR_DELEGATION) -ne 0    $constrainedDelegation = ($account.'msDS-AllowedToDelegateTo').count -gt 0    $isRODC = ($account.useraccountcontrol -band $PARTIAL_SECRETS_ACCOUNT) -ne 0    $resourceDelegation = $account.'msDS-AllowedToActOnBehalfOfOtherIdentity' -ne $null    $comment = ""    if ((-not $isDC) -and $fullDelegation) {        $comment += "WARNING: full delegation to non-DC is not recommended!; "    }    if ($isRODC) {        $comment += "WARNING: investigation needed if this is not a real RODC; "    }    if ($resourceDelegation) {        # to count it using PS, we need the object type to select the correct function... broken, but there we are.        $comment += "INFO: Account allows delegation FROM other server(s); "    }    if ($constrainedDelegation) {        $comment += "INFO: constrained delegation service count: $(($account.'msDS-AllowedToDelegateTo').count); "    } [PSCustomobject] @{        samaccountname = $account.samaccountname        objectClass = $account.objectclass               uac = ('{0:x}' -f $account.useraccountcontrol)        isDC = $isDC        isRODC = $isRODC        fullDelegation = $fullDelegation        constrainedDelegation = $constrainedDelegation        resourceDelegation = $resourceDelegation        comment = $comment    }}
      

Abbildung 3. Beispiel-Skript zur Identifizierung problematischer Delegationen

Wie Netwrix helfen kann

Die Netwrix Active Directory security solution hilft Ihnen, Ihr Active Directory von Anfang bis Ende zu sichern. Sie können:

• Identifizieren und mindern Sie Schwachstellen in Ihrem Active Directory: übermäßige Berechtigungen, „Schatten“-Admins, veraltete Konten, schwache Passwörter, und mehr.

• Steuern Sie AD-Konfigurationen und Berechtigungen, setzen Sie starke password policies durch und verhindern Sie den Diebstahl von Anmeldeinformationen.

• Erkennen Sie selbst fortgeschrittene Bedrohungen, um böswillige Akteure zu stoppen, bevor sie ihre Mission abschließen.

• Enthalten Sie sofort einen Sicherheitsvorfall mit automatisierten Reaktionsaktionen, um den Schaden für Ihr Unternehmen zu minimieren.

• Setzen Sie Änderungen, die bösartig oder anderweitig unangemessen sind, mit minimaler Ausfallzeit zurück oder stellen Sie diese wieder her.