Introdução - Limitação ao utilitário secldap (mksecldap)

O servidor do LDAP é parte importante de qualquer configuração de segurança. No AIX, o daemon secldapclntd gerencia a conexão entre o servidor do LDAP e o módulo interno do LDAP de segurança do AIX. No AIX, a implementação do LDAP do subsistema de segurança está disponível como um módulo de carregamento de autenticação do LDAP. Esse módulo é um pacote completo que oferece suporte para a autenticação do usuário. Os desenvolvedores criaram um utilitário, o mksecldap, para simplificar a configuração do daemon secldapclntd. O comando mksecldap pode ser usado para configurar um servidor de informações de segurança do LDAP.

O IBM Tivoli Directory Server é o servidor do LDAP mais usado e recomendado para a infraestrutura de segurança do AIX. A configuração do gerenciamento de usuários/grupos no AIX usando servidores do IBM Tivoli Directory Server é altamente recomendada. No entanto, ao configurar o daemon secldapclntd, o utilitário mksecldap permite o fornecimento exclusivo de detalhes típicos do servidor do LDAP durante o processo de configuração. Não há opção de fornecimento de uma fonte de dados de autenticação secundária, que poderia ser analisada, como alternativa, se os dados não fossem encontrados no servidor do LDAP primário. No entanto, diversos servidores do LDAP que contêm os dados replicados podem ser configurados com o daemon secldapclntd. Os servidores replicados são ativados quando uma solicitação para os servidores padrão encontrar um RC = 81 (Não é possível contatar o servidor do LDAP) do servidor. Com essa limitação, torna-se necessário o armazenamento de todas as informações sobre autenticação do usuário pelo único servidor do LDAP.

Existem cenários nos quais o Tivoli Directory Server precisa oferecer suporte aos usuários presentes em outro servidor de diretórios. A migração dos usuários de outro diretório para o Tivoli Directory Server é uma das soluções possíveis. Mas esse é um esforço que não consome somente tempo, é preciso considerar o fator de escalabilidade do único Tivoli Directory Server que terá que tratar repentinamente um aumento de carga. A manutenção dos usuários em dois diretórios diferentes ocupa muito espaço e a manutenção dos usuários em sincronia nos dois diretórios causará outra sobrecarga administrativa. Além dos problemas de escalabilidade e de uso da memória, a compatibilidade com os aplicativos existentes também precisa ser considerada. A migração de todos os aplicativos existentes para um novo servidor do LDAP não pode ser feita em curto prazo e normalmente demora para configurar os aplicativos atualizados com um novo servidor do LDAP.

Para resolver essa limitação do secldap, este artigo demonstra o uso do recurso de autenticação de passagem do Tivoli Directory Server. Esse recurso foi apresentado no Tivoli Directory Server V6.1, mas nós usaremos o Tivoli Directory Server V6.2 para demonstrar a nossa configuração de amostra.

Voltar para parte superior

Histórico conceitual da autenticação de passagem

O Tivoli Directory Server fornece autenticação do usuário para os usuários armazenados no seu diretório. Todos os clientes que usam o Tivoli Directory Server e estão procurando informações sobre autenticação precisam se conectar ao Tivoli Directory Server correto para recuperar as informações sobre autenticação. O usuário tem que executar uma conexão bem sucedida ao diretório usando sua senha para ser autorizado para as operações de LDAP subsequentes. Por padrão, o Tivoli Directory Server somente oferece suporte para a autenticação dos usuários locais (isto é, os usuários presentes no diretório local).

A autenticação de passagem é um mecanismo que permite ao cliente a conexão a um servidor de diretórios mesmo se as credenciais do usuário não estiverem disponíveis localmente. Ao usar esse mecanismo, o servidor tenta verificar as credenciais em outro servidor de diretórios externo ou servidor de passagem em prol do cliente. A credencial aqui se refere ao atributo de senha de usuário no Tivoli Directory Server.

