Sistema Red Hat Enterprise Linux 5.

Pacotes instalados:

• openldap-servers-2.3.43-12.el5_5.3
• openldap-clients-2.3.43-12.el5_5.3.i386.rpm
• cyrus-sasl-2.1.22-5.el5_4.3
• samba-3.0.33-3.29.el5_5.1
• nss_ldap-253-37.el5
• php-5.1.6-27.el5_5.3
• php-ldap-5.1.6-27.el5_5.3
• php-common-5.1.6-27.el5_5.3
• php-cli-5.1.6-27.el5_5.3
• phpldapadmin-1.2.0.5.tgz
• httpd-2.2.3-45.el5 (Apache)
• authconfig.i386
• authconfig-gtk.i386
• smbldap-tools-0.9.5-2.el5.rf

Configurando o LDAP:

O arquivo de configuração do LDAP esta localizado em: /etc/openldap/slapd.conf

Estrutura do Samba para o LDAP Master

Arquivos de Schemas são utilizados pelo LDAP para entender as entradas utilizadas pelos sistemas que irão utilizar as informações de usuários contidas no LDAP, permitindo a autenticação dos mesmos nesses sistemas.

Devido a isso, no caso da configuração do Samba com o LDAP é necessário copiar o arquivo /usr/share/doc/samba-3.0.33/LDAP/samba.schema para o diretório: /etc/openldap/schema/

Execute o comando abaixo para realizar essa cópia:

# cp /usr/share/doc/samba-3.0.33/LDAP/samba.schema /etc/openldap/schema/

Após realizar a cópia, informar o LDAP Master através do arquivo /etc/openldap/slapd.conf que ele deverá trabalhar também com o Schema do Samba, inserindo a linha abaixo, logo no inicio do arquivo, seguindo o mesmo padrão das linhas já existentes nele para esse mesmo propósito.


Definindo o Domínio para o LDAP Master.

Acessar o arquivo /etc/openldap/slapd.conf e alterar a linha:

Suffix "dc=dominio,dc=com"

Para:

Definindo o nome para o Administrador do Domínio LDAP Master

Dentro do arquivo /etc/openldap/slapd.conf existe a linha:

rootdn          "cn=Manager,dc=example,dc=com"

Substitua a mesma pela linha abaixo para informar ao LDAP como será o nome completo do seu administrador:

Gerando e configurando a senha para o Administrador do LDAP Master

O LDAP pode utilizar um hash da senha escolhida para ser salvo dentro do arquivo de configuração slapd.conf, desse modo, a senha do administrador não fica diretamente salva no arquivo de configuração do LDAP, aumentando a segurança do sistema, caso algum usuário não autorizado leia esse arquivo.

Para isso, é utilizado o programas slappasswd para realizar essa conversão e gerar o hash, esse hash gerado deve ser salvo no arquivo de configuração do LDAP. Esse código hash deve ser inserido na linha abaixo, dentro do slapd.conf.

Execute o comando:

# slappasswd
# rootpw (cole o hash da senha gerada pelo slappasswd aqui)

Definindo as ACLs (Lista de Controle de Acesso) para os usuários no LDAP Master

Dentro do slapd.conf adicione a linha abaixo, para controlar o acesso as informações mantidas pelo LDAP:


A linha acima concede o acesso para todos como somente leitura, com exceção do rootdn que é o administrador do domínio LDAP.


A linha acima concede o acesso aos atributos: userPassword,sambaLMPassword,sambaNTPassword para escrita pelo seu dono, usuário anônimo precisa se autenticar e para o restante dos usuários a consulta não é permitida.

Copiando o Arquivo de configuração do Banco bdb utilizado pelo LDAP Master

Quando iniciamos o LDAP pela primeira vez, o mesmo cria o seu próprio Banco de Dados, conforme especificado no arquivo: /etc/openldap/slapd.conf, no caso do Red Hat Enterprise 5 um arquivo utilizado pelo banco bdb, não esta salvo dentro do diretório: /var/lib/ldap/ e devido a isso, ao iniciar o LDAP é apresentada a linha abaixo no arquivo de log: /var/log/slapd.log

"bdb_db_open: Warning - No DB_CONFIG file found in directory"

Para corrigir esse problema é necessário parar o ldap (service ldap stop) e copiar o arquivo DB_CONFIG localizado no diretório: /etc/openldap/ para o diretório: /var/lib/ldap/, utilizando os seguintes comandos:

# cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

Adicione as linhas abaixo no arquivo /etc/openldap/slapd.conf para ativar o arquivo de log: slapd.log dentro do /var/log/.


Reinicie o syslog para que o mesmo ative o log.

# service syslog restart

Inicie o servidor LDAP com o comando:

# service ldap start

Notar que o arquivo de log somente será gerado quando ocorrer algum evento. Utilize o comando abaixo para ver o que esta sendo logado no momento nesse arquivo.

