Adicionar um usuário a um grupo VPN não concede acesso por si só

Você colocou a conta no grupo certo, o login funcionou e a conexão continua recusada — ou conecta e não alcança nada útil. O reflexo habitual é adicionar o usuário a mais grupos até que algo ceda, e é assim que as organizações acabam concedendo muito mais do que o chamado pedia. A associação ao grupo é uma entrada numa decisão de autorização, nunca a decisão em si: um gateway reúne algumas informações sobre a sessão, compara-as com uma política ordenada e só então decide o que essa sessão pode alcançar. Se outra condição falhou, editar o grupo não muda nada além da sua exposição. Veja como a decisão é realmente montada, onde a associação deixa de bastar e a verificação que mostra qual falha você está vendo.

Associação ao grupo é uma condição, não uma permissão

No RADIUS, o grupo chega como um atributo de autorização, e atributos descrevem a sessão em vez de concedê-la. O servidor responde com Access-Accept ou Access-Reject; na aceitação, pode anexar Filter-Id, Class ou os atributos de túnel da RFC 2868, e o equipamento de rede na outra ponta interpreta isso como o fornecedor decidiu. Nada no protocolo mapeia um grupo para acesso total. Esse mapeamento é escrito por quem configurou a política no gateway ou no servidor de acesso à rede, e pode ser tão estreito quanto um único host.

É por isso que um mesmo nome de grupo se comporta de forma diferente em dois sistemas. O Microsoft NPS monta políticas de rede a partir de condições, restrições e configurações e as avalia numa ordem definida. O OpenVPN Access Server tem seu próprio modelo de grupos e regras de acesso, enquanto um servidor OpenVPN da comunidade costuma delegar toda a questão a um script client-connect ou a um arquivo client-config-dir. Cada um consome um grupo; nenhum compartilha a lógica de precedência do outro. Um conjunto de regras copiado entre eles não prova nada sobre aquele que você está depurando.

A regra que correspondeu decide, não o grupo que você esperava

A maioria dos mecanismos para na primeira política que corresponde, ou na mais específica. Se a política 3 nega e a política 7 permite, uma sessão pode falhar sem nunca chegar à regra que a deixaria passar. A ordenação é uma configuração real no NPS e na maioria dos produtos de controle de acesso à rede, e ela se desloca quando políticas são adicionadas ao longo dos anos. Alguém sobe uma política de negação para o topo para conter um incidente não relacionado, e um grupo que funcionava no trimestre passado deixa de funcionar.

Condições que acompanham o grupo são a outra metade do problema. Postura do dispositivo, método de autenticação, conclusão de MFA, rede de origem, assunto do certificado ou uma janela de horário podem estar todos na mesma política. Quando uma delas não é cumprida, a política não corresponde, o mecanismo passa adiante e aplica-se uma negação padrão. Do ponto de vista do usuário, isso parece o grupo sendo ignorado; do ponto de vista do mecanismo, o grupo nunca foi consultado.

Detalhes do diretório produzem a mesma ilusão. Uma política que compara associação a grupos do Windows lê os SIDs no token do usuário, e só grupos de segurança são enumerados ali — um grupo de distribuição nunca aparece. O grupo primário de um usuário é carregado em seu próprio campo, e não na lista enumerada, então uma política fixada nesse grupo pode falhar silenciosamente. Grupos renomeados e SIDs entre domínios acrescentam etapas de tradução que falham em silêncio quando a relação de confiança é unidirecional.

Leia o registro de aceitação ou negação antes de mexer num grupo

Faça uma pergunta primeiro: o pedido chegou à etapa de autorização? No NPS, a resposta já está no log de eventos, onde 6272 registra um acesso concedido, 6273 uma negação, e 6274 um pedido que o servidor descartou antes de avaliar a política. Esses três números dividem o problema em três investigações diferentes, e só uma delas é sobre grupos.

Quando o log está fora de alcance, consulte o servidor diretamente e leia o que ele retorna. Uma resposta que não traz Filter-Id nem atributos de túnel diz que o servidor trata a sessão como trivial e que o gateway está aplicando regras próprias. Uma resposta que traz atributos que o ponto de aplicação não implementa é outra falha: a autorização passou e o dispositivo que deveria agir sobre ela ignorou o resultado.

radtest alice 'password' 10.0.0.5 0 testing123

Compare os atributos retornados com os que o gateway documenta, não com o que o nome do grupo sugere. Essa comparação costuma separar um problema de política de um problema de aplicação antes que alguém edite um grupo.

Uma mudança de grupo não é retroativa

Atributos de autorização são retornados uma vez, quando a sessão é autenticada. O gateway os guarda na sessão e não relê o diretório a cada pacote, e é exatamente por isso que uma sessão estabelecida continua funcionando depois que você remove alguém de um grupo. É também por isso que uma sessão nova pode falhar enquanto uma antiga ainda corre, e por que dois usuários com listas de grupos idênticas podem acabar com resultados diferentes.

Para fazer uma mudança valer, você precisa de uma nova decisão de autorização, não apenas de chaves novas. Onde o servidor suporta autorização dinâmica RFC 5176, um Disconnect-Request ou CoA-Request para UDP 3799 força a sessão a ser reavaliada; caso contrário, desconecte o cliente e deixe-o reconectar. A renegociação renova as chaves do túnel e normalmente deixa o resultado da autorização intacto, então tratá-la como atualização de permissões produz resultados de teste contraditórios.

Corrija a condição, não o grupo

Quando você sabe qual política disparou, o reparo costuma ser pequeno: reordenar uma negação que ofusca a permissão pretendida, acrescentar a condição de dispositivo ou MFA que falta à política que você queria que combinasse, ou escrever uma regra estreita para o único recurso em vez de promover o usuário para um grupo que carrega outros dez. Ampliar a associação para fechar um chamado é a versão cara da mesma correção, e é assim que um atalho de suporte vira uma exceção permanente que ninguém revisa.

Um ciclo curto mantém a mudança honesta:

• Reproduza a negação com a conta original e anote o ID do evento antes de mudar qualquer coisa.
• Mude um objeto — uma ordem de política, uma única condição ou um grupo — e registre qual foi.
• Abra uma sessão nova, confirme que a concessão aparece no log e confirme que o recurso realmente abre.
• Teste um usuário que ainda deve ser recusado, para que a correção não tenha ampliado a política por acidente.

Se a concessão está correta e o recurso ainda não abre, o problema mudou para roteamento ou resolução de nomes no momento em que a autorização passou. Mantenha essas duas falhas separadas e o próximo chamado leva minutos em vez de uma tarde.