1. Normalmente, o cliente se conecta ao Tivoli Directory Server sem o conhecimento de nenhuma configuração de autenticação de passagem.
2. O Tivoli Directory Server determina que a entrada do cliente específico existe, mas o atributo de senha de usuário, que ajudaria na autenticação do cliente, não existe. Se a autenticação de passagem não for configurada no Tivoli Directory Server, ele não irá procurar as credenciais em nenhum outro servidor. No entanto, se o servidor for configurado para executar uma autenticação de passagem em outro servidor, o Tivoli Directory Server continuará com as etapas a seguir.
3. As mesmas credenciais usadas pelo cliente para conexão ao Tivoli Directory Server são usadas para conexão com outra fonte de dados.
4. A outra fonte de dados, que possui as credenciais, responde para a conexão do Tivoli Directory Server com a confirmação ou com um erro de credencial inválida.
5. De acordo com o resultado obtido do servidor de passagem, o cliente é autenticado ou uma falha é relatada.

Os atributos a seguir são usados na configuração da autenticação de passagem:

• ibm-slapdPtaSearchBase: Esse atributo obrigatório define o nome distinto da base da subárvore no servidor de passagem com relação à entrada que será procurada.
• ibm-slapdPtaAttrMapping: Esse atributo obrigatório armazena o mapeamento de atributo para a autenticação de passagem.Por exemplo: se o 'attr1' no Tivoli Directory Server estiver associado ao 'attr2' no servidor de passagem, o valor desses atributos será 'attr1$attr2'. Durante a inicialização do servidor, o Tivoli Directory Server verificará se o 'attr1' é um atributo válido no seu esquema. Se o servidor de passagem estiver em execução, ele também tentará verificar se o 'attr2' é um atributo válido no esquema do servidor de passagem. Um aviso será emitido se houver falha na tentativa de verificação do 'attr2' no servidor de passagem. Espera-se que o 'attr1' tenha um valor único no Tivoli Directory Server. Como parte da autenticação de passagem, a entrada no servidor de passagem identificada pelo filtro ('attr2' = valor do 'attr1' no Tivoli Directory Server) na subárvore identificada pelo ibm-slapdPtaSearchBase é consultada. Espera-se que essa consulta retorne uma única entrada no servidor de passagem. Se forem retornadas diversas entradas, será considerada uma falha de conexão. Se uma única entrada correspondente for encontrada no servidor de passagem, será executada uma conexão relacionada com a entrada.
• ibm-slapdPtaBindDN: Esse atributo obrigatório indica o nome distinto a ser usado para conexão com o servidor de passagem durante a consulta no caso da definição de um mapeamento de atributo.
• ibm-slapdPtaBindPW: Esse atributo obrigatório indica a senha de conexão a ser usada para conexão com o servidor de passagem durante a consulta no caso da definição de um mapeamento de atributo.
• ibm-slapdPtaSubtree: Esse atributo obrigatório de multivalores aponta para a subárvore no diretório local no qual o Tivoli Directory Server irá executar a autenticação de passagem. As subárvores especiais como cn=configuration, cn=schema, cn=pwdpolicy, cn=ibmpolicies e cn=changelog não são valores permitidos para esse atributo. Os valores desse atributo não oferecem suporte para o uso de subárvores aninhadas (isto é, c=US e o=ibm, c=US não podem ser especificados como valores para esse atributo). Se especificado, haverá falha na inicialização do servidor no modo normal.
• ibm-slapdPtaResultTimeout: Esse é um atributo opcional que, se especificado, define o tempo em milissegundos que o Tivoli Directory Server esperará para a obtenção do resultado de uma operação de conexão ao servidor de passagem. Se o resultado não for recebido no período de tempo definido, o Tivoli Directory Server retornará LDAP_INVALID_CREDENTIALS para o cliente. O valor padrão do atributo é 1.000 ms. O valor igual a 0 indica que a operação de conexão não esperará e retornará imediatamente após a verificação do resultado. São suportados valores de 0 a 60000 ms (1 minuto).
• ibm-slapdPtaMigratePwd: Esse atributo opcional indica que a solicitação de conexão bem sucedida ao diretório de passagem deve ser seguida pela migração das credenciais de conexão para o diretório local (Tivoli Directory Server). Na falta desse atributo na configuração, não ocorrerá a migração das credenciais. Depois da migração da credencial, as operações de conexão subsequentes da entrada serão executadas com relação ao diretório local e não ao diretório de passagem.
• ibm-slapdPtaConnectionPoolSize: Esse atributo opcional indica o número de conexões que serão abertas com relação ao servidor de passagem para tratar as solicitações de conexão frequentes. Esse atributo destina-se a promover aprimoramentos de desempenho na autenticação de passagem; no entanto, quando o servidor de diretórios de passagem destrói conexões inativas, a criação de um conjunto de conexões através dessa opção pode não ser eficiente. Esse atributo oferece suporte para valores de 2 a 15. Qualquer outro valor especificado para esse atributo resultará na inicialização do servidor no modo de configuração. Na falta desse atributo, um conjunto de conexões com tamanho 4 é criado.
• ibm-ptaReferral: Essa classe de objeto auxiliar é associada a uma entrada do Tivoli Directory Server para definir o mapeamento específico da entrada no servidor de passagem. Ela inclui os atributos ibm-ptaLinkAttribute e ibm-ptaLinkValue.
• ibm-ptaLinkAttribute: Se o valor desse atributo for _DN_, o valor do ibm-ptaLinkValue correspondente será o nome distinto da entrada no servidor de passagem, eliminando dessa forma a necessidade da consulta. Se o valor desse atributo for _DISABLE_, a autenticação de passagem será desativada para essa entrada. Em todos os outros casos, esse atributo armazenará o nome do atributo a ser usado para consulta no servidor de passagem. Isso é necessário porque o mapeamento de atributo definido no atributo ibm-slapdPtaAttrMapping é aplicado em todas as entradas. Se uma entrada precisar de um mapeamento de atributo especial, isso poderá ser feito através desse atributo.
• ibm-ptaLinkValue: Esse atributo obrigatório contém o valor correspondente ao ibm-slapdPtaLinkAttribute.

