Este documento descreve como configurar a Security Assertion Markup Language (SAML) com foco no ASA AnyConnect por meio do Microsoft Entra ID.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
O SAML é uma estrutura baseada em XML para troca de dados de autenticação e autorização entre domínios de segurança. Ele cria um círculo de confiança entre o usuário, um provedor de serviços (SP) e um provedor de identidade (IdP) que permite que o usuário entre uma única vez para vários serviços. O Microsoft Entra ID integra-se perfeitamente com o dispositivo Cisco ASA VPN para fornecer segurança adicional para os logins do Cisco Secure Client AnyConnect VPN.
Metadados: É um documento baseado em XML que garante uma transação segura entre um IdP e um SP. Permite que o IdP e o SP negociem contratos.
Funções suportadas pelos dispositivos (IdP, SP)
Um dispositivo pode suportar mais de uma função e pode conter valores para uma controladora de armazenamento e um IdP. Sob o campo EntityDescriptor está um IDPSSODescriptor, se as informações contidas forem para um IdP de Signon Único, ou um SPSSODescriptor se as informações contidas forem para um SP de Signon Único. Isso é importante, pois os valores corretos devem ser tirados das seções apropriadas para que o SAML possa ser configurado com êxito.
ID da entidade: Esse campo é um identificador exclusivo de um SP ou IdP. Um único dispositivo pode ter vários serviços e pode usar diferentes IDs de entidade para diferenciá-los. Por exemplo, o ASA tem diferentes IDs de entidade para diferentes grupos de túneis que precisam ser autenticados. Um IdP que autentica cada grupo de túneis tem entradas de ID de entidade separadas para cada grupo de túneis para identificar com precisão esses serviços.
O ASA pode suportar vários IdPs e tem um ID de entidade separado para cada IdP para diferenciá-los. Se um dos lados receber uma mensagem de um dispositivo que não contém uma ID de entidade que tenha sido configurada anteriormente, o dispositivo provavelmente descartará essa mensagem e a autenticação SAML falhará. A ID da entidade pode ser encontrada no campo EntityDescriptor ao lado de entityID.
URLs de serviço: Definem a URL para um serviço SAML fornecido pelo SP ou IdP. Para os IdPs, é mais comum ser o Serviço de Logoff Único e o Serviço de Logon Único. Para os SPs, geralmente é o Assertion Consumer Service e o Single Logout Service.
A URL do serviço Single Sign-On encontrada nos metadados do IdP é usada pelo SP para redirecionar o usuário ao IdP para autenticação. Se esse valor estiver configurado incorretamente, o IdP não receberá ou não poderá processar com êxito a solicitação de Autenticação enviada pelo SP.
A URL de serviço do consumidor de asserção encontrada nos metadados da controladora de armazenamento é usada pelo IdP para redirecionar o usuário de volta para a controladora de armazenamento e fornecer informações sobre a tentativa de autenticação do usuário. Se isso for configurado incorretamente, o SP não receberá a asserção (a resposta) ou não poderá processá-la com êxito.
A URL do serviço de logoff único pode ser encontrada tanto no SP quanto no IdP. É usado para facilitar o logoff de todos os serviços SSO do SP e é opcional no ASA. Quando a URL do serviço SLO dos metadados de IdP é configurada na controladora, quando o usuário faz logoff do serviço na controladora, a controladora envia a solicitação ao IdP. Depois que o IdP tiver desconectado com êxito o usuário dos serviços, ele redirecionará o usuário de volta para o SP e usará a URL do serviço do SLO encontrada nos metadados do SP.
Associações SAML para URLs de Serviço: As vinculações são o método que o SP usa para transferir informações para o IdP e vice-versa para serviços. Isso inclui Redirecionamento HTTP, POST HTTP e Artefato. Cada método tem uma maneira diferente de transferir dados. O método de vinculação suportado pelo serviço está incluído na definição desses serviços. Por exemplo: SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= Serviço SSO >. O ASA não oferece suporte à associação de Artefato. O ASA sempre usa o método de Redirecionamento HTTP para solicitações de autenticação SAML, por isso é importante escolher a URL do Serviço SSO que usa a associação de Redirecionamento HTTP para que o IdP espere isso.
Para fornecer confidencialidade e integridade para as mensagens enviadas entre o SP e o IdP, o SAML inclui a capacidade de criptografar e assinar os dados. O certificado usado para criptografar e/ou assinar os dados pode ser incluído nos metadados para que a extremidade que recebe possa verificar a mensagem SAML e garantir que ela vem da fonte esperada. Os certificados usados para assinatura e criptografia podem ser encontrados nos metadados em KeyDescriptor use=signing e KeyDescriptor use=encryption, respectivamente, e X509Certificate. O ASA não oferece suporte à criptografia de mensagens SAML.

