Quem pode discar? Auditoria do msNPAllowDialin antes do acesso VPN

A palavra-passe está correta, a conta está no grupo VPN e a ligação continua a ser recusada com uma mensagem que não menciona qualquer política. Quando isto acontece num servidor de acesso remoto Windows, o primeiro sítio onde olho não é a regra do NPS mas um atributo do Active Directory que ninguém abre: msNPAllowDialin, o valor por trás do separador Dial-in. Tem três estados, e o terceiro entrega a decisão em silêncio a outro lugar. Na maioria das vezes ninguém o alterou de propósito: a conta foi clonada de um modelo ou criada por um script que escreveu uma recusa explícita há anos e nunca foi revisto.

A recusa pode acontecer antes de a política ser lida

O Windows verifica a permissão de marcação da conta enquanto constrói a decisão de autorização, por isso uma recusa explícita termina a conversa cedo. O que se vê no cliente é uma falha de autenticação genérica, por vezes depois de concluída a troca de certificados, e é por isso que as pessoas passam a tarde a testar credenciais que nunca foram o problema.

O caso inverso é igualmente confuso. Uma conta onde o sinalizador nunca foi definido pode ligar-se com sucesso porque a política o permitia, e depois a mesma conta deixa de se ligar quando alguém edita a regra do NPS por um motivo não relacionado. Nenhum dos dois acontecimentos parece, visto de fora, uma alteração da permissão de marcação.

Três estados, e o terceiro é invisível

TRUE permite a marcação, FALSE recusa-a, e um NULL significa que a conta herda a resposta da política de acesso remoto ou da autorização do NPS. A interface mostra esse terceiro estado como "Control access through NPS Network Policy", e lê-se como uma caixa não marcada em vez de uma decisão.

Por isso contar utilizadores permitidos a partir da consola não diz quase nada. Uma conta herdada pode estar permitida hoje e recusada amanhã sem que ninguém lhe toque, e uma FALSE pode continuar a ligar-se num servidor cuja política está configurada para ignorar as propriedades de marcação do utilizador. Leia o atributo e a política em conjunto, ou está a auditar metade de uma decisão.

Exporte os sinalizadores sem perder as contas herdadas

Execute a exportação a partir de um controlador de domínio, ou de uma estação de trabalho com o módulo Active Directory, e guarde o ficheiro em bruto como prova em vez de reescrever um resumo:

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

Um único filtro LDAP é mais fácil de colar num registo de alterações. Este devolve apenas as autorizações explícitas:

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

Depois consulte novamente sem a cláusula de marcação e procure contas cujo valor esteja ausente. Essas são as herdadas, normalmente o maior grupo do domínio, e ignorá-las transforma uma auditoria numa lista das poucas pessoas que alguém se lembrou de configurar à mão.

Separe o sinalizador do acesso por grupo e da saúde da conta

O atributo responde a uma pergunta: esta conta pode marcar. Não diz nada sobre se a pessoa ainda trabalha aqui, se a conta está ativa ou se há uma palavra-passe partilhada numa nota do serviço de apoio. Emparelhe a exportação com o estado de ativação, a data do último início de sessão e a pertença ao grupo que dá acesso ao servidor.

As combinações são o que se deve tratar. Uma conta desativada com TRUE é ruído. Uma conta ativa com TRUE que não inicia sessão há um ano é candidata a remoção. Uma conta herdada no grupo VPN que ninguém sabe explicar é o achado que importa, porque nenhuma definição isolada regista por que motivo foi concedida.

Leia-o a partir do controlador de domínio contra o qual o servidor VPN se autentica realmente. O atraso de replicação pode mostrar um valor que o servidor já substituiu, e uma auditoria que cite um valor de DC desatualizado será contestada no momento em que alguém verificar de novo.

Altere uma conta e prove que a alteração chegou

Para retirar o acesso, defina o atributo como FALSE em vez de o limpar. Limpar devolve a conta à herança de política, que pode voltar a permiti-la na ligação seguinte, e a alteração parece uma correção quando na realidade é uma decisão diferente:

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

A segunda linha é o reinício da herança, mantido à parte de propósito para que ninguém confunda as duas operações. Depois confirme a partir de uma segunda sessão, releia o atributo e verifique os eventos de contabilidade do NPS para a recusa em vez de confiar na atualização da consola.

Por fim, registe qual mecanismo é dono da decisão para cada serviço de acesso remoto. Se a política ignora as propriedades de marcação do utilizador, a condição de grupo é autoritária e o atributo é apenas consultivo para esse serviço. Dois serviços no mesmo domínio podem responder legitimamente de forma diferente, e o registo de revisão deve dizê-lo numa linha por serviço.

O resultado que sobrevive a uma auditoria é curto: quem pode ligar-se, sob que mecanismo, revisto quando, por quem. O sinalizador de marcação fornece as duas primeiras respostas; só a revisão da política fornece o resto.