Voltar para parte superior

Etapas de configuração no Tivoli Directory Server e no secldap

Nesta seção listamos as etapas que precisam ser seguidas para a configuração da autenticação de passagem no Tivoli Directory Server e a modificação que precisa ser feita na configuração do daemon secldapclntd. Vamos dividir a configuração em duas partes. A primeira parte abrange as etapas de configuração de uma instalação completamente nova do zero. No entanto, na segunda seção assumimos que já existe uma configuração de secldap/Tivoli Directory Server que precisa ser estendida para que a autenticação de passagem possa ser usada com a configuração existente para autenticar usuários de qualquer outra fonte de dados.

Etapas de configuração de uma instalação nova

A configuração de exemplo demonstrada neste artigo é um mapeamento de atributo, no qual o mapeamento de atributo é configurado e a entrada é apresentada localmente. Neste cenário, a entrada é apresentada localmente no Tivoli Directory Server e é possível determinar um atributo no Tivoli Directory Server que possui um mapeamento de um para um para atributo no servidor de passagem. O atributo no Tivoli Directory Server e no servidor de passagem que será mapeado não precisa ter o mesmo nome. Quando uma conexão é solicitada com relação ao Tivoli Directory Server e o mapeamento de atributo é definido, a consulta é executada no servidor de passagem para uma entrada que possui o mesmo valor do atributo mapeado no servidor de passagem do valor do atributo mapeado no Tivoli Directory Server. Se tal entrada for encontrada, a conexão é executada com relação a ela com as credenciais passadas pelo aplicativo cliente do Tivoli Directory Server.