Etapa 1. Faça logon no Portal do Azure e escolha a ID do Microsoft Entra.

Etapa 2. Como mostrado nesta imagem, escolha Aplicações Empresariais.

Etapa 3. Agora, escolha New Application, como mostrado nesta imagem.

Etapa 4. Na seção Browse Microsoft Entra Gallery, digite AnyConnect na caixa de pesquisa, escolha autenticação Cisco Secure Firewall - Secure Client (anteriormente AnyConnect) no painel de resultados e, em seguida, Create o aplicativo.

Etapa 5. Escolha o item de menu Logon Único, conforme mostrado nesta imagem.

Etapa 6. Escolha SAML, conforme mostrado na imagem.

Etapa 7. Edite a Seção 1 com esses detalhes.
a. Identifier (Entity ID) - https://<VPN URL>/saml/sp/metadata/<TUNNEL-GROUP NAME> b. Reply URL (Assertion Consumer Service URL) - https://<VPN URL>/+CSCOE+/saml/sp/acs?tgname=<TUNNEL-GROUP NAME> Example: vpn url called asa.example.com and tunnel-group called AnyConnectVPN-1

Etapa 8. Na seção Certificado de assinatura SAML, escolha Download para baixar o arquivo de certificado e salve-o no seu computador.

Etapa 9. Isso é necessário para a configuração do ASA.

Nesta seção, Test1 está habilitado para usar logon único do Azure, à medida que você concede acesso ao aplicativo Cisco Secure Client AnyConnect.
Etapa 1. Na página de visão geral do aplicativo, escolha Usuários e grupos e, em seguida, Adicionar usuário/grupo.

Etapa 2. Escolha Usuários e grupos na caixa de diálogo Adicionar tarefa.
Adicionar tarefa
Etapa 3. Na caixa de diálogo Add Assignment, clique no botão Assign.

Etapa 1. Crie um ponto confiável e importe seu certificado SAML.
config t
crypto ca trustpoint AzureAD-AC-SAML revocation-check none no id-usage enrollment terminal no ca-check crypto ca authenticate AzureAD-AC-SAML -----BEGIN CERTIFICATE----- … PEM Certificate Text you downloaded goes here … -----END CERTIFICATE----- quit
Etapa 2. Esses comandos provisionam seu IdP SAML.
webvpn saml idp https://xxx.windows.net/xxxxxxxxxxxxx/ - [Azure AD Identifier] url sign-in https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxxx/saml2 - [Login URL] url sign-out https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 – Logout URL trustpoint idp AzureAD-AC-SAML - [IdP Trustpoint] trustpoint sp ASA-EXTERNAL-CERT - [SP Trustpoint] no force re-authentication no signature base-url https://asa.example.com
Etapa 3. Aplicar a autenticação SAML a uma configuração de túnel VPN.
tunnel-group AnyConnectVPN-1 webvpn-attributes saml identity-provider https://xxx.windows.net/xxxxxxxxxxxxx/ authentication saml end write memory
Etapa 1. Conecte à sua URL VPN e insira seu log em detalhes do Azure AD.
Etapa 2. Aprovar solicitação de entrada.
Etapa 3. O AnyConnect está conectado.



