MFA (SAML) no Cisco ASA/ISE em duas interfaces Outside
Olá, pessoal este será minha
primeira postagem sobre Security.
Irei compartilhar algumas
atividades que venho realizando em clientes. Estas atividades irão mostrar
alguns problemas encontrados e as soluções implantadas.
Acredito que este
tipo de ação possa ajudar vocês no dia a dia.
Tópico: MFA (SAML)
no ASA/ISE em duas interfaces Outside.
Cenário:
Cliente possui a
solução do Cisco ISE e Firewall Cisco ASA.
Problema 1:
Cliente solicitou a
configuração de MFA, usando o Microsoft Azure.
Configuração do SAML é suportada no ASA, porém devido a arquitetura do SAML, se
faz necessário a separação dos processos do AAA, sendo necessário realizar a
autenticação via SAML e autorização via Cisco ISE.
Como o ISE não
possui a integração nativa de SAML, a única solução foi separar os processos de
AAA.
Problema 2:
O Cisco ASA na
versão 9.x suporta somente uma configuração de SAML por IDP, sendo assim, em
caso de queda do link primário, seria necessário utilizar a autenticação via
ISE (incluindo a autorização).
O Cisco ASA do
cliente possuía dois certificados digitais, sendo um para a interface outside
(vpn.cliente.com) e outra para outside2 (vpn1.cliente.com). Também possuía
resolução externa para vpn.cliente.com e vpn1.cliente.com
A configuração de
IDP no ASA, é feito utilizando uma URL, sendo essa para formar o TRUST entre o
ASA e o IDP (AZURE). Neste caso a URL era vpn.cliente.com.br, quando caia a
interface outside, a relação de confiança era perdida (link down). Desta forma
o MFA não funcionava na segunda interface (Outside2).
Na imagem
podemos ver o comando base-url, no qual é usado para montar a confiança do ASA
com o IDP da Azure, comando em uso é via vpn.cliente.com. Este comando é opcional, porém
não é possível incluir dois comandos. Caso o mesmo não seja utilizado, a url
utilizada é o hostname do ASA + Domain name (ex:
asa-cliente.cliente.local).
Porém devido a
mudança de experiência do usuário defini a seguinte solução.
Solução:
Foi solicitado a configuração do Traffic Manager da Azure para fazer a função
de GTM (DNS Load Balance).
https://azure.microsoft.com/pt-br/services/traffic-manager/
Esta solução é paga,
porém o custo para este cliente, ficou entre U$ 7,0. e U$ 12,00. Esta conta foi
feita utilizando a quantidade de clientes (total de 80 licenças de AnyConnect)
e custos encontrados no link acima.
Configuração do
Traffic Manager:
Foi criado dois links, sendo:
Link1 = IP Público do ASA - Interface Outside
Link2 = IP Público do ASA - Interface Outside
Aqui foi
criado a monitoração dos links utilizando TCP443.
Usando o método de roteamento de prioridade, sendo o LINK 1 como principal.
Acima encontramos a resolução de nome depois do traffic manager estar
configurado. Todo o processo é automático.
Foi solicitado a remoção da entrada A do DNS externo do cliente,
removendo assim o endereço IP. E solicitado a inclusão do CNAME do
traffimanager.
Acima podemos ver que a entrada de dns de vpn.cliente.com possui um
Aliases, que é o CNAME.
Desta forma o Traffic Manager atualiza a entrada de DNS em caso de queda
do link do ASA.
Obs.: Clientes continuam utilizando vpn.cliente.com para acesso a VPN.
Configuração do ASA:
Interfaces:
Neste caso é um IP privado, porém há um firewall acima realizando NAT estático.
Roteamento:
SLA criado para uso no track
Track:
As configurações acima podem ser adaptadas a qualquer ambiente. Assim no
meu caso, o track monitora o ip do google (8.8.8.8) via outside, em caso de
perda a rota é removida e o acesso ocorre via Outside2.
Cliente já possuía um certificado público para o uso da vpn.cliente.com.
Atividades para configuração do SAML no ASA.
Link para referência:
Para configuração do IDP do lado da Microsoft é necessário
informar os seguintes itens para a equipe Microsoft:
1. Identifier (Entity ID)
1.1. https://vpn.cliente.com/saml/sp/metadata/TUNNEL_NAME_1
2. Reply URL (Assertion Consumer Service URL)
2.1. https://vpn.cliente.com/+CSCOE+/saml/sp/acs?tgname= TUNNEL_NAME_1
Necessário alterar a url e o tunnel name (tunnel-group) e passar para a
Microsoft. Esta url é o link externo da vpn e o tunnel name (tunnel-group) pode ser coletado usando o comando abaixo:
show running-config tunnel-group
O Pessoal da Microsoft precisa informar os seguintes itens:
1. url sign-in
2. url sign-out
3. endereço de IDP (azure identifier)
No Cisco ASA temos as seguintes atividades:
1. Importar Certificado Digital.
1.1. Configurar TrustPoint
config
!
crypto ca trustpoint AzureAD-AC-SAML
revocation-check none
no id-usage
enrollment terminal
no ca-check
!
1.2. Importar Certificado Digital (copy e paste)
!
crypto ca authenticate AzureAD-AC-SAML
-----BEGIN CERTIFICATE-----
…
PEM Certificate Text you downloaded goes
here
…
-----END CERTIFICATE-----
quit
!
1.3. Configurar Webvpn
!
webvpn
saml idp
https://sts.windows.net/xxxxxxxxxxxxx/ - [Azure AD Identifier]
url sign-in
https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxxx/saml2 - [URL SIGN-IN]
url sign-out
https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 – [URL
SIGN-OUT]
trustpoint idp AzureAD-AC-SAML - [IdP
Trustpoint]
trustpoint sp ASA-EXTERNAL-CERT - [OUTSITE
INTERFACE Trustpoint]
no force re-authentication
no signature
base-url https://asa.example.com
!
1.4. Configurar Tunnel-Group
!
tunnel-group AnyConnectVPN-1 webvpn-attributes
saml identity-provider
https://sts.windows.net/xxxxxxxxxxxxx/
authentication saml
end
!
write memory
!
Atividades Cisco ISE:
1. Criado uma Policy Set dando match no tunnel-group
name.
2. Como explicado o processo de AAA seria dividido,
sendo a autenticação realizada diretamente no ASA via SAML e Autorização via
ISE, sendo assim é necessário alterar o Options abaixo para Continue.
3. Configurar as Authorization Policies, neste caso
foi utilizado um grupo de SAP para a primeira regra.
as demais podem ser criadas da mesma forma, usando grupos de AD diferentes.
Testes:
Ao logar na vpn.cliente.com via anyconnect o
usuário é redirecionado ao microsoftonline para autenticação.
Após usar as credenciais da Microsoft (azure AD) e
MFA o acesso é autorizado via ISE. Assim o acesso a VPN é realizado com
sucesso.
Obs.: Em
caso de queda do link primário, o traffic manager irá atualizar a entrada A
para o IP do link da Outside2, assim o acesso irá funcionar sem alterações do
lado do ASA e sem percepção do usuário.
Comentários
Postar um comentário