Introdução

Em qualquer ambiente distribuído, para manter o acesso universal, a autenticação consistente e os serviços de autorização são uma necessidade. Um grande número de implementações desse tipo usam o IBM Directory Server (TDS) para fins de segurança centralizada.

A centralização dos serviços de autenticação e senha não só aumenta a segurança, mas também reduz a sobrecarga administrativa associada a ela. Uma boa solução para este problema é ter um único servidor que trata todas as solicitações em um ambiente. Entretanto, essa vantagem compromete a alta disponibilidade do servidor. A alta disponibilidade é desejada sempre em qualquer solução de autenticação do usuário, pois, se um único servidor de autenticação fica inativo, todo o empreendimento pode parar de funcionar. Com o LDAP, há duas opções para combater essa situação. O IBM Tivoli Directory Server fornece os recursos de replicação que podem ser usados para configurar os servidores no modo principal/principal ou principal/réplica. Na configuração principal/principal, não há servidor principal e as mudanças feitas em qualquer dos servidores são propagadas para os outros mestres. Na configuração principal/réplica, todas as mudanças ocorrem no servidor principal e as atualizações são propagadas para uma réplica ou mais. A replicação pode ser configurada para ocorrer de forma planejada ou imediatamente depois que a mudança é concluída no servidor principal.

Para demonstrar uma solução escalável, este artigo apresenta uma proxy do TDS na configuração do secldapclntd. Uma grande quantidade de informações sobre o usuário definidas em um único servidor do LDAP pode fazer com que o tempo de resposta aumente, e o sistema como um todo pode ficar mais lento. Para aumentar a escalabilidade do sistema, este artigo propõe uma solução com diretórios distribuídos. Um diretório distribuído é um ambiente de diretório no qual os dados são particionados em vários servidores de diretórios.

O servidor proxy é um tipo especial de servidor do IBM Tivoli Directory que pode receber solicitações dos clientes e roteá-los conforme a necessidade. Além de rotear as solicitações, o servidor proxy também pode fazer balanceamento de carga, failover e autenticação distribuída. Já que os clientes no ambiente só têm conhecimento do servidor proxy de frontend, o cluster de servidores atrás do servidor proxy permanece oculto e uma visualização de diretório unificado é apresentada ao cliente.

Introdução ao do servidor proxy do TDS

O LDAP é usado para armazenar qualquer tipo de informação semelhante a um diretório que precise de consultas rápidas e atualizações menos frequentes. Espera-se que os servidores do LDAP corporativos armazenem milhões de entradas. E suportem esse grande número de entradas e as solicitações correspondentes a elas e, ainda assim, não receber chamadas sobre deterioração do desempenho do hardware altamente escalável. Para tratar desses problemas, pode-se usar um diretório distribuído.

Os diretórios distribuídos foram introduzidos para resolver os problemas de desempenho e escalabilidade. Os diretórios distribuídos ajudam a dividir a grande quantidade de dados em mais de um servidor. Com os dados distribuídos, o número de solicitações que chega a cada servidor é reduzido automaticamente, facilitando o gerenciamento da configuração.

Essa configuração do diretório distribuído é abstraída muito eficazmente ao incluir um servidor proxy na frente dela. Os clientes só têm conhecimento da proxy, e o servidor proxy é configurado com os detalhes dos dados distribuídos no backend. O servidor proxy é configurado com a metodologia de dividir os dados. Isso permite que a proxy obtenha os dados a partir do backend e os transfira para os clientes. A interação entre o servidor proxy e os servidores de diretórios de backend é totalmente transparente para os clientes. Um servidor proxy também pode atuar como balanceador de carga ou gerenciador de failover.

Os recursos-chave do servidor proxy do Tivoli Directory são:

• Escalabilidade: a escalabilidade é um requisito importante de um servidor de diretórios. O diretório distribuído escala eficazmente qualquer configuração de diretório.

  Há formas diferentes de configurar um diretório distribuído. Os mecanismos disponíveis atualmente são:

  • Divisão de RDN baseada emhash: a entrada de servidor de diretórios é usada para calcular um valor de hash exclusivo. O valor de hash é calculado com base no RDN da entrada. Quando os diretórios são distribuídos, esse valor de hash é correlacionado a uma entrada específica em um servidor de diretórios específico no backend.
  • Divisão baseada em subárvore: nesse mecanismo de divisão, cada subárvore é configurada para residir em um servidor de diretórios separado no backend.
• Abstração: o servidor proxy age como uma camada abstração sobre um conjunto de servidores de diretórios. Um cliente vê a topologia completa como um diretório unificado e não tem conhecimento da distribuição no backend. Além disso, a interação entre o backend e o servidor de diretórios é transparente para os clientes.

Configurar o secldapclntd com a proxy do TDS

O comando mksecldap pode ser usado para configurar o cliente e o servidor para qualquer configuração típica com secldapclntd e o IBM Tivoli Directory Server. De forma muito geral, as seguintes etapas são realizadas pelo comando mksecldap durante a configuração do servidor:

1. Cria uma instância padrão do IBM Tivoli Directory Server chamada ldapdb2.
2. Configura o sufixo sob o qual os usuários de AIX e os grupos serão armazenados.
3. O banco de dados de LDAP é carregado com as informações sobre grupos e usuários provenientes dos arquivos de banco de dados de segurança do host local.
4. O DN e a senha do administrador do servidor do LDAP são configurados.
5. O plug-in de auditoria do AIX para o servidor do LDAP é instalado.
6. O servidor do LDAP é iniciado.
7. O mecanismo padrão de criptografia de senha é alterado para crypt.
8. Inclui a entrada do servidor do LDAP (slapd) em/etc/inittab para reinício automático depois da reinicialização.

Este artigo não usa o comando mksecldap para configurar o servidor do LDAP. Evitaremos usar o mksecldap porque o nosso objetivo final é configurar os clientes de AIX com o servidor proxy do TDS, e não o backend de RDBM do TDS. Se usarmos o comando mksecldap, acabaremos tendo um servidor de RDBM do TDS configurado com os clientes de AIX. O servidor de RDBM do TDS tem um ® backend de DB2, do qual não precisamos.

Precisamos de um servidor proxy do TDS configurado com os clientes de AIX. Os servidores proxy não têm um backend de DB2.

Todos os dados do AIX estão na subárvore cn=aixdata. Essa subárvore, por sua vez, tem outras subárvores separadas sob ela que contêm as entradas de usuários, entradas de grupo e outras informações necessárias. As informações sobre os usuários estão presentes em ou=people,cn=aixdata. Já que a subárvore ou=people, cn=aixdata tem o número máximo de ocorrências, dividiremos essa subárvore em dois servidores de backend do TDS de forma que a carga seja distribuída em dois backends atrás da proxy. A base da subárvore de nível superior cn=aixdata só estará em um servidor de backend atrás da proxy.

Configuraremos um ambiente semelhante a este:

Os detalhes da figura são:

1. Proxy do TDS: a proxy do TDS é o Tivoli Directory Proxy Server, do qual os clientes no ambiente têm conhecimento.
2. Linhas azuis: as linhas azuis atrás do servidor proxy mostram a topologia de replicação para cn=aixdata e cn=ibmpolocies.
3. Linhas pretas: as linhas pretas atrás do servidor proxy mostram a topologia de replicação de ou=People,cn=aixdata.
4. secldapinst1a e secldapinst1b: são as divisões de replicação do RDBM que contêm a subárvore completa para cn=aixdata e cn=ibmpolocies e a subárvore parcial para ou=People,cn=aixdata.
5. secldapinst2a e secldapinst2b: são as divisões de replicação do RDBM que contêm subárvore parcial para ou=People,cn=aixdata. A subárvore completa para cn=aixdata (que não seja a subárvore completa para ou=People,cn=aixdata) e cn=ibmpolocies estaria presente aqui por causa da topologia de replicação.
6. Grupo de servidores 1: o grupo de servidores 1 agrupa secldapinst1a e secldapinst1b, deixando-o altamente disponível.
7. Grupo de servidores 2: o grupo de servidores 2 agrupa secldapinst2a e secldapinst2b, deixando-o altamente disponível.

