                               Autenticac,ao LDAP

  Toby Burress

       <kurin@causa-sui.net>
     

   Revisao: b3bb49e732

   Copyright (c) 2007-2008 Projeto de Documentac,ao do FreeBSD

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   Many of the designations used by manufacturers and sellers to distinguish
   their products are claimed as trademarks. Where those designations appear
   in this document, and the FreeBSD Project was aware of the trademark
   claim, the designations have been followed by the "(TM)" or the "(R)"
   symbol.

   2018-09-06 00:20:03 +0000 por Edson Brandi.
   Resumo

   Este documento pretende ser um guia para a configurac,ao de um servidor
   LDAP (principalmente um servidor OpenLDAP) para autenticac,ao no FreeBSD.
   Isso e util para situac,oes em que muitos servidores precisam das mesmas
   contas de usuario, por exemplo, como substituto do NIS.

   [ Documento HTML em partes / Documento HTML completo ]

     ----------------------------------------------------------------------

   Indice

   1. Prefacio

   2. Configurando o LDAP

   3. Configurac,ao do Cliente

   4. Considerac,oes de seguranc,a

   A. Ajudas Uteis

   B. Certificados do OpenSSL para LDAP

1. Prefacio

   Este documento destina-se a fornecer ao leitor uma compreensao suficiente
   do LDAP para configurar um servidor LDAP. Este documento tentara fornecer
   uma explicac,ao de net/nss_ldap e security/pam_ldap para uso com servic,os
   de maquinas cliente para uso com o servidor LDAP.

   Quando terminar, o leitor deve ser capaz de configurar e implantar um
   servidor FreeBSD que possa hospedar um diretorio LDAP e configurar e
   implantar um servidor FreeBSD que possa autenticar em um diretorio LDAP.

   Este artigo nao pretende ser um relato exaustivo da seguranc,a, robustez
   ou considerac,oes sobre praticas recomendadas para configurar o LDAP ou os
   outros servic,os discutidos aqui. Embora o autor tenha o cuidado de fazer
   tudo corretamente, ele nao aborda problemas de seguranc,a alem do escopo
   geral. Este artigo deve ser considerado para estabelecer as bases teoricas
   somente, e qualquer implementac,ao real deve ser acompanhada por uma
   analise cuidadosa dos requisitos.

2. Configurando o LDAP

   LDAP significa "Lightweight Directory Access Protocol" e e um subconjunto
   do X.500 Directory Access Protocol. Suas especificac,oes mais recentes
   estao na RFC4510 e documentos amigaveis. Essencialmente, e um banco de
   dados que espera ser lido com mais frequencia do que e escrito.

   O servidor LDAP OpenLDAP sera usado nos exemplos deste documento; embora
   os principios aqui devam ser geralmente aplicaveis &#8203;&#8203;a muitos
   servidores diferentes, a maior parte da administrac,ao concreta e
   especificamente para OpenLDAP. Existem varias versoes de servidor nos
   ports, por exemplo net/openldap24-server. Os servidores clientes
   precisarao das bibliotecas net/openldap24-client correspondentes.

   Existem (basicamente) duas areas do servic,o LDAP que precisam de
   configurac,ao. A primeira e a configurac,ao de um servidor para receber as
   conexoes corretamente, e o segundo e adicionar entradas ao diretorio do
   servidor para que as ferramentas do FreeBSD saibam como interagir com ele.

  2.1. Configurando o servidor para conexoes

  Nota:

   Esta sec,ao e especifica do OpenLDAP. Se voce estiver usando outro
   servidor, precisara consultar a documentac,ao desse servidor.

    2.1.1. Instalando o OpenLDAP

   Primeiro, instale o OpenLDAP:

   Exemplo 1. Instalando o OpenLDAP

 # cd /usr/ports/net/openldap24-server
 # make install clean

   Isso instala os binarios slapd e slurpd, juntamente com as bibliotecas
   OpenLDAP requeridas.

    2.1.2. Configurando o OpenLDAP

   Em seguida, devemos configurar o OpenLDAP.

   Voce desejara exigir criptografia em suas conexoes com o servidor LDAP;
   caso contrario, as senhas de seus usuarios serao transferidas em texto
   simples, o que e considerado inseguro. As ferramentas que usaremos
   suportam dois tipos muito semelhantes de criptografia, SSL e TLS.

   TLS significa "Seguranc,a da Camada de Transporte". Servic,os que empregam
   TLS tendem a se conectar nas mesmas portas que os mesmos servic,os sem
   TLS; assim, um servidor SMTP que suporte o TLS escutara as conexoes na
   porta 25 e um servidor LDAP escutara no 389.

   SSL significa "Secure Sockets Layer", e servic,os que implementam SSL nao
   escutam nas mesmas portas que seus equivalentes nao-SSL. Assim, o SMTPS
   atende na porta 465 (nao 25), HTTPS escuta na 443 e LDAPS na 636.

   A razao pela qual o SSL usa uma porta diferente do TLS e porque uma
   conexao TLS comec,a como texto simples e alterna para o trafego
   criptografado apos a diretiva STARTTLS. As conexoes SSL sao criptografadas
   desde o inicio. Alem disso, nao ha diferenc,as substanciais entre os dois.

  Nota:

   Ajustaremos o OpenLDAP para usar o TLS, ja que o SSL e considerado
   obsoleto.

   Uma vez que o OpenLDAP esteja instalado via ports, os seguintes parametros
   de configurac,ao em /usr/local/etc/openldap/slapd.conf irao ativar o TLS:

 security ssf=128

 TLSCertificateFile /caminho/para/seu/cert.crt
 TLSCertificateKeyFile /caminho/para/sua/cert.key
 TLSCACertificateFile /caminho/para/seu/cacert.crt

   Aqui, ssf=128 diz ao OpenLDAP para exigir criptografia de 128 bits para
   todas as conexoes, tanto de pesquisa quanto de atualizac,ao. Esse
   parametro pode ser configurado com base nas necessidades de seguranc,a do
   seu site, mas raramente e necessario enfraquece-la, pois a maioria das
   bibliotecas de clientes LDAP oferece suporte `a criptografia forte.

   Os arquivos cert.crt, cert.key e cacert.crt sao necessarios para que os
   clientes autentiquem voce como o servidor LDAP valido. Se voce
   simplesmente quiser um servidor que seja executado, podera criar um
   certificado autoassinado com o OpenSSL:

   Exemplo 2. Gerando uma chave RSA

 % openssl genrsa -out cert.key 1024
 Generating RSA private key, 1024 bit long modulus
 ....................++++++
 ...++++++
 e is 65537 (0x10001)
 % openssl req -new -key cert.key -out cert.csr

   Neste ponto, voce deve ser solicitado para digitar alguns valores. Voce
   pode inserir os valores que quiser; no entanto, e importante que o valor
   "Common Name" seja o nome de dominio totalmente qualificado do servidor
   OpenLDAP. No nosso caso, e os exemplos aqui, o servidor e
   server.example.org. Definir incorretamente esse valor fara com que os
   clientes falhem ao fazer conexoes. Isso pode causar uma grande
   frustrac,ao, portanto, certifique-se de seguir atentamente estas etapas.

   Por fim, a requisic,ao de assinatura de certificado precisa ser assinada:

   Exemplo 3. Auto-assinando o certificado

 % openssl x509 -req -in cert.csr -days 365 -signkey cert.key -out cert.crt
 Signature ok
 subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
 Getting Private key

   Isso criara um certificado auto-assinado que pode ser usado para as
   diretivas em slapd.conf, onde cert.crt e cacert.crt sao o mesmo arquivo.
   Se voce for usar muitos servidores OpenLDAP (para replicac,ao via slurpd),
   voce vai querer ver Apendice B, Certificados do OpenSSL para LDAP para
   gerar uma chave CA e usa-la para assinar certificados de servidor
   individuais.

   Feito isso, coloque o seguinte em /etc/rc.conf:

 slapd_enable="YES"

   Em seguida, execute /usr/local/etc/rc.d/slapd start. Isso deve iniciar o
   OpenLDAP. Confirme que esta escutando em 389 com

 % sockstat -4 -p 389
 ldap     slapd      3261  7  tcp4   *:389                 *:*

    2.1.3. Configurando o Cliente

   Instale o port net/openldap24-client para as bibliotecas do OpenLDAP. As
   maquinas cliente sempre terao bibliotecas OpenLDAP, ja que e todo o
   suporte a security/pam_ldap e net/nss_ldap, pelo menos por enquanto.

   O arquivo de configurac,ao para as bibliotecas OpenLDAP e
   /usr/local/etc/openldap/ldap.conf. Edite este arquivo para conter os
   seguintes valores:

 base dc=example,dc=org
 uri ldap://server.example.org/
 ssl start_tls
 tls_cacert /path/to/your/cacert.crt

  Nota:

   E importante que seus clientes tenham acesso ao cacert.crt, caso
   contrario, eles nao poderao se conectar.

  Nota:

   Existem dois arquivos chamados ldap.conf. O primeiro e este arquivo, que e
   para as bibliotecas OpenLDAP e define como falar com o servidor. O segundo
   e /usr/local/etc/ldap.conf e e para pam_ldap.

   Neste ponto, voce deve conseguir executar ldapsearch -Z na maquina
   cliente; -Z significa "usar o TLS". Se voce encontrar um erro, entao algo
   esta configurado errado; muito provavelmente sao seus certificados. Use os
   comandos s_client e s_server do openssl(1) para assegurar que voce os
   tenha configurado e assinado corretamente.

  2.2. Entradas no banco de dados

   A autenticac,ao em um diretorio LDAP geralmente e realizada pela tentativa
   de vincular ao diretorio como o usuario de conexao. Isso e feito
   estabelecendo um vinculo "simples" no diretorio com o nome de usuario
   fornecido. Se houver uma entrada com o uid igual ao nome do usuario e o
   atributo userPassword da entrada corresponder `a senha fornecida, o
   vinculo sera bem-sucedido.

   A primeira coisa que temos que fazer e descobrir onde no diretorio os
   nossos usuarios irao estar.

   A entrada de base para nosso banco de dados e dc=example,dc=org. O local
   padrao para usuarios que a maioria dos clientes parece esperar e algo como
   ou=people, base , entao e isso que sera usado aqui. No entanto, tenha em
   mente que isso e configuravel.

   Assim, a entrada ldif para a unidade organizacional people sera semelhante
   a:

 dn: ou=people,dc=example,dc=org
 objectClass: top
 objectClass: organizationalUnit
 ou: people

   Todos os usuarios serao criados como subentradas dessa unidade
   organizacional.

   Alguma considerac,ao pode ser dada `a classe de objeto a que seus usuarios
   pertencerao. A maioria das ferramentas, por padrao, usara people, o que e
   bom se voce quiser simplesmente fornecer entradas para autenticar. No
   entanto, se voce for armazenar informac,oes do usuario no banco de dados
   LDAP, provavelmente usara inetOrgPerson, que possui muitos atributos
   uteis. Em ambos os casos, os esquemas relevantes precisam ser carregados
   em slapd.conf.

   Para este exemplo, usaremos a classe de objeto person. Se voce estiver
   usando inetOrgPerson, as etapas sao basicamente identicas, exceto que o
   atributo sn e necessario.

   Para adicionar um usuario testuser, o ldif seria:

 dn: uid=tuser,ou=people,dc=example,dc=org
 objectClass: person
 objectClass: posixAccount
 objectClass: shadowAccount
 objectClass: top
 uidNumber: 10000
 gidNumber: 10000
 homeDirectory: /home/tuser
 loginShell: /bin/csh
 uid: tuser
 cn: tuser

   Eu inicio os UIDs dos meus usuarios LDAP em 10000 para evitar colisoes com
   contas do sistema; voce pode configurar o numero que desejar aqui, desde
   que seja menor que 65536.

   Tambem precisamos de entradas de grupo. Eles sao configuraveis
   &#8203;&#8203;como entradas do usuario, mas usaremos os padroes abaixo:

 dn: ou=groups,dc=example,dc=org
 objectClass: top
 objectClass: organizationalUnit
 ou: groups

 dn: cn=tuser,ou=groups,dc=example,dc=org
 objectClass: posixGroup
 objectClass: top
 gidNumber: 10000
 cn: tuser

   Para inseri-los em seu banco de dados, voce pode usar slapadd ou ldapadd
   em um arquivo contendo essas entradas. Alternativamente, voce pode usar o
   sysutils/ldapvi.

   O utilitario ldapsearch na maquina cliente deve agora retornar essas
   entradas. Em caso afirmativo, o banco de dados esta configurado
   corretamente para ser usado como um servidor de autenticac,ao LDAP.

3. Configurac,ao do Cliente

   O cliente ja deve ter bibliotecas do OpenLDAP do Sec,ao 2.1.3,
   "Configurando o Cliente", mas se voce estiver instalando varias maquinas
   clientes, precisara instalar o net/openldap24-client em cada um deles.

   O FreeBSD requer que dois ports sejam instalados para autenticac,ao em um
   servidor LDAP, security/pam_ldap e net/nss_ldap.

  3.1. Autenticac,ao

   O security/pam_ldap e configurado atraves do /usr/local/etc/ldap.conf.

  Nota:

   Este e um arquivo diferente que o arquivo de configurac,ao das func,oes da
   biblioteca OpenLDAP, /usr/local/etc/openldap/ldap.conf; no entanto, sao
   necessarias muitas das mesmas opc,oes; na verdade, e um superconjunto
   desse arquivo. Para o resto desta sec,ao, referencias a ldap.conf irao
   significar o arquivo /usr/local/etc/ldap.conf.

   Assim, vamos querer copiar todos os nossos parametros de configurac,ao
   originais do openldap/ldap.conf para o novo ldap.conf. Feito isso,
   queremos informar ao security/pam_ldap o que procurar no servidor de
   diretorio.

   Estamos identificando nossos usuarios com o atributo uid. Para configurar
   isso (embora seja o padrao), defina a diretiva pam_login_attribute no
   ldap.conf:

   Exemplo 4. Definindo pam_login_attribute

 pam_login_attribute uid

   Com esta definic,ao, o security/pam_ldap pesquisara todo o diretorio LDAP
   na base para o valor uid=username . Se encontrar uma e apenas uma entrada,
   ela tentara se vincular como aquele usuario com a senha que foi fornecida.
   Se vincular corretamente, entao permitira o acesso. Caso contrario,
   falhara.

   Os usuarios cujo shell nao esta em /etc/shells nao poderao efetuar login.
   Isto e particularmente importante quando o Bash e definido como o shell do
   usuario no servidor LDAP. O Bash nao esta incluido em uma instalac,ao
   padrao do FreeBSD. Quando instalado a partir de um pacote ou port, ele
   esta localizado em /usr/local/bin/bash. Verifique se o caminho para o
   shell no servidor esta definido corretamente:

 % getent passwd username

   Existem duas opc,oes quando a saida mostra /bin/bash na ultima coluna. A
   primeira e alterar a entrada do usuario no servidor LDAP para
   /usr/local/bin/bash. A segunda opc,ao e criar um link simbolico no
   computador cliente LDAP para que o Bash seja encontrado no local correto:

 # ln -s /usr/local/bin/bash /bin/bash

   Certifique-se de que /etc/shells contenha entradas para ambos
   /usr/local/bin/bash e /bin/bash. O usuario podera entao efetuar login no
   sistema com Bash como seu shell.

    3.1.1. PAM

   PAM, que significa "Pluggable Authentication Modules", e o metodo pelo
   qual o FreeBSD autentica a maioria de suas sessoes. Para dizer ao FreeBSD
   que desejamos usar um servidor LDAP, teremos que adicionar uma linha ao
   arquivo PAM apropriado.

   Na maioria das vezes o arquivo PAM apropriado e /etc/pam.d/sshd, se voce
   quiser usar SSH (lembre-se de definir as opc,oes relevantes em
   /etc/ssh/sshd_config, caso contrario o SSH nao usara o PAM).

   Para usar o PAM para autenticac,ao, adicione a linha

 auth suficiente /usr/local/lib/pam_ldap.so no_warn

   Exatamente onde essa linha aparece no arquivo e quais opc,oes aparecem na
   quarta coluna, determine o comportamento exato do mecanismo de
   autenticac,ao; veja pam.d(5)

   Com essa configurac,ao, voce deve conseguir autenticar um usuario em um
   diretorio LDAP. O PAM executara uma ligac,ao com suas credenciais e, se
   for bem-sucedido, informara ao SSH para permitir o acesso.

   No entanto, nao e uma boa ideia permitir que todo usuario no diretorio
   dentro de todo computador cliente. Com a configurac,ao atual, tudo o que
   um usuario precisa para efetuar login em uma maquina e uma entrada LDAP.
   Felizmente, existem algumas maneiras de restringir o acesso do usuario.

   O ldap.conf suporta uma diretiva pam_groupdn; Cada conta que se conecta a
   essa maquina precisa ser membro do grupo especificado aqui. Por exemplo,
   se voce tem

 pam_groupdn cn=servername,ou=accessgroups,dc=example,dc=org

   em ldap.conf, somente os membros desse grupo poderao efetuar login.
   Entretanto, ha algumas coisas a serem lembradas.

   Os membros desse grupo sao especificados em um ou mais atributos memberUid
   e cada atributo deve ter o nome distinto completo do membro. Entao
   memberUid:someuser nao funcionara; deve ser:

 memberUid: uid=algum usuario, ou=pessoas, dc=exemplo, dc=org

   Alem disso, essa diretiva nao e verificada no PAM durante a autenticac,ao,
   ela e verificada durante o gerenciamento de contas, portanto, voce
   precisara de uma segunda linha em seus arquivos PAM sob account. Isso
   exigira, por sua vez, que todo usuario seja listado no grupo, o que nao e
   necessariamente o que queremos. Para evitar o bloqueio de usuarios que nao
   estao no LDAP, voce deve ativar o atributo ignore_unknown_user.
   Finalmente, voce deve definir a opc,ao ignore_authinfo_unavail para que
   voce nao fique bloqueado em todos os computadores quando o servidor LDAP
   estiver indisponivel.

   Seu pam.d/sshd pode acabar ficando assim:

   Exemplo 5. Exemplo pam.d/sshd

 auth            required        pam_nologin.so          no_warn
 auth            sufficient      pam_opie.so             no_warn no_fake_prompts
 auth            requisite       pam_opieaccess.so       no_warn allow_local
 auth            sufficient      /usr/local/lib/pam_ldap.so      no_warn
 auth            required        pam_unix.so             no_warn try_first_pass

 account         required        pam_login_access.so
 account         required        /usr/local/lib/pam_ldap.so      no_warn ignore_authinfo_unavail ignore_unknown_user

  Nota:

   Como estamos adicionando essas linhas especificamente para pam.d/sshd,
   isso so tera um efeito nas sessoes SSH. Os usuarios LDAP nao poderao
   efetuar login no console. Para mudar este comportamento, examine os outros
   arquivos em /etc/pam.d e modifique-os de acordo.

  3.2. Switch de servic,o de nome

   NSS e o servic,o que mapeia atributos para nomes. Assim, por exemplo, se
   um arquivo e de propriedade do usuario 1001, um aplicativo consultara o
   NSS para o nome de 1001, e ele pode obter bob ou ted ou qualquer que seja
   o nome do usuario.

   Agora que nossas informac,oes sobre o usuario sao mantidas no LDAP,
   precisamos dizer ao NSS para procurar la quando perguntado.

   O port net/nss_ldap faz isso. Ele usa o mesmo arquivo de configurac,ao
   como security/pam_ldap e nao deve precisar de nenhum parametro extra
   depois de instalado. Em vez disso, o que resta e simplesmente editar e
   /etc/nsswitch.conf para aproveitar o diretorio. Simplesmente substitua as
   seguintes linhas:

 group: compat
 passwd: compat

   com

 group: files ldap
 passwd: files ldap

   Isso permitira que voce mapeie nomes de usuarios para UIDs e UIDs para
   nomes de usuarios.

   Parabens! Agora voce deve ter autenticac,ao LDAP em funcionamento.

  3.3. Ressalvas

   Infelizmente, a partir do momento em que isso foi escrito, o FreeBSD nao
   suportava a mudanc,a de senhas de usuario com passwd(1). Por causa disso,
   a maioria dos administradores estao deixando para implementar uma soluc,ao
   por conta propria. Eu fornec,o alguns exemplos aqui. Observe que, se voce
   escrever seu proprio script de alterac,ao de senha, ha alguns problemas de
   seguranc,a dos quais voce deve estar ciente; veja Sec,ao 4.3,
   "Armazenamento de Senha"

   Exemplo 6. Script de shell para alterac,ao de senhas

 #!/bin/sh

 stty -echo
 read -p "Old Password: " oldp; echo
 read -p "New Password: " np1; echo
 read -p "Retype New Password: " np2; echo
 stty echo

 if [ "$np1" != "$np2" ]; then
   echo "Passwords do not match."
   exit 1
 fi

 ldappasswd -D uid="$USER",ou=people,dc=example,dc=org \
   -w "$oldp" \
   -a "$oldp" \
   -s "$np1"

  Cuidado:

   Esse script dificilmente faz qualquer verificac,ao de erros, mas, o mais
   importante, e muito indiferente sobre como ele armazena suas senhas. Se
   voce fizer algo assim, ajuste pelo menos o valor de sysctl
   security.bsd.see_other_uids:

 # sysctl security.bsd.see_other_uids=0

   Uma abordagem mais flexivel (e provavelmente mais segura) pode ser usada
   escrevendo um programa personalizado, ou ate mesmo uma interface web. A
   seguir, parte de uma biblioteca Ruby que pode alterar senhas LDAP. Ele ve
   o uso na linha de comando e na web.

   Exemplo 7. Script Ruby para Alterar Senhas

 require 'ldap'
 require 'base64'
 require 'digest'
 require 'password' # ruby-password

 ldap_server = "ldap.example.org"
 luser = "uid=#{ENV['USER']},ou=people,dc=example,dc=org"

 # get the new password, check it, and create a salted hash from it
 def get_password
   pwd1 = Password.get("New Password: ")
   pwd2 = Password.get("Retype New Password: ")

   raise if pwd1 != pwd2
   pwd1.check # check password strength

   salt = rand.to_s.gsub(/0\./, '')
   pass = pwd1.to_s
   hash = "{SSHA}"+Base64.encode64(Digest::SHA1.digest("#{pass}#{salt}")+salt).chomp!
   return hash
 end

 oldp = Password.get("Old Password: ")
 newp = get_password

 # We'll just replace it.  That we can bind proves that we either know
 # the old password or are an admin.

 replace = LDAP::Mod.new(LDAP::LDAP_MOD_REPLACE | LDAP::LDAP_MOD_BVALUES,
                         "userPassword",
                         [newp])

 conn = LDAP::SSLConn.new(ldap_server, 389, true)
 conn.set_option(LDAP::LDAP_OPT_PROTOCOL_VERSION, 3)
 conn.bind(luser, oldp)
 conn.modify(luser, [replace])

   Apesar de nao ter a garantia de estar livre de falhas de seguranc,a (a
   senha e mantida na memoria, por exemplo), isso e mais limpo e mais
   flexivel do que um simples script sh.

4. Considerac,oes de seguranc,a

   Agora que suas maquinas (e possivelmente outros servic,os) estao
   autenticando em seu servidor LDAP, este servidor precisa ser protegido
   pelo menos tao bem quanto /etc/master.passwd seria em um servidor regular,
   e possivelmente mais ainda, uma vez que um servidor LDAP corrompido
   quebraria todos os servic,os do cliente.

   Lembre-se, esta sec,ao nao e exaustiva. Voce deve revisar continuamente
   sua configurac,ao e procedimentos para melhorias.

  4.1. Definindo atributos somente leitura

   Varios atributos no LDAP devem ser somente leitura. Se deixado gravavel
   pelo usuario, por exemplo, um usuario poderia alterar seu atributo
   uidNumber para 0 e obter acesso ao root!

   Para comec,ar, o atributo userPassword nao deve ser legivel por todos. Por
   padrao, qualquer pessoa que possa se conectar ao servidor LDAP pode ler
   esse atributo. Para desabilitar isso, coloque o seguinte em slapd.conf:

   Exemplo 8. Ocultar senhas

 access to dn.subtree="ou=people,dc=example,dc=org"
   attrs=userPassword
   by self write
   by anonymous auth
   by * none

 access to *
   by self write
   by * read

   Isso nao permitira a leitura do atributo userPassword, enquanto ainda
   permite que os usuarios alterem suas proprias senhas.

   Alem disso, voce desejara impedir que os usuarios alterem alguns de seus
   proprios atributos. Por padrao, os usuarios podem alterar qualquer
   atributo (exceto aqueles que os proprios esquemas LDAP negam alterac,oes),
   como uidNumber. Para fechar este buraco, modifique o acima para

   Exemplo 9. Atributos somente leitura

 access to dn.subtree="ou=people,dc=example,dc=org"
   attrs=userPassword
   by self write
   by anonymous auth
   by * none

 access to attrs=homeDirectory,uidNumber,gidNumber
   by * read

 access to *
   by self write
   by * read

   Isso impedira que os usuarios se disfarc,am como outros usuarios.

  4.2. Definic,ao da conta root

   Geralmente, a conta root ou a conta de administrador para o servic,o LDAP
   sera definida no arquivo de configurac,ao. O OpenLDAP suporta isso, por
   exemplo, e funciona, mas pode causar problemas se o slapd.conf estiver
   comprometido. Pode ser melhor usar isto apenas para se autoinicializar no
   LDAP, e entao definir uma conta root .

   Melhor ainda e definir contas com permissoes limitadas e omitir totalmente
   uma conta root. Por exemplo, os usuarios que podem adicionar ou remover
   contas de usuario sao adicionados a um grupo, mas nao podem alterar a
   participac,ao desse grupo. Essa politica de seguranc,a ajudaria a mitigar
   os efeitos de uma senha perdida.

    4.2.1. Criando um grupo de gerenciamento

   Digamos que voce queira que seu departamento de TI possa alterar os
   diretorios pessoais dos usuarios, mas nao deseja que todos eles possam
   adicionar ou remover usuarios. A maneira de fazer isso e adicionar um
   grupo para esses administradores:

   Exemplo 10. Criando um grupo de gerenciamento

 dn: cn=homemanagement,dc=example,dc=org
 objectClass: top
 objectClass: posixGroup
 cn: homemanagement
 gidNumber: 121 # required for posixGroup
 memberUid: uid=tuser,ou=people,dc=example,dc=org
 memberUid: uid=user2,ou=people,dc=example,dc=org

   E entao mude os atributos de permissoes em slapd.conf:

   Exemplo 11. ACLs para um grupo de gerenciamento de diretorio inicial

 access to dn.subtree="ou=people,dc=example,dc=org"
   attr=homeDirectory
   by dn="cn=homemanagement,dc=example,dc=org"
   dnattr=memberUid write

   Agora tuser e user2 podem alterar os diretorios home de outros usuarios.

   Neste exemplo, demos um subconjunto de poder administrativo a certos
   usuarios sem dar a eles poder em outros dominios. A ideia e que em breve
   nenhuma conta de usuario tenha o poder de uma conta root, mas todo poder
   que root tem seja tido por pelo menos um usuario. A conta root torna-se
   desnecessaria e pode ser removida.

  4.3. Armazenamento de Senha

   Por padrao, OpenLDAP armazenara o valor do atributo userPassword conforme
   ele armazena quaisquer outros dados: puro texto. Na maioria das vezes, ele
   e codificado na base 64, o que fornece protec,ao suficiente para impedir
   que um administrador honesto conhec,a sua senha, mas pouco ainda.

   E uma boa ideia, entao, armazenar senhas em um formato mais seguro, como o
   SSHA (salted SHA). Isso e feito por qualquer programa que voce use para
   alterar as senhas dos usuarios.

A. Ajudas Uteis

   Existem alguns outros programas que podem ser uteis, especialmente se voce
   tiver muitos usuarios e nao quiser configurar tudo manualmente.

   O security/pam_mkhomedir e um modulo PAM que sempre e bem-sucedido; Sua
   finalidade e criar diretorios pessoais para usuarios que nao os possuem.
   Se voce tiver dezenas de servidores clientes e centenas de usuarios, e
   muito mais facil usar isso e configurar diretorios esqueletos do que
   preparar cada diretorio inicial.

   O sysutils/cpu e um utilitario do tipo pw(8) que pode ser usado para
   gerenciar usuarios no diretorio LDAP. Voce pode chama-lo diretamente ou
   encapsular os scripts em torno dele. Ele pode manipular tanto o TLS (com o
   sinalizador -x) quanto o SSL (diretamente).

   O sysutils/ldapvi e um otimo utilitario para editar valores LDAP em uma
   sintaxe semelhante a LDIF. O diretorio (ou subsec,ao do diretorio) e
   apresentado no editor escolhido pela variavel de ambiente EDITOR. Isso
   facilita a ativac,ao de alterac,oes em grande escala no diretorio sem a
   necessidade de escrever uma ferramenta personalizada.

   O security/openssh-portable tem a capacidade de contatar um servidor LDAP
   para verificar as chaves SSH. Isso e extremamente bom se voce tiver muitos
   servidores e nao quiser copiar suas chaves publicas em todos eles.

B. Certificados do OpenSSL para LDAP

   Se voce estiver hospedando dois ou mais servidores LDAP, provavelmente nao
   desejara usar certificados autoassinados, ja que cada cliente precisara
   ser configurado para trabalhar com cada certificado. Embora isso seja
   possivel, nao e tao simples quanto criar sua propria autoridade de
   certificac,ao e assinar os certificados de seus servidores com isso.

   Os passos aqui sao apresentados como eles sao, com muito pouca tentativa
   de explicar o que esta acontecendo - mais explicac,oes podem ser
   encontradas em openssl(1) e aplicac,oes iguais.

   Para criar uma autoridade de certificac,ao, simplesmente precisamos de um
   certificado e chave autoassinados. As etapas para isso novamente sao

   Exemplo B.1. Criando um Certificado

 % openssl genrsa -out root.key 1024
 % openssl req -new -key root.key -out root.csr
 % openssl x509 -req -days 1024 -in root.csr -signkey root.key -out root.crt

   Estas serao sua chave e certificado de CA raiz. Voce provavelmente
   desejara criptografar a chave e armazena-la em um local seguro; qualquer
   pessoa com acesso a ele pode se passar por um dos seus servidores LDAP.

   Em seguida, usando as duas primeiras etapas acima, crie uma chave
   ldap-server-one.key e a solicitac,ao de assinatura de certificado
   ldap-server-one.csr. Depois de assinar o pedido de assinatura com
   root.key, voce podera usar o ldap-server-one.* nos servidores LDAP.

  Nota:

   Nao se esquec,a de usar o nome de dominio totalmente qualificado para o
   atributo "common name" ao gerar a solicitac,ao de assinatura de
   certificado; caso contrario, os clientes rejeitarao uma conexao com voce e
   podera ser muito complicado diagnosticar.

   Para assinar a chave, use -CA e -CAkey em vez de -signkey:

   Exemplo B.2. Assinando como uma autoridade de certificac,ao

 %   openssl x509 -req -dias 1024 \
 -em servidor ldap-one.csr -CA root.crt -CAkey root.key \
 -out ldap-server-one.crt

   O arquivo resultante sera o certificado que voce pode usar em seus
   servidores LDAP.

   Finalmente, para os clientes confiarem em todos os seus servidores,
   distribua root.crt (o certificado , nao a chave!) Para cada cliente, e
   especifique-o na directiva TLSCACertificateFile no ldap.conf.
