Qu'est-ce que la délégation Kerberos ? Un aperçu de la délégation Kerberos

Objectif de la délégation Kerberos

La délégation Kerberos existe depuis longtemps (depuis Windows Server 2000, pour être exact). Mais bien souvent, les ingénieurs qui travaillent avec Active Directory ne sont pas familiers avec toutes les différentes implémentations de la délégation Kerberos, leurs utilisations et les manières dont elles peuvent être détournées. Certains confondent même la délégation Kerberos avec les permissions déléguées.

L'utilisation pratique de la délégation Kerberos est de permettre à une application d'accéder à des ressources hébergées sur un serveur différent. Un exemple est lorsqu'une application, telle qu'un serveur web, doit accéder à des ressources pour le site web hébergé ailleurs, comme une base de données SQL. Au lieu de donner au compte de service qui exécute le serveur web l'accès direct à la base de données, vous pouvez permettre à ce compte de service d'être délégué au service du serveur SQL. Une fois qu'un utilisateur se connecte au site web, le compte de service demandera l'accès au service du serveur SQL au nom de cet utilisateur. Cela permet à l'utilisateur d'accéder au contenu dans la base de données auquel il a été provisionné, sans avoir à provisionner d'accès au compte de service du serveur web lui-même.

Types de délégation Kerberos

Au fil des années, plusieurs variantes de la délégation Kerberos ont vu le jour. L'implémentation originale de Windows Server 2000 est la délégation non restreinte. Depuis, des versions plus strictes de la délégation ont été développées pour améliorer la sécurité : la délégation restreinte et la délégation restreinte basée sur les ressources. Je vais examiner plus en détail chaque type de délégation ci-dessous.

Pour configurer la délégation sur un ordinateur ou un compte utilisateur, utilisez l'onglet Delegation dans Active Directory Users and Computers, comme indiqué ci-dessous. Notez que les comptes d'utilisateurs doivent avoir un servicePrincipalName (SPN) défini.

Figure 1. Onglet Délégation dans Active Directory Users and Computers

La première option (en jaune) vous permet de configurer un compte de manière à ce qu'il ne soit PAS autorisé à être utilisé pour la délégation ; cela est le plus souvent utilisé pour les comptes sensibles ou administratifs qui ne devraient jamais être utilisés pour la délégation. La deuxième option (en vert) vous permet de configurer un compte pour une délégation non contrainte. La troisième option (en rouge) vous permet de configurer un compte pour une délégation contrainte.

Délégation sans contrainte

Ceci est la mise en œuvre originale de la délégation, et également la moins sécurisée. Que fait réellement la délégation non contrainte ? Sous le capot, lorsque la délégation non contrainte est configurée, l'attribut userAccountControl de l'objet est mis à jour pour inclure le drapeau « TRUSTED_FOR_DELEGATION ». Lorsqu'un objet s'authentifie auprès d'un hôte avec la délégation non contrainte configurée, le ticket d'accès (TGT) pour ce compte est stocké en mémoire afin que l'hôte avec la délégation non contrainte configurée puisse se faire passer pour cet utilisateur plus tard, si nécessaire.

Imaginez un scénario où un compte privilégié s'authentifie sur un hôte avec une délégation non contrainte configurée. Ce compte peut accéder à n'importe quel service configuré dans le domaine en tant qu'utilisateur privilégié. Pour aller plus loin, que se passerait-il s'il existait des moyens de forcer les comptes privilégiés à s'authentifier automatiquement sur votre hôte ? En utilisant le « bug de l'imprimante », vous pouvez obtenir qu'un contrôleur de domaine s'authentifie sur votre hôte, laissant le TGT pour ce compte en mémoire.

Étant donné que des mécanismes comme le « bug de l'imprimante » existent, la délégation non contrainte est très peu sûre et ne devrait pas être utilisée si possible. Il est important de noter que, par défaut, les contrôleurs de domaine sont configurés avec une délégation non contrainte. Cependant, étant donné que vos contrôleurs de domaine devraient être beaucoup plus sécurisés qu'un serveur d'application aléatoire hébergeant un service, cela ne devrait pas poser de problème.

Délégation restreinte