Etapas para configurar a replicação para os backends

Basicamente,iremos nos concentrar nos dados sob cn=aixdata e cn=ibmpolicies. Os dados sob cn=aixdata (com exceção da subárvore ou=people,cn=aixdata) e cn=ibmpolicies estarão presente em todos os quatro servidores na nossa configuração. Antes de começar a configurar a replicação, as etapas básicas a seguir são necessárias para criar a instância do e prepará-la para a configuração de replicação.

• Criar quatro instâncias do TDS usando os comandos a seguir e executar estes comandos para criar a instância de RDBM do ITDS:
  
  Listagem 1. Criar e configurar as instâncias de RDBM do TDS
  

  Add user aixauth # idsadduser -g idsldap -l /home/aixauth -u aixauth -w aixauth Create TDS instance # idsicrt -I aixauth -e abcd1234567890 -l /home/aixauth -n Configure database instance with this TDS instance # idscfgdb -I aixauth -l /home/aixauth -a aixauth -w aixauth -t aixauth -n Configure Admin username and password # idsdnpw -I aixauth -u cn=root -p root -n Configure cn=aixdata suffix # idscfgsuf -I aixauth -s cn=aixdata -n Start TDS instance to change default password encryption # ibmslapd -I aixauth -n < Change default password encryption to crypt # idsldapadd -D cn=root -w root dn: cn=Configuration changetype : modify replace : ibm-slapdPwEncryption ibm-slapdPwEncryption: crypt

  
  

  Vamos supor que as quatro instâncias criadas estejam em máquinas separadas e cada uma dessas instâncias tenha recebido o nome aixauth. Aqui, estamos supondo que o nome do host das quatro caixas seja secldapinst1a.ibm.com, secldapinst1b.ibm.com, secldapinst2a.ibm.com esecldapinst2b.ibm.com.

• Configure a replicação paracn=aixdata e cn=ibmpolicies.

  Configure a replicação ponto a ponto entre as quatro instâncias da subárvore cn=aixdata. A replicação para a subárvore cn=aixdata deve ter a seguinte aparência:

  
  
  Figura 2. Amostra de configuração
  
  
  
• Configure a topologia de replicação ponto a ponto como um grupo de duas instâncias entre secldapinst1a.ibm.com esecldapinst1b.ibm.com (como Grupo de Servidores 1) e secldapinst2a.ibm.com e secldapinst2b.ibm.com (como Grupo de Servidores 2) para a subárvore ou=people,cn=aixdata.

  A configuração de uma topologia de replicação diferente sob uma base que já está com a replicação configurada pode ser muito chata. Deve-se tomar cuidado ao configurar essa topologia. Na etapa anterior, configuramos a replicação para cn=aixdata; agora estamos configurando uma topologia de replicação diferente para a entrada ou=people,cn=aixdata, que está sob cn=aixdata. Conforme o design do TDS, podemos usar uma configuração desse tipo, na qual temos topologias de replicação aninhadas.

  A replicação para essa subárvore deve ter a seguinte aparência:

  
  
  Figura 3. Topologia de replicação para ou=people,cn=aixdata
  
  
  

Configuração de proxy do TDS