Nesse caso, o administrador é responsável por identificar um atributo que identifica de forma exclusiva a entrada no Tivoli Directory Server e no servidor de passagem. Se não for possível localizar um atributo comum nas entradas que identifica cada entrada de forma exclusiva, o mapeamento de atributo poderá ser definido explicitamente por entrada usando os atributos de link na classe de objeto ibm-slapdPtaReferral.

				
# idsadduser -g idsldap -l /home/aixauth -u aixauth -w aixauth
			

				
# idsicrt -I aixauth -e abcd1234567890 -l /home/aixauth -n
			

				
# idscfgdb -I aixauth -l /home/aixauth -a aixauth -w aixauth -t aixauth -n
			

				
# idsdnpw -I aixauth -u cn=root -p root -n
			

				
# idscfgsuf -I aixauth -s cn=aixdata -n
			

				
# ibmslapd -I aixauth -n
			

				
Create an ldif file:

====enablepta.ldif Begins====
dn : cn=configuration
changetype : modify
replace : ibm-slapdPtaEnabled
ibm-slapdPtaEnabled : TRUE
===enablepta.ldif Ends====

Command to enable pass-through authentication:

# idsldapmodify -D cn=root -w root -i <path for enablepta.ldif>
			

				
Create an ldif file:

====ptaconfig.ldif Begins====
dn: cn=PassthroughServer1, cn=Passthrough Authentication, cn=Configuration
cn: PassthroughServer1
ibm-slapdPtaURL: ldap://9.182.194.84:389
ibm-slapdPtaSubtree: cn=aixdata
ibm-slapdPtaAttrMapping: uid $ sAMAccountName
ibm-slapdPtaSearchBase: CN=Users,DC=tamesso,DC=com
ibm-slapdPtaBindDN: CN=Administrator,CN=Users,DC=tamesso,DC=com
ibm-slapdPtabindPW: tivoli@123
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdPta
objectclass: ibm-slapdPtaExt

===ptaconfig.ldif Ends====

Command to enable pass-through authentication:

# idsldapmodify -D cn=root -w root -i <path for ptaconfig.ldif>

***Note :
1. With the configuration entry given in this listing, we are setting up Pass-through
   Authentication for the subtree cn=aixdata. Any bind request arriving at the Tivoli
   Directory Server server for the user under this subtree will be a candidate for PTA. 
	
2. Pass-through Authentication will be performed at the server located at the
   location ldap://9.182.194.84:389. 
	
3. On the destination server, a search will be performed under the subtree
   CN=Users,DC=tamesso,DC=com.

4. While binding to the PTA server, Tivoli Directory Server will use the
   DN as N=Administrator,CN=Users,DC=tamesso,DC=com and the password as tivoli@123.
	
5. With the attribute mapping defined as uid $ sAMAccountName, any value associated
   with uid in the Tivoli Directory Server will be looked for in the sAMAccountName
   attribute in the destination PTA server.
			

				
# ibmslapd -I aixauth -k			
			

Nesse momento, é necessário modificar o arquivo ldif do usuário de forma que o atributo de senha de usuário seja excluído para o usuário que será autenticado através do servidor de passagem. Enquanto estiver usando a autenticação de passagem de mapeamento de atributo, certifique-se de que o valor do atributo uid de qualquer entrada no Tivoli Directory Server corresponde exclusivamente a um valor de atributo particular no servidor de passagem (de acordo com a configuração de autenticação de passagem definida pelo ibm-slapdPtaAttrMapping).

				
dn: uid=user1,ou=People,cn=aixdata
uid: user1
objectClass: aixauxaccount
objectClass: shadowaccount
objectClass: posixaccount
objectClass: account
objectClass: ibm-securityidentities
objectClass: top
cn: user1
passwordchar: !
uidnumber: 205
gidnumber: 14
homedirectory: /home/ldapdb2
loginshell: /usr/bin/ksh
isadministrator: false
shadowlastchange: 14203
passwordflags: NOCHECK
ixtimelastlogin: 1227177141
hostlastlogin: braziltivl2
unsuccessfullogincount: 0

