Ajuda com DIT

[Roberval Lustosa]

Olá pessoal!

Já possuo uma base openldap funcionando e integrada com alguns
sistemas, mas preciso modificar
a árvore para uma melhor organização e delegação de permissões a
alguns usuários a alguns nós.
Atualmente tenho a seguinte estrutura:
-dc=xxx,dc=edu,dc=br
-ou=people (todos os usuários estão aqui)
-ou=Group
-ou=Computers
-ou=AddressBook

Nessa atual estrutura tenho:
Um samba como PDC
Um qmail-ldap
Joomla e outros serviços.

Porém agora preciso replicar a base ldap para outras localidades e
dividir essa árvore. Sendo assim tive a seguinte ideia:
-dc=xxx,dc=edu,dc=br

dc=Cidade1
-ou=people
-ou=Group
-ou=Computers
-ou=AddressBook
dc=Cidade2
-ou=people
-ou=Group
-ou=Computers
-ou=AddressBook
dc=Cidade3
-ou=people
-ou=Group
-ou=Computers
-ou=AddressBook

OBS:
- Para cada cidade criarei um usuário administrador e definirei uma
ACL para que ele só possa mexer no seu nó correspondente. Esse usuário
administrador fará criação/remoção de usuários, computadores e dominio samba.
- Utilizarei como gerenciador gráfico, o LAM(Ldap Account Manager),
pois ele me da a possibilidade de criar perfis e cada perfil terá
acesso a sua cidade.
- Todas as modificações serão realizadas no servidor MASTE que fica no
nosso datacenter e será replicado para os SLAVES localizados nas suas
respectivas cidades.
- Cada cidade terá:
Um Servidor samba como PDC
Um servidor proxy

Até agora acho que tudo pode funcionar.

Agora... minha dúvida é relacionada a alguns serviços que são
centralizados no nosso datacenter, como por exemplo
o serviço de email (Qmail).
- Como o qmail vai identificar os usuários, sendo que não estão mais
dentro de uma OU única, mas sim em várias OU separadas dentro de DC's?
Será
que fazendo uma pesquisa na raiz dc=xxx,dc=edu,dc=br seria o
suficiente? Se essa pesquisa na raiz for suficiente, o desenpenho pode
ser prejudicado?

Valeu pessoal

--
++++++++++++++++++++++++++++++
+ Roberval Lustosa de Aguiar Filho         +
+ Técnico de Tecnologia da Informação   +
+ Instituto Federal de Goiás - IFG           +
++++++++++++++++++++++++++++++

[Jarbas Peixoto Júnior]

Em 13 de julho de 2011 09:22, Roberval Lustosa <r.lu...@gmail.com> escreveu:

Olá pessoal!

Já possuo uma base openldap funcionando e integrada com alguns
sistemas, mas preciso modificar
a árvore para uma melhor organização e delegação de permissões a
alguns usuários a alguns nós.
Atualmente tenho a seguinte estrutura:
-dc=xxx,dc=edu,dc=br
       -ou=people (todos os usuários estão aqui)
       -ou=Group
       -ou=Computers
       -ou=AddressBook

É uma estrutura de uma DIT "bem comportada" e muito funcional.

Uma análise fria dessa "nova" DIT é que as configurações, pesquisas e alterações terão que serem refeitas. Mas uma implementação dessa é viável, pois todos os objetos necessários ainda estarão na DIT. Porém requer um planejamento das alterações principalmente no impacto nos clientes dessa DIT.

Eu lhe dou uma nova idéia:

 * mantenha sua DIT original

 * acrescente o atributo ("l, localityName" - RFC2256: locality which this object resides in) em cada objeto (pessoa, grupo, etc) que represente a localidade.

 * crie grupos de administradores para cada "l"

 * cria uma ACL que permita ao grupo de administradores de cada "l" alterar somente os objetos pertencentes à essa "localityName".

Evite criar ACL para usuários específicos, a administração é muito mais fácil com "grupos" pois usuários podem ser incluídos/removidos mais facilmente sem alterar as ACLs.

