Mapeamento de grupos LDAP no ASA versus DAP para a política de grupo VPN

Dois registos distintos decidem que política de grupo uma sessão AnyConnect recebe, e vivem em partes diferentes da configuração com modos de falha diferentes. Um mapa de atributos LDAP traduz um valor do diretório num atributo de autorização da ASA durante a autenticação; um registo DAP avalia condições depois e pode adicionar ou substituir atributos. Ambos podem terminar no mesmo nome de política, pelo que um início de sessão que funciona não lhe diz nada sobre o mecanismo que o produziu. O sentido de os comparar é escolher um deliberadamente em vez de deixar o segundo anular silenciosamente o primeiro.

Dois mecanismos, dois pontos de decisão

A escolha resume-se a três perguntas. Depende a decisão de um único valor de atributo do diretório, precisa de mais do que esse valor, e que mecanismo tem permissão para ganhar quando ambos coincidem?

Se a única entrada for a pertença a um grupo, o mapa de atributos é a ferramenta mais pequena e a mais fácil de auditar: um mapa, associado a um servidor AAA, com uma linha por grupo. Se a seleção tiver de considerar a postura, a identidade do endpoint, um segundo atributo ou uma janela temporal, o mapa fica sem entradas e o DAP é o mecanismo capaz de expressar a regra. Se ambos estiverem em jogo, conheça a precedência na sua versão antes de escrever qualquer um deles, porque uma sessão que coincide com um registo DAP pode não conservar a política devolvida pelo mapa. Todo o resto é contabilidade.

O caminho do mapa de atributos, pela ordem da configuração

O caminho do mapa começa na definição do servidor AAA. O mapa de atributos tem de estar associado à entrada do servidor LDAP que o perfil de ligação realmente utiliza; um mapa que existe na configuração em execução mas não é referenciado por esse servidor não altera nada. É essa linha de associação que torna viva o resto da configuração. O guia de mapeamento LDAP da ASA é a referência para a sintaxe do mapa nas versões 9.x.

Dentro do mapa, uma instrução nomeia o atributo do diretório e o atributo da ASA que alimenta, e outras instruções traduzem valores concretos. map-name memberOf Group-Policy seguido de map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly é a forma: o lado esquerdo é o que o diretório devolveu, o lado direito é o nome de uma política de grupo que já deve existir. Um nome distinto e um nome de apresentação de política não são intermutáveis, e uma quase-coincidência em qualquer das duas cadeias não produz qualquer erro no início de sessão.

Dois detalhes mordem aqui: memberOf devolve todos os grupos a que a conta pertence, por isso um utilizador em dois grupos mapeados dá ao mapa dois valores candidatos, e a regra alfabética do guia é o único desempate com que pode contar em vez da sua própria ordem de prioridade. Um valor não mapeado não devolve nada, o que recai silenciosamente na política predefinida do perfil.

O caminho DAP e o que acrescenta

O DAP avalia condições e aplica atributos por cima do resultado AAA. Um registo transporta uma prioridade, uma ação e um conjunto de condições; os registos são avaliados por ordem de prioridade e a ação decide se a avaliação continua ou para. É um modelo de execução diferente de uma pesquisa de valor, e é precisamente por isso que consegue expressar regras que o mapa não consegue.

O que o DAP acrescenta são entradas. As condições podem referenciar atributos do diretório, atributos do endpoint e o estado do dispositivo, e um registo correspondente pode transportar ACL, listas de URL ou filtros para essa sessão. Assim, uma regra como o pessoal de suporte num portátil gerido receber a política só de leitura enquanto o mesmo pessoal num dispositivo não gerido recebe uma restrita é exprimível em DAP e não num mapa de atributos. O mapa tem exatamente uma entrada: o valor que o diretório devolveu para o atributo que indicou.

O DAP acrescenta também um segundo local onde olhar quando uma sessão acaba na política errada. Um registo que coincide com uma ação de continuar não termina a avaliação, e um registo posterior ainda pode alterar o resultado, pelo que o que observa é o produto de uma sequência e não de uma única pesquisa. Leia os números de prioridade por ordem, e lembre-se de que pode ser o registo de recurso a fazer o trabalho. O mapa, em contrapartida, não tem sequência: um atributo, um valor, uma resposta.

Onde os dois discordam

A precedência é a parte que quebra desenhos. Quando uma sessão coincide tanto com uma entrada do mapa como com um registo DAP, o resultado depende da versão e da ação do registo, por isso verifique-o na sua própria ASA em vez de assumir que um dos mecanismos possui o resultado.

Três modos de falha explicam a maior parte da confusão. Um mapa definido mas nunca associado à etiqueta de servidor que o perfil utiliza produz a política predefinida sem qualquer erro em lado nenhum. Uma cadeia de condição DAP que difere do valor do diretório em maiúsculas ou espaços nunca coincide, e o registo de recurso aplica-se silenciosamente. E uma política de grupo que ainda não existe é aceite pelo mapa, porque o mapa só devolve um nome, pelo que a sessão não recebe nenhuma das permissões previstas e não há nada no registo que aponte para o objeto em falta. Verifique os três antes de tocar na pertença a grupos.

Ler as provas de uma sessão ativa

Leia a resposta de uma sessão nova e não da configuração. show vpn-sessiondb detail anyconnect filter name jdoe imprime a política de grupo que a sessão recebeu realmente, e show running-config ldap attribute-map confirma que valores o mapa poderia ter devolvido. Do lado do diretório, test aaa-server authentication LDAP-AD username jdoe password <password> mostra os atributos que a ASA recebeu de volta, e debug ldap 255 mostra a troca quando o teste não coincide com o que esperava.

Depois concilie quatro registos por escrito: o valor do diretório, o mapa ou a condição DAP configurados, a política de grupo local e o recurso a que o utilizador conseguiu realmente chegar. Se os três primeiros coincidirem e o quarto não, o problema está no corpo da política e não na seleção. Se a sessão mostrar o nome de política correto mas a ACL errada, deixe de olhar para o LDAP por completo. Altere um registo de cada vez e verifique novamente uma sessão nova, porque uma sessão reconectada é a única prova que reflete a configuração que acabou de escrever.