Mises à jour de la délégation TGT entre approbations entrantes dans Windows Server

Résumé

Les approbations forestières permettent aux ressources d’une forêt Active Directory d’approuver des identités d’une autre forêt. Cette approbation peut être configurée dans les deux directions. La forêt approuvée est la source de l’identité de l’utilisateur. La forêt d’approbation contient la ressource sur laquelle les utilisateurs s’authentifient. La forêt approuvée peut authentifier les utilisateurs de la forêt approuvée sans autoriser l’inverse.

La délégation Kerberos sans contraintes est un mécanisme par lequel un utilisateur envoie ses informations d’identification à un service pour permettre au service d’accéder aux ressources en son nom. Pour activer la délégation Kerberos sans contraintes, le compte du service dans Active Directory doit être marqué comme approuvé pour la délégation. Cela crée un problème si l’utilisateur et le service appartiennent à des forêts différentes. La forêt de service est chargée d’autoriser la délégation. La délégation inclut les informations d’identification des utilisateurs de la forêt de l’utilisateur.

Permettre à une forêt de prendre des décisions de sécurité qui affectent les comptes d’une autre forêt viole la limite de sécurité entre les forêts. Un attaquant propriétaire de la forêt d’approbation peut demander la délégation d’un TGT pour une identité de la forêt approuvée, ce qui lui donne accès aux ressources de la forêt approuvée. Cela ne s’applique pas à la délégation Kerberos contrainte (KCD).

Windows Server 2012 a introduit l’application des limites de forêt pour la délégation complète Kerberos. Cette fonctionnalité ajoutait une stratégie au domaine approuvé afin de désactiver la délégation sans contraintes pour chaque approbation. Le paramètre par défaut de cette fonctionnalité autorise la délégation sans contraintes et n’est pas sécurisé.

Des mises à jour renforçant la sécurité existent pour les versions suivantes de Windows Server :

• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012

Cette fonctionnalité, ainsi que les modifications apportées au renforcement de la sécurité, ont été rétroportées vers les versions suivantes :

• Windows Server 2008 R2
• Windows Server 2008

Ces mises à jour de sécurité apportent les modifications suivantes :

• La délégation Kerberos sans contraintes est désactivée par défaut sur les nouvelles forêts et les nouvelles approbations externes après l’installation de la mise à jour du 14 mai et des mises à jour ultérieures.
• La délégation Kerberos sans contraintes est désactivée sur les forêts (nouvelles et existantes) et les approbations externes après l’installation de la mise à jour du 9 juillet 2019 et des mises à jour ultérieures.
• Les administrateurs peuvent activer la délégation Kerberos sans contraintes à l’aide du module NETDOM et AD PowerShell de mai ou d’une version ultérieure.

Les mises à jour peuvent entraîner des conflits de compatibilité pour les applications qui nécessitent actuellement une délégation sans contraintes entre des approbations de forêt ou externes. Cela est particulièrement vrai pour les approbations externes pour lesquelles l’indicateur de quarantaine (également appelé filtrage SID) est activé par défaut. Plus précisément, les demandes d’authentification concernant des services qui utilisent la délégation sans contraintes sur les types d’approbations mentionnés échoueront lors de la demande de nouveaux tickets.

Pour connaître les dates de publication, consultez Mises à jour chronologie.

Solution de contournement

Pour assurer la sécurité des données et du compte sur une version de Windows Server dotée de la fonctionnalité Application des limites forestières pour la délégation complète Kerberos, vous pouvez bloquer la délégation TGT après avoir installé les mises à jour de mars 2019 sur une approbation entrante en définissant l’indicateur netdom EnableTGTDelegation sur Non, comme suit :

netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No

La délégation TGT est bloquée sur les approbations forestières et externes nouvelles et existantes après l’installation des mises à jour de mai et juillet 2019 respectivement.

Pour réactiver la délégation entre les approbations et revenir à la configuration non sécurisée d’origine jusqu’à ce que la délégation contrainte ou basée sur les ressources puisse être activée, définissez l’indicateur EnableTGTDelegation sur Oui.

La ligne de commande NETDOM pour activer la délégation TGT est la suivante :

netdom trust <TrustedDomainName > /domain:<TrustingDomainName > /EnableTgtDelegation:Yes

Vous pouvez concevoir la syntaxe NETDOM pour activer la délégation TGT comme suit :

netdom trust <domain that you are administering> /domain:<domain whose trust NETDOM is modifying> /EnableTgtDelegation:Yes

La syntaxe NETDOM permettant la délégation TGT des utilisateurs fabrakam.com sur contoso.com serveurs est la suivante :

netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:Yes

         Remarques