Exemplo de depuração:
[SAML] consume_assertion: O identificador de um provedor é desconhecido para #LassoServer. Para registrar um provedor em um objeto #LassoServer, você deve usar os métodos lasso_server_add_provider() ou lasso_server_add_provider_from_buffer().
Problema: Geralmente, significa que o comando saml idp [entityID] na configuração webvpn do ASA não corresponde à ID de entidade do IdP encontrada nos metadados do IdP.
Solução: Verifique a ID da entidade do arquivo de metadados do IdP e altere o comando saml idp [entity id] para corresponder a isso.
Exemplo de depuração:
[SAML] NotBefore:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z tempo limite: 0
[SAML] consume_assertion: a asserção expirou ou não é válida
Problema 1. Tempo de VMR não sincronizado com o tempo do IdP.
Solução 1. Configure ASA com o mesmo servidor NTP usado pelo IdP.
Problema 2. A asserção não é válida entre o tempo especificado.
Solução 2. Modifique o valor de tempo limite configurado no ASA.
Exemplo de depuração:
[Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:os dados não correspondem:a assinatura não corresponde
[SAML] consume_assertion: O perfil não pode verificar uma assinatura na mensagem
Problema: O ASA não pode verificar a mensagem assinada pelo IdP ou não há assinatura para o ASA verificar.
Solução: Verifique o certificado de assinatura IdP instalado no ASA para certificar-se de que ele corresponda ao que é enviado pelo IdP. Se isso for confirmado, certifique-se de que a assinatura esteja incluída na resposta SAML.
Exemplo de depuração:
[SAML] consume_assertion: audiência de asserção inválida
Problema: O IdP define o público incorreto.
Solução: Corrija a configuração de Audiência no IdP. Ele deve corresponder à ID da entidade do ASA.
Exemplo de depuração: Não é possível receber depurações após o envio da solicitação de autenticação inicial. O usuário pode inserir credenciais no IdP, mas o IdP não é redirecionado para o ASA.
Problema: O IdP está configurado para a URL incorreta do Serviço de Consumidor de Asserção.
Solução(ões): Verifique a URL base na configuração e certifique-se de que esteja correta. Verifique os metadados ASA com show para certificar-se de que a URL do Assertion Consumer Service esteja correta. Para testá-lo, procure-o. Se ambos estiverem corretos no ASA, verifique o IdP para certificar-se de que o URL está correto.
Exemplo: Depois que uma URL de logon único é modificada ou alterada, o certificado SP, o SAML ainda não funciona e envia as configurações anteriores.
Problema: O ASA precisa regenerar seus metadados quando houver uma alteração de configuração que o afete. Ele não faz isso automaticamente.
Solução: Depois que as alterações forem feitas, no grupo de túneis afetado, remova e reaplique o comando saml idp [entity-id].
A maioria das soluções de problemas SAML envolve uma configuração incorreta que pode ser encontrada quando a configuração SAML é verificada ou quando depurações são executadas. debug webvpn saml 255 pode ser usado para solucionar a maioria dos problemas, no entanto, em cenários onde essa depuração não fornece informações úteis, depurações adicionais podem ser executadas:
debug webvpn saml 255 debug webvpn 255 debug webvpn session 255 debug webvpn request 255
| Revisão | Data de publicação | Comentários |
|---|---|---|
5.0 |
22-Apr-2026
|
Texto Alt e Formatação Atualizados. |
4.0 |
28-Aug-2024
|
Tradução Automática e Formatação Atualizadas. |
3.0 |
11-Aug-2023
|
PII removido.
Otimização de mecanismo de pesquisa, texto alternativo, requisitos de estilo, tradução automática e formatação atualizados. |
1.0 |
19-Aug-2020
|
Versão inicial |