# tail -f -n150 /var/log/slapd.log

Gerando a base e populando o LDAP Master

Crie um arquivo com o comando touch base.ldif, após isso, edite esse arquivo com comando vi base.ldif e insira as linhas abaixo, após fazer isso salve o arquivo teclando :wq


Esse arquivo informará para o LDAP qual será a nossa estrutura, desse modo, será criado a árvore do domínio através do atributo "dc", e as Unidades Organizacionais "ou": Usuários e Grupos

Importante: Notar as linhas em branco, caso não sejam inseridas o ldapadd retorna o erro:

"ldap_add: Type or value exists (20) additional info: objectClass: value #0 provided more than once"

Observação: Observe que não utilizei a "ou=Computadores", pois identifiquei que a versão do Samba utilizado nesse documento, não consulta as informações dos computadores nessa "OU" e em vez disso, ele esta pesquisando na "OU=Usuarios", ou seja, trocar a referência para "ou=Usuarios" toda vez que encontrar algum apontamento para "ou=Computadores".

Após salvar e fechar o arquivo base.ldif e subir o servidor LDAP, vamos agora importar as informações sobre essa estrutura para dentro do LDAP, utilizando o comando ldapadd, para isso, execute a linha de comando abaixo:

# ldapadd -x -D cn=administrador,dc=dominio,dc=com,dc=br -W -f base.ldif

Será solicitada a senha do Administrador do Domínio LDAP, a mesma utilizada quando gerado o parâmetro rootpw do arquivo slapd.conf.

Até esse ponto o LDAP sabe a estrutura o qual serão armazenadas as informações de grupos e usuários que já existem no Linux, mas ainda não possui essas informações. O próximo passo é migrar as informações dos usuários e grupos do Linux, servindo futuramente como base para autenticação do Samba, já que esse utiliza os Grupos e Usuários existentes no Linux.

Importando os Usuários e Grupos Linux com o Migration Tools

Para essa tarefa será necessário utilizar o MigrationTool, um script escrito em Pearl que converte as informações do /etc/passwd e /etc/group, salvando as mesmas em arquivos .ldif.

Acesse o link http://www.padl.com/OSS/MigrationTools.html para obter o script ou utilize o comando abaixo para realizar o download:

# wget http://www.padl.com/download/MigrationTools.tgz

Após realizar o download, descompacte o mesmo com o comando abaixo:

# tar -xzvf MigrationTools.tgz

Acesse o diretório que foi gerado e altere o arquivo migrate_common.ph conforme as linhas abaixo.

Altere as linhas deixando conforme mostrado abaixo:


Descrição:

$NAMINGCONTEXT{'passwd'} = "ou=Usuarios"; Nessa linha é apontada a "ou=Usuarios" para receber as informações dos usuários mantidas no /etc/passwd. Com isso o script gera o arquivo usuarios.ldif com a estrutura reconhecida pelo LDAP, mas especificamente pelo ldapadd

$NAMINGCONTEXT{'group'} = "ou=Grupos"; Nessa linha é apontada a "ou=Grupos" para receber as informações dos grupos mantidas no /etc/group. Com isso o script gera o arquivo grupos.ldif com a estrutura reconhecida pelo LDAP, mas especificamente pelo ldapadd

$DEFAULT_MAIL_DOMAIN = "dominio.com.br"; Nessa linha deve ser especificado o domínio de e-mail utilizado pelo seu domínio;

$DEFAULT_BASE = "dc=dominio,dc=com,dc=br"; Nessa linha deve ser especificado o DN do seu domínio LDAP;

$DEFAULT_MAIL_HOST = "mail.dominio.com.br"; Nessa linha deve ser especificado com o nome DNS do seu servidor de e-mail.

Após alterar as linhas descritas acima dentro do arquivo migrate_common.pl, salve e copie o mesmo para o diretório: /usr/share/openldap/migration, esse processo de cópia é necessário caso seja instalado através do RPM. Após a cópia execute conforme descrito abaixo:

# ./migrate_group.pl /etc/group /root/grupos.ldif
# ./migrate_passwd.pl /etc/passwd /root/usuarios.ldif

Observe que os dois arquivos .ldif serão salvos no diretório /root, altere esse diretório conforme a sua necessidade.

Após realizar esse processo de exportação, agora vamos realizar finalmente a importação dessas informações para dentro da base LDAP.

Para isso acesse o diretório onde os dois arquivos .ldif foram salvos e execute o comando abaixo, notar que o mesmo informa o administrador do domínio LDAP, altere conforme a DN do seu administrador do seu domínio, conforme configurado no slapd.conf no parâmetro rootdn.

# ldapadd -x -D cn=administrador,dc=dominio,dc=com,dc=br -W -f grupos.ldif
# ldapadd -x -D cn=administrador,dc=dominio,dc=com,dc=br -W -f usuarios.ldif

