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 unificada Cisco do gerente de uma comunicação (CUCM) em um ambiente da Multi-floresta.
Cisco recomenda que você tem:
Este documento não se restringe a versões de software e hardware específicas.
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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Microsoft AD LD, conhecido anteriormente como ADAM, pode ser usado para proporcionar serviços de diretório para aplicativos diretório-permitidos. Em vez de usar o base de dados do serviço do domínio do diretório ativo da sua organização (AD DS) a fim armazenar os dados do aplicativo diretório-permitidos, o AD LD pode ser usado para armazenar os dados. O AD LD pode ser usado conjuntamente com AD DS de modo que você possa ter um local central para as contas de Segurança (AD DS) e um outro lugar a fim apoiar os dados da configuração do aplicativo e do diretório (AD LD). Com AD LD, você pode reduzir o associado aéreo com replicação AD, você não tem que estender o esquema AD a fim apoiar o aplicativo, e você pode dividir a estrutura do diretório de modo que o serviço AD LD seja distribuído somente aos server que precisam de apoiar o aplicativo diretório-permitido.
Há muitas diferenças entre ADAM e o AD, ADAM pode somente entregar parte das funções entregado pelo AD.
O objetivo deste documento é explicar os mecanismos que permitem CUCM, ou todos os outros produtos Cisco que usarem o serviço da integração de diretório (DirSync), para obter a informação sobre o usuário e executar a autenticação dos domínios diferentes AD que podem existir em florestas diferentes. A fim conseguir este objetivo, ADAM é usado a fim sincronizar sua base de dados de usuário com os controladores de domínio diferentes AD ou as outras fontes LDAP.
ADAM pode criar um base de dados dos usuários e armazenar seus detalhes. O único sinal na funcionalidade (SSO) é desejado a fim evitar os utilizadores finais que têm que manter grupos diferentes de credenciais em sistemas diferentes; consequentemente, a reorientação do ligamento de ADAM é usada. A reorientação do ligamento de ADAM é uma função especial para os aplicativos que apoiam o ligamento LDAP como um mecanismo da autenticação. Em alguns casos, o esquema especial, ou a nomeação do contexto, puderam forçá-lo a evitar o AD, que faz a ADAM uma escolha necessária. Isto evita os usuários que têm que recordar as senhas múltiplas devido ao emprego de um diretório adicional com seu próprio usuário - identificação e senha.
Um objeto do proxy do usuário do special em ADAM traça a uma conta de usuário regular AD. O proxy do usuário não tem uma senha real armazenada no objeto próprio de ADAM. Quando o aplicativo executa sua operação normal do ligamento, verifica o ID localmente, mas verifica a senha contra o AD sob as tampas segundo as indicações desta figura. O aplicativo não precisa de estar ciente desta interação AD.
A reorientação do ligamento de ADAM deve ser usada somente nos casos especiais onde um aplicativo pode executar um ligamento simples LDAP a ADAM. Contudo, o aplicativo ainda precisa de associar o usuário com um principal da Segurança no AD.
A reorientação do ligamento de ADAM ocorre quando um ligamento a ADAM é tentado com uso de um objeto especial chamado um objeto do proxy. Um objeto do proxy é um objeto em ADAM que representa um principal da Segurança no AD. Cada objeto do proxy em ADAM contém SID de um usuário no AD. Quando um usuário tenta ligar ao proxy um objeto, ADAM toma SID que é armazenado no objeto do proxy, junto com a senha que é fornecida no tempo do ligamento, e apresenta SID e a senha ao AD para a autenticação. Um objeto do proxy em ADAM não armazena uma senha, e os usuários não podem mudar suas senhas AD através dos objetos do proxy de ADAM.
A senha é apresentada no texto simples a ADAM porque o pedido inicial do ligamento é um pedido simples do ligamento LDAP. Por este motivo, uma conexão SSL é exigida à revelia entre o cliente do diretório e o ADAM. ADAM usa a Segurança API de Windows a fim apresentar a senha ao AD.
Você pode obter mais informação na reorientação do ligamento em compreender a reorientação do ligamento de ADAM.
A fim explicar o método, imagine uma encenação onde o Cisco Systems (floresta 2) adquira outras duas empresas: Tandberg (floresta 3) e WebEx (floresta 1). Na fase da migração, integre a estrutura AD de cada empresa a fim permitir o desenvolvimento de um único conjunto das comunicações unificadas de Cisco.
No exemplo, a empresa Cisco (floresta 2) tem dois domínios dos domínios, da raiz da floresta chamados CISCO (dns cisco.com) e um subdomínio chamado a emergência (dns emerg.cisco.com). Both of these domínios têm um controlador de domínio que seja igualmente um catálogo global, e cada um é hospedado no server SP2 de Windows 2008.
A empresa que Tandberg (floresta 3) o tem um único domínio com um controlador de domínio que seja igualmente um catálogo global, e é hospedada no server SP2 de Windows 2008.
A empresa que o WebEx (floresta 1) o tem um único domínio com um controlador de domínio que seja igualmente um catálogo global, e é hospedada no server R2 SP2 de Windows 2003.
O AD LD é instalado no controlador de domínio para o domínio CISCO, ou pode ser uma máquina separada; de fato poderia estar em qualquer lugar em uma das três florestas. A infraestrutura DNS deve ser no lugar tais que os domínios em uma floresta podem se comunicar com os domínios em outras florestas e estabelecer as relações de confiança e as validações apropriadas entre as florestas.
Para a autenticação dos usuários a trabalhar, você precisa de ter uma confiança entre o domínio onde o exemplo de ADAM é hospedado, e o outro domínio que hospeda as contas de usuário. Esta confiança pode ser uma confiança de sentido único se for necessário (confiança que parte do domínio que hospeda o exemplo de ADAM ao domínio que hospeda as contas de usuário). Esta maneira, o exemplo de ADAM poderá enviar os pedidos de autenticação aos DC naqueles domínios da conta.
Além disso, você precisará de ter uma conta de usuário de ambos os domínios da conta que tenha o acesso a todos os atributos de todas as contas de usuário no domínio. Esta conta é usada por ADAMSync a fim sincronizar os usuários de domínio da conta a ADAM.
Último mas não de menor importância, a máquina que executa ADAM deve poder encontrar todos os domínios (DNS), encontrar controladores de domínio em ambos os domínios (com DNS), e conectá-los a estes controladores de domínio.
Termine estas etapas a fim estabelecer os relacionamentos do intertrust:
Este é o resultado que você recebe depois que você executa este processo para os domínios de Tandberg e de WebEx. A emergência do domínio está lá à revelia desde que é um domínio infantil. Clique em OK.
Verifique a caixa de verificação de pouco peso dos serviços de diretório do diretório ativo. Clique em Next.
Termine estas etapas a fim estabelecer AD LD em 2012:
O AD LD pode executar exemplos diferentes dos serviços com portas diferentes que permite o diretório de usuário diferente “aplicativos” ser sido executado na mesma máquina. À revelia o AD LD escolhe as portas 389/LDAP e 636/LDAPS, mas se o sistema já tem qualquer tipo dos serviços LDAP que os executam ele usará as portas 50000/LDAP e 50001/LDAPS. Cada exemplo terá um par de portas que o incremento baseou nos números precedentes usados.
Em alguns casos, devido a um erro de Microsoft, as portas são usadas já pelo servidor DNS de Microsoft e o assistente do exemplo dá um erro (que não é evidente). Este erro pode ser fixo quando você reserva as portas na pilha TCP/IP. Se você encontra este problema, veja que começo do serviço AD LD falha com erro “instalação não poderia começar o serviço…” + código de erro 8007041d.
Nota: CUCM apoia somente a única separação do diretório do aplicativo, multi separação não é apoiado atualmente.
Veja a etapa 5: Pratique trabalhar com as separações do diretório do aplicativo para obter informações sobre de como criar uma separação do diretório do aplicativo. O processo para criar uma separação do diretório para cada domínio que você quer sincronizar contra trabalhos baseou na referência LDAP (RFC 2251) e exige que o cliente de LDAP (CUCM, COPO, e assim por diante) apoia referências.
Clique o Yes, crie um botão de rádio da separação do diretório do aplicativo. Dê entrada com o nome da separação no campo de nome da separação para o exemplo. Não forneça uma NC como no exemplo do assistente, porque na maioria das vezes isso cria um erro nos esquemas. Nesta encenação, a mesma separação que o controlador de domínio AD que hospeda AD LD (dc=cisco, dc=com) foi entrada. Clique em Next.
Clique o botão de rádio atualmente entrado do usuário. Dê entrada com o nome do usuário com permissões administrativas. Clique em Next.
Nota: Se ADAM é instalado em Windows 2003 separe, a seguir a tela precedente terá somente quatro opções: MS-AZMan.LDF, MS-InetOrgPerson.LDF, MS-User.LDF, e MS-UserProxy.LDF. Destes quatro, verifique somente as caixas de seleção para ver se há MS-User.LDF e MS-InetOrgPerson.LDF.
Nota: CUCM apoia somente a única separação do diretório do aplicativo, multi separação não é apoiado atualmente.
Veja a etapa 5: Pratique trabalhar com as separações do diretório do aplicativo para obter informações sobre de como criar uma separação do diretório do aplicativo. O processo para criar uma separação do diretório para cada domínio que você quer sincronizar contra trabalhos baseou na referência LDAP (RFC 2251) e exige que o cliente de LDAP (CUCM, COPO, e assim por diante) apoia referências. Veja o apoio de Microsoft para mais informação.
Clique o Yes, crie um botão de rádio da separação do diretório do aplicativo. Dê entrada com o nome da separação. Crie a separação para LD como cisco.com. Todo o valor apropriado pode ser fornecido. Clique em Next.
Se o usuário - os ids (sAMAccountNames) são originais através dos domínios diferentes e lá não são usuários múltiplos com o mesmo ID em domínios diferentes de florestas diferentes, a seguir os usuários podem ser sincronizados do AD às florestas respectivas no AD LD, que pode existir em uma única separação no AD LD em uma multi instalação da floresta. Por exemplo, considere a figura na encenação múltipla do apoio da floresta do diretório ativo na seção CUCM, e se um usuário - a identificação “Alice” existe em somente um dos três domínios que a instalação nesta encenação seria como segue:
FLORESTA DN DA SEPARAÇÃO
Dc=cisco P1 cisco.com, dc=com
webex.com DC=webex, dc=cisco, dc=com
tandberg.com DC=Tandberg, dc=cisco, dc=com
A fim configurar CUCM com AD LD, o usuário - a identificação (sAMAccountName) precisa de ser original através de todas as florestas. CUCM apoia atualmente somente uma única separação em AD LD.
Se os sAMAccountNames não são originais, considere usar qualquens um atributos se identificam excepcionalmente uma conta de usuário - email, telephoneNumber, employeeNumber, uid, ou userPrincipalName.
Uma opção disponível para ajudar a organizar os arquivos que precisam de ser gerados é criar um diretório separado a fim permitir estes arquivos ser separado do diretório principal de c:\windows\adam. Abra um comando prompt e crie um diretório do 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
Refira a utilização da LDIFDE para importar e exportar objetos de diretório ao diretório ativo para opções e formatos de comando adicionais da ldifde.
O objeto para a autenticação de proxy precisa de ser criado e a classe de objeto “usuário” não será usada. A classe de objeto que é criada, userProxy, é o que permite a reorientação do ligamento. O detalhe da classe de objeto precisa de ser criado em um arquivo do ldif. O arquivo é uma criação de um arquivo novo, que neste exemplo seja MS-UserProxy-Cisco.ldf. Este arquivo novo é gerado do MS-UserProxy.ldf original e editado, use um texto editam o programa, para ter este índice:
#==================================================================
# @@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
-
Salvar o arquivo MS-UserProxy-Cisco.ldf em C:\windows\adam.
Importe a classe de objeto nova a AD LD.
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 precisa agora de ser importado a AD LD. Esta etapa precisa de ser repetida para cada domínio que precisa de sincronizar. Este exemplo mostra somente o processo contra um dos domínios. Comece com o MS-AdamSyncConf.xml original e crie um arquivo XML para cada domínio que precisa de ser sincronizado e altere o arquivo com os detalhes específicos a cada domínio para ter este índice:
<?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, estas etiquetas devem ser substituídas para combinar o domínio:
Refira a sintaxe do filtro da busca para obter mais informações sobre de como criar um <object-filter>.
Salvar o arquivo recém-criado XML em C:\windows\adam.
Abra uma janela de comando, CD \ indicadores \ adam.
Incorpore o comando, ADAMSync /install localhost:50000 c:\windows\ADAM\AdamSyncConf1.xml /log c:\windows\adam\logs\install.log.
Verifique que o arquivo AdamSyncConf1.xml é o arquivo recém-criado XML.
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 similar a:
A fim terminar uma sincronização automática do AD a ADAM, use o task scheduler em Windows.
Crie um arquivo do .bat com este índice nele:
“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
Programe a tarefa executar de acordo com as necessidades o arquivo do .bat. Isto tomam das adições, as alterações, e os supressões que acontecem no AD a ser refletido também em ADAM.
Você pode criar um outro arquivo do .bat e programá-lo para terminar uma sincronização automática da outra floresta.
À revelia, ligar a ADAM com reorientação do ligamento exige uma conexão SSL. O SSL exige a instalação e o uso dos Certificados no computador que executa ADAM e no computador que conecta a ADAM como um cliente. Se os Certificados não são instalados em seu ambiente de teste de ADAM, você pode desabilitar a exigência para o SSL como uma alternativa.
À revelia, o SSL é permitido. A fim fazer o trabalho do protocolo LDAP em ADAM/LDS que você precisará de gerar um certificado.
Neste exemplo, o server da autoridade de certificação de Microsoft é usado a fim emitir o certificado. A fim pedir um certificado, vá ao página da web de Microsoft CA - http:// <MSFT CA hostname>/certsrv e termine estas etapas:
Vá para trás à relação da autoridade de certificação e clique o dobrador pendente dos Certificados. Clicar com o botão direito o pedido do certificado feito pela máquina ADAM/AD-LDS e emita o certificado.
O certificado agora tem sido criado e reside “no dobrador dos Certificados emitidos”. Em seguida, você precisa de transferir e instalar o certificado:
A fim deixar o ADAM prestar serviços de manutenção ao uso o certificado, você precisa de pôr o certificado na loja pessoal do serviço de ADAM:
A fim conceder leia a permissão no certificado de autenticação de servidor à conta de serviço de rede, terminam estas etapas:
Mais informação pode ser encontrada no apêndice A: Configurando o LDAP sobre exigências SSL para AD LD.
Em seguida, transfira arquivos pela rede o certificado de CA que emitiu o certificado à máquina ADAM/AD LD como uma confiança do diretório CUCM.
Refira o Guia de Administração de Sistema das operações das comunicações unificadas de Cisco para detalhes adicionais.
Escolha a caixa de seleção a fim usar o SSL na página do diretório LDAP e na página da autenticação LDAP.
Incorpore 50001 (neste exemplo) para a porta LDAP, que é o número de porta SSL dado quando você instalou o exemplo ADAM/AD LD.
A fim desabilitar a exigência SSL para a reorientação do ligamento, termine estas etapas:
A sincronização e a autenticação ADAM/AD LD são apoiadas na versão 9.1(2) e mais recente CUCM.
o uid é usado somente com ADAM/AD autônomo LD e não com apoio da multi-floresta AD.
Atualmente, para o tipo de servidor ldap de “modo Microsoft ADAM ou dos serviços de diretório de pouco peso”, o samAccountName não é incluído no atributo LDAP para a gota-para baixo Userid. A razão é que não é um atributo apoiado com ADAM/AD autônomo LD. Se o CUCM UserID traçado ao sAMAccountName precisa de ser usado então que o acordo deve ser configurado como o AD.
O usuário da classe de objeto é usado já não. Consequentemente, o filtro LDAP precisa de ser mudado para usar o userProxy em vez do usuário.
O filtro do padrão é:
(& (objectclass=user) (! (objectclass=Computer))(! (msDS-UserAccountDisabled=TRUE)))
A fim alterar este filtro, entre ao ccmadmin com um navegador da Web e escolha a opção de filtro feita sob encomenda LDAP do menu da configuração ldap.
Este filtro é usado na página do diretório LDAP ao configurar o LDAP o acordo da sincronização segundo as indicações da figura precedente.