• Inclua o membro do grupo Global Admin

  Execute os comandos a seguir em qualquer servidor backend. Isso só pode ser feito em uma instância porque, como uma replicação em cn=ibmpolocies já está configurada, ela replicará para os outros três servidores.

  
  
  Listagem 2. Comando para incluir o membro do grupo Admin
  

  # idsldapadd -h secldapinst1a.ibm.com -D cn=root -w root dn: cn=manager,cn=ibmpolicies objectclass: person sn: manager cn: manager userpassword: sec001ret # idsldapmodify -h secldapinst1a.ibm.com -D cn=root -w root dn: globalGroupName=GlobalAdminGroup,cn=ibmpolicies changetype: modify add: member member: cn=manager,cn=ibmpolicies

  
  
• Crie e configure uma instância de proxy do TDS.

  Execute os comandos a seguir para criar e configurar a instância de proxy do TDS.

  
  
  Listagem 3. Criar e configurar a instância de proxy do TDS
  

  Add user proxy # idsadduser -g idsldap -l /home/proxy -u proxy -w proxy Create TDS proxy instance # idsicrt -I proxy -e abcd1234567890 -l /home/proxy -x -n Configure Admin username and password # idsdnpw -I proxy -u cn=root -p root -n Start the TDS proxy instance in configuration mode to change default password encryption # ibmslapd -I proxy -a Change default password encryption to crypt # idsldapmodify -h secldapproxy.ibm.com -D cn=root -w root dn: cn=Configuration changetype : modify replace : ibm-slapdPwEncryption ibm-slapdPwEncryption: crypt

  
  
• Defina o contexto de nomenclatura na instância de proxy do TDS.

  Execute os comandos a seguir em uma instância de proxy do TDS para incluir cn=aixdata, cn=ibmpolicies e ou=people,cn=aixdata como contextos de nomenclatura.

  
  
  Listagem 4. Definir os contextos de nomenclatura no servidor proxy do TDS
  

  # idsldapmodify -h secldapproxy.ibm.com -D cn=root -w root dn: cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory, cn=Schemas, cn=Configuration changetype : modify add : ibm-slapdSuffix ibm-slapdSuffix: cn=aixdata - add : ibm-slapdSuffix ibm-slapdSuffix: ou=people, cn=aixdata - add : ibm-slapdSuffix ibm-slapdSuffix: cn=ibmpolicies

  
  
• Defina os quatro servidores de backend para o servidor proxy do TDS.

  Execute os comandos a seguir na instância de proxy do TDS, e ela registrará todos os quatro backends na proxy do TDS com um conjunto de conexões de 10.

  
  
  Listagem 5. Defining the backend servers
  

  # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=secldapinst1a,cn=ProxyDB,cn=Proxy Backends,cn=IBM Directory,\ cn=Schemas,cn=Configuration cn: secldapinst1a ibm-slapdProxyBindMethod: Simple ibm-slapdProxyConnectionPoolSize: 10 ibm-slapdProxyDN: cn=manager,cn=ibmpolicies ibm-slapdProxyPW: sec001ret ibm-slapdProxyTargetURL: ldap://secldapinst1a.ibm.com:389 objectClass: top objectClass: ibm-slapdProxyBackendServer objectClass: ibm-slapdConfigEntry # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=secldapinst1b,cn=ProxyDB,cn=Proxy Backends,cn=IBM Directory,\ cn=Schemas,cn=Configuration cn: secldapinst1b ibm-slapdProxyBindMethod: Simple ibm-slapdProxyConnectionPoolSize: 10 ibm-slapdProxyDN: cn=manager,cn=ibmpolicies ibm-slapdProxyPW: sec001ret ibm-slapdProxyTargetURL: ldap://secldapinst1b.ibm.com:389 objectClass: top objectClass: ibm-slapdProxyBackendServer objectClass: ibm-slapdConfigEntry # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=secldapinst2a,cn=ProxyDB,cn=Proxy Backends,cn=IBM Directory,\ cn=Schemas,cn=Configuration cn: secldapinst2a ibm-slapdProxyBindMethod: Simple ibm-slapdProxyConnectionPoolSize: 10 ibm-slapdProxyDN: cn=manager,cn=ibmpolicies ibm-slapdProxyPW: sec001ret ibm-slapdProxyTargetURL: ldap://secldapinst2a.ibm.com:389 objectClass: top objectClass: ibm-slapdProxyBackendServer objectClass: ibm-slapdConfigEntry # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=secldapinst2b,cn=ProxyDB,cn=Proxy Backends,cn=IBM Directory,\ cn=Schemas,cn=Configuration cn: secldapinst2b ibm-slapdProxyBindMethod: Simple ibm-slapdProxyConnectionPoolSize: 10 ibm-slapdProxyDN: cn=manager,cn=ibmpolicies ibm-slapdProxyPW: sec001ret ibm-slapdProxyTargetURL: ldap://secldapinst2b.ibm.com:389 objectClass: top objectClass: ibm-slapdProxyBackendServer objectClass: ibm-slapdConfigEntry

  
  
