Filtrage des SID et authentification sélective, pas à pas

Une approbation étend votre frontière de sécurité à tout ce qui se trouve de l'autre côté. Si le domaine approuvé est compromis, deux éléments déterminent jusqu'où l'attaquant peut aller : les SID que vos contrôleurs de domaine acceptent dans les données d'autorisation qui traversent l'approbation, et les ordinateurs qui acceptent tout simplement l'authentification de principaux approuvés. Le filtrage des SID répond à la première question, l'authentification sélective à la seconde. Ce sont deux interrupteurs simples, et tous deux sont régulièrement laissés dans la mauvaise position après une migration ou une intégration de partenaire menée dans l'urgence.

L'article pilier sur les approbations et les frontières de forêt explique pourquoi la forêt est la frontière. Ce guide en est le prolongement opérationnel : comment lire l'état réel de chaque approbation à partir de trustAttributes, comment le filtrage des SID se comporte sur les approbations externes et les approbations de forêt, comment déployer l'authentification sélective sans casser les accès inter-forêts, et comment le vérifier grâce aux événements.

Mesurer : lire les indicateurs de l'approbation, pas l'interface graphique

La boîte de dialogue des propriétés d'une approbation masque plusieurs paramètres. La source qui fait foi est le masque de bits trustAttributes de l'objet trustedDomain situé dans CN=System.