Introduite dans Windows Server 2003, la délégation restreinte vous permet de configurer à quels services un compte peut être délégué. Cela limite en théorie l'exposition potentielle en cas de compromission.

Figure 2. TestUserA peut être délégué au service HTTP/test.

Une restriction à noter pour la délégation contrainte est qu'elle ne fonctionne pas entre forêts.

Lorsque la délégation restreinte est configurée sur un compte, deux choses se produisent en arrière-plan :

• L'attribut userAccountControl de l'objet est mis à jour avec le drapeau « TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION ».

• L'attribut msDS-AllowedToDelegateTo est renseigné avec le SPN configuré dans l'onglet de délégation.

Abuser de la délégation contrainte est différent de l'abus de délégation non contrainte. Une manière courante dont elle peut être abusée est si les attaquants parviennent à compromettre le mot de passe en clair ou le hash NTLM d'un compte utilisateur configuré pour la délégation contrainte. En utilisant un outil comme Kekeo, ils peuvent demander un TGT pour le compte dont ils ont le mot de passe, exécuter la demande de TGS pour n'importe quel utilisateur (tant que l'utilisateur n'est pas marqué comme ‘Sensible’), puis injecter le ticket et accéder au service demandé en tant que cet utilisateur.

Délégation contrainte basée sur les ressources

Introduite dans Windows Server 2012, la délégation contrainte basée sur les ressources change la manière dont vous pouvez configurer la délégation contrainte, et elle fonctionnera à travers une confiance. Au lieu de spécifier quel objet peut déléguer à quel service, la ressource hébergeant le service spécifie quels objets peuvent lui déléguer. D'un point de vue administratif, cela permet au propriétaire de la ressource de contrôler qui peut y accéder. Par exemple, au lieu de spécifier avec la délégation contrainte que le compte de service WebServer peut déléguer au service SQL pour accéder à la base de données, vous pouvez spécifier sur le compte de service du serveur SQL que le compte de service WebServer a les permissions pour lui déléguer l'accès.

La délégation contrainte basée sur les ressources est configurée en remplissant l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity sur la ressource cible avec le SID de l'objet qui est autorisé à déléguer vers celle-ci. Pour configurer la délégation contrainte basée sur les ressources, vous devez utiliser PowerShell ; il n'y a pas de composant GUI au sein d'Active Directory Users and Computers et la page de l'éditeur d'attributs ne permet pas de modification manuelle de cet attribut.

Vous pouvez en savoir plus sur la délégation contrainte basée sur les ressources et les moyens de l'abuser ici.

Identification de la délégation Kerberos existante

Maintenant que vous comprenez certains des principes de base des différents types de délégation et certaines manières dont ils peuvent être abusés, je souhaite partager avec vous une méthode que vous pouvez utiliser pour comprendre quels types de délégation sont déjà configurés dans votre environnement. Nous allons spécifiquement chercher à mettre en évidence des scénarios non sécurisés, tels que la délégation non contrainte configurée sur des objets autres que les contrôleurs de domaine.

Voici un script, qui a été initialement publié dans la galerie Microsoft Technet, qui identifiera les comptes avec une délégation non contrainte, contrainte et basée sur les ressources configurée, en mettant en évidence les informations et les avertissements potentiels concernant les configurations qu'il liste :

      <#.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    }}
      

Figure 3. Exemple de script pour identifier une délégation problématique

Comment Netwrix peut aider

La solution de sécurité Active Directory de Netwrix vous aide à sécuriser votre Active Directory de bout en bout. Vous pouvez :

• Identifiez et atténuez les vulnérabilités dans votre Active Directory : permissions excessives, administrateurs “fantômes”, comptes obsolètes, weak passwords, et plus encore.

• Contrôlez les configurations et les permissions AD, appliquez des politiques de mots de passe strictes et prévenez le vol d'identifiants.

• Détectez même les menaces avancées pour arrêter les acteurs malveillants dans leur élan avant qu'ils n'achèvent leur mission.

• Contenez instantanément une violation de sécurité avec des actions de réponse automatisées, minimisant les dommages à votre entreprise.

• Annulez ou récupérez des modifications malveillantes ou inappropriées avec un temps d'arrêt minimal.