Avant de blâmer le code, regarde le groupe Windows

Je viens de perdre beaucoup trop de temps sur un bug qui n’était pas dans mon code. Un module apparaissait pour une personne et disparaissait pour sa voisine. Même poste, même réseau, même version de l’application. La différence se trouvait finalement dans les groupes Windows des deux comptes.

C’est ma première vraie rencontre avec Active Directory comme dépendance d’une application, pas seulement comme écran de connexion du matin. Pour comprendre le comportement, il faut suivre l’identité plus loin que le nom affiché.

Quand une personne ouvre une session dans un domaine Windows, son poste trouve un contrôleur de domaine grâce au DNS. Le contrôleur vérifie son identité, généralement avec Kerberos dans un domaine Windows 2000, et fournit des preuves qui permettront d’accéder à d’autres services sans renvoyer le mot de passe à chacun. Windows construit ensuite un jeton d’accès pour la session. Ce jeton contient le SID du compte — un identifiant stable — ainsi que les SID de ses groupes et certains privilèges.

Lorsqu’un programme ouvre un fichier, appelle SQL Server avec la sécurité intégrée ou vérifie un rôle, Windows compare ces SID aux listes de contrôle d’accès de la ressource. Le nom DOMAINE\GroupeCompta est pratique pour nous; la décision réelle repose sur les identifiants contenus dans le jeton.

Réutiliser l’identité déjà là

Une application .NET peut consulter l’identité de la session courante :

Imports System.Security.Principal

Public Function EstDansGroupe(nomGroupe As String) As Boolean
    Dim identite As WindowsIdentity = WindowsIdentity.GetCurrent()
    Dim principal As New WindowsPrincipal(identite)
    Return principal.IsInRole("DOMAINE\" & nomGroupe)
End Function

Puis le formulaire adapte ce qu’il montre :

If Not EstDansGroupe("GroupeCompta") Then
    btnComptabilite.Enabled = False
End If

Ça évite un deuxième fichier de mots de passe et rend l’écran plus clair. Mais le bouton désactivé n’est pas une barrière de sécurité. Une autre fenêtre, un appel direct ou une future version du client pourrait atteindre la même opération. La couche qui effectue l’action sensible doit vérifier l’autorisation elle aussi, et SQL Server ou le système de fichiers doit accorder seulement les droits nécessaires au compte qui s’y présente.

Le détail qui m’a fait perdre du temps est le cycle de vie du jeton. Ajouter une personne au groupe dans Active Directory modifie l’annuaire, pas le jeton déjà créé sur son poste. Fermer et rouvrir l’application ne suffit pas toujours; il faut souvent fermer la session Windows pour obtenir un nouveau jeton. Les groupes imbriqués et la réplication entre contrôleurs de domaine peuvent ajouter un autre délai. Deux postes peuvent donc voir temporairement des réponses différentes sans que le code ait changé.

Il faut aussi prévoir l’indisponibilité du domaine. Windows peut permettre une ouverture de session avec des informations mises en cache quand un portable ne rejoint pas le contrôleur, mais une recherche LDAP en direct peut échouer. Pour une action critique, « je ne peux pas vérifier » ne devrait pas devenir automatiquement « oui ». L’application doit distinguer un refus réel d’une infrastructure inaccessible et donner un message utile sans révéler la liste complète des groupes.

Je ne veux pas coder une permission par personne. Je préfère des groupes qui décrivent un rôle métier, un responsable clairement chargé de leurs membres et une vérification côté opération. Une entrée de journal peut noter le SID, l’action et le résultat, mais pas le mot de passe ni tout le jeton.

Ma liste de dépannage devient donc concrète : confirmer le compte réellement utilisé, inspecter ses groupes, savoir quel contrôleur a reçu le changement, recréer la session, puis tester la ressource finale. La prochaine fois qu’un module disparaît pour une seule personne, je vais suivre le jeton avant de démonter le formulaire.

Mise à jour de 2026

L’Active Directory dont il est question ici est le service d’annuaire local de Windows Server, aujourd’hui désigné plus précisément comme Active Directory Domain Services. Il existe toujours et n’a pas été renommé. C’est Azure Active Directory, le service cloud distinct, qui a pris le nom Microsoft Entra ID en 2023. Microsoft explique cette distinction dans sa foire aux questions sur le changement de nom.