¿Quién puede marcar? Auditoría de msNPAllowDialin antes del acceso VPN

La contraseña es correcta, la cuenta está en el grupo VPN y la conexión sigue rechazándose con un mensaje que no menciona ninguna directiva. Cuando eso ocurre en un servidor de acceso remoto de Windows, el primer sitio donde miro no es la regla de NPS sino un atributo de Active Directory que nadie abre: msNPAllowDialin, el valor que hay detrás de la pestaña Dial-in. Tiene tres estados, y el tercero cede la decisión en silencio a otro lugar. La mayoría de las veces nadie lo cambió a propósito: la cuenta se clonó de una plantilla o la creó un script que escribió una denegación explícita hace años y nunca se revisó.

El rechazo puede ocurrir antes de que se lea la directiva

Windows comprueba el permiso de marcado de la cuenta mientras construye la decisión de autorización, así que una denegación explícita termina la conversación pronto. Lo que se ve en el cliente es un error genérico de autenticación, a veces después de completarse el intercambio de certificados, y por eso la gente pasa la tarde probando credenciales que nunca fueron el problema.

El caso inverso es igual de confuso. Una cuenta en la que nunca se fijó el indicador puede conectarse con éxito porque la directiva lo permitía, y luego la misma cuenta deja de conectarse cuando alguien edita la regla de NPS por un motivo no relacionado. Ninguno de los dos sucesos parece desde fuera un cambio del permiso de marcado.

Tres estados, y el tercero es invisible

TRUE permite el marcado, FALSE lo rechaza, y un NULL significa que la cuenta hereda su respuesta de la directiva de acceso remoto o de la autorización de NPS. La GUI muestra ese tercer estado como "Control access through NPS Network Policy", y se lee como una casilla sin marcar más que como una decisión.

Por eso contar usuarios permitidos desde la consola no dice casi nada. Una cuenta heredada puede estar permitida hoy y denegada mañana sin que nadie la toque, y una FALSE puede seguir conectándose en un servidor cuya directiva está configurada para ignorar las propiedades de marcado del usuario. Lea el atributo y la directiva juntos, o estará auditando la mitad de una decisión.

Exporte los indicadores sin perder las cuentas heredadas

Ejecute la exportación desde un controlador de dominio, o desde una estación de trabajo con el módulo de Active Directory, y conserve el archivo sin procesar como prueba en lugar de reescribir un resumen:

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

Un solo filtro LDAP es más fácil de pegar en un registro de cambios. Este devuelve solo las autorizaciones explícitas:

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

Luego consulte de nuevo sin la cláusula de marcado y busque cuentas cuyo valor esté ausente. Esas son las heredadas, normalmente el grupo más grande del dominio, y omitirlas convierte una auditoría en una lista de las pocas personas que alguien recordó configurar a mano.

Separe el indicador del acceso por grupo y de la salud de la cuenta

El atributo responde a una pregunta: si esta cuenta puede marcar. No dice nada sobre si la persona sigue trabajando aquí, si la cuenta está habilitada o si hay una contraseña compartida en una nota del servicio de asistencia. Empareje la exportación con el estado de habilitación, la fecha del último inicio de sesión y la pertenencia al grupo que da acceso al servidor.

Las combinaciones son lo que se debe atender. Una cuenta deshabilitada con TRUE es ruido. Una cuenta habilitada con TRUE que no ha iniciado sesión en un año es candidata a la retirada. Una cuenta heredada en el grupo VPN que nadie sabe explicar es el hallazgo que importa, porque ningún ajuste aislado registra por qué se concedió.

Léalo desde el controlador de dominio contra el que el servidor VPN autentica realmente. El retraso de replicación puede mostrar un valor que el servidor ya ha sustituido, y una auditoría que cite un valor obsoleto del DC será cuestionada en cuanto alguien vuelva a comprobarlo.

Cambie una cuenta y demuestre que el cambio llegó

Para retirar el acceso, ponga el atributo en FALSE en lugar de borrarlo. Borrarlo devuelve la cuenta a la herencia de directiva, que puede volver a permitirla en la siguiente conexión, y el cambio parece una corrección cuando en realidad es una decisión distinta:

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

La segunda línea es el reinicio de la herencia, mantenido aparte a propósito para que nadie confunda las dos operaciones. Después confirme desde una segunda sesión, vuelva a leer el atributo y revise los eventos de contabilidad de NPS para el rechazo en lugar de fiarse de la actualización de la consola.

Por último, anote qué mecanismo posee la decisión para cada servicio de acceso remoto. Si la directiva ignora las propiedades de marcado del usuario, la condición de grupo es autoritativa y el atributo es solo consultivo para ese servicio. Dos servicios en el mismo dominio pueden responder legítimamente de forma distinta, y el registro de revisión debería decirlo en una línea por servicio.

El resultado que sobrevive a una auditoría es corto: quién puede conectarse, con qué mecanismo, cuándo se revisó y por quién. El indicador de marcado aporta las dos primeras respuestas; solo la revisión de la directiva aporta el resto.