LaBouaBouate

Authentication Policies & Silos

#activedirectory
Publié le 12 mai 2026 12 minutes de lecture

Concept

Après de nombreuses tentatives échouées de prendre le sujet en main et de monter un lab, j’ai enfin trouvé une source simple et concise : How to implement Auth Policy and Silos : r/activedirectory

Déjà le terme de Authentication Policy et Authentication Policy Silos est un peu abstrait. On pourrait parler d’un pare-feu d’authentification (la partie policy) qui s’applique à un regroupement de machine (la partie silo). On définit donc des règles dans le pare-feu (qui peut se connecter, quelle est la durée de vie maximum d’un ticket Kerberos, est-ce que l’usage du NTLM est autorisé) que l’on appliquera ensuite à un ensemble d’ordinateurs.

Note : le silo est optionnel, et il est tout à faire possible de faire sans. Comme cet article vise à faire un tutoriel au plus simple, on va ignorer la configuration sans silo.

Si vous êtes familier du concept de tiering-model, vous comprendrez qu’on a simplement à ajouter nos utilisateurs du TIER 1 dans la policy et nos serveurs TIER 1 dans le silo pour empêcher n’importe quel compte en dehors du TIER 1 de s’y connecter.

Avantages

Les avantages par rapport au tiering par GPO :

Inconvénients

Les inconvénients par rapport au tiering par GPO :

Je n’ai pas encore eu le temps de tester la partie “Inconvénients”, donc je ne fais que relater des points qui m’ont été remontés par des collègues ou dans d’autres articles.

Procédure

Contexte

On va essayer de répliquer une configuration de tiering en utilisant exclusivement les AuthNPolicy & AuthNPolicySilo. Présentation des personnages principaux :

L’objectif va donc être de restreindre l’accès au serveur SRV01 uniquement aux utilisateurs du TIER 1. Si un compte TIER 0 (membre du groupe Domain Admins) tente de s’y connecter, la connexion sera refusée même si le compte TIER 0 a les droits nécessaires.

Ajout du support pour le Kerberos Armoring

Le Kerberos Armoring est obligatoire pour l’utilisation des AuthNPolicy & AuthNPolicySilo (d’où la limite de compatibilité sur les systèmes d’exploitation). Pour activer les paramètres :

Plus d’informations sur le sujet ici : Authentification composée et revendications Active Directory Domain Services dans Services ADFS | Microsoft Learn (Étape 1 & 2 uniquement).

Création du groupe de ciblage

Création d’un groupe “Allowed to authenticate to T1” pour réunir tous les comptes qui auront l’autorisation de se connecter sur des serveurs du TIER 1 :

$splat = @{
    Name          = 'Allowed to authenticate to T1'
    Path          = 'OU=Groups,OU=T1,DC=corp,DC=contoso,DC=com'
    Description   = 'Members of this group are allowed to access to T1 computers through the authentication firewall'
    GroupCategory = 'Security'
    GroupScope    = 'DomainLocal'
}
New-ADGroup @splat

Ajout de mon compte administrateur T1 dans le nouveau groupe :

Add-ADGroupMember 'Allowed to authenticate to T1' -Members 't1_lbouard'

Création des règles du pare-feu d’authentification

Création des règles du pare-feu avec le moins de paramètres possibles :

$groupSid = (Get-ADGroup 'Allowed to authenticate to T1').SID.Value
$sddl = "O:SYG:SYD:(XA;OICI;CR;;;WD;(Member_of_any{SID($groupSID)}))"
$splat = @{
    Name                            = 'T1 Authentication Policy'
    Enforce                         = $true
    ComputerAllowedToAuthenticateTo = $sddl
}

New-ADAuthenticationPolicy @splat

Les paramètres invoqués ont la fonction suivante :

Le SDDL peut être créé à partir de la commande Show-ADAuthenticationPolicyExpression. Plus d’informations sur la commande ici : Show-ADAuthenticationPolicyExpression (ActiveDirectory) | Microsoft Learn