• Defina o Grupo de servidores 1 e o Grupo de Servidores 2.

  A definição dos grupos de servidores garante a manutenção da alta disponibilidade. Se o servidor proxy não consegue contatar um servidor de backend ou se a autenticação falha, a inicialização do servidor proxy falha e o servidor proxy inicia no modo somente de configuração por padrão, a menos que os agrupamentos de servidores tenham sido definidos no arquivo de configuração. Os agrupamentos de servidores possibilitam que o usuário declare que vários servidores de backend são espelhos uns dos outros, e o processamento do servidor proxy pode continuar até mesmo se um servidor de backend (ou mais) do grupo está inativo, supondo que pelo menos um servidor de backend esteja online. As conexões são reiniciadas periodicamente se as conexões estão fechadas por algum motivo, como a parada ou a reinicialização do servidor remoto.

  
  
  Listagem 6. Definindo grupos de servidores
  

  # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=serverGroupA, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory,\ cn=Schemas, cn=Configuration cn: serverGroupA ibm-slapdProxyBackendServerDN: cn=secldapinst1a,cn=ProxyDB,cn=Proxy Backends,\ cn=IBM Directory, cn=Schemas,cn=Configuration ibm-slapdProxyBackendServerDN: cn=secldapinst1b,cn=ProxyDB,cn=Proxy Backends,\ cn=IBM Directory, cn=Schemas,cn=Configuration objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdProxyBackendServerGroup # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=serverGroupB, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory, cn=Schemas,\ cn=Configuration cn: serverGroupB ibm-slapdProxyBackendServerDN: cn=secldapinst2a,cn=ProxyDB,cn=Proxy Backends,\ cn=IBM Directory, cn=Schemas,cn=Configuration ibm-slapdProxyBackendServerDN: cn=secldapinst2b,cn=ProxyDB,cn=Proxy Backends,\ cn=IBM Directory, cn=Schemas,cn=Configuration objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdProxyBackendServerGroup

  
  
