01-28-2025 06:36 AM - editado 02-03-2025 02:10 PM
Esta é uma tradução do documento: 3.6 Additional Identity Sources de @Kai Shin (respeitosamente com informações adicionais minhas).
Este Artigo é dividido em:
PART I: ISE - Identity Management
PART II: ISE - Active Directory Identity Source
PART III: ISE - Outros Identity Sources
Para obter uma cópia off-line ou impressa deste documento, basta escolher ⋮ Opções > Página Amigável para Impressora. Você pode então Imprimir > Imprimir em PDF ou Copiar & Colar em qualquer outro formato de documento de sua preferência. |
O Cisco ISE pode usar várias Identity Sources diferentes para verificar User ou Device Identities.
O Internal Database do ISE e o Microsoft Active Directory são as Identity Sources mais comumente usadas em Empresas, mas há muitas outras External Identity Sources que podem ser usadas.
Essas Identity Sources podem ser combinadas em qualquer ordem que permita que sejam usadas até que uma Identity seja verificada ou não.
Neste Artigo, aprenderemos sobre várias Identity Sources e como criar uma Identity Source Sequence que pode ser usada nas Authentication Policy Rules do Cisco ISE (em Policy > Policy Set > selecione a Policy Set > Authentication Policy).
Nota: os principais motivos para usar uma External Identity Source são:
LDAP é um Networking Protocol baseado em padrões usado para consultar e modificar Directory Services. É também um Lightweight Mechanism para acessar Directory Servers baseados em X.500. O Cisco ISE usa o LDAP Protocol para interagir com um External LDAP Database.
O LDAP suporta nativamente apenas Plain-Password Authentication, que é menos segura do que a maioria dos métodos do Active Directory. Para aumentar a segurança do Protocol, é recomendável proteger as comunicações LDAP. As conexões do LDAP Server geralmente podem ser protegidas usando dois protocolos: LDAP over TLS (STARTTLS) e LDAP over SSL (LDAPS).
O LDAP Directory Services são baseados em um modelo Client - Server. Para iniciar uma LDAP Session, um Client se conecta e envia Operation Requests ao Server, que responde. Um ou mais LDAP Servers contêm dados em uma LDAP Directory Tree ou em um LDAP Backend Database.
Um LDAP Directory é estruturado como uma Tree Hierachy simples e pode ser distribuído em vários Servers. Cada Server pode ter uma versão replicada de todo o Directory, que é sincronizado periodicamente.
Uma Entry na Tree contém um conjunto de Attributes. Cada Attribute tem um Name (um Attribute Type ou um Attribute Description) e um ou mais Values. Os Attributes são definidos em um Schema, e cada Entry tem um Distinguished Name (DN), que é um Relative Distinguished Name (RDN), que consiste nos Attributes de cada Entry seguidos pelo DN de sua Parent Entry. Você pode pensar no DN como o nome completo do File e no RDN como o nome relativo do File no Folder.
O Cisco ISE vem com três LDAP Schema pré-configurados:
Você pode acessar o Active Directory Database como um Active Directory (em Administration > Identity Management > External Identity Sources > Active Directory) ou LDAP Server (em Administration > Identity Management > External Identity Sources > LDAP).
Ao conectar o Cisco ISE ao Active Directory usando o método Active Directory, você configura um Administrator User e um Password que tenham acesso ao Domain. Este método oferece várias vantagens, incluindo uma ampla gama de Attributes, bom desempenho e a capacidade de Searches Up & Down na Tree.
Ao conectar o Cisco ISE ao Active Directory usando o método LDAP Server, você configura Users e uma Search Base. Este método é lento, fornece menos Attributes e suporta apenas Searches Down na Tree.
Você pode criar mais de uma LDAP Instance no Cisco ISE com diferentes IP Addr ou Port Settings. Isso permite que o Cisco ISE se autentique com diferentes LDAP Servers ou diferentes Database no mesmo LDAP Server. Cada IP Addr e Port Configuration do Primary Server, juntamente com um IP Addr e Port Configuration do Secondary Server, configuram uma LDAP Instance. Esta Instance corresponde a uma definição de Cisco ISE - LDAP Identity Source.
FUNÇÃO |
DESCRIÇÃO |
Multiple LDAP Instances |
Suporte para múltiplas LDAP Instances. Defina diferentes IP Addr ou Ports. Uma LDAP Instance consiste em Primary & Secondary Servers. |
Failover |
Se você não puder se conectar ao Primary Server, conecte-se do Primary Server ao Secondary Server. Ao configurar uma Authorization Policy, você deve conseguir se conectar ao Primary Server. |
User lookup |
Encontre Users e obtenha User Attributes sem Authentication. |
MAC Addr Lookup |
Recuperação de MAC Addr sem Authentication (se permitido). |
Attributes, Group Membership e Certificate Retrieval |
Você pode recuperar Attribute Values, Group Membership e Certificates do Database, independentemente da Authentication. |
O Cisco ISE não exige que cada LDAP Instance corresponda a um LDAP Database exclusivo. Você pode ter mais de uma LDAP Instance configurada para acessar o mesmo Database, o que é útil se seu LDAP Database contiver mais de uma SubTree para Users ou Groups. Cada LDAP Instance suporta apenas um SubTree Directory para Users e apenas um Subtree Directory para Groups. Portanto, você deve configurar uma LDAP Instance separada para cada combinação de User Directory SubTree e Group Directory Subtree para uso com o Cisco ISE.
O Cisco ISE suporta Failover entre Primary & Secondary LDAP Servers. O Failover ocorre quando o Cisco ISE não consegue se conectar a um LDAP Server, causando falhas nos Authentication Requests, seja porque o Server está inativo ou porque o Cisco ISE não consegue se conectar a ele. Para usar o recurso de Failover, você deve definir os Primary & Secondary LDAP Servers e configurar as configurações de Failover.
Quando o Failover está habilitado, o Cisco ISE sempre tentará se conectar a outro Server se não conseguir se conectar ao Primary Server. O Primary Server ao qual ele se conecta pode não ser sempre o Primary LDAP Server. O Primary LDAP Server ao qual ele se conecta depende da tentativa de LDAP Authentication anterior e do valor inserido na caixa de texto Failback To Primary Server After.
Nota |
O Cisco ISE sempre usa o Primary LDAP Server para recuperar Groups e Attributes para usar em Authorization Policies na User Interface, portanto, o Primary LDAP Server deve estar acessível ao configurar essas Entries. O Cisco ISE usa o Secondary LDAP Server apenas para Authentication e Authorization em tempo de execução, dependendo da configuração de Failover. |
Para Authenticate um User, o Cisco ISE envia um Bind Request ao LDAP Server. O Bind Request inclui o User's Distinguished Name e Pasword em Plain Text. Se o Distinguised Name e o Password corresponderem às Entries no LDAP Directory, o usuário será Authenticated.
O Cisco ISE oferece suporte a um recurso de User Lookup que permite pesquisar Users e recuperar informações de um LDAP Database sem Authentication. O processo de User Lookup inclui as seguintes tarefas:
O Cisco ISE também oferece suporte à funcionalidade de Lookup de MAC Addr. Esse recurso permite que você pesquise MAC Addr em um LDAP Database e recupere as informações sem Authetication. O processo de pesquisa de MAC Addr inclui as seguintes tarefas:
Você também pode configurar o Cisco ISE para recuperar Attribute Values, Group Membership e Certificates com ou sem Authentication.
Um RADIUS Server suporta o RADIUS Protocol e fornece AAA Services (Authentication, Authorization e Accounting) para Users e Devices. Um RADIUS Server pode atuar como uma External Identity Source por meio de Subject & Credentials Collections. O RADIUS Protocol é usado para se comunicar com um RADIUS Server.
O Cisco ISE oferece suporte a qualquer RADIUS Server compatível com os padrões como uma External Identity Source, incluindo o RSA SecurID Server e o SafeWord Server. O SafeWord Token Server pode conter vários Users e suas Credentials como One-Time Passwords. O Cisco ISE pode consultar esse Identity Store por meio do RADIUS Protocol.
Para redundância, o RADIUS consiste em um Primary Server e um Secondary Server. Se o Primary Server atingir o tempo limite devido a RADIUS Requests, o Cisco ISE envia os Request ao Secondary Server.
O RADIUS Server pode fornecer Password-Based Authentication usando RADIUS PAP ou Token-Based Authentication usando PEAP with inner EAP-GTC ou EAP-FAST with inner EAP-GTC. Exemplos de implementações de RADIUS Token Server com suporte incluem os RSA SecurID e SafeWord Servers.
A RADIUS Identity Source usa a mesma UDP Port para todas as comunicações RADIUS para Authentication Sessions. Para que o Cisco ISE envie com sucesso RADIUS Messages para um RADIUS-enabled Server, o Gateway Device entre o RADIUS-enabled Server e o Cisco ISE deve permitir a comunicação pela mesma UDP Port.
Para integrar o Cisco ISE com um RADIUS Server, você pode prosseguir no menu abaixo.
Em Administration > Identity Management > External Identity Sources > RADIUS Token – Add in the Cisco ISE Administrative Interface.
Depois disso, insira as informações abaixo:
SAML é um formato de dados Open Standard baseado em XML. O SAML permite que você acesse perfeitamente um conjunto definido de Applications após efetuar Login em um deles.
O SAML descreve a troca de informações relacionadas à Security entre Trusted Business Partners. Ele permite que informações de Secure Authentication sejam trocadas entre um Identity Provider (Azure Active Directory) e um Service Provider (Cisco ISE).
O SAML facilita o Single Sign-On (SSO). O SSO permite que a responsabilidade de Authentication seja transferida do Cisco ISE para um Third-Party System. O Cisco ISE pode usar o SSO para Web-based Authentication para Network Resources e vários ISE Portals.
Aqui estão as etapas básicas para SSO Authentication usando o Azure Active Directory e o WebAuth (Web Authentication) para acesso à Wireless Network:
O Identity Provider armazena e valida User Credentials e gera uma SAML Response que autoriza o User a acessar recursos definidos pelo Service Provider. As informações de Authentication são criptografadas, e o Cisco ISE e o Identity Provider são Authenticated usando Certificates. Alguns SSO Identity Providers, como o Azure Active Directory, permitem que você imponha Two-Factor Authentication.
O SAML SSO estabelece um Circle of Trust (CoT) por meio da troca de Metadata e Certificates como parte do processo de provisionamento entre um Identity Provider e um Service Provider. O Service Provider trust nas informações do Identity Provider's User para fornecer acesso a vários Services ou Applications.
Lista de Identity Providers fornecidos pelo Cisco ISE:
Lista de Portals fornecidos pelo SAML SSO:
Nota |
Para habilitar o BYOD, selecione um Identity Provider para o Guest Portal e habilite o BYOD Flow. |
A Identity Source Sequence define a ordem na qual o Cisco ISE procura User Credentials em diferentes Databases. Se você armazenar User Information em mais de um Database, poderá definir a ordem na qual o Cisco ISE verifica esses Databases em busca de User Information. Se uma correspondência for encontrada, o Cisco ISE não pesquisará mais. Ele avalia as Credentials e retorna os resultados ao User. Esta Policy é uma "First Match" Policy.
Você também pode configurar o comportamento do Cisco ISE para situações em que um Database específico está inacessível. As duas configurações disponíveis são "Continue to Search other Databases" ou "Stop Processing Altogether".
Por exemplo, se você tiver uma Identity Source Sequence composta por três Databases:
Se o User não for encontrado no Active Directory Database, o Cisco ISE prosseguirá para a segunda opção de Identity Source, o LDAP. Se o LDAP Server estiver inativo e a opção "Proceed to the Next Store in the Sequence" estiver configurada, o Cisco ISE retornará para a terceira opção de Identity Source. Se o User for encontrado neste Database e as Credentials corresponderem, então a Authentication será bem-sucedida.
Por padrão, se a Identity Source que está sendo usada não estiver acessível, o processamento será interrompido e o Cisco ISE não acessará nenhum outro Store na sequência. Esse comportamento faz com que o status de Authentication seja definido como "Process Error". Para habilitar o Rollover, você deve definir a configuração da Advanced Search List como "Treat as if the User was not Found and Process to the Next Store in the Sequence" ao configurar o Identity Source Sequence.
O diagrama anterior mostra o Authentication Flow usando a Identity Source Sequence em um Authentication Process simples. O ponto principal desse Flow é que, se um User não for encontrado em uma Identity Source específica, a Authentication será tentada usando a próxima Source na sequência.
Para adicionar Identity Source Sequences, acesse Administration > Identity Management > Identity Source Sequences:
A imagem acima mostra que adicionamos um novo Identity Source Sequence que examinará o Active Directory abc.public antes de examinar o Internal User Database. As Available Identity Sources são listadas à esquerda, e a Selected Identity Sources estão à direita. Nesse caso, o Internal User Store é verificado após o Active Directory Store.
Confira a seção Advanced Search List Settings na parte inferior. Essas duas opções definem o comportamento quando o Database está inacessível.
Nossa que aula maravilhosa
@Adonay dos Anjos ... muito obrigado !!!
Encontre respostas, faça perguntas e conecte-se com nossa comunidade de especialistas da Cisco de todo o mundo.
Estamos felizes por você estar aqui! Participe de conversas e conecte-se com sua comunidade.
Navegue pelos links rápidos da Comunidade e usufrua de um conteúdo personalizado e em seu idioma nativo: