Alta Escalabilidade e Disponibilidade do AIX secldapclntd usando a proxy do Tivoli Directory Server

O daemon secldapclntd fornece e gerencia a conexão entre o módulo de carregamento de segurança do LDAP de AIX® do host local e um servidor do LDAP e trata transações do módulo de carregamento do LDAP para o servidor do LDAP. Etapas simples de configuração não permitem especificar servidores do LDAP altamente disponíveis e escaláveis no backend. Este artigo lista as etapas para configurar um LDAP de backend altamente disponível e escalável para o daemon secldapclntd usando a proxy do Tivoli ® Directory Server proxy.

Nikhil Firke, System Software Engineer, IBM India Software Labs

Nikhil FirkeNikhil é 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 T. Patel, System Software Engineer, IBM India Software Labs

Nilesh PatelNilesh é 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®.



13/Dez/2010

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:

Figura 1. Configuração de amostra
Sample configuration

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
    Sample configuration
  • 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
    Replication topology for 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

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.

Figura 4. Configuração típica para a autenticação
Typical setup for authentication

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

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

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tivoli
ArticleID=600822
ArticleTitle=Alta Escalabilidade e Disponibilidade do AIX secldapclntd usando a proxy do Tivoli Directory Server
publish-date=12132010