Chi può comporre? Verifica di msNPAllowDialin prima dell’accesso VPN

La password è corretta, l’account è nel gruppo VPN e la connessione viene comunque rifiutata con un messaggio che non menziona alcun criterio. Quando accade su un server di accesso remoto Windows, il primo posto che guardo non è la regola NPS ma un attributo di Active Directory che nessuno apre: msNPAllowDialin, il valore dietro la scheda Dial-in. Ha tre stati, e il terzo affida in silenzio la decisione a un altro luogo. Il più delle volte nessuno l’ha cambiato di proposito: l’account è stato clonato da un modello, o creato da uno script che ha scritto un rifiuto esplicito anni fa e non è mai stato riesaminato.

Il rifiuto può avvenire prima che il criterio venga letto

Windows controlla l’autorizzazione alla composizione dell’account mentre costruisce la decisione di autorizzazione, quindi un rifiuto esplicito chiude la conversazione presto. Ciò che si vede sul client è un errore di autenticazione generico, a volte dopo il completamento dello scambio dei certificati, ed è per questo che le persone passano il pomeriggio a provare credenziali che non sono mai state il problema.

Il caso opposto è altrettanto confuso. Un account in cui il flag non è mai stato impostato può connettersi con successo perché il criterio lo consentiva, e poi lo stesso account smette di connettersi quando qualcuno modifica la regola NPS per un motivo non correlato. Nessuno dei due eventi appare dall’esterno come un cambiamento dell’autorizzazione alla composizione.

Tre stati, e il terzo è invisibile

TRUE consente la composizione, FALSE la rifiuta, e un NULL significa che l’account eredita la risposta dal criterio di accesso remoto o dall’autorizzazione NPS. L’interfaccia mostra questo terzo stato come "Control access through NPS Network Policy", e si legge come una casella non selezionata più che come una decisione.

Per questo contare gli utenti consentiti dalla console non dice quasi nulla. Un account ereditato può essere consentito oggi e negato domani senza che nessuno lo tocchi, e un FALSE può comunque connettersi su un server il cui criterio è configurato per ignorare le proprietà di composizione dell’utente. Leggi insieme l’attributo e il criterio, altrimenti stai verificando metà di una decisione.

Esporta i flag senza perdere gli account ereditati

Esegui l’esportazione da un controller di dominio, o da una postazione con il modulo Active Directory, e conserva il file grezzo come prova invece di riscrivere un riepilogo:

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

Un singolo filtro LDAP è più facile da incollare in un record di modifica. Questo restituisce solo le autorizzazioni esplicite:

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

Poi interroga di nuovo senza la clausola di composizione e cerca gli account il cui valore è assente. Sono quelli ereditati, di solito il gruppo più grande del dominio, e saltarli trasforma una verifica in un elenco delle poche persone che qualcuno si è ricordato di configurare a mano.

Separa il flag dall’accesso di gruppo e dalla salute dell’account

L’attributo risponde a una domanda: questo account può comporre. Non dice nulla sul fatto che la persona lavori ancora qui, che l’account sia abilitato o che una password condivisa giaccia in una nota dell’help desk. Abbina l’esportazione allo stato di abilitazione, alla data dell’ultimo accesso e all’appartenenza al gruppo che dà accesso al server.

Le combinazioni sono ciò su cui si agisce. Un account disabilitato con TRUE è rumore. Un account abilitato con TRUE che non accede da un anno è candidato alla rimozione. Un account ereditato nel gruppo VPN che nessuno sa spiegare è il risultato che conta, perché nessuna singola impostazione registra perché è stato concesso.

Leggilo dal controller di dominio contro cui il server VPN si autentica davvero. Il ritardo di replica può mostrare un valore che il server ha già sostituito, e una verifica che cita un valore DC obsoleto sarà contestata nel momento in cui qualcuno ricontrolla.

Modifica un account e dimostra che la modifica è arrivata

Per rimuovere l’accesso, imposta l’attributo su FALSE invece di cancellarlo. La cancellazione riporta l’account all’ereditarietà del criterio, che può consentirlo di nuovo alla connessione successiva, e la modifica sembra una correzione mentre in realtà è una decisione diversa:

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

La seconda riga è il ripristino dell’ereditarietà, tenuto separato di proposito perché nessuno confonda le due operazioni. Poi conferma da una seconda sessione, rileggi l’attributo e controlla gli eventi di contabilità NPS per il rifiuto invece di fidarti dell’aggiornamento della console.

Infine, annota quale meccanismo possiede la decisione per ogni servizio di accesso remoto. Se il criterio ignora le proprietà di composizione dell’utente, la condizione di gruppo è autoritativa e l’attributo è solo consultivo per quel servizio. Due servizi nello stesso dominio possono legittimamente rispondere in modo diverso, e il verbale di riesame dovrebbe dirlo in una riga per servizio.

Il risultato che sopravvive a una verifica è breve: chi può connettersi, con quale meccanismo, riesaminato quando, da chi. Il flag di composizione fornisce le prime due risposte; solo il riesame del criterio fornisce il resto.