Após isso, todas as informações de grupos e usuários contidos em seu Linux estão dentro da base LDAP e podemos agora configurar o Linux para autenticar nessa base.

Verificando se as informações estão realmente no LDAP

Para realizar uma pesquisa para verificar se as informações realmente estão no LDAP, execute o comando abaixo:

# ldapsearch -x -b "dc=dominio,dc=com,dc=br"

Configurando o Linux para autenticar na base LDAP Master

Cliente LDAP:

Para que isso seja possível é necessário ter instalado o módulo nss_ldap o qual permite que o Linux consulte as informações sobre os grupos e usuários na base LDAP, servindo como uma interface.

Verifique se o módulo esta instalado com o comando abaixo:

# rpm -qa | grep nss_ldap

Caso não esteja, realize a instalação do pacote rpm.

Com o módulo nss_ldap instalado. Agora é necessário editar o arquivo de configuração do cliente LDAP, localizado em: /etc/ldap.conf, conforme mostrado abaixo:


Descrição:

host 127.0.0.1 Nessa linha é especificado o local onde esta o servidor LDAP, no nosso caso, o servidor esta localmente;

base dc= dominio,dc=com,dc=br Nessa linha é definido o DN do domínio

rootbinddn cn=administrador,dc= dominio,dc=com,dc=br Nessa linha é definido o DN do administrador do domínio, no nosso caso é administrador;

nss_base_passwd ou=Usuarios,dc= dominio,dc=com,dc=br?one
nss_base_shadow ou=Usuarios,dc= dominio a,dc=com,dc=br?one
nss_base_group ou=Grupos,dc= dominio,dc=com,dc=br?one

Nas três linhas acima, utilizar a mesma "OUs" definida no arquivo base.ldif que é igual ao arquivo usuários.ldif e grupos.ldif.

bind_timelimit 10 Essa linha informa para o cliente esperar somente 10 segundos pela consulta feita do nss_ldap para o servidor ldap

bind_policy soft Essa linha informa para o cliente LDAP tentar conectar somente uma vez com o servidor LDAP, caso não consiga, o cliente já retorna o erro. A opção "hard" faz com que as tentativas sejam feitas de tempo em tempo.

nss_initgroups_ignoreusers ldap root Essa linha informa para o Linux não buscar esses usuários no LDAP, pois caso contrário, é apresentada lentidão no sistema, caso o LDAP esteja parado.

Direcionando os programas Linux para utilizar o LDAP Master

Para realizar esse procedimento é utilizado o arquivo: /etc/nsswitch.conf o qual instrui ao Linux em qual base ele deve verificar os usuários e senha e o que fazer quando a consulta falhar.

# vi /etc/nsswitch.conf

Altere as seguintes linhas:


Observação: NUNCA coloque somente a opção ldap, pois nesse caso, durante a inicialização do sistema o LDAP não funcione, o Linux não terá como verificar a senha do usuário root!

Isso custou uma nova instalação do Linux e dois dias de trabalho.

Nessa configuração o Linux tentará primeiro verificar os usuários e senhas localmente, através do /etc/passwd e /etc/group, caso não encontre, ele irá consultar no LDAP.

Configurando o Samba Master para utilizar o LDAP Master

Abaixo consta o arquivo smb.conf com as alterações necessárias:


Execute o comando abaixo para dizer ao Samba qual é a senha do administrador do LDAP:

# smbpasswd -w Senha do rootdn

Observação 1: Notar que foi definido o parâmetro "smb ports", esse parâmetro instrui o Samba a escutar somente essa porta ao responder a requisições. Foi identificado nos logs do Samba que a não utilização desse parâmetro estava gerando a mensagem:

"Error Conexão fechada pela outra ponta"

Isso ocorre, por que o Windows XP trabalha com a porta 139 ou a porta 445, ele pode iniciar a comunicação por uma porta e fechar a comunicação por outra, mas o Samba não consegue identificar isso, gerando a mensagem de erro no log. Notar que essa configuração impossibilita a comunicação na porta 445.

Observação 2: Notar que foi definido o parâmetro "obey pam restrictions = yes", esse parâmetro instrui o Samba a obedecer o sistema de login no Linux utilizando o módulo PAM. O Linux está configurado nessa documentação para criar o diretório home do usuário automaticamente, mas para que isso funcione, esse parâmetro deve estar ativado no Samba, pois caso algum usuário tente logar no Samba e o mesmo ainda não possua o diretório home, o módulo PAM identifica isso e cria o diretório no Linux.

Observação 3: Necessário definir os atributos acl e user_xattr no /etc/fstab para que os usuários do LDAP consigam lidar com as ACLs e atributos compatíveis com o Windows para a partição /home do Linux. Segue o exemplo da linha do /etc/fstab abaixo:


Notar que os atributos devem ser adicionados na quarta coluna acima, o restante da linha não deve ser alterada.

Configurando as estações Windows

Foi desativado a memorização das senhas em cachê pelo Windows, para isso, foi realizada a alteração abaixo:

Iniciar -> Painel de Controle -> Ferramentas administrativas -> Diretiva de segurança local -> Diretivas Locais -> Opções de Segurança -> Logon Interativo: número de logon anteriores para colocar em cachê (caso o controlador de domínio não esteja disponível) = 0 logons

A configuração acima desativa o logon com senhas em cache.

A configuração abaixo realiza a mesma configuração, mas através do registro do Windows:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\
ValueName: CachedLogonsCount
Data Type: REG_SZ
Values: 0 - 50

Criado o home do usuário automaticamente no Linux

Identifiquei que ao configurar no menu iniciar -> Configurações -> Autenticador, informando que a autenticação do Linux deve ser feita consultando uma base LDAP e ativando o recurso de criar o home do usuário no primeiro login, ou seja, automaticamente. As permissões setadas estavam incorretas, sendo setadas como /home/usuario 755.

Como o smbldap-adduser cria os novos usuários na base LDAP, todos com o mesmo grupo "Domain Users", esse comportamento se tornou uma falha de segurança, pois na configuração original, feita no modo gráfico através do software Autenticador, seria possível que um usuário acesse o home de outro usuário, por exemplo.

Corrigi isso, no menu iniciar -> Configurações -> Autenticador, informando para o mesmo logar no servidor LDAP Master, mas desativando a opção para criar o diretório /home automaticamente no primeiro login e adicionei a linha abaixo no arquivo /etc/pam.d/system-auth:


Mudei a mascara para 0007, com isso, os diretórios ficam com permissão 770 e os arquivos com 660, lembrando que devemos subtrair a mask da permissão máxima, 777 para diretórios e 666 para aquivos.

Alterei a mascara padrão de permissão do Linux para 007, acessei o arquivo /etc/bashrc e mudei logo no começo do arquivo de 002 e 022 para 007 e 07.

Gerando e administrando o backup da base LDAP

1° método:

Podemos utilizar para essa tarefa o comando slapcat direcionando a saída do mesmo para um arquivo .ldif, conforme o comando abaixo:

# slapcat > base_bkp.ldif

Instalando e configurando o smbldap-tools para administrar o LDAP

Acesse o link descrito abaixo e realize o download do smbldap:

• http://download.gna.org/smbldap-tools/packages/smbldap-tools-0.9.5-1.src.rpm

Ou execute o comando abaixo para baixar diretamente no diretório onde você está:

# wget http://download.gna.org/smbldap-tools/packages/smbldap-tools-0.9.5-1.src.rpm

Execute o comando abaixo para realizar a pré-instalação:

# rpm -ivh smbldap-tools-0.9.5-1.src.rpm

Após executar o comando acima, será criado o diretório: /usr/src/redhat/SOURCES/smbldap-tools-0.9.5, acesse o mesmo com o comando:

# cd /usr/src/redhat/SOURCES/smbldap-tools-0.9.5

Copie todos os scripts para o diretório /usr/local/sbin executando o comando:

# cp smbldap-* /usr/local/sbin/

Necessário editar os arquivos smbldap.conf e smbldap_bind.conf conforme o seu ambiente.

Antes de editar o arquivo smbldap.conf, execute o comando abaixo para pegar a Serial do seu domínio Samba, esse código deverá ser inserido dentro do arquivo smbldap.conf:


Copie o valor retornado.

Edite o arquivo: /etc/smbldap-tools/smbldap.conf

Nas linhas:

• SID="" Coloque a serial obtida no comando anterior entre as aspas duplas
• sambaDomain="" Coloque o domínio do Samba, conforme o parâmetro workgroup do arquivo /etc/samba/smb.conf
• slaveLDAP="" Coloque o IP do servidor LDAP Slave.
• slavePort="389" A porta 389 é a padrão.
• masterLDAP="" Coloque o IP do servidor LDAP Master, no meu caso, seria 127.0.0.1
• masterPort="389" A porta 389 é a padrão.
• verify="none" No momento não estou usando criptografia, TLS, por isso, deixei como "none"
• ldapTLS="0" Definido como "0" pois não estou utilizando TLS no momento.
• suffix="dc=domínio,dc=com,dc=br" Informe o domínio LDAP;

usersdn="ou=Usuarios,${suffix}"
computersdn="ou=Usuarios,${suffix}"
groupsdn="ou=Grupos,${suffix}"
idmapdn="ou=Idmap,${suffix}"

Essas quatro linhas acima estão setadas conforme o arquivo base.ldif utilizado para montar a estrutura LDAP Master e Slave.

Observe que as contas de máquinas estão sendo salvas na OU=Usuários, pois a versão do Samba utilizado nesse documento lê essa informação nessa OU, provavelmente é um BUG do Samba.

• userSmbHome="\\smbpdc\%U" Indique o caminho de rede UNC para o home do servidor Samba Master
• userProfile="" Não utilize Home Profile para os meus usuários, por isso, esta em branco;
• userHomeDrive="F:" A letra que deve ser utilizada para montar o Home na estação do usuário

O restante da configuração nesse arquivo deve ser realizado conforme o seu ambiente.

Edite o arquivo smbldap_bind.conf e configure o dn para o LDAP Master e Slave e suas respectivas senhas.

slaveDN="cn=administrador,dc=domínio,dc=com,dc=br"
slavePw="senha"
masterDN="cn=administrador,dc=domínio,dc=com,dc=br"
masterPw="senha"

Após editar e salvar os dois arquivos copie os mesmos para o diretório: /etc/smbldap-tools/, para isso, execute os comandos abaixo:

# mkdir /etc/smbldap-tools/
# cp smbldap_bind.conf /etc/smbldap-tools/
# cp smbldap.conf /etc/smbldap-tools/

Acesse o diretório /etc/smbldap-tools/ e altere as permissões desses dois arquivos:

# cd /etc/smbldap-tools/
# chmod 644 smbldap.conf
# chmod 600 smbldap_bind.conf

Copie o arquivo smbldap_tools.pm para o diretório /usr/local/sbin/:

# cp smbldap_tools.pm /usr/local/sbin/

Ao executar pela primeira vez são exibidas algumas mensagens de erro, informando que alguns módulos Perl não foram encontrados, mas para resolver esse problema, será necessário utilizar o utilitário CPAN do próprio Perl que realiza a instalação automática dos módulos.

Execute o comando abaixo para realizar a instalação dos módulos:

# cpan
cpan>
cpan> install Net::LDAP
cpan> install Unicode::MapUTF8
cpan> install Crypt::SmbHash

Após executar o comando acima Perl estará apto a executar os scripts smbldap-tools.

Agora é necessário executar o smbldap-populate para gerar dentro do LDAP as instruções e registros necessários para utilizar o Samba com o LDAP, por isso a importância de executar o passo anterior, que instrui os scripts a utilizar a configuração correta.

# smbldap-populate

Utilizando o smbldap

Adicionar conta de máquina:

Necessário criar uma conta de máquina para que a mesma consiga se anexar ao domínio, segue o comando abaixo:

# smbldap-useradd -w username

A opção w do smbldap-useradd indica que estamos criando uma conta para uma máquina.

Adicionar conta de usuário:

Para adicionar um novo usuário ao LDAP, execute o comando abaixo:

# smbldap-useradd -a -P username

• -a Adiciona uma nova conta
• -P Chama o utilitário passwd solicitando uma senha

Cria um novo grupo:

# smbldap-groupadd -a breny

Altera o grupo para um usuário:

# smbldap-usermod breny -g breny -G "Domain Users"

Definido que o usuário breny pertence ao grupo primário -g (breny) e ao grupo secundário -G (Domain Admins).

Consultar dados de usuários:

# smbldap-usershow usuário

Alterar senha do usuário:

# smbldap-passwd -u usuário

Deletar usuário:

# smbldap-userdel usuario

Configurando interface gráfica para administração LDAP (Master e Slave)

Vamos utilizar para isso o phpldapadmin para administrar a estrutura do servidor LDAP.

Acesse este ink, utilize sempre a última versão. Realize o download e salve em um diretório dentro do servidor LDAP.

Execute o comando abaixo para descompactar o arquivo gerando automaticamente o diretório phpldapadmin:

# tar -xzvf arquivo_phpldapadmin.gz

O phpldapadmin precisa de um servidor web para hospedar os arquivos, vamos utilizar o Apache para isso. O Necessário agora copiar o conteúdo desse diretório para dentro do diretório root do Apache, que esta localizado em: /var/www/html/. Crie um diretório dentro desse diretório, por exemplo, /var/www/html/ldapadm/ Pode ser executado o comando rsync -av para realizar essa copia, por exemplo:

# rsync -av phpldapadmin/ /var/www/html/ldapadmin/

Após copiar os arquivos, acesse o arquivo de configuração do Apache em /etc/httpd/conf/httpd.conf e verifique se o modulo php5 esta configurado para o Apache utilizar.

Por padrão, no Red Hat Enterprise Linux 5 vem com o módulo php configurado no Apache, para ativar o php5 no apache é necessário colocar a linha abaixo dentro do httpd.conf ou verificar se no diretório conf.d existe o arquivo php.conf apontando para a mesma linha abaixo:


Com essa configuração já é possível acessar a página de login do phpldapadmin, mas antes disso, precisamos acessar o diretório do phpldapadmin e renomear o arquivo config.php.example para config.php, para isso execute o comando abaixo:

# mv /var/www/html/ldapadmin/config/config.php.example config.php

Agora necessário acessar esse arquivo e realizar a configuração abaixo:

# vi /var/www/html/ldapadmin/config/config.php

Configura o idioma do aplicativo:


Edite o arquivo de configuração do Apache e realize as substituições abaixo:

# vi /etc/httpd/conf/httpd.conf

Observação - bugs:

1) Identificado que existe um bug nessa versão do ldapphpadmin ao criar um grupo de mapeamento Samba, sendo necessário antes de criar o grupo, limpar apagar os arquivos temporários do navegador, fechar a janela e iniciar o processo novamente, pois notou-se que ao criar o grupo de mapeamento Samba, em vez do phpldapadmin trazer o SID do domínio Samba para o grupo, o mesmo não era feito.

2) Identificado problemas com a senha dos usuários, quando era realizar alguma alteração na "cn" do usuário que não fosse a própria senha. Observou-se que ao alterar qualquer atributo do usuário, ao finalizar o processo, na tela para confirmar as alterações, é necessário marcar o check-box "pular" referente aos campos das senhas, ao não realizar esse procedimento, foi observado que o ldapphpadmin mandava sujeira para o campo válido das senhas, corrompendo as senhas do usuário já definidas e com isso, o usuário parava de logar nas estações Windows.

Criando usuários e grupos com o ldapphpadmin

O conceito realizado aqui foi o de criar grupos Samba para cada usuário com o respectivo nome do usuário, procedimento que estamos acostumados quando criamos usuários em um sistema Linux. Dessa maneira, aumento o nível de acesso do usuário específico e mantenho restrito o acesso de outros usuários aos arquivos desse usuário em questão.

O conceito é de primeiro criar um grupo de mapeamento Samba com o mesmo nome do usuário, depois criar o usuário apontando para o mesmo grupo que possui o mesmo nome de usuário e após adicionar o usuário nos grupos de compartilhamento que por ventura será criado conforme o acesso que o usuário precise ter em casa compartilhamento no servidor.

Prestar atenção que o Samba possui uma numeração para os seus grupos, iniciando em 3000 e os usuários possuem a numeração iniciando em 500, os quais já conhecemos como UIDs e a numeração dos grupos iniciando em 500 que conhecemos como GIDs.

Observei que o conceito original continua em operação, ou seja, o Samba precisa mapear um grupo do próprio Samba para um grupo pertencente ao nível Linux o qual possui um UID do usuário preso ao mesmo.

Criando a replicação da base LDAP para outro equipamento (Master-Slave)

Antes de iniciar o processo de configuração, necessário realizar a instalação do LDAP no equipamento que irá atuar como Servidor LDAP Slave.

Agora que o OpenLDAP esta instalado no sistemas/equipamento que atuará como Slave, realize a copia do arquivo /etc/openldap/slapd.conf contido no equipamento LDAP Master para o mesmo local no equipamento LDAP Slave. Realize a copia do diretório: /etc/openldap/schema/ para o mesmo diretório no equipamento LDAP Slave.

Copie o arquivo /etc/openldap/DB_CONFIG.example para o diretório /var/lib/ldap/ utilizando os seguintes comandos:

# cd /etc/openldap/
# cp DB_CONFIG.example /var/lib/ldap/DB_CONFIG

Após realizar a copia do arquivo de configuração do LDAP para o equipamento Slave, abra o arquivo /etc/openldap/slapd.conf do servidor LDAP Master e adicione as seguintes linhas:


Onde:

• replica uri - Define o endereço para o equipamento que atuará como LDAP Slave;
• binddn - Define o bind do administrador do LDAP;
• bindmethod - Define que a senha a ser utilizada esta definida no parâmetro credentials para contactar o LDAP Slave;
• credentials - Insira a senha do administrador do LDAP;
• replogfile - Define o local e o nome do arquivo de log dos eventos de replicação.

Após o processo acima, é necessário agora editar o mesmo arquivo no servidor LDAP Slave, inserindo as seguintes linhas:

O responsável por realizar essa atualização no LDAP Slave é o próprio rootdn ou seja, o administrador, desse modo, não é necessário conceder qualquer tipo de autorização para escrita, pois o rootdn possui acesso completo na base LDAP.


Sendo que:

• access to * by dn="cn=admin,dc=dominio,dc=com,dc=br" write - Define que o acesso de escrita será permitido para o administrador do LDAP
• updatedn "cn=admin,dc=dominio,dc=com,dc=br" - Define qual o usuário que será responsável para realizar as atualizações
• updateref ldap://IP_LDAP_MASTER - Define o IP do equipamento que possui o LDAP Master

Após isso, necessário gerar o backup das informações contidas na base de dados do LDAP Master, exportando as mesmas para um arquivo .DIF, utilizando o comando abaixo:

# slapcat > base_ldap_slave.dif

Após gerar o arquivo base.dif, necessário copiar o mesmo para o equipamento que será o LDAP Slave e executar os comandos abaixo para subir o servidor LDAP Slave e importar a base para o LDAP Slave:

# service ldap start
# ldapadd -x -D "cn=administrador,dc=transbrasa,dc=com,dc=br" -W -f base_ldap_slave.dif

Digite a senha do administrador do LDAP.

Observação: Pode ser utilizado o phpldapadmin no equipamento LDAP Slave para verificar as alterações e atualizações ocorrendo on the fly! Siga o procedimento descrito nesse documento para realizar a instalação do phpldapadmin no LDAP Slave.

Abra o phpldapadmin no LDAP Master, pegue por exemplo, algum login de usuário na ou=usuários e altere alguma entrada, por exemplo, a entrada Gecos, clique no atualizar objeto no final da página e com o phpldapadmin no LDAP Slave, clique em atualizar página, verifique a mesma alteração foi replicada para o LDAP Slave.

Sincronizar os arquivos e compartilhamentos entre os servidores

Para esse procedimento eu criei um script que realiza o sync entre os diretórios /home dos dois servidores, mas para esse script funcionar é necessário que a autenticação através do ssh seja permitido entre os usuários root dos dois servidores.

Para isso, vamos gerar o certificado do root no servidor Linux Master e copiar o mesmo renomeado para o Linux Slave.

No servidor Master execute o comando abaixo para gerar as chaves:

# ssh-keygen -b 1024 -t rsa

Ao executar o comando acima, apenas tecle [Enter] para as perguntas, dessa forma será gerada a chave, mas sem senha.

Após realizar o procedimento acima as chaves foram geradas no diretório /root/.ssh/, copie a chave pública id_rsa.pub para o mesmo diretório no Linux Slave. Após realizar essa cópia, acesse o diretório no servidor Linux Slave e mude o nome do arquivo para authorized_keys.

Esse arquivo authorized_keys possui a chave pública do servidor Linux Master e com isso ao executar o script no servidor Linux Master, não será solicitado nenhuma senha por parte do servidor Linux Slave, pois o mesmo irá estabelecer a conexão através do certificado que copiamos anteriormente.

Após realizar o procedimento acima, já podemos por exemplo executar o comando abaixo, pois o mesmo não solicitará senha:

# ssh root@192.168.5.121 (servidor Linux Slave)

Perceba que o ssh conectou normalmente sem pedir senha.

Abaixo segue um exemplo de script que realiza o sincronismo entre os diretórios /home dos dois servidores.


O comando rsync é o responsável por manter os arquivos e diretórios sincronizados nos dois servidores, segue o que os parâmetros passados para o comando:

• -av Define para manter as permissões originais nos diretórios e arquivos sincronizados;
• -X Define para manter as permissões estendidas nos diretórios e arquivos sincronizados;
• --delete Define que se o diretório original for deletado, o mesmo deve ser deletado no destino;
• --exclude-from= Define um arquivo que possui os sub-diretórios que não devem ser copiados;
• --force Define que até mesmos os diretórios não vazios devem ser deletados no destino;

Configurando compartilhamento no Samba

Até o momento a configuração descrita estava baseando na redundância sobre o LDAP e Samba, nessa parte estou colocando a configuração de alguns compartilhamentos a nível do Samba, mesmo funcionando com o funcionamento do Samba com o LDAP, nada mudou nesse nível, para o Samba é abstrato onde o mesmo deve buscar a base para autenticar os usuários e os próprios compartilhamentos.

O Samba precisa saber onde buscar, com as informações em Mão, para ele, tudo continua da mesma forma. Desse modo, segue algum exemplo utilizados para os compartilhamentos.


Um problema que enfrento com o Linux e Samba é respectivo há algumas configurações de permissões para acessar o compartilhamento, por exemplo, preciso que um alguns usuários e grupos consigam acessar o compartilhamento CPD, desses usuários, alguns poderão alterar o conteúdo do compartilhamento e outros somente ler o conteúdo, para isso a nível de compartilhamento Samba existe os parâmetros valid users, write list e read list.

Lembrando independente da configuração de permissões setadas no Samba, o mesmo respeita as permissões já existentes no nível do sistema de arquivos Linux, ou seja, as permissões existentes no Linux para o diretório: /home/cpd são prioritárias sobre o Samba. Não adianta liberar o acesso completo no Samba para tal diretório, sendo que esse mesmo diretório no Linux não permite o acesso completo.

O conceito é, primeiro criamos o diretório no Linux, depois setamos as permissões que queremos para esse diretório com os comandos chown e chmod, após isso, vamos pensar em como configurar o Samba para que as permissões sejam iguais as já setadas no Linux.

Os parâmetros create mask e directory mask, são o segundo ponto que o Samba verifica após o usuário conseguir o acesso ao compartilhamento, pois respectivamente, esses dois parâmetros informa ao Samba como o mesmo deve proceder com as permissões quando algum usuário criar um novo arquivo (create mask) e quando algum usuário criar um diretório (directory mask).

O conceito é o mesmo, mas utilizamos a base octal do chmod e devemos respeitar a mesma regra de compatibilidade entre o Linux e o Samba. No exemplo acima, esta setado para que toda vez que for criado um diretório ou arquivo, o Samba deve setar automaticamente as permissões 770 para os mesmos, ou seja, Dono e Grupo acesso completo e os outros sema acesso.

Um outro parâmetro interessante é o "force group", que permite que o Samba sempre salve o arquivo como pertencendo ao grupo setado nesse parâmetro. O Samba chama o comando chown para alterar o grupo para cada novo arquivo e diretório criado.

Esse comando é muito útil no seguinte contexto:

Quando todos os novos arquivos e diretórios criados nesse compartilhamento precisam ser setados para um grupo específico, permitindo que os outros usuários pertencentes ao mesmo grupo consigam alterar o mesmo.

Infelizmente o Linux possui uma grande limitação com as permissões de arquivos e diretórios se comparado com o Windows, nesse ponto, o Windows é melhor. Pois o conceito de permissões no Linux concentram-se em dono.grupo.outros, nesse conceito, quando defino para um usuário que o mesmo possui permissão de gravação (w) para um arquivo, o Linux entende implicitamente que esse mesmo usuário poderá deletar o arquivo, ou seja, essa responsabilidade no contexto com o Samba esta para o usuário que criou o arquivo e não para o administrador.

Imagine o caso que precise criar um compartilhamento, onde todos os arquivos criados no mesmo não possam ser deletados, somente atualizados. Isso não é possível, mesmo utilizando o setfacl o qual controla as permissões a nível de ACLs diminuindo um pouco mais essa limitação.

No Windows, isso não acontece, pois o mesmo, com a família NT (Windows 2000, XP e adiante) já entendiam o conceito de o usuário que pode salvar, não necessariamente pode deletar o mesmo arquivo.

Tudo bem que isso pareça não ter lógica, pois o usuário que possui permissão para salvar um arquivo no Windows e que não possua permissão para deletá-lo, poderia simplesmente abrir o arquivo em questão, apagar todo o seu conteúdo e após salvar o arquivo. Mas necesse caso, podemos utilizar logues de acesso e recorrer a backups gerados para restaurar o mesmo arquivo e com certeza esse mesmo usuário não ficaria legal na história.

Scripts de logon Netlogon e restringir alterações dos usuários nas estações

Com a utilização do servidor de domínio é possível utilizar o recurso de executar scripts no momento que o usuário loga em uma estação de trabalho Windows e com isso instruindo o Windows a realizar alterações no registro do próprio Windows para restringir alterações dos usuários em configurações do Windows.

Para isso funcionar é necessário que os parâmetros abaixo estejam definidos no arquivo: /etc/samba/smb.conf


Com essas linhas acima, o Samba foi instruído a executar qualquer arquivo .vbs desde que o mesmo arquivo possua o mesmo nome da conta de logon utilizada pelo usuário que irá logar no domínio. Segue o conteúdo do arquivo .vbs:


Obs.: Eu utilizo um arquivo .vbs para cada usuário separadamente para impedir que o Windows na estação do usuário mostre a tela do prompt do DOS, executando as linhas de configurações, desse modo, impedindo que o usuário feche essa janela e o script não seja executado até o final.

Observe que esse script .vbs chama um arquivo .bat. Esse arquivo .bat é o que contem as linhas que devem ser executadas pelo Windows. Ambos os arquivos devem ser salvos para cada usuário dentro do compartilhamento netlogon, localizado em /home/netlogon.

Segue o conteúdo do arquivo .bat:


A primeira linha informa para o Windows onde o mesmo deve sincronizar o relógio da estação, para que isso funcione é necessário instruir o Samba a ser um servidor de horas para a rede com o parâmetro "time server = yes", desse modo o Samba pega o horário do servidor Linux e repassa para as estações, conforme as mesmas solicitam a ele durante o logon de cada usuário.

A segunda linha chama o comando "net use" e indica uma letra de unidade para o Windows e o caminho onde esse compartilhamento existe no servidor. Utilize esse conceito para mapear unidades automaticamente conforme a necessidade de cada usuário.

A quarta linha chama o comando reg e instrui o mesmo a adicionar uma chave de configuração no registro do Windows em questão, instruindo o mesmo a desativar o acesso ao Painel de Controle para o usuário em questão. Esse conceito funciona como uma Group Polices do AD, o único inconveniente é que dependendo da chave que deseja alterar é necessário realizar dois logoff e logon consecutivos para o Windows ler a chave alterada.

Utilize o site http://www.pctools.com para mais exemplos ou pesquise no Google chaves interessantes do registro que possam ser alteradas seguindo esse conceito.

Atualização desse artigo:

Eu mantenho esse artigo atualizado no meu blog: http://genixsky.blogspot.com/