Qui pot marcar? Auditoria de msNPAllowDialin abans de l’accés VPN

La contrasenya és correcta, el compte és al grup VPN i la connexió continua rebutjada amb un missatge que no esmenta cap política. Quan això passa en un servidor d’accés remot de Windows, el primer lloc on miro no és la regla de NPS sinó un atribut d’Active Directory que ningú obre: msNPAllowDialin, el valor que hi ha darrere la pestanya Dial-in. Té tres estats, i el tercer cedeix la decisió en silenci a un altre lloc. La majoria de vegades ningú l’ha canviat a propòsit: el compte es va clonar d’una plantilla o el va crear un script que va escriure una denegació explícita fa anys i mai no s’ha revisat.

El rebuig pot arribar abans que es llegeixi la política

Windows comprova el permís de marcatge del compte mentre construeix la decisió d’autorització, així que una denegació explícita acaba la conversa aviat. El que es veu al client és un error genèric d’autenticació, de vegades després que s’hagi completat l’intercanvi de certificats, i per això la gent passa la tarda provant credencials que mai no eren el problema.

El cas invers és igual de confús. Un compte que mai no ha tingut l’indicador pot connectar-se amb èxit perquè la política ho permetia, i després el mateix compte deixa de connectar-se quan algú edita la regla de NPS per un motiu no relacionat. Cap dels dos esdeveniments no sembla des de fora un canvi de permís de marcatge.

Tres estats, i el tercer és invisible

TRUE permet el marcatge, FALSE el rebutja, i un NULL significa que el compte hereta la resposta de la política d’accés remot o de l’autorització de NPS. La GUI mostra aquest tercer estat com a "Control access through NPS Network Policy", i es llegeix com una casella no marcada més que com una decisió.

Per això comptar usuaris permesos des de la consola no diu gairebé res. Un compte heretat pot estar permès avui i denegat demà sense que ningú el toqui, i un FALSE pot connectar-se igualment en un servidor la política del qual està configurada per ignorar les propietats de marcatge de l’usuari. Llegeix l’atribut i la política junts, o estàs auditant la meitat d’una decisió.

Exporta els indicadors sense perdre els comptes heretats

Executa l’exportació des d’un controlador de domini, o des d’una estació de treball amb el mòdul d’Active Directory, i conserva el fitxer en brut com a prova en lloc de reescriure’n un resum:

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

Un sol filtre LDAP és més fàcil d’enganxar en un registre de canvis. Aquest retorna només les autoritzacions explícites:

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

Després torna a consultar sense la clàusula de marcatge i busca comptes amb el valor absent. Aquests són els heretats, normalment el grup més gran del domini, i saltar-te’ls converteix una auditoria en una llista de les poques persones que algú va recordar configurar a mà.

Separa l’indicador de l’accés per grup i de la salut del compte

L’atribut respon una pregunta: pot marcar aquest compte. No diu res sobre si la persona encara treballa aquí, si el compte està habilitat o si hi ha una contrasenya compartida en una nota del servei d’assistència. Aparella l’exportació amb l’estat d’habilitació, la data de l’últim inici de sessió i la pertinença al grup que dona accés al servidor.

Les combinacions són el que fas servir. Un compte deshabilitat amb TRUE és soroll. Un compte habilitat amb TRUE que no ha iniciat sessió en un any és candidat a la retirada. Un compte heretat al grup VPN que ningú no sap explicar és la troballa que importa, perquè cap paràmetre no enregistra per què es va concedir.

Llegeix-ho del controlador de domini contra el qual el servidor VPN autentica realment. El retard de replicació pot mostrar un valor que el servidor ja ha substituït, i una auditoria que citi un valor obsolet del DC serà qüestionada tan bon punt algú ho torni a comprovar.

Canvia un compte i demostra que el canvi ha arribat

Per retirar l’accés, posa l’atribut a FALSE en lloc d’esborrar-lo. Esborrar-lo retorna el compte a l’herència de política, que pot tornar-lo a permetre a la connexió següent, i el canvi sembla una correcció quan en realitat és una decisió diferent:

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

La segona línia és el reinici de l’herència, mantingut a part a propòsit perquè ningú no confongui les dues operacions. Després confirma-ho des d’una segona sessió, torna a llegir l’atribut i revisa els esdeveniments de comptabilitat de NPS pel rebuig en lloc de confiar en l’actualització de la consola.

Finalment, anota quin mecanisme posseeix la decisió per a cada servei d’accés remot. Si la política ignora les propietats de marcatge de l’usuari, la condició de grup és autoritativa i l’atribut és només consultiu per a aquell servei. Dos serveis al mateix domini poden respondre legítimament de manera diferent, i el registre de revisió ho ha de dir en una línia per servei.

El resultat que sobreviu a una auditoria és curt: qui pot connectar-se, amb quin mecanisme, quan s’ha revisat, per qui. L’indicador de marcatge dona les dues primeres respostes; només la revisió de la política dona la resta.