• L’indicateur EnableTGTDelegation doit être défini dans le domaine approuvé (fabrikam.com dans ce cas) pour chaque domaine d’approbation (par exemple, contoso.com). Une fois l’indicateur défini, le domaine approuvé n’autorise plus la délégation de TGT au domaine d’approbation.
• L’état sécurisé pour EnableTGTDedélégation est Non.
• Toute application ou service qui s’appuie sur une délégation sans contraintes entre forêts échouera lorsque EnableTGTDelegation est défini manuellement ou par programme sur Oui. EnableTGTDelegation par défaut sur NON sur les approbations nouvelles et existantes après l’installation des mises à jour de mai 2019 et de juillet 2019. Pour plus d’informations sur la détection de ce problème, consultez Recherche de services qui s’appuient sur la délégation sans contraintes. Consultez Mises à jour chronologie pour obtenir une chronologie des modifications qui affectent la façon dont cette solution de contournement peut être appliquée.
• Pour plus d’informations sur NETDOM, consultez la documentationNetdom.exe.
• Si vous devez activer la délégation TGT sur une approbation, il est recommandé d’atténuer ce risque en activant Windows Defender Credential Guard sur les ordinateurs clients. Cela empêche toute délégation sans contraintes à partir d’un ordinateur sur lequel Windows Defender Credential Guard est activé et en cours d’exécution.
• Si vous avez une forêt ou une approbation externe et que l’une ou l’autre est configurée comme étant en quarantaine, la délégation TGT ne peut pas être activée, car les deux indicateurs ont une sémantique opposée. Le bit de quarantaine renforce la limite de sécurité entre les domaines participants. L’activation de la délégation TGT efface les limites de sécurité entre les domaines en donnant au domaine d’approbation l’accès aux informations d’identification des utilisateurs du domaine approuvé. Vous ne pouvez pas avoir les deux côtés.
  Ajoutez l’indicateur quarantine :no à la syntaxe de ligne de commande NETDOM si l’indicateur de quarantaine est actuellement activé.
• Si vous avez remplacé EnableTGTDelegation par Oui, supprimez les tickets Kerberos sur les appelants d’origine et intermédiaires si nécessaire. Le ticket pertinent à supprimer est le ticket TGT de référence du client auprès de la fiducie concernée. Cela peut impliquer plusieurs appareils, en fonction du nombre de sauts de délégation dans un environnement donné.

Pour plus d’informations sur cette procédure, voir l’article suivant de Windows IT Pro Center :

Protéger les informations d’identification de domaine dérivées avec Windows Defender Credential Guard

Mises à jour chronologie

12 mars 2019

L’application des limites de forêt pour la délégation complète de Kerberos sera disponible sous la forme d’une mise à jour pour activer cette fonctionnalité sur toutes les versions prises en charge de Windows Server répertoriées dans la section S’applique à en haut de cet article. Nous vous recommandons de définir cette fonctionnalité sur les approbations de forêt entrantes.

La mise à jour ajoute la fonctionnalité de mise en conformité des limites forestières pour la délégation complète de Kerberos aux systèmes suivants :

• Windows Server 2008 R2
• Windows Server 2008

14 mai 2019

Une mise à jour a été publiée pour ajouter une nouvelle configuration par défaut sécurisée aux nouvelles approbations de forêt et externes. Si vous avez besoin d’une délégation entre approbations, l’indicateur EnableTGTDelegation doit être défini sur Oui avant l’installation de la mise à jour du 9 juillet 2019. Si vous n’exigez pas de délégation entre les approbations, vous ne devez pas définir l’indicateur EnableTGTDelegation . L’indicateur EnableTGTDelegation sera ignoré jusqu’à ce que la mise à jour du 9 juillet 2019 soit installée pour donner aux administrateurs le temps de réactiver la délégation Kerberos sans contraintes lorsque celle-ci est nécessaire.

Dans le cadre de cette mise à jour, l’indicateur EnableTGTDelegation sera défini sur Non par défaut pour toutes les approbations nouvellement créées. C’est le contraire du comportement précédent. Nous recommandons aux administrateurs de reconfigurer plutôt les services concernés pour utiliser la délégation sans contraintes basée sur les ressources.

Pour plus d’informations sur la détection des problèmes de compatibilité, consultez Recherche de services qui s’appuient sur la délégation sans contraintes.

9 juillet 2019

Une mise à jour a été publiée pour appliquer le nouveau comportement par défaut du côté entrant de la forêt et des approbations externes. Les demandes d’authentification concernant des services qui utilisent la délégation sans contraintes sur les types d’approbations mentionnés seront authentifiées, mais sans délégation. Le service échoue lorsqu’il essaie d’exécuter des opérations déléguées.

Pour les atténuations, consultez la section « Solution de contournement ».

Recherche de services qui s’appuient sur la délégation sans contraintes

Pour rechercher les forêts qui ont des approbations entrantes autorisant la délégation TGT et les principaux de sécurité qui autorisent la délégation sans contraintes, exécutez les scripts PowerShell suivants dans un fichier de script (par exemple, Get-RiskyServiceAccountsByTrust.ps1 -Collect) :

[CmdletBinding()]  
Param  
(  
    [switch]$Collect, 
    [switch]$ScanAll 
) 
 
