Qui peut composer ? Auditer msNPAllowDialin avant l’accès VPN

Le mot de passe est correct, le compte est dans le groupe VPN, et la connexion est pourtant refusée avec un message qui ne mentionne aucune stratégie. Quand cela arrive sur un serveur d’accès à distance Windows, le premier endroit où je regarde n’est pas la règle NPS mais un attribut Active Directory que personne n’ouvre : msNPAllowDialin, la valeur derrière l’onglet Dial-in. Il a trois états, et le troisième confie discrètement la décision à ailleurs. La plupart du temps, personne ne l’a modifié exprès : le compte a été cloné depuis un modèle, ou créé par un script qui a écrit un refus explicite il y a des années et n’a jamais été revu.

Le refus peut survenir avant la lecture de la stratégie

Windows vérifie l’autorisation de composition du compte pendant qu’il construit la décision d’autorisation, donc un refus explicite met fin à la conversation tôt. Ce que l’on voit sur le client est un échec d’authentification générique, parfois après la fin de l’échange de certificats, et c’est pourquoi les gens passent l’après-midi à tester des identifiants qui n’ont jamais été le problème.

Le cas inverse est tout aussi déroutant. Un compte dont l’indicateur n’a jamais été défini peut se connecter avec succès parce que la stratégie l’autorisait, puis le même compte cesse de se connecter quand quelqu’un modifie la règle NPS pour une raison sans rapport. Aucun des deux événements ne ressemble de l’extérieur à un changement d’autorisation de composition.

Trois états, et le troisième est invisible

TRUE autorise la composition, FALSE la refuse, et un NULL signifie que le compte hérite de sa réponse de la stratégie d’accès à distance ou de l’autorisation NPS. L’interface affiche ce troisième état sous la forme "Control access through NPS Network Policy", et il se lit comme une case non cochée plutôt que comme une décision.

C’est pourquoi compter les utilisateurs autorisés depuis la console ne dit presque rien. Un compte hérité peut être autorisé aujourd’hui et refusé demain sans que le compte soit touché, et un FALSE peut encore se connecter sur un serveur dont la stratégie est configurée pour ignorer les propriétés de composition de l’utilisateur. Lisez l’attribut et la stratégie ensemble, sinon vous auditez la moitié d’une décision.

Exportez les indicateurs sans perdre les comptes hérités

Lancez l’export depuis un contrôleur de domaine, ou depuis un poste de travail disposant du module Active Directory, et conservez le fichier brut comme preuve au lieu de retaper un résumé :

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

Un seul filtre LDAP est plus facile à coller dans un enregistrement de changement. Celui-ci ne renvoie que les autorisations explicites :

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

Interrogez ensuite à nouveau sans la clause de composition et cherchez les comptes dont la valeur est absente. Ce sont les comptes hérités, généralement le plus grand groupe du domaine, et les ignorer transforme un audit en liste des quelques personnes que quelqu’un a pensé à configurer à la main.

Séparez l’indicateur de l’accès par groupe et de la santé du compte

L’attribut répond à une question : ce compte peut-il composer. Il ne dit rien sur le fait que la personne travaille encore ici, que le compte est activé ou qu’un mot de passe partagé traîne dans une note du service d’assistance. Associez l’export à l’état d’activation, à la date de dernière ouverture de session et à l’appartenance au groupe qui donne accès au serveur.

Ce sont les combinaisons qui comptent. Un compte désactivé avec TRUE est du bruit. Un compte activé avec TRUE qui ne s’est pas connecté depuis un an est candidat au retrait. Un compte hérité dans le groupe VPN que personne ne peut expliquer est la constatation qui compte, car aucun réglage isolé n’enregistre pourquoi il a été accordé.

Lisez-le depuis le contrôleur de domaine contre lequel le serveur VPN s’authentifie réellement. Le retard de réplication peut montrer une valeur que le serveur a déjà remplacée, et un audit qui cite une valeur de DC obsolète sera contesté dès que quelqu’un vérifiera à nouveau.

Modifiez un compte et prouvez que le changement a bien été appliqué

Pour retirer l’accès, mettez l’attribut à FALSE au lieu de l’effacer. L’effacement renvoie le compte à l’héritage de stratégie, ce qui peut l’autoriser de nouveau à la connexion suivante, et le changement ressemble à un correctif alors qu’il s’agit en réalité d’une décision différente :

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

La deuxième ligne est la réinitialisation de l’héritage, volontairement séparée pour que personne ne confonde les deux opérations. Confirmez ensuite depuis une seconde session, relisez l’attribut et vérifiez les événements de comptabilité NPS pour le refus au lieu de vous fier au rafraîchissement de la console.

Enfin, notez quel mécanisme détient la décision pour chaque service d’accès à distance. Si la stratégie ignore les propriétés de composition de l’utilisateur, la condition de groupe fait autorité et l’attribut n’est qu’indicatif pour ce service. Deux services du même domaine peuvent légitimement répondre différemment, et le compte rendu de revue devrait le dire en une ligne par service.

Le résultat qui survit à un audit est court : qui peut se connecter, selon quel mécanisme, vérifié quand, par qui. L’indicateur de composition fournit les deux premières réponses ; seule la revue de la stratégie fournit le reste.