• Definindo as divisões.

  Os comandos a seguir definem as divisões sob cn=ibmpolicies, cn=aixdata e ou=people,cn=aixdata.

  
  
  Listagem 7. Definindo divisões diferentes
  

  ======== cn=ibmpolicies split definitions : ======== # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=cn\=ibmpolicies split, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory,\ cn=Schemas, cn=Configuration cn: cn=ibmpolicies split ibm-slapdProxyNumPartitions: 1 ibm-slapdProxyPartitionBase: cn=ibmpolicies ibm-slapdProxySplitName: ibmpolicysplit objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdProxyBackendSplitContainer # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=split1, cn=cn\=ibmpolicies split, cn=ProxyDB, cn=Proxy Backends,\ cn=IBM Directory, cn=Schemas, cn=Configuration cn: split1 ibm-slapdProxyBackendServerDN: cn=secldapinst1a,cn=ProxyDB,cn=Proxy Backends,\ cn=IBM Directory,cn=Schemas,cn=Configuration ibm-slapdProxyBackendServerRole: any ibm-slapdProxyPartitionIndex: 1 objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdProxyBackendSplit ======== cn=aixdata split definitions : ======== # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=cn\=aixdata, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory, cn=Schemas,\ cn=Configuration cn: cn=aixdata ibm-slapdProxyNumPartitions: 1 ibm-slapdProxyPartitionBase: cn=aixdata ibm-slapdProxySplitName: ouaixdatasplit objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdProxyBackendSplitContainer # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=split1, cn=cn\=aixdata, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory,\ cn=Schemas, cn=Configuration cn: split1 ibm-slapdProxyBackendServerDN: cn=secldapinst1a,cn=ProxyDB,cn=Proxy Backends,\ cn=IBM Directory,cn=Schemas,cn=Configuration ibm-slapdProxyBackendServerRole: any ibm-slapdProxyPartitionIndex: 1 objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdProxyBackendSplit ======== ou=people,cn=aixdata split ======== # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=ou\=people\,cn\=aixdata, cn=ProxyDB, cn=Proxy Backends, cn=IBM Directory,\ cn=Schemas, cn=Configuration cn: ou=peple,cn=aixdata ibm-slapdProxyNumPartitions: 2 ibm-slapdProxyPartitionBase: ou=People,cn=aixdata ibm-slapdProxySplitName: oupoepleouaixdatasplit objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdProxyBackendSplitContainer # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=split1, cn=ou\=people\,cn\=aixdata, cn=ProxyDB, cn=Proxy Backends,\ cn=IBM Directory, cn=Schemas, cn=Configuration cn: split1 ibm-slapdProxyBackendServerDN: cn=secldapinst1a,cn=ProxyDB,cn=Proxy Backends,\ cn=IBM Directory,cn=Schemas,cn=Configuration ibm-slapdProxyBackendServerRole: any ibm-slapdProxyPartitionIndex: 1 objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdProxyBackendSplit # idsldapadd -h secldapproxy.ibm.com -D cn=root -w root dn: cn=split2, cn=ou\=people\,cn\=aixdata, cn=ProxyDB, cn=Proxy Backends,\ cn=IBM Directory, cn=Schemas, cn=Configuration cn: split2 ibm-slapdProxyBackendServerDN: cn=secldapinst2a,cn=ProxyDB,cn=Proxy Backends,\ cn=IBM Directory,cn=Schemas,cn=Configuration ibm-slapdProxyBackendServerRole: any ibm-slapdProxyPartitionIndex: 2 objectclass: top objectclass: ibm-slapdConfigEntry objectclass: ibm-slapdProxyBackendSplit

  
  
• sectoldif - segurança local do AIX para a migração de dados de LDAP

  O comando sectoldif é uma ferramenta de migração fornecida com o AIX para migrar dados de segurança locais para o LDAP. Pode converter os dados do sistema local diretamente para um dos três esquemas: RFC2307, RFC2307AIX ou o esquema do AIX. Os dados são gravados na saída padrão. Em seguida, o arquivo LDIF pode ser importado para o servidor do LDAP usando o comando idsldapadd.

  
  
  Listagem 8. Convertendo as informações do sistema para o formato LDIF
  

  # sectoldif -d cn=aixdata -S RFC2307 > /tmp/systeminfo.ldif

  
  

  Para carregar os dados a partir do servidor de AIX já existente, execute o comando sectoldif para que o usuário/grupo e outras informações sejam transferidos no formato LDIF. Depois de obter essas informações, é possível carregar diretamente o LDIF de saída no servidor proxy.

• Use o comando idsldapadd para carregar os dados.

  Depois que todos os dados estiverem no formato LDIF, é possível carregar facilmente esses dados no seu ambiente usando o comando idsldapadd. Execute essa operação de carregamento no servidor proxy. A inclusão das informações no servidor proxy garante que as entradas específicas vão para a divisão de proxy correta.

  
  
  Listagem 9. Carregando os dados do LDIF
  

  # idsldapadd -h secldapproxy.ibm.com -D cn=manager,cn=ibmpolicies -w sec001ret \ -c -i /tmp/systeminfo.ldif

  
  