**Note:
1. attributes might be different, and their values can be different too.
2. Userpassword attribute has been removed.
3. As per the configuration in listing8 ( ibm-slapdPtaAttrMapping: uid $ sAMAccountName)
   uid has been set to user1. This will uniquely map this entry to the entry on the
   Pass-through Server.
			

				
# idsldif2db -I aixauth -i <path of user.ldif file>
			

				
# mksecldap -c -h secldaptds.ibm.com -a cn=root -p root
			

				
# stop-secldapclntd
			

				
# cp /etc/security/ldap/ldap.cfg <a safe location>
			

				
Edit the value for ldap_auth parameter and set it to ldap_auth.
By default it is set unix_auth

auth_type:ldap_auth
			

				
# start-secldapclntd
			

Voltar para parte superior

Etapas de configuração da instalação existente

A seção anterior demonstrou as etapas de configuração de uma instalação completamente nova. Nesta seção, vamos fornecer as etapas para modificação de uma configuração existente. Os leitores deste artigo certamente irão procurar etapas que ajudem a modificar suas configurações existentes para obter os benefícios do recurso de autenticação de passagem no Tivoli Directory Server. As etapas de modificação de uma configuração existente serão sempre consultadas quando uma organização é adquirida por outra organização e não é possível migrar todos os usuários no LDAP da organização recém-adquirida para o servidor do LDAP existente. Como exemplo para iniciar com uma configuração existente, mostramos uma configuração muito simples que existe na maioria das implementações.

As etapas a seguir convertem a configuração anterior em outra configuração, conforme mostrado na Figura 2.

				
# stop-secldapclntd
			

				
# cp /etc/security/ldap/ldap.cfg <safer location>
			

				
Edit the value for ldap_auth parameter and set it to ldap_auth.
By default it is set unix_auth

auth_type:ldap_auth
			

				
# start-secldapclntd
			

				
Create an ldif file:

====enablepta.ldif Begins====
dn : cn=configuration
changetype : modify
replace : ibm-slapdPtaEnabled
ibm-slapdPtaEnabled : TRUE
===enablepta.ldif Ends====

Command to enable pass-through authentication:

# idsldapmodify -D cn=root -w root -i <path for enablepta.ldif>
			

				
Create an ldif file:

====ptaconfig.ldif Begins====
dn: cn=PassthroughServer1, cn=Passthrough Authentication, cn=Configuration
cn: PassthroughServer1
ibm-slapdPtaURL: ldap://9.182.194.84:389
ibm-slapdPtaSubtree: cn=aixdata
ibm-slapdPtaAttrMapping: uid $ sAMAccountName
ibm-slapdPtaSearchBase: CN=Users,DC=tamesso,DC=com
ibm-slapdPtaBindDN: CN=Administrator,CN=Users,DC=tamesso,DC=com
ibm-slapdPtabindPW: tivoli@123
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdPta
objectclass: ibm-slapdPtaExt

===ptaconfig.ldif Ends====

Command to enable pass-through authentication:

# idsldapmodify -D cn=root -w root -i <path for ptaconfig.ldif>
			

Precisamos somente de uma amostra de entrada do usuário no Tivoli Directory Server primário para os usuários para os quais a autenticação de passagem tem que ser executada. Se a autenticação de passagem tiver que ser executada para uma entrada, remova o atributo de senha de usuário e mantenha os outros atributos. Normalmente, quando uma nova organização é adquirida, não é possível importar todos os dados do usuário do servidor do LDAP existente da organização adquirida. Nesse caso, é necessário criar uma entrada simples no servidor do LDAP das organizações adquiridas com os atributos mínimos necessários e deixar a autenticação de passagem manipular a autenticação de tal usuário. Em tal cenário, sempre que uma solicitação de autenticação de um funcionário da organização adquirida chegar ao servidor do LDAP da organização compradora, a entrada correspondente será localizada, e como o atributo de senha de usuário não estará disponível, o módulo de autenticação de passagem irá assumir o controle e irá autenticar o usuário usando o servidor de passagem.

				
# ibmslapd -I aixauth -k
# ibmslapd -I aixauth -n			
			

