O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento discute como configurar a Integração de Diretório do Cisco Unified Communication Manager (CUCM) em um ambiente de várias florestas.
A Cisco recomenda que você:
Este documento não se restringe a versões de software e hardware específicas.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
O Microsoft AD LDS, anteriormente conhecido como ADAM, pode ser usado para fornecer serviços de diretório para aplicativos habilitados para diretório. Em vez de usar o banco de dados do Ative Diretory Domain Service (AD DS) da sua organização para armazenar os dados do aplicativo habilitado por diretório, o AD LDS pode ser usado para armazenar os dados. O AD LDS pode ser usado em conjunto com o AD DS para que você possa ter um local central para contas de segurança (AD DS) e outro local para suportar a configuração de aplicativos e dados de diretório (AD LDS). Com o AD LDS, você pode reduzir a sobrecarga associada à replicação do AD, você não precisa estender o esquema do AD para dar suporte ao aplicativo, e você pode particionar a estrutura de diretório para que o serviço do AD LDS seja implantado somente nos servidores que precisam suportar o aplicativo habilitado por diretório.
Há muitas diferenças entre ADAM e AD, o ADAM só pode fornecer parte das funções fornecidas pelo AD.
O objetivo deste documento é explicar os mecanismos que permitem que o CUCM, ou qualquer outro produto da Cisco que use o Diretory Integration Service (DirSync), obtenha informações do usuário e execute a autenticação de diferentes domínios do AD que possam existir em diferentes florestas. Para atingir esse objetivo, o ADAM é usado para sincronizar seu banco de dados de usuários com diferentes controladores de domínio do AD ou outras fontes LDAP.
O ADAM pode criar um banco de dados de usuários e armazenar seus detalhes. A funcionalidade de sign-on único (SSO) é desejada para evitar que os usuários finais tenham que manter diferentes conjuntos de credenciais em diferentes sistemas; portanto, o redirecionamento de associação ADAM é usado. O redirecionamento de associação ADAM é uma função especial para aplicativos que suportam associação LDAP como um mecanismo de autenticação. Em alguns casos, o esquema especial, ou contexto de nomenclatura, pode forçá-lo a evitar AD, o que faz do ADAM uma escolha necessária. Isso evita que os usuários tenham que se lembrar de várias senhas devido ao emprego de um diretório adicional com sua própria ID de usuário e senha.
Um objeto de proxy de usuário especial no ADAM mapeia para uma conta de usuário AD regular. O proxy de usuário não tem uma senha real armazenada no próprio objeto ADAM. Quando o aplicativo executa sua operação de associação normal, ele verifica o ID localmente, mas verifica a senha em relação ao AD nas tampas, como mostrado na figura. O aplicativo não precisa estar ciente desta interação do AD.
O redirecionamento de associação ADAM deve ser usado somente em casos especiais em que um aplicativo pode executar uma associação LDAP simples ao ADAM. No entanto, o aplicativo ainda precisa associar o usuário a um principal de segurança no AD.
O redirecionamento de associação ADAM ocorre quando uma associação ao ADAM é tentada com o uso de um objeto especial chamado de objeto proxy. Um objeto proxy é um objeto no ADAM que representa um principal de segurança no AD. Cada objeto proxy no ADAM contém o SID de um usuário no AD. Quando um usuário tenta se vincular a um objeto proxy, o ADAM pega o SID que está armazenado no objeto proxy, juntamente com a senha que é fornecida no momento da associação, e apresenta o SID e a senha para o AD para autenticação. Um objeto proxy no ADAM não armazena uma senha e os usuários não podem alterar suas senhas do AD por meio de objetos proxy do ADAM.
A senha é apresentada em texto simples ao ADAM porque a solicitação de associação inicial é uma solicitação de associação LDAP simples. Por esse motivo, uma conexão SSL é necessária por padrão entre o cliente de diretório e o ADAM. O ADAM usa APIs de segurança do Windows para apresentar a senha ao AD.
Você pode obter mais informações sobre o redirecionamento de associação em Entendendo o redirecionamento de associação ADAM .
Para explicar o método, imagine um cenário em que a Cisco Systems (Forest 2) adquiriu duas outras empresas: Tandberg (Floresta 3) e Webex (Floresta 1). Na fase de migração, integre a estrutura do AD de cada empresa para permitir a implantação de um único cluster do Cisco Unified Communications.
No exemplo, a empresa Cisco (Floresta 2) tem dois domínios, domínio raiz de floresta chamado CISCO (dns cisco.com) e um subdomínio chamado EMERG (dns emerg.cisco.com). Esses dois domínios têm um Controlador de Domínio que também é um Catálogo Global e cada um é hospedado no Windows 2008 Server SP2.
A empresa Tandberg (Floresta 3) tem um único domínio com um Controlador de Domínio que também é um Catálogo Global e está hospedada no Windows 2008 Server SP2.
O Company Webex (Forest 1) tem um único domínio com um Controlador de Domínio que também é um Catálogo Global e está hospedado no Windows 2003 R2 Server SP2.
O AD LDS está instalado no Controlador de Domínio para o domínio CISCO ou pode ser uma máquina separada; de fato, poderia estar em qualquer parte de uma das três florestas. A infraestrutura de DNS deve ser criada de modo a que os domínios de uma floresta possam comunicar-se com domínios de outras florestas e estabelecer as relações de confiança e validações adequadas entre as florestas.
Para que a autenticação dos usuários funcione, você precisa ter uma confiança entre o domínio onde a instância do ADAM está hospedada e o(s) outro(s) domínio(s) que hospeda(s) contas de usuário. Essa confiança pode ser uma confiança unidirecional se necessário (confiança de saída do domínio que hospeda a instância do ADAM para o(s) domínio(s) que hospeda as contas de usuário). Dessa forma, a instância do ADAM poderá encaminhar as solicitações de autenticação para DCs nesses domínios de conta.
Além disso, você precisará ter uma conta de usuário de ambos os domínios de conta que tenha acesso a todos os atributos de todas as contas de usuário no domínio. Essa conta é usada pelo ADAMSync para sincronizar os usuários do domínio de conta com o ADAM.
Por último, mas não menos importante, a máquina que executa o ADAM deve ser capaz de localizar todos os domínios (DNS), localizar controladores de domínio em ambos os domínios (com DNS) e conectar-se a esses Controladores de domínio.
Conclua estes passos para configurar as relações de confiança:
Esse é o resultado que você recebe depois de executar esse processo para os domínios Tandberg e Webex. A integração de domínio está lá por padrão, pois é um domínio filho. Click OK.
Marque a caixa de seleção Serviços LDS do Ative Diretory. Clique em Next.
Conclua estes passos para configurar o AD LDS em 2012:
O AD LDS pode executar diferentes instâncias dos serviços com diferentes portas, o que permite que diferentes "aplicativos" de diretório de usuário sejam executados na mesma máquina. Por padrão, o AD LDS escolhe as portas 389/LDAP e 636/LDAPS, mas se o sistema já tiver qualquer tipo de serviço LDAP que as execute, ele usará as portas 50000/LDAP e 50001/LDAPS. Cada instância terá um par de portas incrementadas com base nos números anteriores usados.
Em alguns casos, devido a um bug da Microsoft, as portas já são usadas pelo servidor DNS da Microsoft e o assistente de instância apresenta um erro (que não é autoexplicativo). Esse erro pode ser corrigido quando você reserva as portas na pilha TCP/IP. Se você encontrar esse problema, consulte Falha no início do serviço do AD LDS com o erro "a configuração não pôde iniciar o serviço...". + código de erro 8007041d.
Note: O CUCM suporta apenas uma única partição de diretório de aplicativo, não há suporte para várias partições no momento.
Consulte a Etapa 5: Pratique Trabalhar com Partições de Diretório de Aplicativos para obter informações sobre como criar uma Partição de Diretório de Aplicativos. O processo para criar uma partição de diretório para cada domínio que você deseja sincronizar com os trabalhos com base na referência LDAP (RFC 2251) e exige que o cliente LDAP (CUCM, CUP, etc.) suporte referências.
Clique no botão de opção Yes, create a application diretory partition (Sim, criar uma partição de diretório de aplicativos). Insira o nome da partição no campo Nome da partição para a instância. Não forneça um cn como no exemplo do assistente, porque na maioria das vezes isso cria um erro nos Esquemas. Neste cenário, foi inserida a mesma partição que o controlador de domínio do AD que hospeda o AD LDS (dc=Cisco,dc=com). Clique em Next.
Clique no botão de opção Usuário conectado atualmente. Digite o nome do usuário com permissões administrativas. Clique em Next.
Note: Se o ADAM estiver instalado em um servidor Windows 2003, a tela anterior terá apenas quatro opções: MS-AZMan.LDF, MS-InetOrgPerson.LDF, MS-User.LDF e MS-UserProxy.LDF. Dessas quatro, marque apenas as caixas de seleção de MS-User.LDF e MS-InetOrgPerson.LDF.
Note: O CUCM suporta apenas uma única partição de diretório de aplicativo, não há suporte para várias partições no momento.
Consulte a Etapa 5: Pratique Trabalhar com Partições de Diretório de Aplicativos para obter informações sobre como criar uma Partição de Diretório de Aplicativos. O processo para criar uma partição de diretório para cada domínio que você deseja sincronizar com os trabalhos com base na referência LDAP (RFC 2251) e exige que o cliente LDAP (CUCM, CUP, etc.) suporte referências. Consulte Suporte da Microsoft para obter mais informações.
Clique no botão de opção Yes, create a application diretory partition (Sim, criar uma partição de diretório de aplicativos). Digite o Nome da partição. Crie a partição para LDS como cisco.com. Qualquer valor adequado pode ser fornecido. Clique em Next.
Se as IDs de usuário (sAMAccountNames) forem exclusivas em domínios diferentes e não houver vários usuários com a mesma ID em domínios diferentes de florestas diferentes, os usuários poderão ser sincronizados do AD com as respectivas florestas no AD LDS, que podem existir em uma única partição no AD LDS em uma configuração de várias florestas. Por exemplo, considere a figura na seção Cenário de Suporte a Múltiplas Florestas do Ative Diretory no CUCM, e se a ID de usuário ‘alice’ existir em apenas um dos três domínios, a configuração neste cenário seria a seguinte:
PARTIÇÃO FLORESTA DN
P1 cisco.com DC=cisco,DC=com
webex.com DC=webex, DC=cisco,DC=com
tandberg.com DC=Tandberg, DC=cisco,DC=com
Para configurar o CUCM com o AD LDS, a ID de usuário (sAMAccountName) precisa ser exclusiva em todas as florestas. O CUCM atualmente suporta apenas uma única partição no AD LDS.
Se os sAMAccountNames não forem exclusivos, considere usar qualquer um desses atributos se eles identificarem exclusivamente uma conta de usuário - e-mail, número de telefone, número de funcionário, uid ou userPrincipalName.
Uma opção disponível para ajudar a organizar os arquivos que precisam ser gerados é criar um diretório separado para permitir que esses arquivos sejam separados do diretório c:\windows\adam directory principal. Abra um prompt de comando e crie um diretório de log em c:\windows\adam.
cd \windows\adam
mkdir logs
ldifde -i -s localhost:50000 -c CN=Configuration,DC=X
#ConfigurationNamingContext -f diff-schema.ldf -j c:\windows\adam\logs
Consulte Utilização do LDIFDE para importar e exportar objetos de diretório para o Ative Diretory para obter opções adicionais e formatos de comandos.
O objeto para a autenticação de proxy precisa ser criado e a classe de objeto 'user' não será usada. A classe de objeto criada, userProxy, é o que permite o redirecionamento de associação. O detalhe da classe de objeto precisa ser criado em um arquivo ldif. O arquivo é uma criação de um novo arquivo, que neste exemplo é MS-UserProxy-Cisco.ldf. Este novo arquivo é gerado a partir do MS-UserProxy.ldf original e editado, use um programa de edição de texto para ter este conteúdo:
#==================================================================
# @@UI-Description: AD LDS simple userProxy class.
#
# This file contains user extensions for default ADAM schema.
# It should be imported with the following command:
# ldifde -i -f MS-UserProxy.ldf -s server:port -b username domain password -k -j . -c
"CN=Schema,CN=Configuration,DC=X" #schemaNamingContext
#
#==================================================================
dn: CN=User-Proxy,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaAdd
objectClass: top
objectClass: classSchema
cn: User-Proxy
subClassOf: top
governsID: 1.2.840.113556.1.5.246
schemaIDGUID:: bxjWYLbzmEiwrWU1r8B2IA==
rDNAttID: cn
showInAdvancedViewOnly: TRUE
adminDisplayName: User-Proxy
adminDescription: Sample class for bind proxy implementation.
objectClassCategory: 1
lDAPDisplayName: userProxy
systemOnly: FALSE
possSuperiors: domainDNS
possSuperiors: organizationalUnit
possSuperiors: container
possSuperiors: organization
defaultSecurityDescriptor:
D:(OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)S:
defaultHidingValue: TRUE
defaultObjectCategory: CN=User-Proxy,CN=Schema,CN=Configuration,DC=X
systemAuxiliaryClass: msDS-BindProxy
systemMayContain: userPrincipalName
systemMayContain: givenName
systemMayContain: middleName
systemMayContain: sn
systemMayContain: manager
systemMayContain: department
systemMayContain: telephoneNumber
systemMayContain: mail
systemMayContain: title
systemMayContain: homephone
systemMayContain: mobile
systemMayContain: pager
systemMayContain: msDS-UserAccountDisabled
systemMayContain: samAccountName
systemMayContain: employeeNumber
systemMayContain: initials
systemMayContain: ipPhone
systemMayContain: displayName
systemMayContain: msRTCSIP-primaryuseraddress
systemMayContain: uid
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
Salve o arquivo MS-UserProxy-Cisco.ldf em C:\windows\adam.
Importar a nova classe de objeto para AD LDS.
ldifde -i -s localhost:50000 -c CN=Configuration,DC=X #ConfigurationNamingContext -f
MS-UserProxy-Cisco.ldf -j c:\windows\adam\logs
O usuário de cada domínio agora precisa ser importado para o AD LDS. Esta etapa precisa ser repetida para cada domínio que precisa ser sincronizado. Este exemplo mostra apenas o processo em relação a um dos domínios. Comece com o MS-AdamSyncConf.xml original e crie um arquivo XML para cada domínio que precisa ser sincronizado e modifique o arquivo com os detalhes específicos de cada domínio para ter este conteúdo:
<?xml version="1.0"?>
<doc>
<configuration>
<description>Adam-Sync1</description>
<security-mode>object</security-mode>
<source-ad-name>ad2k8-1</source-ad-name>
<source-ad-partition>dc=cisco,dc=com</source-ad-partition>
<source-ad-account></source-ad-account>
<account-domain></account-domain>
<target-dn>dc=cisco,dc=com</target-dn>
<query>
<base-dn>dc=cisco,dc=com</base-dn>
<object-filter>
(|(&(!cn=Administrator)(!cn=Guest) (!cn=ASPNET)
(!cn=krbtgt)(sAMAccountType=805306368))(&(objectClass=user)(isDeleted=TRUE)))
</object-filter>
<attributes>
<include>objectSID</include>
<include>mail</include>
<include>userPrincipalName</include>
<include>middleName</include>
<include>manager</include>
<include>givenName</include>
<include>sn</include>
<include>department</include>
<include>telephoneNumber</include>
<include>title</include>
<include>homephone</include>
<include>mobile</include>
<include>pager</include>
<include>msDS-UserAccountDisabled</include>
<include>samAccountName</include>
<include>employeeNumber</include>
<include>initials</include>
<include>ipPhone</include>
<include> displayName</include>
<include> msRTCSIP-primaryuseraddress</include>
<include>uid</include>
<exclude></exclude>
</attributes>
</query>
<user-proxy>
<source-object-class>user</source-object-class>
<target-object-class>userProxy</target-object-class>
</user-proxy>
<schedule>
<aging>
<frequency>0</frequency>
<num-objects>0</num-objects>
</aging>
<schtasks-cmd></schtasks-cmd>
</schedule>
</configuration>
<synchronizer-state>
<dirsync-cookie></dirsync-cookie>
<status></status>
<authoritative-adam-instance></authoritative-adam-instance>
<configuration-file-guid></configuration-file-guid>
<last-sync-attempt-time></last-sync-attempt-time>
<last-sync-success-time></last-sync-success-time>
<last-sync-error-time></last-sync-error-time>
<last-sync-error-string></last-sync-error-string>
<consecutive-sync-failures></consecutive-sync-failures>
<user-credentials></user-credentials>
<runs-since-last-object-update></runs-since-last-object-update>
<runs-since-last-full-sync></runs-since-last-full-sync>
</synchronizer-state>
</doc>
Neste arquivo, essas marcas devem ser substituídas para corresponder ao domínio:
Consulte a Sintaxe do Filtro de Pesquisa para obter mais informações sobre como criar um <object-filter>.
Salve o arquivo XML recém-criado em C:\windows\adam.
Abra uma janela de comando, cd \windows\adam.
Digite o comando ADAMSync /install localhost:50000 c:\windows\ADAM\AdamSyncConf1.xml /log c:\windows\adam\logs\install.log.
Verifique se o arquivo AdamSyncConf1.xml é o arquivo XML recém-criado.
Sincronize os usuários com o comando ADAMSync /sync localhost:50000 "dc=cisco,dc=com" /log c:\windows\adam\logs\sync.log.
O resultado deve ser semelhante a:
Para concluir uma sincronização automática de AD para ADAM , use o agendador de tarefas no Windows.
Crie um arquivo .bat com este conteúdo:
"C:\Windows\ADAM\ADAMSync" /install localhost:50000 c:\windows\ADAM\AdamSyncConf1.xml /log c:\windows\adam\logs\install.log
"C:\Windows\ADAM\ADAMSync" /sync localhost:50000 "dc=cisco,dc=com" /log c:\windows\adam\logs\syn.log
Agende a tarefa para executar o arquivo .bat como e quando necessário. Isso cuida de adições, modificações e exclusões que acontecem no AD para serem refletidas também no ADAM.
Você pode criar outro arquivo .bat e agendá-lo para concluir uma sincronização automática da outra floresta.
Por padrão, a associação ao ADAM com o redirecionamento de associação requer uma conexão SSL. O SSL exige a instalação e o uso de certificados no computador que executa o ADAM e no computador que se conecta ao ADAM como um cliente. Se os certificados não estiverem instalados no ambiente de teste do ADAM, você poderá desativar o requisito para SSL como alternativa.
Por padrão, o SSL está ativado. Para que o protocolo LDAPS funcione no ADAM/LDS, você precisará gerar um certificado.
Neste exemplo, o Microsoft Certification Authority Server é usado para emitir o certificado. Para solicitar um certificado, vá para a página Web do Microsoft CA - http://<nome de host do MSFT CA>/certsrv e conclua estas etapas:
Volte para a interface da autoridade de certificação e clique na pasta Certificados Pendentes. Clique com o botão direito do mouse na solicitação de certificado feita pela máquina ADAM/AD-LDS e emita o certificado.
O certificado foi criado e reside na pasta "Certificados emitidos". Em seguida, é necessário baixar e instalar o certificado:
Para permitir que o serviço ADAM use o certificado, você precisa colocar o certificado no armazenamento pessoal do serviço ADAM:
Para conceder permissão de Leitura no certificado de autenticação do servidor à conta de serviço da Rede, faça o seguinte:
Para mais informações, consultar o apêndice A: Configuração de requisitos LDAP sobre SSL para AD LDS.
Em seguida, carregue o certificado da CA que emitiu o certificado para a máquina ADAM/AD LDS como uma fidedignidade de diretório CUCM.
Consulte o Cisco Unified Communications Operations System Administration Guide para obter mais detalhes.
Escolha a caixa de seleção para usar SSL na página Diretório LDAP e na página Autenticação LDAP.
Digite 50001 (neste exemplo) para a porta LDAP, que é o número de porta SSL fornecido quando você instalou a instância ADAM/AD LDS.
Para desabilitar o requisito SSL para redirecionamento de associação, faça o seguinte:
A sincronização e a autenticação do ADAM/AD LDS são suportadas no CUCM versão 9.1(2) e posterior.
O uid é usado somente com ADAM/AD LDS autônomo, e não com suporte para multifloresta AD.
No momento, para o tipo de servidor LDAP "Microsoft ADAM ou Lightweight Diretory Services", samAccountName não está incluído na lista suspensa Atributo LDAP para ID de usuário . O motivo é que não é um atributo suportado com ADAM/AD LDS autônomo. Se a ID de usuário do CUCM mapeada para sAMAccountName precisar ser usada, o contrato deve ser configurado como AD.
O usuário da classe de objeto não é mais usado. Portanto, o filtro LDAP precisa ser alterado para usar userProxy em vez de User.
O filtro padrão é:
(&(objectclass=user)(!(objectclass=Computer))(!(msDS-UserAccountDisabled=TRUE))
Para modificar esse filtro, faça login no CCMAdmin com um navegador da Web e escolha a opção Filtro personalizado LDAP no menu de configuração LDAP.
Esse filtro é usado na página do diretório LDAP ao configurar o acordo de sincronização LDAP como mostrado na figura anterior.