• Use o comando mksecldap para configurar clientes com a proxy.

  Agora os servidores do LDAP estão prontos. Você tem uma configuração pronta com a topologia de replicação desejada e também um servidor proxy que os clientes contatarão.

  
  
  Listagem 10. Comando para configurar um cliente
  

  # mksecldap -c -h secldapproxy.ibm.com -a cn=manager,cn=ibmpolicies -p sec001ret

  
  

Voltar para parte superior

Introduzindo a proxy do ITDS em um ambiente já existente

Em um ambiente de produção típico, o repositório do usuário é mantido em um servidor do LDAP centralizado. Todos os clientes autenticam o servidor do LDAP. A alta disponibilidade é mantida por meio de um servidor do LDAP peer/principal. A Figura 4 mostra a topologia.

Com essa configuração estabelecida, é necessário obter um servidor proxy do ITDS estabelecido entre a infraestrutura já existente e os clientes. Para começar, é necessário obter o backup da subárvore básica (por exemplo: cn=aixdata). As etapas são estas:

1. Fazer o backup dos dados sob ou=people,cn=aixdata. Essa subárvore terá todos os dados dos usuários, como gidnumber, shell de login, detalhes do último login, etc.
   
   Listagem 11. Obter o dump de LDIF para ou=people,cn=aixdata
   

   # idsdb2ldif -I aixauth -s ou=people,cn=aixdata -o /tmp/people.ldif

   
   
2. Após fazer o backup dos dados sob ou=people,cn=aixdata, exclua a mesma subárvore, para que os backups subsequentes não tenham cópias.
   
   Listagem 12. Excluir os dados sobou=people,cn=aixdata do servidor
   

   # idsldapdelete -D cn=root -w root -s ou=people,cn=aixdata

   
   
3. Faça o backup dos dados sob cn=aixdata. Nesse backup, não há dados sob ou=people,cn=aixdata.
   
   Listagem 13. Obter o dump de LDIF referente a cn=aixdata
   

   # idsdb2ldif -I aixauth cn=aixdata -o /tmp/aixdata.ldif

   
   
4. Excluir os dados sob cn=aixdata.
   
   Listagem 14. Excluir os dados sob cn=aixdata do servidor
   

   # idsldapdelete -D cn=root -w root -s cn=aixdata

   
   
5. Alterar a criptografia da senha para crypt.
   
   Listagem 15. Alterar a criptografia padrão de senha para crypt
   

   # idsldapadd -D cn=root -w root dn: cn=Configuration changetype : modify replace : ibm-slapdPwEncryption ibm-slapdPwEncryption: crypt

   
   
6. Criar duas instâncias novas. Você usará a configuração já existente da replicação peer/peer para se tornar um dos grupos de servidores (digamos que seja o Grupo de Servidores 1, como mostra a Figura 1). As duas novas instâncias que estão sendo incluídas nesse grupo serão usadas como outra configuração de servidores, que conterá toda a subárvore cn=aixdata, a subárvore cn=ibmpolicies e uma parte da subárvore ou=people,cn=aixdata.
   
   Listagem 16. Criar duas novas instâncias, de preferência em dois servidores diferentes
   

   Add user aixauth # idsadduser -g idsldap -l /home/aixauth -u aixauth -w aixauth Create TDS RDBM instance # idsicrt -I aixauth -e abcd1234567890 -l /home/aixauth -n Configure database instance with this TDS instance # idscfgdb -I aixauth -l /home/aixauth -a aixauth -w aixauth -t aixauth -n Configure Admin username and password # idsdnpw -I aixauth -u cn=root -p root -n Configure cn=aixdata suffix # idscfgsuf -I aixauth -s cn=aixdata -n Start TDS instance to change default password encryption # ibmslapd -I aixauth -n Change default password encryption to crypt # idsldapadd -D cn=root -w root dn: cn=Configuration changetype : modify replace : ibm-slapdPwEncryption ibm-slapdPwEncryption: crypt

   
   

