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

Résumé

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

La délégation Kerberos sans contrainte est un mécanisme dans lequel un utilisateur envoie ses informations d’identification à un service pour permettre au service d’accéder aux ressources pour le compte de l’utilisateur. Pour activer la délégation Kerberos sans contrainte, 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 à différentes forêts. La forêt de services 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’une identité TGT à partir 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 introduit l’application de la limite de forêt pour la délégation complète Kerberos. Cette fonctionnalité a ajouté une stratégie au domaine approuvé pour désactiver la délégation sans contrainte par approbation. Le paramètre par défaut de cette fonctionnalité autorise la délégation sans contrainte et n’est pas sécurisé.

Mises à jour qui fournissent un renforcement de 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 dans 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 contrainte est désactivée par défaut sur la nouvelle forêt 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 contrainte 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 contrainte à l’aide des versions de mai ou ultérieures de NETDOM et d’AD PowerShell.

Les mises à jour peuvent entraîner des conflits de compatibilité pour les applications qui nécessitent actuellement une délégation sans contrainte entre les approbations de forêt ou externes. Cela est particulièrement vrai pour l’approbation externe pour laquelle l’indicateur de quarantaine (également appelé filtrage SID) est activé par défaut. Plus précisément, les demandes d’authentification pour les services qui utilisent une délégation sans contrainte sur les types d’approbation répertoriés échouent lorsque vous demandez 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 des comptes sur une version Windows Server qui a la fonctionnalité Application de la limite de forêt 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 forêts nouvelles et existantes et les approbations externes 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 limitée 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 penser conceptuellement à la syntaxe NETDOM pour l’activation de 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 pour activer 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 des TGT au domaine d’approbation.
• L’état sécurisé pour EnableTGTDelegation est Non.
• Toute application ou service qui s’appuie sur une délégation sans contrainte entre les forêts échoue lorsque EnableTGTDelegation est défini manuellement ou par programme sur Oui. EnableTGTDelegation est défini 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 cet échec, consultez Recherche de services qui reposent sur une délégation sans contrainte. Consultez Mises à jour chronologie pour obtenir un 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 contrainte à partir d’un ordinateur sur lequel Windows Defender Credential Guard est activé et en cours d’exécution.
• Si vous disposez d’une forêt ou d’une approbation externe, et que vous êtes configuré comme mis 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 l’avoir dans les deux sens.
  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 approprié à supprimer est le TGT de référence du client sur l’approbation approprié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, consultez l’article Windows IT Pro Center suivant :

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

Mises à jour chronologie

12 mars 2019

L’application de la limite de forêt pour la délégation complète Kerberos sera disponible en tant que 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 la fonctionnalité sur les approbations de forêt entrantes.

La mise à jour ajoute la fonctionnalité Application de la limite de forêt pour la délégation complète Kerberos aux systèmes suivants :

• Windows Server 2008 R2
• Windows Server 2008

14 mai 2019

Une mise à jour a été publiée, ajoutant une nouvelle configuration par défaut sécurisée à la nouvelle forêt et aux approbations 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’avez pas besoin d’une 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 contrainte quand elle est nécessaire.

Dans le cadre de cette mise à jour, l’indicateur EnableTGTDelegation est défini sur Non par défaut pour les approbations nouvellement créées. Il s’agit de l’opposé du comportement précédent. Nous recommandons aux administrateurs de reconfigurer les services affectés pour utiliser la délégation contrainte basée sur les ressources.

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

9 juillet 2019

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

Pour l’atténuation, consultez la section « Solution de contournement ».

Recherche de services qui s’appuient sur une délégation sans contrainte

Pour rechercher les forêts qui ont des approbations entrantes qui autorisent la délégation TGT et rechercher les principaux de sécurité qui autorisent la délégation sans contrainte, 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 à partir du domaine en cours d’exécution pour lequel la délégation sans contrainte est configurée. La sortie ressemble à l’exemple suivant.

Détection de la délégation non contrainte par le biais d’événements Windows

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

Résolution des problèmes d’authentification

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

Les applications qui s’appuient sur l’authentification aller-retour entre approbations ne sont pas prises en charge à l’aide 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.