Voltar para parte superior

Exemplo com um cenário complexo

Muitas vezes o daemon secldapclntd é configurado para usar uma configuração do Tivoli Directory Server altamente disponível. O Tivoli Directory Server pode ser altamente disponibilizado usando a configuração de replicação de mestre para mestre. Nessa configuração, um Tivoli Directory Server replicado é usado como servidor primário. enquanto o outro é usado como servidor secundário. Todas as solicitações de leitura/gravação são primeiramente enviadas ao servidor primário. Qualquer alteração feita nesse servidor primário é imediatamente replicada no servidor secundário, para manter uma cópia dos dados ativos. Nesse caso, quando o servidor primário não puder ser contatado ou ficar indisponível devido a algum problema, o daemon secldapclntd automaticamente muda para o servidor secundário. Isso permite uma alta disponibilidade e evita o tempo de inatividade.

De acordo com a figura, os clientes do AIX entram em contato com um dos dois Tivoli Directory Servers configurados no backend com base na prioridade ou na disponibilidade. Podemos incluir as configurações de autenticação de passagem nos dois servidores de backend para que o diretório Domino de passagem (de acordo com este exemplo) seja referenciado quando a senha de usuário não for encontrada no Tivoli Directory Server. Todas as outras configurações no lado do secldap permanecem iguais.

Voltar para parte superior

Restrições ao usar a autenticação de passagem no Tivoli Directory Server

• A autenticação de passagem abrange muitos outros cenários. No entanto, usamos apenas o cenário no qual a entrada está presente localmente e a senha de usuário não está disponível no Tivoli Directory Server. Usamos este cenário pois é o cenário mais aplicável nesta situação. Outro cenário de autenticação de passagem define a situação na qual a entrada não está presente localmente. No entanto, esse cenário não pode ser usado como o secldap para usar a autenticação do Tivoli Directory Server, a entrada deve estar presente no Tivoli Directory Server, apesar da senha de usuário estar ausente.
• Para os usuários que serão autenticados usando o servidor de passagem, não será possível usar o comando passwd para alterar a senha do usuário. Isso não é permitido, pois o recurso de autenticação de passagem não atualiza nenhum valor no servidor de passagem. A execução do comando passwd resultará na adição da senha de usuário no Tivoli Directory Server primário e pode fazer com que os servidores do LDAP não fiquem sincronizados. Como opção, o Tivoli Identity Manager pode ser usado para sincronizar as senhas e solucionar alternativamente essa limitação.

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.
  
  
• Obtenha produtos e tecnologias! Faça o download das versões de avaliação de produto IBM e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
  
  
• Artigo do developerWorks: High scalability and availability of AIX secldapclntd using the Tivoli Directory Server proxy
  
  

Discutir

• Siga o developerWorks no Twitter.
  
  
• Participe da comunidade My developerWorks.
  
  
• Participe dos fóruns de AIX e UNIX® :
  • Fórum do AIX
  • Fórum do AIX para desenvolvedores
  • Gerenciamento de Sistemas em Cluster
  • Fórum Assistente de Suporte IBM
  • Fórum de Ferramentas de Desempenho
  • Fórum de Virtualização
  • Mais Fóruns de AIX e UNIX
  
  

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 - Limitação ao utilitário secldap (mksecldap)
• Histórico conceitual da autenticação de passagem
• Etapas de configuração no Tivoli Directory Server e no secldap
• Etapas de configuração de uma instalação nova
• Etapas de configuração da instalação existente
• Exemplo com um cenário complexo
• Restrições ao usar a autenticação de passagem no Tivoli Directory Server
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais