A autenticação LDAP do OpenVPN funciona mas a verificação de grupo falha: onde olhar

A autenticação pode passar enquanto a verificação de grupo rejeita todos. Revise o bloco Authorization, o atributo de associação e o endpoint do diretório, um de cada vez.

As credenciais passam, o túnel começa a subir e então a sessão falha com uma mensagem sobre o grupo e não sobre a palavra-passe. Essa combinação coloca a falha na segunda metade do trabalho do plug-in LDAP: a ligação e a verificação da palavra-passe tiveram sucesso, e a decisão de associação que se segue não. As duas metades leem da mesma estrofe de configuração, por isso uma correção num ponto pode deixar a outra intacta. Comece pela linha de registo que nomeia o passo, não pela conta com que está a testar por acaso.

Trate a rejeição como uma resposta de autorização

O plug-in realiza uma ligação de serviço, procura a conta, verifica a palavra-passe fornecida e depois pergunta se essa conta pertence a um grupo permitido. São quatro operações distintas, e só a última diz respeito a grupos. Por isso uma rejeição que chega depois de uma ligação bem-sucedida nada diz sobre a palavra-passe, mesmo quando o cliente mostra um erro genérico de autenticação. Subir o nível de registo do plug-in antes de alterar a configuração é o que separa as quatro na saída.

Procure a própria avaliação do grupo. Quando não aparece nenhuma consulta de grupo, o bloco de autorização não é alcançado, o que normalmente significa que uma diretiva está fora da estrofe que a possui ou que falta uma opção obrigatória. Quando a consulta aparece e não devolve nada, o endpoint ou o filtro respondem a uma pergunta diferente da que pretendia.

Decida se a associação vive no filtro ou num bloco de grupo

Há duas formas suportadas, e misturá-las é a maneira como uma configuração que funcionava deixa de funcionar. A primeira empurra a associação para a pesquisa de utilizadores pedindo um atributo no objeto de utilizador; a segunda deixa a pesquisa de utilizadores em paz e faz com que o plug-in procure o objeto de grupo depois. Escolha uma por implementação e anote qual escolheu.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

Com essa forma o filtro decide tudo, por isso RequireGroup tem de ser false ou o plug-in vai procurar um objeto de grupo que o filtro nunca mencionou. O atributo no filtro tem de existir no objeto de utilizador e estar preenchido, o que não está garantido quando os grupos estão aninhados.

A outra forma mantém a pesquisa simples e acrescenta uma procura de grupo depois. O objeto de grupo é nomeado explicitamente, e o plug-in compara o utilizador com os membros que o diretório devolve para ele. Nada muda no filtro de utilizador, o que torna esta forma mais fácil de auditar quando outra equipa gere o grupo.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

O ponto cego é comum: uma comparação simples de associação não expande grupos aninhados, por isso uma conta cujo acesso chega através de um grupo pai falha enquanto a consola continua a mostrar a associação. O Active Directory expõe member no grupo, outros esquemas usam uniqueMember, e apontar para o atributo errado devolve um resultado vazio em vez de um erro.

Escolha um endpoint que contenha o objeto de grupo

O URL decide a que diretório o plug-in pergunta, e um controlador de domínio na porta 389 só responde pelo seu próprio contexto de nomes. Um catálogo global na porta 3268 responde por toda a floresta, só de leitura e com um conjunto parcial de atributos. Quando as contas estão num domínio e o grupo VPN noutro, uma consulta de um só domínio pode encontrar o utilizador e ainda assim perder a associação. É o caso em que mover o URL para a porta do catálogo resolve a rejeição, e é também o caso em que as pessoas generalizam demasiado.

O conjunto parcial de atributos é o limite: não se pode filtrar por um atributo que o catálogo não contém, por isso a mesma alteração pode fazer uma implementação funcionar e outra devolver nada. Confirme o que o endpoint devolve realmente para o utilizador e o grupo reais antes de reescrever a estrofe. As referências e o TLS são de novo assuntos separados, já que uma referência tem de ser seguida e um endpoint que exige TLS precisa dos ficheiros de confiança correspondentes.

Mantenha o estado da conta e o âmbito da pesquisa nos seus próprios campos

O sinalizador de desativado pertence ao filtro, não à verificação de grupo. No Active Directory é o segundo bit de userAccountControl, e sem essa condição uma conta desativada com uma palavra-passe válida autentica-se e depois falha no passo do grupo, o que parece um erro de autorização. O âmbito da pesquisa pertence ao DN base, porque começar na raiz do domínio é mais lento e pode corresponder a objetos fora da unidade organizacional que queria cobrir.

Mantenha também estreitos os direitos da conta de ligação. Direitos de diretório amplos transformam um filtro mal configurado numa consulta bem-sucedida e escondem o erro até alguém auditar a conta. Altere a associação no próprio diretório, nunca numa lista local de exceções, para que desativar a conta baste para retirar o acesso. Se outra equipa gere o grupo, acorde o atributo que eles preenchem antes de escrever um filtro sobre ele.

Prove o resultado com três contas

Execute a configuração contra três identidades: um membro permitido, uma conta válida fora do grupo e uma conta que foi desativada. Se as três forem rejeitadas, a ligação ou a consulta de grupo estão quebradas; se as três forem aceites, não se aplica qualquer condição de grupo. Um resultado misto é o único que prova que a configuração distingue os casos que lhe importam.

Leia as mesmas três respostas diretamente do diretório antes de culpar o plug-in. A primeira consulta mostra o atributo de grupo do qual o filtro depende, e a segunda mostra o valor de controlo da conta. Substitua pelo seu próprio DN base, conta e endpoint:

ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControl

Um utilizador cujo memberOf volta vazio é um facto do diretório, não um erro do plug-in, e uma conta que continua a autenticar-se depois de ser desativada significa que ao filtro falta a condição de controlo da conta. Corrija essa evidência primeiro e volte a executar o teste das três contas. Mantenha a linha de registo que nomeou o passo falhado ao lado da alteração de configuração, para que a pessoa seguinte possa separar a autorização da autenticação sem repetir a pesquisa.

Artigos relacionados