Get-ADObject -SearchBase "CN=System,$((Get-ADDomain).DistinguishedName)" `
    -LDAPFilter "(objectClass=trustedDomain)" -Properties trustAttributes, trustDirection, trustType |
  Select-Object Name, trustDirection, trustType,
    @{n='Attr';e={'0x{0:X}' -f $_.trustAttributes}},
    @{n='Forest';e={[bool]($_.trustAttributes -band 0x8)}},
    @{n='Quarantined';e={[bool]($_.trustAttributes -band 0x4)}},
    @{n='SelectiveAuth';e={[bool]($_.trustAttributes -band 0x10)}},
    @{n='SIDHistoryAllowed';e={[bool]($_.trustAttributes -band 0x40)}},
    @{n='TGTDelegationEnabled';e={[bool]($_.trustAttributes -band 0x800)}}

trustDirection vaut 1 pour une approbation entrante (ils vous approuvent), 2 pour une approbation sortante (vous les approuvez, leurs utilisateurs peuvent vous atteindre) et 3 pour une approbation bidirectionnelle. Le durcissement s'applique du côté qui approuve : les contrôles ci-dessous protègent le domaine approbateur contre les principaux du domaine approuvé. Exécutez la requête dans chaque domaine qui possède des approbations.

Comment le filtrage des SID se comporte réellement

Le filtrage a lieu sur les contrôleurs de domaine du côté approbateur, lorsqu'ils traitent les données d'autorisation (le PAC) qui traversent l'approbation.

• Approbations externes avec quarantaine : seuls les SID du domaine approuvé lui-même sont conservés. L'historique des SID provenant de tout autre domaine est supprimé.
• Approbations de forêt (par défaut) : les SID appartenant à n'importe quel domaine de la forêt approuvée sont acceptés ; les SID prétendant appartenir à votre forêt ou à une troisième forêt sont supprimés. Autrement dit, un historique des SID pointant vers vos propres groupes est filtré, ce qui neutralise précisément l'injection de SID history.
• Approbations de forêt avec /enablesidhistory:yes (TREAT_AS_EXTERNAL) : l'historique des SID provenant de l'extérieur de la forêt approuvée est accepté, à l'exception des SID dont le RID est inférieur à 1000. Les groupes intégrés comme Domain Admins et Enterprise Admins sont protégés, mais les groupes d'administration personnalisés, les groupes Exchange et les groupes de support délégués ont tous un RID supérieur à 1000 et peuvent être injectés.
• Approbations intra-forêt : aucun filtrage. Les approbations parent-enfant se trouvent à l'intérieur de la frontière ; les mettre en quarantaine n'est pas pris en charge et casse le fonctionnement de la forêt.

Lorsqu'un DC supprime des SID, il journalise l'événement 4675, « SIDs were filtered », qui constitue un signal direct soit d'un effet de bord de migration, soit d'une tentative d'injection. Les accès inter-forêts légitimes sont décrits plus en détail dans l'entrée du glossaire consacrée au filtrage des SID.

Auditer : qui dépend de quoi

Avant de resserrer, identifiez ce qui traverse chaque approbation.

1. Appartenances aux groupes : les principaux de sécurité étrangers de CN=ForeignSecurityPrincipals représentent les utilisateurs et groupes du domaine approuvé placés dans vos groupes. Résolvez-les et passez-les en revue.
2. Ouvertures de session : l'événement 4624 sur les serveurs avec un TargetDomainName du domaine approuvé, et l'événement 4769 sur vos DC pour les tickets de référence, montrent quelles machines les principaux du partenaire utilisent réellement.
3. Dépendance à l'historique des SID : tout compte du domaine approuvé dont le sIDHistory contient des SID de votre domaine, ce qui ne fonctionne que tant que SID history est autorisé. Ce travail relève du nettoyage de SID history.

Get-ADObject -SearchBase "CN=ForeignSecurityPrincipals,$((Get-ADDomain).DistinguishedName)" -Filter * -Properties memberOf |
  ForEach-Object {
    $name = try { ([Security.Principal.SecurityIdentifier]$_.Name).Translate([Security.Principal.NTAccount]).Value } catch { 'unresolved' }
    [pscustomobject]@{ SID = $_.Name; Account = $name; MemberOf = ($_.memberOf -join '; ') }
  }

Les FSP impossibles à résoudre correspondent généralement à des objets partenaires supprimés ou à des approbations décommissionnées, et peuvent être retirés des groupes.

Appliquer : le filtrage des SID

Exécutez netdom sur un DC du domaine approbateur, en tant que Domain Admin de ce domaine. Pour les approbations externes :

netdom trust corp.example.com /domain:partner.example.net /quarantine
netdom trust corp.example.com /domain:partner.example.net /quarantine:yes

La première forme indique l'état actuel ; la seconde active la quarantaine. Pour les approbations de forêt, rétablissez le filtrage par défaut après une migration :

netdom trust corp.example.com /domain:partner.example.net /enablesidhistory
netdom trust corp.example.com /domain:partner.example.net /enablesidhistory:no

Profitez d'être dans netdom pour vérifier la délégation de TGT. Depuis les mises à jour de juillet 2019, la délégation non contrainte à travers les approbations de forêt est bloquée par défaut, et l'indicateur 0x800 de la requête de mesure montre si quelqu'un l'a réactivée. Les recommandations de Microsoft pour ce commutateur nomment d'abord la forêt approuvée ; confirmez l'ordre des arguments avec netdom trust /? sur votre DC :

netdom trust <TrustedForestName> /domain:<TrustingForestName> /EnableTGTDelegation:No

Autoriser la délégation de TGT permettrait à un serveur configuré en délégation non contrainte dans une forêt de capturer des TGT de l'autre.

Appliquer : l'authentification sélective

L'authentification sélective (CROSS_ORGANIZATION) fait passer le comportement par défaut pour les principaux approuvés de « les utilisateurs authentifiés peuvent atteindre n'importe quel ordinateur » à « aucun ordinateur sauf autorisation explicite ». Déployez-la dans l'ordre suivant.

1. Créer des groupes d'autorisation côté ressources

Créez un groupe de domaine local par ensemble de ressources dans le domaine approbateur, par exemple SA-Partner-FileServers, et ajoutez-y les groupes globaux du partenaire. Conserver les accès dans des groupes que vous possédez garde les ACL lisibles.

2. Accorder Allowed to Authenticate sur chaque ordinateur cible

Il s'agit du droit étendu Allowed to Authenticate (68b1d179-0d15-4d4f-ab71-46152e79a7bc) sur les objets ordinateur. Accordez-le avec PowerShell :

$group   = Get-ADGroup "SA-Partner-FileServers"
$sid     = [Security.Principal.SecurityIdentifier]$group.SID
$guid    = [Guid]"68b1d179-0d15-4d4f-ab71-46152e79a7bc"
$targets = "FS01","FS02"

foreach ($t in $targets) {
    $dn  = (Get-ADComputer $t).DistinguishedName
    $acl = Get-Acl "AD:$dn"
    $ace = New-Object DirectoryServices.ActiveDirectoryAccessRule($sid, "ExtendedRight", "Allow", $guid)
    $acl.AddAccessRule($ace)
    Set-Acl "AD:$dn" $acl
}

En général, aucune autorisation n'est nécessaire sur vos contrôleurs de domaine pour que les utilisateurs du partenaire atteignent les serveurs membres. N'accordez ce droit sur un DC que si les principaux du partenaire doivent utiliser une ressource hébergée sur ce DC, et jamais de manière large sur l'UO Domain Controllers.

3. Basculer l'interrupteur

netdom trust corp.example.com /domain:partner.example.net /SelectiveAuth:yes

La modification prend effet au fil de la réplication. Gardez /SelectiveAuth:no sous la main comme retour arrière, et effectuez le changement dans une fenêtre où le partenaire peut tester.

Planifier le déploiement avec le partenaire

Les modifications d'approbation affectent des personnes que vous ne gérez pas : traitez-les comme un changement conjoint plutôt que comme un paramètre local.

• Partagez d'abord les éléments factuels. Envoyez au partenaire la liste des principaux de sécurité étrangers et des serveurs sur lesquels ses utilisateurs s'authentifient réellement, tirée des données 4624 ci-dessus. Il repérera souvent des comptes obsolètes et des accès inutilisés que vous pourrez supprimer au lieu de les accorder.
• Réduisez le sens de l'approbation avant d'ajouter des contrôles. Si seuls ses utilisateurs ont besoin de vos ressources, l'approbation doit être unidirectionnelle sortante depuis votre domaine ; une approbation bidirectionnelle double la surface sans aucun bénéfice. Recréez l'approbation dans le sens nécessaire plutôt que de durcir un côté que personne n'utilise.
• Préférez les approbations de forêt aux approbations externes entre des forêts que vous maîtrisez : les approbations de forêt utilisent Kerberos par défaut, prennent en charge les restrictions de routage des suffixes de noms et filtrent les SID en tenant compte de la forêt. Les approbations externes se replient plus souvent sur NTLM, ce qui interfère avec tout projet de restriction de NTLM.
• Restreignez le routage des suffixes de noms sur les approbations de forêt afin que le partenaire ne puisse pas router l'authentification pour des suffixes que vous n'aviez pas l'intention d'accepter.
• Convenez d'un cycle de revue. Les approbations survivent aux projets qui les ont créées. Attribuez à chaque approbation un responsable et une date de revue, et supprimez-la avec netdom trust /remove lorsque le besoin métier disparaît.

Vérifier

# Relancer la requête trustAttributes ci-dessus, puis recouper avec Get-ADTrust
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, SIDFilteringQuarantined, SIDFilteringForestAware, SelectiveAuthentication

# Qui est autorisé à s'authentifier sur un serveur donné
(Get-Acl "AD:$((Get-ADComputer FS01).DistinguishedName)").Access |
  Where-Object { $_.ObjectType -eq '68b1d179-0d15-4d4f-ab71-46152e79a7bc' } |
  Select-Object IdentityReference, AccessControlType

SIDFilteringForestAware à True sur une approbation de forêt signifie que SID history est autorisé, l'état que vous souhaitez inverser. Testez ensuite depuis le côté partenaire : un utilisateur autorisé atteint FS01 ; le même utilisateur tentant d'atteindre un autre serveur doit échouer avec l'événement 4625 et le statut 0xC0000413 sur ce serveur. Transférez les événements 4675 et les 4625 portant ce statut vers votre SIEM en suivant l'architecture de collecte décrite dans Windows Event Forwarding.

Ce que cela casse

• Tout ce qui reposait sur un accès implicite à travers une approbation ouverte : partages de fichiers, connexions SQL, applications web utilisant Kerberos et serveurs d'impression échouent pour les utilisateurs du partenaire tant que chaque ordinateur cible ne dispose pas d'une autorisation Allowed to Authenticate.
• Les ouvertures de session interactives des utilisateurs du partenaire sur des postes de travail ou des hôtes RDS de votre domaine nécessitent une autorisation sur chacune de ces machines ; si la liste est longue, c'est la conception même de l'approbation qui mérite d'être revue.
• Les migrations en cours cassent lorsque le filtrage de SID history est rétabli, car les utilisateurs migrés perdent les accès accordés via leurs anciens SID.
• Les scénarios de délégation non contrainte inter-forêts cessent de fonctionner lorsque la délégation de TGT est désactivée ; migrez-les vers la délégation contrainte ou RBCD.
• Les outils d'identité tiers qui énumèrent ou s'authentifient à travers l'approbation depuis des serveurs arbitraires ont besoin de leurs propres autorisations.

Pour aller plus loin : la thématique Approbations & conception de forêt, l'entrée du glossaire sur SID history et la délégation contrainte et RBCD en toute sécurité pour remplacer la délégation non contrainte inter-forêts.