NetExtender inicia sessão mas sem acesso: SonicWall local + LDAP

O início de sessão é bem-sucedido, o túnel sobe e nada atrás da firewall responde. Esse padrão num SonicWall SSL VPN costuma significar que a conta passou a autenticação e parou numa de duas permissões posteriores: a admissão ao serviço SSL VPN ou a permissão para chegar a um recurso. Contas locais e LDAP misturadas pioram a situação, porque os dois armazéns chegam a essas permissões por caminhos diferentes. O sintoma é idêntico do lado do cliente, e é por isso que as camadas têm de ser separadas deliberadamente.

O sintoma e as três permissões por trás

Três decisões independentes separam um nome de utilizador de um servidor acessível. O método de autenticação decide se a credencial é aceite e por que armazém. A pertença ao serviço SSL VPN decide se essa identidade pode usar o SSL VPN. A lista de acesso VPN decide quais destinos privados a sessão pode alcançar. Passar uma não diz nada sobre as duas seguintes.

Um utilizador que se autentica mas não está no grupo do serviço SSL VPN vê uma ligação que se estabelece e depois não transporta nada, e o registo da firewall mostra um início de sessão aceite em vez de uma falha. É o caso que vale a pena reconhecer depressa, porque a correção é uma pertença a um grupo e não uma reposição da palavra-passe.

Um utilizador admitido mas sem recursos vê uma sessão que liga e não encaminha para nenhum sítio útil. Ambos parecem um túnel avariado do help desk, e ambos são configuração e não conectividade.

O campo de domínio não é o diretório

O NetExtender pede um domínio, e esse campo não é uma base de pesquisa para o Active Directory. Na disposição predefinida o campo tem de ser igual ao domínio de utilizador SSL VPN configurado na firewall, e o valor predefinido documentado é LocalDomain. A comparação distingue maiúsculas de minúsculas, por isso um valor escrito com outra capitalização falha mesmo quando a conta está correta.

Com a partição de autenticação configurada, os nomes de partição selecionam o contexto de autenticação externo, e o valor predefinido configurado mantém o seu próprio papel. Em qualquer das duas disposições, a etiqueta de domínio do lado do cliente não é reencaminhada para LDAP ou RADIUS como parte do nome de utilizador, por isso não pode orientar uma pesquisa no diretório.

Mantenha as três cadeias separadas nas suas notas: o sufixo DNS da empresa, a base de pesquisa LDAP e a etiqueta de domínio do NetExtender. Parecem-se e nenhuma substitui outra. Copie o valor do operador para esta instalação e não um valor de uma publicação de fórum sobre outra versão de firmware.

A admissão e o acesso a recursos são permissões separadas

As contas locais precisam de pertencer ao grupo do serviço SSL VPN antes de o serviço as aceitar. As contas de diretório chegam ao mesmo grupo através do fluxo de trabalho de mapeamento de grupos suportado, o que significa que a relação de grupo LDAP tem de ser configurada e depois verificada como pertença efetiva em vez de assumida do lado do diretório.

O acesso a recursos vem a seguir, em Acesso VPN no utilizador ou no grupo. Conceda as sub-redes e os serviços concretos de que a função precisa, e resista ao atalho de conceder toda a LAN porque é necessária uma aplicação. As rotas da sessão, as regras de acesso e as permissões do serviço de destino têm todas de concordar com esse âmbito.

Uma rota no cliente torna um destino selecionável e não o autoriza. A pertença ao grupo SSL VPN também não torna a conta administradora da firewall, e não deve ser tratada como uma concessão geral de privilégios.

Duas identidades, quatro verificações cada

Teste com uma conta local e uma conta de diretório, ambas com autorização estreita e ambas documentadas como contas de teste. Para cada uma, registe a origem de autenticação que aceitou o início de sessão, os grupos efetivos, o acesso a recursos atribuído e uma operação de aplicação permitida. Quatro verificações, dois armazéns e um resultado escrito para cada combinação.

Depois teste os casos negativos: um recurso a que a conta não deve chegar e uma conta que deve ser rejeitada de imediato. Um desenho que só prova o caminho positivo tende a deixar uma segunda entrada aberta, sobretudo quando o mesmo nome de utilizador curto existe nos dois armazéns. Desative a conta de diretório e confirme que a local não continua a funcionar em silêncio.

Reveja os nomes duplicados como parte da implementação e não depois de um incidente. A mesma pessoa em dois armazéns é ao mesmo tempo uma conveniência para o suporte e um problema de auditoria, e a firewall autenticará de bom grado aquela que configurou.

Mantenha estreito o caminho de recuperação

Preserve a política MFA para cada classe de conta em vez de isentar as contas locais dela. Se as contas locais oferecerem um caminho de recuperação aprovado para uma falha do diretório, limite esse caminho a administradores nomeados e opere-o deliberadamente, porque uma conta de emergência local para cada funcionário é um segundo sistema de autenticação com supervisão mais fraca.

Escreva o domínio do cliente, a origem de autenticação e o acesso efetivo no mesmo registo. O próximo administrador pode então reproduzir um desenho de contas mistas que funcione em vez de experimentar cadeias de domínio até um início de sessão resultar.