if ($Debug) {  
    $DebugPreference = 'Continue'  
} 
else { 
    $DebugPreference = 'SilentlyContinue'  
} 

function Get-AdTrustsAtRisk 
{ 
    [CmdletBinding()]  
    Param  
    (  
        [string]$Direction = "Inbound", 
        [switch]$ScanAll 
    ) 
 
    if ($ScanAll) { 
        return get-adtrust -filter {Direction -eq $Direction} 
    } 
    else { 
        return get-adtrust -filter {Direction -eq $Direction -and TGTDelegation -eq $false} 
    } 
} 
 
function Get-ServiceAccountsAtRisk 
{ 
    [CmdletBinding()]  
    Param  
    (  
        [string]$DN = (Get-ADDomain).DistinguishedName, 
        [string]$Server = (Get-ADDomain).Name 
    ) 
 
    Write-Debug "Searching $DN via $Server" 
 
    $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  
  
$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 "[\s\n]", ''  
  
    $propertylist = @(  
        "servicePrincipalname",   
        "useraccountcontrol",   
        "samaccountname",   
        "msDS-AllowedToDelegateTo",   
        "msDS-AllowedToActOnBehalfOfOtherIdentity"  
    )  
 
    $riskyAccounts = @() 
 
    try { 
        $accounts = Get-ADObject -LDAPFilter $filter -SearchBase $DN -SearchScope Subtree -Properties $propertylist -Server $Server 
    } 
    catch { 
        Write-Warning "Failed to query $Server. Consider investigating seperately. $($_.Exception.Message)" 
    } 
              
    foreach ($account in $accounts) {  
        $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  
      
        $acct = [PSCustomobject] @{  
            domain = $Server 
            sAMAccountName = $account.samaccountname  
            objectClass = $account.objectclass          
            isDC = $isDC  
            isRODC = $isRODC  
            fullDelegation = $fullDelegation  
            constrainedDelegation = $constrainedDelegation  
            resourceDelegation = $resourceDelegation  
        }  
 
        if ($fullDelegation) {  
            $riskyAccounts += $acct    
        } 
    }  
 
    return $riskyAccounts 
} 
 
function Get-RiskyServiceAccountsByTrust  
{ 
    [CmdletBinding()]  
    Param  
    ( 
        [switch]$ScanAll 
    ) 
     
    $riskyAccounts = @() 
 
    $trustTypes = $("Inbound", "Bidirectional") 
 
    foreach ($type in $trustTypes) { 
 
        $riskyTrusts = Get-AdTrustsAtRisk -Direction $type -ScanAll:$ScanAll 
 
        foreach ($trust in $riskyTrusts) { 
            $domain = $null 
     
            try { 
                $domain = Get-AdDomain $trust.Name -ErrorVariable eatError -ErrorAction Ignore 
            } catch { 
                write-debug $_.Exception.Message 
            } 
 
            if($eatError -ne $null) { 
                Write-Warning "Couldn't find domain: $($trust.Name)" 
            } 
 
            if ($domain -ne $null) { 
                $accts = Get-ServiceAccountsAtRisk -DN $domain.DistinguishedName -Server $domain.DNSRoot 
 
                foreach ($acct in $accts) { 
                    Write-Debug "Risky: $($acct.sAMAccountName) in $($acct.domain)" 
                }             
 
                $risky = [PSCustomobject] @{  
                    Domain = $trust.Name 
                    Accounts = $accts 
                } 
 
                $riskyAccounts += $risky 
            } 
        } 
    } 
 
    return $riskyAccounts 
} 
 
if ($Collect) { 
   Get-RiskyServiceAccountsByTrust -ScanAll:$ScanAll | Select-Object -expandProperty Accounts | format-table 
}

La sortie des scripts PowerShell répertorie les principaux de sécurité Active Directory dans les domaines configurés pour une approbation entrante du domaine en cours d’exécution avec une délégation sans contraintes configurée. Le résultat ressemblera à l’exemple suivant.

Détection de la délégation sans contraintes par le biais d’événements Windows

Lorsqu’un ticket Kerberos est émis, un contrôleur de domaine Active Directory consigne les événements de sécurité suivants. Les événements contiennent des informations sur le domaine cible. Vous pouvez utiliser ces événements pour déterminer si la délégation sans contraintes est utilisée entre les approbations entrantes.

Résolution des problèmes d’authentification

Lorsque la délégation sans contraintes est désactivée, les applications peuvent rencontrer des problèmes de compatibilité avec ces modifications si elles utilisent la délégation sans contraintes. Ces applications doivent être configurées pour utiliser la délégation contrainte ou la délégation contrainte basée sur les ressources. Pour plus d’informations, consultez Présentation de la délégation contrainte Kerberos.

Les applications qui reposent sur l’authentification aller-retour entre approbations ne sont pas prises en charge par l’utilisation de la délégation contrainte. Par exemple, une délégation échoue si un utilisateur de la forêt A s’authentifie auprès d’une application de la forêt B et que l’application de la forêt B tente de déléguer un ticket à la forêt A.