Palestra LatinoWare - Migrando 40 mil usuários para OpenLDAP

Resumo da Palestra

Desde maio de 2007, as mais de 1300 APS (Agências da Previdência Social) já utilizam a dobradinha Debian/Samba para prover login de acesso aos mais de 50.000 Desktops Windows. O objetivo é eliminar adminstração de usuários/senhas que é feita em cada um desses servidores das APS, através da autenticação centralizada no OpenLDAP. Por considerar o Diretório um serviço estratégico dentro da empresa, utilizamos o conceito de Multi-Master do AD (Active Directory) disponível na série 2.4 do OpenLDAP através do Mirror-Mode. Essa implementação, juntamente com um switch de conteúdo, garante a alta-disponibilidade do mesmo.

A administração dessa base de dados armazenadas no OpenLDAP é realizada por ferramenta WEB desenvolvida (WeMOiP - Gerenciador Web de Diretório), pois nenhuma ferramenta testada (web ou client/server) incorpora as “regras de negócio” internas da Previdência Social.

Outro ponto problemático são os perfis dos usuários Windows que precisaram ser convertidos para o novo domínio único. Um script que realiza a conversão automática desses perfis foi desenvolvido.

Paralelamente, implementamos o wpkg - Windows Packager que é um add-on que ajuda a distribuir softwares, correções e patches para vários clientes de forma centralizada.

O Download da palestra pode ser feita no link: Palestra LatinoWare

Alterando o Domínio nos Desktops Windows

Se você já teve que reinstalar um SAMBA (mantendo o mesmo nome do Domínio) e os Desktops Windows tiveram que ser reingressados no domínio e ao logar no Desktop Windows percebeu que os Perfis de Usuários não foram preservados então continue lendo esse artigo, pois descrevo a solução que encontrei para estes problemas e disponibilizo um "script" que resolve estes problemas.

Aos apressados: baixe o change-domain.zip e descompacte dentro do compartilhamento \\SERVIDOR\netlogon. Dois arquivos são extraídos:

• Permissions-To-NewDomain.vbs - o script propriamente dito (escrito em VBscript)
• SetACL.EXE - um aplicativo que faz o papel do CACLS.EXE (nativo do Windows) com mais opções. É um GPL e está disponível em http://setacl.sourceforge.net/html/examples.html

Após ter ingressado o Windows no DOMAIN-A, logue com um usuário do grupo "Domain Admins" e não como "Administrador" local. Dê dois cliques no script e aguarde o relatório de migração ser exibido. É isso mesmo, um relatório com os perfis convertidos ao novo domínio e (principalmente) os comandos executados no Windows será mostrado automaticamente pelo editor de textos padrão Windows (NOTEPAD).

Aos interessados em entender o problema detalho abaixo minha experiência:

Imaginemos a seguinte situação:

1. você instala um SAMBA para atuar como PDC do domínio DOMAIN-A
2. cria diversos usuários (USER-A, USER-B, ..., USER-N)
3. ingressa diversas máquinas nesse domínio (MACHINE-A, MACHINE-B, ..., MACHINE-N)
4. tudo funciona perfeitamente bem, até que um dia o servidor apresenta um problema sério de Hardware e não tem salvação, ou seja, foi pro lixo.
5. você tem backups diários de todos os dados compartilhados pelo samba, incluindo os usuários/senhas do Linux e do Samba ( /etc/passwd - /etc/shadow - /etc/samba/smbpasswd ) e as configurações do samba ( /etc/samba/smb.conf )
6. imediatamente você instala um novo servidor e restaura todo o seu backup
7. ao tentar logar no Windows você recebe uma mensagem: XXX
8. seus usuários estão achando que você não fez o backup/restore corretamente, pois ao logar com o mesmo usuário/senha as informações do Perfil do Usuário logado não são as mesmas de antes do problema do servidor. A impressão do usuário é que ele simplesmente PERDEU TUDO (isso inclui o Papel de Parede, Meus Documentos, Meus Favoritos, etc ).
9. o pior de tudo é que você tem certeza que os arquivos foram restaurados corretamente, e apesar de os usuários terem a mesma identificação anterior (nome, ID, GID, etc), os perfis não foram aproveitados, causando um grande aborrecimento aos usuários e consequentemente ao administrador desse domínio.

Normalmente isso acontece quando NÃO se preserva o SID do domínio antigo. Isso se deve ao fato de o Windows "enchergar" cada recurso (Usuário, Máquina, Impressora) como um SID e não pelo nome. O usuário quer uma solução rápida para o problema dele, pois no perfil antigo tinham todas as informações e arquivos que o usuário precisa no seu dia-a-dia.

Se você está mudando nome de domínio para DOMAIN-B, além do problema dos perfis acima, você terá que ingressar todos os desktops nesse novo domínio.

Uma das soluções espartanas para resolver o problema do usuário USER-X é copiar os arquivos de perfil antigo (C:\Documents and Settings\User_X) para o novo perfil criado (.C:\Documents and Settings\User_X.DOMAIN). Mas essa solução é demorada e tem que ser repetida para cada perfil de usuário em todas as máquinas, gerando um trabalho enorme para o administrador.