Exemple de commande pour la création du SDDL en question :

$sddl = Show-ADAuthentificationPolicyExpression -AllowedToAuthenticateTo

Création du silo

Création du silo qui va être soumis au pare-feu d’authentification que l’on a créé précédemment :

$authNpolicy = Get-ADAuthenticationPolicy 'T1 Authentication Policy'
$splat = @{
    Name                         = 'T1 Silo'
    Enforce                      = $true
    ComputerAuthenticationPolicy = $authNpolicy
    ServiceAuthenticationPolicy  = $authNpolicy
    UserAuthenticationPolicy     = $authNpolicy
}
New-ADAuthenticationPolicySilo @splat

Ici encore une fois on vise la configuration la plus simple possible : on applique les mêmes règles pour les authentifications d’ordinateurs, d’utilisateurs ou de comptes de service.

Intégration des serveurs dans le silo

Ajouter le serveur SRV01 en tant que membre du silo :

$computerDn = (Get-ADComputer SRV01).DistinguishedName
Set-ADAuthenticationPolicySilo 'T1 Silo' -Add @{ 'msDS-AuthNPolicySiloMembers' = $computerDn }

Affecter le silo au serveur SRV01, ce qui permet d’exposer le serveur au pare-feu d’authentification :

Set-ADAccountAuthenticationPolicySilo 'SRV01$' -AuthenticationPolicySilo 'T1 Silo'

Pourquoi est-ce qu’il y a deux étapes ? J’en ai aucune foutue idée, mais les deux étapes sont nécessaires pour que le blocage soit effectif. Si le serveur n’est pas membre du silo (attribut msDS-AuthNPolicySiloMembersBL), même si celui-ci est exposé au pare-feu d’authentification (attribut msDS-AssignedAuthNPolicySilo), le blocage des comptes non-autorisés n’est pas effectif.

À partir de maintenant, seul un membre du groupe Allowed to authenticate to T1 pourra s’authentifier sur l’ordinateur “SRV01”. Si un utilisateur ne faisant pas partie de ce groupe essaye de se connecter, il tombera sur l’erreur suivante :
The computer you are signing into is protected by an authentication firewall. The specified account is not allowed to authenticate to the computer.

D’après mes tests, le compte administrateur par défaut (avec le SID 500) n’est pas affecté par les AuthNPolicy. Il pourra donc servir de compte brise glace sur tous les ordinateurs du domaine (qu’importe le silo d’authentification).

Sortir un serveur d’un silo

Voici la commande pour retirer le serveur SRV01 du silo :

$computerDn = (Get-ADComputer SRV01).DistinguishedName
Set-ADAuthenticationPolicySilo 'T1 Silo' -Remove @{ 'msDS-AuthNPolicySiloMembers' = $computerDn }

Et la ligne supplémentaire pour ne plus exposer le serveur SRV01 du pare-feu d’authentification :

Set-ADComputer SRV01 -Clear 'msDS-AssignedAuthNPolicySilo'

Si l’ajout dans un silo se fait en deux étapes, deux étapes sont également nécessaires pour le retrait.

Questions supplémentaires

Que se passe-t’il si un ordinateur est affecté dans deux silos différents ?

On va prendre l’exemple d’un ordinateur qui serait dans le silo TIER 1 & le silo TIER 2.

J’ai testé pour vous, et si mon hypothèse initiale était que le contrôleur de domaine allait bloquer les connexions pour les utilisateurs du TIER 1 & 2 : ce n’est pas le cas ! En fait l’attribut msDS-AssignedAuthNPolicySilo (celui qui permet d’exposer l’ordinateur au pare-feu d’authentification) ne peut contenir qu’une seule valeur.

Donc pour répondre à la question : un ordinateur peut être dans deux silos en même temps, mais seul celui indiqué dans l’attribut msDS-AssignedAuthNPolicySilo sera actif. On peut consulter celui qui prime avec la commande suivante :

