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 directions. La forêt approuvée est la source de l’identité utilisateur. La forêt autorisée à approuver contient la ressource à laquelle les utilisateurs s’authentifient. La forêt approuvée peut authentifier les utilisateurs sur la forêt autorisée à approuver sans permettre l’inverse.
La délégation Kerberos sans contraintes est un mécanisme selon lequel un utilisateur envoie ses informations d’identification à un service pour lui permettre d’accéder à des ressources en son nom. Pour que la délégation Kerberos sans contraintes puisse être activée, le compte du service dans Active Directory doit être marqué comme approuvé pour la délégation. Cela entraîne un problème si l’utilisateur et le service appartiennent à des forêts différentes. La forêt du 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.
Autoriser une forêt à prendre des décisions en matière de sécurité concernant les comptes d’une autre forêt enfreint la limite de sécurité entre les forêts. Un attaquant qui possède la forêt autorisée à approuver peut demander la délégation d’un ticket TGT pour une identité de la forêt approuvée, ce qui lui permet d’accéder aux ressources de la forêt approuvée. Cela ne s’applique pas à la délégation contrainte du protocole Kerberos (KCD).
Windows Server 2012 a introduit la fonctionnalité d’application de la limite de la forêt pour la délégation totale Kerberos. Cette fonctionnalité a ajouté une stratégie au domaine approuvé pour 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ûr.
Il existe des mises à jour qui renforcent la sécurité pour les versions suivantes de Windows Server :
-
Windows Server 2019
-
Windows Server 2016
-
Windows Server 2012 R2
-
Windows Server 2012
Cette fonctionnalité et les modifications de renforcement de la sécurité ont été rétroportées dans les versions suivantes :
-
Windows Server 2008 R2
-
Windows Server 2008
Ces mises à jour apportent les modifications suivantes :
-
La délégation Kerberos sans contraintes est désactivée par défaut pour les nouvelles approbations de 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 contraintes est désactivée pour 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 en utilisant la version de mai ou une version ultérieure de NETDOM et du module AD PowerShell.
Les mises à jour peuvent provoquer des conflits de compatibilité pour les applications qui nécessitent actuellement une délégation sans contraintes entre les approbations de forêt ou externes. Cela concerne tout particulièrement les approbations externes pour lesquelles l’indicateur de mise en quarantaine (également appelé « filtrage des SID ») est activé par défaut. En particulier, 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 la section Calendrier des mises à jour.
Solution de contournement
Pour assurer la sécurité des données et des comptes sur une version de Windows Server qui intègre la fonctionnalité d’application de la limite de la forêt pour la délégation totale Kerberos, vous pouvez bloquer la délégation TGT après l’installation des mises à jour de mars 2019 sur une approbation entrante en affectant la valeur Non à l’indicateur netdom EnableTGTDelegation comme suit :
netdom.exe trust fabrikam.com /domain:contoso.com /EnableTGTDelegation:No
La délégation TGT est bloquée pour les approbations de forêt et les approbations externes nouvelles et existantes après l’installation des mises à jour de mai et de juillet 2019 respectivement.
Pour réactiver la délégation dans les approbations et rétablir 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, affectez la valeur Oui à l’indicateur EnableTGTDelegation.
La ligne de commande NETDOM permettant d’activer la délégation TGT est la suivante :
netdom trust <TrustedDomainName > /domain:<TrustingDomainName > /EnableTgtDelegation:Yes
La syntaxe NETDOM permettant d’activer la délégation TGT peut être envisagée comme suit :
netdom trust <domain that you are administering> /domain:<domain whose trust NETDOM is modifying> /EnableTgtDelegation:Yes
La syntaxe NETDOM permettant d’activer la délégation TGT des utilisateurs fabrakam.com sur les serveurs contoso.com 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 autorisé à approuver (contoso.com, par exemple). Une fois l’indicateur défini, le domaine approuvé n’autorise plus la délégation des tickets TGT au domaine autorisé à approuver.
-
La valeur sécurisée pour EnableTGTDelegation est Non.
-
Les applications et les services reposant sur la délégation sans contraintes entre forêts échouent quand la valeur Oui est définie manuellement ou par programme pour EnableTGTDelegation. Par défaut, EnableTGTDelegation a la valeur NON pour 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 la section Recherche de services reposant sur la délégation sans contraintes. Consultez le calendrier des mises à jour pour connaître les dates de publication des modifications concernant l’application de cette solution de contournement.
-
Pour plus d’informations sur NETDOM, consultez la documentation sur Netdom.exe.
-
Si vous devez activer la délégation TGT dans une approbation, il est recommandé d’atténuer ce risque en activant Windows Defender Credential Guard sur les ordinateurs clients. Vous empêchez ainsi toute délégation sans contraintes à partir d’un ordinateur sur lequel Windows Defender Credential Guard est activé et exécuté.
-
Si vous possédez une approbation de forêt ou externe 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 contraire. 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 permettant au domaine autorisé à approuver d’accéder aux informations d’identification des utilisateurs du domaine approuvé. Il est impossible d’appliquer les deux à la fois.
Ajoutez l’indicateur quarantine:no à la syntaxe de la ligne de commande NETDOM si l’indicateur quarantine est actuellement activé.
-
Si vous avez affecté la valeur Oui à EnableTGTDelegation, supprimez les tickets Kerberos sur les appelants d’origine et intermédiaires. Le ticket correspondant à supprimer est le ticket TGT de référence du client sur l’approbation appropriée. Cette suppression peut concerner 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 suivant sur Windows IT Pro Center :
Calendrier des mises à jour
12 mars 2019
L’application de la limite de la forêt pour la délégation totale Kerberos sera disponible dans le cadre d’une mise à jour qui activera cette fonctionnalité sur toutes les versions prises en charge de Windows Server répertoriées dans la section « S’applique à » en début d’article. Nous vous recommandons de définir cette fonctionnalité sur les approbations de forêt entrantes.
La mise à jour ajoute la fonctionnalité d’application de la limite de la forêt pour la délégation totale 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ûre aux nouvelles approbations de forêt et externes. Si vous avez besoin de la délégation entre les approbations, vous devez affecter la valeur Oui à l’indicateur EnableTGTDelegation avant d’installer la mise à jour du 9 juillet 2019. Si vous n’exigez pas la délégation entre les approbations, ne définissez pas l’indicateur EnableTGTDelegation. L’indicateur EnableTGTDelegation est ignoré jusqu’à ce que la mise à jour du 9 juillet 2019 soit installée pour laisser le temps aux administrateurs de réactiver la délégation Kerberos sans contraintes quand elle est nécessaire.
Dans le cadre de cette mise à jour, l’indicateur EnableTGTDelegation prend par défaut la valeur Non pour les nouvelles approbations. Il s’agit d’une pratique inverse au comportement précédent. Microsoft recommande aux administrateurs de reconfigurer les services concernés pour pouvoir 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 la section Recherche de services reposant 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 au côté entrant des approbations de forêt et externes. Les demandes d’authentification concernant des services qui utilisent la délégation sans contraintes sur les types d’approbations mentionnés sont authentifiées, mais sans délégation. Le service échoue quand il tente d’exécuter des opérations déléguées.
Pour obtenir l’atténuation, consultez la section « Solution de contournement ».
Recherche de services reposant sur la délégation sans contraintes
Pour rechercher les forêts contenant des approbations entrantes autorisant la délégation TGT et les principaux de sécurité autorisant la délégation sans contraintes, exécutez les scripts PowerShell suivants dans un fichier de script (par exemple, Get-RiskyServiceAccountsByTrust.ps1 -Collect) :
Remarque
Vous pouvez également transmettre l’indicateur -ScanAll pour effectuer une recherche sur les approbations n’autorisant pas la délégation TGT.
[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
}
Les résultats des scripts PowerShell répertorient les principaux de sécurité Active Directory dans les domaines configurés pour une approbation entrante à partir du domaine d’exécution pour lequel la délégation sans contraintes est configurée. Les résultats sont similaires à l’exemple ci-dessous.
|
Domaine |
sAMAccountName |
objectClass |
|
partner.fabrikam.com |
dangerous |
user |
|
partner.fabrikam.com |
labsrv$ |
computer |
Détection de la délégation sans contraintes à l’aide d’événements Windows
Lorsqu’un ticket Kerberos est généré, un contrôleur de domaine Active Directory journalise les événements de sécurité ci-dessous. 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 contraintes est utilisée entre les approbations entrantes.
Remarque
Vérifiez la présence d’événements qui contiennent une valeur TargetDomainName correspondant au nom de domaine approuvé.
|
Journal des événements |
Source de l’événement |
ID d’événement |
Détails |
|
Sécurité |
Microsoft-Windows-Security-Auditing |
4768 |
Un ticket TGT Kerberos a été généré. |
|
Sécurité |
Microsoft-Windows-Security-Auditing |
4769 |
Un ticket de service Kerberos a été généré. |
|
Sécurité |
Microsoft-Windows-Security-Auditing |
4770 |
Un ticket de service Kerberos a été renouvelé. |
Dépannage des échecs d’autorisation
Lorsque la délégation sans contraintes est désactivée, les applications peuvent subir des problèmes de compatibilité avec ces modifications si elles reposent sur la délégation sans contraintes. Ces applications doivent être configurées pour utiliser la délégation sans contraintes ou une délégation sans contraintes basée sur les ressources. Pour plus d’informations, consultez l’article Vue d’ensemble de la délégation contrainte du protocole Kerberos.
Les applications qui reposent sur l’authentification aller-retour entre les approbations ne sont pas prises en charge avec la délégation contrainte. Par exemple une délégation échoue si un utilisateur de la forêt A s’authentifie dans une application dans la forêt B et que l’application de la forêt B tente de redéléguer un ticket à la forêt A.