O que descobri quando o usuário USER-Y se loga nesse domínio:

• tudo fica mais complicado se o usuário USER-Y não for um membro do grupo "Domain Admins" (Administradores de Domínio) e sim um usuário sem privilégios adminstrativos ( essa todos sabem )
• que o Windows trata tudo através do SID ( essa quase todo mundo já sabia );
• que ao se logar no Windows uma chave de registro é criada e é associa da ao SID desse usuário no domínio ( essa muita gente já sabia)
• que dentro dessa entrada de registro tem um caminho (PATH) que indica qual é o diretório desse usuário ( essa algumas pessoas já imaginavam)
• que dentro desse diretório tem um arquivo (NTUSER.DAT) que contém as informações do perfil desse usuário ( essa tenho quase certeza que poucos sabiam)
• que esse arquivo tem uma estrutura de REGistro interna que pode ter as permissões alteradas através do regedit, ou seja, pode-se abrir o NTUSER.DAT, alterar as permissões internas e fechá-lo novamente. Esse truque eu custei para entender, principalmente porque não sou usuário de Desktop Windows e não tenho prática diária com esses truques do Windows/RegEdit ( essa eu acredito que a maioria nem imaginava e não irá compreender de primeira )

Pois bem, a solução consiste em:

1. varrer todas as entradas de registro referentes aos Perfis;
2. para cada entrada efetuar uma cópia desse registro com o novo SID;
3. dar permissões NTFS totais para esse nova entrada no perfil (simulando um login) no PATH do perfil antigo;
4. dar permissões NTFS totais no conteúdo do NTUSER.DAT para essa nova entrada no perfil. Para isso necessitamos através do REGEDIT, clicar no HKEY_USERS e através do menu "Carregar seção", navegar até o arquivo NTUSER.DAT do perfil desejado, informar um nome de chave temporária a ser criada (pode ser qualquer nome) pela carga desse NTUSER.DAT, setar as permissões NTFS nessa nova entrada no registro que foi carregada e por último "Descarregar seção" temporária criada;
5. dessa forma não altero nenhuma entrada no registro, eu simplesmente adiciono novas entradas e altero algumas permissões NTFS no sistema de arquivos e no perfil do usuário. Assim tenho garantida a "volta" para o domínio antigo caso seja necessário (imaginemos que o servidor problemático tinha era um problema de OSMAR Contato que foi resolvido).

Se você está se perguntando porque um blog relacionado ao ldap tem essa matéria publicada, eu respondo: porque certamente será útil para alguém, mesmo para aqueles que já estejam utilizando ldap como backend do samba (aliás, é essa é configuração que estou utilizando atualmente).

Como Planejar uma DIT

DIT - Directory Information Tree (Árvore de Informação de Diretórios)

É possível fazer um diretório LDAP servir para muitas aplicações numa organização. Esta tem sido uma vantagem de reduzir esforços necessários para manter os dados, mas significa que o layout deve ser planejado muito cuidadosamente antes de iniciar sua implementação.

Diretórios LDAP são estruturados como uma árvore de entradas, onde cada entrada consiste de um conjunto de pares (atributos/valores) descrevendo um objeto. Estes objetos são freqüentemente pessoas, organizações, e departamentos, mas podem ser qualquer coisa. Schema é um termo usado para descrever uma forma de um diretório e as regras que descrevem os conteúdos.

Um plano é proposto para o layout da árvore de diretórios (DIT), com ênfase principalmente em evitar a necessidade de uma reorganização posterior. Isto envolve separar cuidadosamente os dados que descrevem pessoas, departamentos, grupos e objetos específicos de aplicações. Uma simples técnica para definir as entradas é mostrada, baseando-se no uso de classes de objetos locais. Os efeitos dos tipos de schemas são mostrados e a performance é discutida. Alguns "problemas" e "pontos de falha" são apresentados, baseados em recentes experiências de consultoria.

Tá gostando desse texto? Então veja mais no DesignDeUmaDIT.pdf

Nova Lista "ldap-br" criada

Tenho notado que algumas vezes o serviço de lista disponibilizado pela Cooperativa Solis ( http://www.solis.coop.br ) no http://server.solis.coop.br/mailman/listinfo/ldap-l encontra-se meio congestionado.

Pensei numa alternativa de lista grátis que tem funcionado satisfatoriamente bem para outra Cooperativa, a Sintectus http://www.sintectus.com ).

Pensando em poder contribuir com a comunidade ldap no Brasil, criei este blog e uma lista http://groups.google.com/group/ldap-br que além das discussões, pretendo armazenar os arquivos relacionados http://groups.google.com/group/ldap-br/files .

Quem quiser contribuir com sugestões/melhorias neste blog ou lista esteja à vontade.

Quem quiser compartilhar a tarefa de administrar as postagens neste blog mande um email pra mim que eu compartilho a adminstração, pois manter um blog requer muito tempo disponível.