Quen pode marcar? Auditoría de msNPAllowDialin antes do acceso VPN

O contrasinal é correcto, a conta está no grupo VPN e a conexión segue a ser rexeitada cunha mensaxe que non menciona ningunha política. Cando iso ocorre nun servidor de acceso remoto de Windows, o primeiro lugar onde miro non é a regra de NPS senón un atributo de Active Directory que ninguén abre: msNPAllowDialin, o valor que hai detrás da pestana Dial-in. Ten tres estados, e o terceiro cede a decisión en silencio a outro lugar. A maioría das veces ninguén o cambiou a propósito: a conta clonouse dun modelo ou creouna un script que escribiu unha denegación explícita hai anos e nunca se revisou.

O rexeitamento pode ocorrer antes de que se lea a política

Windows comproba o permiso de marcado da conta mentres constrúe a decisión de autorización, así que unha denegación explícita remata a conversación cedo. O que se ve no cliente é un erro xenérico de autenticación, ás veces despois de completarse o intercambio de certificados, e por iso a xente pasa a tarde probando credenciais que nunca foron o problema.

O caso inverso é igual de confuso. Unha conta na que nunca se fixou o indicador pode conectarse con éxito porque a política o permitía, e despois a mesma conta deixa de conectarse cando alguén edita a regra de NPS por un motivo non relacionado. Ningún dos dous acontecementos parece desde fóra un cambio do permiso de marcado.

Tres estados, e o terceiro é invisible

TRUE permite o marcado, FALSE rexeitao, e un NULL significa que a conta herda a súa resposta da política de acceso remoto ou da autorización de NPS. A GUI mostra ese terceiro estado como "Control access through NPS Network Policy", e lese como unha caixa sen marcar máis que como unha decisión.

Por iso contar usuarios permitidos desde a consola non di case nada. Unha conta herdada pode estar permitida hoxe e denegada mañá sen que ninguén a toque, e unha FALSE pode seguir conectándose nun servidor cuxa política está configurada para ignorar as propiedades de marcado do usuario. Lea o atributo e a política xuntos, ou estará auditando a metade dunha decisión.

Exporte os indicadores sen perder as contas herdadas

Execute a exportación desde un controlador de dominio, ou desde unha estación de traballo co módulo de Active Directory, e conserve o ficheiro sen procesar como proba en lugar de reescribir un resumo:

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

Un só filtro LDAP é máis fácil de pegar nun rexistro de cambios. Este devolve só as autorizacións explícitas:

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

Logo consulte de novo sen a cláusula de marcado e busque contas cuxo valor estea ausente. Esas son as herdadas, normalmente o grupo máis grande do dominio, e omitilas converte unha auditoría nunha lista das poucas persoas que alguén lembrou configurar a man.

Separe o indicador do acceso por grupo e da saúde da conta

O atributo responde a unha pregunta: se esta conta pode marcar. Non di nada sobre se a persoa segue traballando aquí, se a conta está habilitada ou se hai un contrasinal compartido nunha nota do servizo de asistencia. Emparexe a exportación co estado de habilitación, a data do último inicio de sesión e a pertenza ao grupo que dá acceso ao servidor.

As combinacións son o que hai que atender. Unha conta deshabilitada con TRUE é ruído. Unha conta habilitada con TRUE que non iniciou sesión nun ano é candidata á retirada. Unha conta herdada no grupo VPN que ninguén sabe explicar é o achado que importa, porque ningún axuste illado rexistra por que se concedeu.

Léao desde o controlador de dominio contra o que o servidor VPN autentica realmente. O atraso de replicación pode mostrar un valor que o servidor xa substituíu, e unha auditoría que cite un valor obsoleto do DC será cuestionada en canto alguén volva comprobalo.

Cambie unha conta e demostre que o cambio chegou

Para retirar o acceso, poña o atributo en FALSE en lugar de borralo. Borralo devolve a conta á herdanza de política, que pode volver permitila na seguinte conexión, e o cambio parece unha corrección cando en realidade é unha decisión distinta:

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

A segunda liña é o reinicio da herdanza, mantido á parte a propósito para que ninguén confunda as dúas operacións. Despois confirme desde unha segunda sesión, volva ler o atributo e revise os eventos de contabilidade de NPS para o rexeitamento en lugar de fiarse da actualización da consola.

Por último, anote que mecanismo posúe a decisión para cada servizo de acceso remoto. Se a política ignora as propiedades de marcado do usuario, a condición de grupo é autoritativa e o atributo é só consultivo para ese servizo. Dous servizos no mesmo dominio poden responder lexitimamente de forma distinta, e o rexistro de revisión debería dicilo nunha liña por servizo.

O resultado que sobrevive a unha auditoría é curto: quen pode conectarse, con que mecanismo, cando se revisou e por quen. O indicador de marcado achega as dúas primeiras respostas; só a revisión da política achega o resto.