Get-ADComputer SRV01 -Properties AuthenticationPolicySilo

Pourquoi faire un modèle en tiers avec des GPO et des AuthNPolicy/Silo ?

Dans ses recommandations relatives à l’administration sécurisée des systèmes d’information reposant sur Microsoft Active Directory, l’ANSSI conseille le déploiement conjoint des AuthNPolicy et des GPO de restriction de connexion classiques (qui utilise les User Rights Assignment), sans détailler la raison d’un tel design. Et visiblement je ne suis pas le seul à ne pas savoir pourquoi :

Après avoir creusé un peu, je pense que la raison principale de déployer AuthNPolicy + GPO est pour réduire l’administration quotidienne. L’ajout systématique dans un silo pour les ordinateurs personnels me paraît peu crédible sur la durée, et la GPO sert de filet de sécurité pour appliquer une restriction de connexion dès qu’un objet ordinateur est déplacé dans une unité d’organisation du TIER (dans le cas d’un oubli).

Et comme le fonctionnement des deux méthodes est différent, elles restent complémentaires :

Pour plus d’informations sur les GPO de limitation de connexion, vous pouvez consulter mon article sur le sujet.

Automatisation de l’ajout dans le silo

C’est cadeau, je n’ai pas pu le tester de manière extensive mais voici un bout de code qui permet d’ajouter automatiquement tous les serveurs TIER 1 dans le silo du TIER 1 :

$sb = 'OU=Servers,OU=T1,DC=corp,DC=contoso,DC=com'
$computers = Get-ADComputer -Filter * -SearchBase $sb -Properties 'msDS-AssignedAuthNPolicySilo'
$silo = Get-ADAuthenticationPolicySilo 'T1 Silo' -Properties 'msDS-AuthNPolicySiloMembers'

$computers | Where-Object { $_.'msDS-AssignedAuthNPolicySilo' -ne $silo.DistinguishedName } |
ForEach-Object {
    Write-Host "Processing $($_.Name)"
    Set-ADAuthenticationPolicySilo $silo -Add @{ 'msDS-AuthNPolicySiloMembers' = $_.DistinguishedName }
    Set-ADAccountAuthenticationPolicySilo $_.SamAccountName -AuthenticationPolicySilo $silo
}

Et comme je suis très gentil, voici de quoi mettre en place les délégations de contrôle qui permettront d’exécuter le script avec un compte dédié (svc_authnpolicysilo) en utilisant le principe du moindre privilège.

Ajout du droit d’écriture de l’attribut msDS-AssignedAuthNPolicySilo sur les objets ordinateurs sous “OU=Servers,OU=T1,DC=corp,DC=contoso,DC=com” :

dsacls "OU=Servers,OU=T1,DC=corp,DC=contoso,DC=com" /G "CORP\svc_authnpolicysilo:WP;msDS-AssignedAuthNPolicySilo;computer" /I:S

Ajout du droit d’écriture de l’attribut msDS-AuthNPolicySiloMembers sur les objets silos sous “CN=AuthN Silos,CN=AuthN Policy Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com” :

dsacls "CN=AuthN Silos,CN=AuthN Policy Configuration,CN=Services,CN=Configuration,DC=corp,DC=contoso,DC=com" /G "CORP\svc_authnpolicysilo:WP;msDS-AuthNPolicySiloMembers;msDS-AuthNPolicySilo" /I:S

Pour des raisons de simplicité je donne les droits directement sur le compte de service, mais la bonne pratique est de donner les droits sur des groupes dédiés, pour rendre les permissions explicites.

Photo de profil
Article écrit par Léo Bouard

Ingénieur systèmes spécialisé dans les infrastructures, les technologies et l'écosystème Microsoft. Je travaille depuis 2017 sur les questions de gestion d'identité, d'outils collaboratifs et d'automatisation.

Cet article pourrait-il vous intéresser ?