7. As etapas a seguir devem ser realizadas para configurar o ambiente. Como você já aprendeu detalhadamente as etapas na seção anterior, daremos apenas uma referência à seção/listagem de código acima nesta seção ao listar as etapas.

   • Configure a replicação entre as quatro instâncias do TDS para cn=aixdata e cn=ibmpolicies. Duas instâncias eram do ambiente já existente e outras duas instâncias foram criadas na Listagem 14.
   • Carregar os dados em qualquer um dos servidores a partir do arquivo /tmp/aixdata.ldif. Esse arquivo LDIF foi coletado da Listagem 13.
   • Incluir a entrada ausente de ou=people,cn=aixdata somente nos servidores.
   • Configure a topologia de replicação ponto a ponto como um grupo de duas instâncias entre secldapinst1a.ibm.com e secldapinst1b.ibm.com (como Grupo de Servidores 1) e secldapinst2a.ibm.com e secldapinst2b.ibm.com (como Grupo de Servidores 2) para a subárvore ou=people,cn=aixdata. A topologia deve se parecer com a da Figura 3.
   • Siga as etapas mencionadas na seção Configuração de proxy do TDS deste artigo para configurar e ativar um servidor proxy para o seu uso.
   • Incluir os dados coletados em aixdata.ldif da Listagem 13.
8. 
   
   Listagem 17. Carregando os dados a partir do LDIF
   

   idsldapadd command can be used as follows : # idsldapadd -h secldapproxy.ibm.com -D cn=manager,cn=ibmpolicies -w sec001ret \ -c -i /tmp/aixdata.ldif

   
   
9. Comando mksecldap para configurar clientes com a proxy.
   
   Listagem 18. Comando para configurar um cliente
   

   # mksecldap -c -h secldapproxy.ibm.com -a cn=manager,cn=ibmpolicies -p sec001ret

   
   

Recursos

Aprender

• Documentação do IBM Tivoli Directory Server contém informações sobre instalação, configuração, administração e uso do Tivoli Directory Server.
  
  
• Saiba mais sobre o daemon secldapclntd .
  
  
• Introdução ao servidor proxy ITDSv6.1
  
  

Obter produtos e tecnologias

• Faça o download das versões de avaliação de produtos IBM e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2 ®, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  

Discutir

• Participe dos fóruns de AIX e UNIX:
  • Fórum de AIX
  • Fórum de AIX para desenvolvedores
  • Gerenciamento de sistemas de cluster
  • Fórum do Assistente de Suporte IBM
  • Fórum de ferramentas de desempenho
  • Fórum de virtualização
  • Mais fóruns de AIX e UNIX
  
  
• Blogs do developerWorks e participe da comunidade do developerWorks .
  
  

Sobre os autores

Nikhil é engenheiro de software de sistemas e atualmente trabalha com a equipe de suporte nível 2 do Tivoli Directory Server, nos Laboratórios de Software IBM Índia. É formado em Engenharia da Computação pelo Pune Institute of Computer Technology, de Pune (Índia).

Nilesh é engenheiro de software de sistemas. Trabalha atualmente com a equipe de segurança Tivoli nível 2, nos laboratórios de software IBM Índia e é formado em tecnologia da informação pelo Pune Institute of Computer Technology, de Pune (Índia). As suas áreas de conhecimento envolvem IBM Tivoli Directory Server dos Tivoli Security Products e DB2®.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Introdução ao do servidor proxy do TDS
• Configurar o secldapclntd com a proxy do TDS
• Etapas para configurar a replicação para os backends
• Configuração de proxy do TDS
• Introduzindo a proxy do ITDS em um ambiente já existente
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais