Active Directory : restreindre la connexion d’un utilisateur à son poste assigné

Limiter la connexion interactive de chaque compte Active Directory à un ou plusieurs postes désignés renforce la posture de sécurité, réduit la surface d’attaque latérale et simplifie la conformité. Ce guide complet détaille les méthodes, outils et bonnes pratiques pour y parvenir dans les environnements Windows Server modernes.

Sommaire

Vue d’ensemble de la problématique

Par défaut, tout utilisateur membre du groupe Domain Users peut ouvrir une session interactive sur n’importe quelle machine jointée au domaine. Dans un réseau d’entreprise, cette liberté :

accroît le risque de compromission latérale (mouvements pass‑the‑hash / pass‑the‑ticket) ;
complique la traçabilité des actions (journaux répartis) ;
va souvent à l’encontre des standards ISO 27001 ou RGPD requérant le principe du moindre privilège.

La solution consiste à combiner :

une GPO qui restreint les droits de connexion (Allow / Deny log on locally) ;
l’attribut « Log On To » du compte utilisateur pour cibler des postes précis.

Concepts techniques clés

Concept	Description synthétique
Session interactive	Connexion physique ou console (Ctrl‑Alt‑Del) ouvrant un jeton primaire local.
Jeton d’accès	Structure interne contenant identités, SID et privilèges, évaluée lors des ouvertures de session et des accès aux ressources.
Privilèges User Rights Assignment	Liste de droits évalués avant la création du jeton (ex. SeInteractiveLogonRight).
Attribut userWorkstations	Champ multivalué d’un objet utilisateur AD restreignant le NetBIOS des hôtes autorisés.

Stratégie de groupe : création et ciblage

Les droits sont configurés dans Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Attribution des droits utilisateur.

Étapes détaillées

Lancez GPMC.msc depuis un contrôleur de domaine ou une machine équipée des RSAT.
Créez une nouvelle GPO (ex. « Restrict Interactive Logon »).
Dans l’éditeur, ouvrez Allow log on locally et :
- supprimez Users ou Domain Users ;
- ajoutez un groupe ad hoc par poste (ex. PC‑FIN‑123‑Users).
(Facultatif) Renseignez Deny log on locally avec Domain Users pour un blocage explicite.
Liez la GPO à l’OU qui contient les ordinateurs cibles, pas l’OU des utilisateurs.
Activez le filtrage de sécurité : ne laissez que Authenticated Users.
Pour éviter les faux‑positifs, ajoutez un filtre WMI : Select * from Win32_OperatingSystem where ProductType = "1" (stations uniquement).

Propagation et validation

Forcer immédiatement la prise en compte :

gpupdate /target:computer /force

Puis ouvrez rsop.msc ou utilisez gpresult /h rapport.html pour confirmer que la GPO impose bien les droits souhaités.

Limiter via la propriété « Log On To »

L’attribut userWorkstations se configure côté utilisateur.

Ouvrez dsa.msc (ADUC) ;
Clic droit > Propriétés sur le compte ;
Onglet Compte > bouton Se connecter à… ;
Sélectionnez « Uniquement les ordinateurs suivants » et saisissez jusqu’à 64 noms NetBIOS ou FQDN.

La valeur est contrôlée lors de l’authentification kerberos : si le poste n’est pas listé, le contrôleur de domaine retourne « ERROR_LOGON_WORKSTATION_RESTRICTION » et l’événement 4625 est journalisé.

Automatiser avec PowerShell

# Ajout d’un poste autorisé
Import-Module ActiveDirectory
Set-ADUser -Identity jdupont -Add @{userWorkstations="PC-FIN-123"}
# Ajout en mode cumulatif
$user = Get-ADUser jdupont -Properties userWorkstations
$ws = $user.userWorkstations + ",PC-FIN-124"
Set-ADUser jdupont -Replace @{userWorkstations=$ws}

Scénario complet pas à pas

Inventaire : exportez la liste des couples Utilisateur ‑> Poste assigné depuis votre CMDB ou Intune.
Création des groupes : un groupe global par poste (script PowerShell disponible plus bas).
Population des groupes : ajoutez l’utilisateur à son groupe‑poste.
GPO : configurez Allow log on locally avec uniquement le groupe‑poste.
Attribut userWorkstations : renseignez le même poste (redondance bienvenue).
Tests de non‑régression : vérifiez que les administrateurs locaux, les comptes de service et l’équipe support conservent l’accès.
Déploiement en production : planifiez l’activation lors d’une fenêtre de moindre activité.

Tableau de correspondance des droits

Type d’accès	Droit à autoriser	Droit à refuser	Commentaire
Console physique	Allow log on locally	Deny log on locally	Évalué dès la saisie du mot de passe.
RDP	Allow log on through Remote Desktop Services	Deny log on through Remote Desktop Services	Gérer séparément si le bureau à distance reste activé.
Partage de fichiers	Access this computer from the network	Deny access to this computer from the network	Indispensable pour les serveurs de fichiers.

Scripts de création massive

Le script ci‑dessous génère un groupe par poste et applique automatiquement la GPO via l’attribut GpoId :

# Variables
$csv = Import-Csv .\assignations.csv # Colonnes: User,Computer
$gpoName = "Restrict Interactive Logon"
# Boucle
foreach ($row in $csv) {
    $grp = "G-WS-" + $row.Computer
    if (-not (Get-ADGroup -Filter "Name -eq '$grp'")) {
        New-ADGroup -Name $grp -GroupScope Global -Path "OU=WorkstationGroups,DC=lab,DC=local"
    }
    Add-ADGroupMember -Identity $grp -Members $row.User
    # Ajout du poste comme workstation autorisée
    Set-ADUser -Identity $row.User -Add @{userWorkstations=$row.Computer}
}
# Liaison GPO automatique (exemple avec AGPM ou PowerShell GPMC)
Invoke-GPLink -Name $gpoName -Target "OU=Workstations,DC=lab,DC=local" -Enforced Yes

Journalisation & dépannage

En cas d’échec de connexion, exploitez l’Observateur d’événements local :

Log : Security ;
ID 4625 : « An account failed to log on » ;
SubStatus : 0xC000006E (workstation restriction).

Côté contrôleur de domaine, recherchez l’ID 4769 (échec de ticket service) avec l’erreur KDC_ERR_CLIENT_REVOKED.

Gestion des exceptions et maintenance

Comptes d’administration locale

Les membres du groupe local Administrators contournent toujours Allow log on locally. Utilisez Microsoft LAPS v2 pour randomiser le mot de passe admin et supprimer tout compte redondant.

Accès temporaire d’un technicien

Créez un groupe IT‑Support‑Elevated ;
Ajoutez-le à Allow log on locally et à Allow log on through RDS ;
Limitez le membre avec un TTL (Time‑To‑Live) AD (dsadd group ... -acctExpires).

Questions fréquentes

Que se passe‑t‑il en cas de changement de nom d’ordinateur ?

Le champ userWorkstations contenant l’ancien NetBIOS devient invalide ; l’utilisateur sera bloqué tant que le nouveau nom n’est pas ajouté. Automatiser la mise à jour via un script de jointure au domaine évite l’interruption.

Les ordinateurs portables hors ligne sont‑ils concernés ?

Oui. Le contrôleur a déjà émis un TGT ; la restriction userWorkstations n’est pas réévaluée hors réseau, mais le droit Allow log on locally reste en cache via la dernière GPO appliquée. Planifiez une stratégie différente pour les nomades (VPN, BitLocker, Credential Guard).

Bonnes pratiques récapitulatives

Implémentez la restriction d’abord sur un groupe pilote.
Conservez un compte « break glass » stocké hors ligne pour les urgences.
Activez l’audit des échecs d’ouverture de session dans la GPO pour repérer rapidement les postes mal configurés.
Documentez toute exception dans une base CMDB et révisez‑la trimestriellement.
Combinez avec Credential Guard, SMB Signing et un SOC pour une défense en profondeur.

Conclusion

Restreindre les comptes de domaine à leurs postes attribués n’est pas seulement une mesure de durcissement : c’est un accélérateur de conformité et un gage de sérénité opérationnelle. En alliant GPO, attribut userWorkstations, automatisation PowerShell et bonnes pratiques de gouvernance AD, vous verrouillez efficacement l’accès tout en conservant la flexibilité nécessaire pour la maintenance et le support.

Active Directory : restreindre la connexion d’un utilisateur à son poste assigné