Se ainda quiser outra boa fonte que lhe ajude a repensar sua DIT veja o link http://wiki.sintectus.com/bin/view/GrupoLinux/DesignDeUmaDIT

Att,

Jarbas

Até agora acho que tudo pode funcionar.

Agora... minha dúvida é relacionada a alguns serviços que são
centralizados no nosso datacenter, como por exemplo
o serviço de email (Qmail).
- Como o qmail vai identificar os usuários, sendo que não estão mais
dentro de uma OU única, mas sim em várias OU separadas dentro de DC's?
Será
que fazendo uma pesquisa na raiz dc=xxx,dc=edu,dc=br seria o
suficiente? Se essa pesquisa na raiz for suficiente, o desenpenho pode
ser prejudicado?


Valeu pessoal

--
++++++++++++++++++++++++++++++
+ Roberval Lustosa de Aguiar Filho         +
+ Técnico de Tecnologia da Informação   +
+ Instituto Federal de Goiás - IFG           +
++++++++++++++++++++++++++++++

--
Você está recebendo esta mensagem porque se inscreveu no grupo "ldap-br" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para lda...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para ldap-br+u...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/ldap-br?hl=pt-BR.

[Roberval Lustosa]

Legal sua ideia Jarbas.

Pra usuário eu consegui usar o atributo "l", mas pro grupo ainda não.
Meus objectClass para os grupos são:
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping

Tentei acrescentar o objectClass "Locallity" , mas deu erro de
violação. Ainda vou ver o motivo.

No caso de usar a DIT nessa forma mais simples eu esbarraria no
problema de utilização do LAM(ldap account manager0. O mesmo tem o a
opção de usar o atributo "l" para cadastro de usuários, mas para o
cadastro de grupos, não.
Bem... poderia resolver esse problema acrescentando esse atributo no
"visualizador de árvore" da aplicação. Outra solução seria
personaliza-la ou criar uma solução que atendesse minhas necessidades.
Como vc faz ai onde vc trabalha? Personalizou uma solução ou criou
alguma do zero para lhe atender?

No caso dessa minha nova DIT, montei uma de teste.movendo os objetos
para seus respectivos contêiner. Vou fazer alguns testes com os
atuais serviços que temos pra ver o resultado.

Agradeço sua contribuição...

valeu

Em 13 de julho de 2011 10:45, Jarbas Peixoto Júnior
<jarbas...@gmail.com> escreveu:

[Jarbas Peixoto Júnior]

Em 14 de julho de 2011 09:16, Roberval Lustosa <r.lu...@gmail.com> escreveu:

Legal sua ideia Jarbas.

Pra usuário eu consegui usar o atributo "l", mas pro grupo ainda não.
Meus objectClass para os grupos são:
objectClass: top
objectClass: posixGroup
objectClass: sambaGroupMapping

Com apenas esses objectClass acima o atributo "l" não pode ser inserido diretamente, pois nenhum "schema" de grupo básico possui esse atributo nem mesmo como 'opcional'. Porém existe um objectClass "extensibleObject" que possui "TODOS" os atributos disponíveis de todos schemas.

Primeiro você deve incluir um novo atributo "objectClass: extensibleObject" em todos os seus grupos. Depois você pode incluir qualquer atributo nos grupos sem violar as regras do openldap.

É super simples de ser utilizado.

Aqui eu fiz de uma forma ligeiramente diferente. Eu criei um schema próprio com atributos: Matrícula, CPF, NIT, etc para um objectClass de pessoa da empresa. Fiz a mesma coisa com os grupos. É meio complicado fazer um schema sem conhecer bem as regras de confecção de schemas. No link que te passei tem um exemplo didático muito bom para esse tipo de necessidade. Mas somente se aventure nesse processo se realmente entender o processo.

Att,

Jarbas

[Roberval Lustosa]

Esse objectClass é interessante. Testei e deu certo.
Quanto a criação de novos schemas, não irei me aventurar, mesmo porque
teremos que usar um schema específico chamado brEduPerson.

Valeu a ajuda cara...
abraço

Em 14 de julho de 2011 12:27, Jarbas Peixoto Júnior