LDAP significa “Lightweight Directory Access Protocol” e é um subconjunto do X.500 Directory Access Protocol. Suas especificações mais recentes estão na RFC4510 e documentos amigaveis. Essencialmente, é um banco de dados que espera ser lido com mais frequência do que é escrito.
O servidor LDAP OpenLDAP será usado nos exemplos deste documento; embora os princípios aqui devam ser geralmente aplicáveis a muitos servidores diferentes, a maior parte da administração concreta é especificamente para OpenLDAP. Existem várias versões de servidor nos ports, por exemplo net/openldap24-server. Os servidores clientes precisarão das bibliotecas net/openldap24-client correspondentes.
Existem (basicamente) duas áreas do serviço LDAP que precisam de configuração. A primeira é a configuração de um servidor para receber as conexões corretamente, e o segundo é adicionar entradas ao diretório do servidor para que as ferramentas do FreeBSD saibam como interagir com ele.
Esta seção é específica do OpenLDAP. Se você estiver usando outro servidor, precisará consultar a documentação desse servidor.
Primeiro, instale o OpenLDAP:
Isso instala os binários slapd
e slurpd
, juntamente com as bibliotecas OpenLDAP requeridas.
Em seguida, devemos configurar o OpenLDAP.
Você desejará exigir criptografia em suas conexões com o servidor LDAP; caso contrário, as senhas de seus usuários serão transferidas em texto simples, o que é considerado inseguro. As ferramentas que usaremos suportam dois tipos muito semelhantes de criptografia, SSL e TLS.
TLS significa “Segurança da Camada de Transporte”. Serviços que empregam TLS tendem a se conectar nas mesmas portas que os mesmos serviços sem TLS; assim, um servidor SMTP que suporte o TLS escutará as conexões na porta 25 e um servidor LDAP escutará no 389.
SSL significa “Secure Sockets Layer”, e serviços que implementam SSL não escutam nas mesmas portas que seus equivalentes não-SSL. Assim, o SMTPS atende na porta 465 (não 25), HTTPS escuta na 443 e LDAPS na 636.
A razão pela qual o SSL usa uma porta diferente do TLS é porque uma conexão TLS começa como texto simples e alterna para o tráfego criptografado após a diretiva STARTTLS
. As conexões SSL são criptografadas desde o início. Além disso, não há diferenças substanciais entre os dois.
Ajustaremos o OpenLDAP para usar o TLS, já que o SSL é considerado obsoleto.
Uma vez que o OpenLDAP esteja instalado via ports, os seguintes parâmetros de configuração em /usr/local/etc/openldap/slapd.conf
irão 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 conexões, tanto de pesquisa quanto de atualização. Esse parâmetro pode ser configurado com base nas necessidades de segurança do seu site, mas raramente é necessário enfraquecê-la, pois a maioria das bibliotecas de clientes LDAP oferece suporte à criptografia forte.
Os arquivos cert.crt
, cert.key
e cacert.crt
são necessários para que os clientes autentiquem você como o servidor LDAP válido. Se você simplesmente quiser um servidor que seja executado, poderá criar um certificado autoassinado com o OpenSSL:
%
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, você deve ser solicitado para digitar alguns valores. Você pode inserir os valores que quiser; no entanto, é importante que o valor “Common Name” seja o nome de domínio totalmente qualificado do servidor OpenLDAP. No nosso caso, e os exemplos aqui, o servidor é server.example.org
. Definir incorretamente esse valor fará com que os clientes falhem ao fazer conexões. Isso pode causar uma grande frustração, portanto, certifique-se de seguir atentamente estas etapas.
Por fim, a requisição de assinatura de certificado precisa ser assinada:
%
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 criará um certificado auto-assinado que pode ser usado para as diretivas em slapd.conf
, onde cert.crt
e cacert.crt
são o mesmo arquivo. Se você for usar muitos servidores OpenLDAP (para replicação via slurpd
), você vai querer ver Apêndice B, Certificados do OpenSSL para LDAP para gerar uma chave CA e usá-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 está escutando em 389 com
%
sockstat -4 -p 389
ldap slapd 3261 7 tcp4 *:389 *:*
Instale o port net/openldap24-client para as bibliotecas do OpenLDAP. As máquinas cliente sempre terão bibliotecas OpenLDAP, já que é todo o suporte a security/pam_ldap e net/nss_ldap, pelo menos por enquanto.
O arquivo de configuração para as bibliotecas OpenLDAP é /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
É importante que seus clientes tenham acesso ao cacert.crt
, caso contrário, eles não poderão se conectar.
Existem dois arquivos chamados ldap.conf
. O primeiro é este arquivo, que é para as bibliotecas OpenLDAP e define como falar com o servidor. O segundo é /usr/local/etc/ldap.conf
e é para pam_ldap.
Neste ponto, você deve conseguir executar ldapsearch -Z
na máquina cliente; -Z
significa “usar o TLS”. Se você encontrar um erro, então algo está configurado errado; muito provavelmente são seus certificados. Use os comandos s_client
e s_server
do openssl(1) para assegurar que você os tenha configurado e assinado corretamente.
A autenticação em um diretório LDAP geralmente é realizada pela tentativa de vincular ao diretório como o usuário de conexão. Isso é feito estabelecendo um vinculo “simples” no diretório com o nome de usuário fornecido. Se houver uma entrada com o uid
igual ao nome do usuário e o atributo userPassword
da entrada corresponder à senha fornecida, o vinculo será bem-sucedido.
A primeira coisa que temos que fazer é descobrir onde no diretório os nossos usuários irão estar.
A entrada de base para nosso banco de dados é dc=example,dc=org
. O local padrão para usuários que a maioria dos clientes parece esperar é algo como ou=people,
, então é isso que será usado aqui. No entanto, tenha em mente que isso é configurável.base
Assim, a entrada ldif para a unidade organizacional people
será semelhante a:
dn: ou=people,dc=example,dc=org objectClass: top objectClass: organizationalUnit ou: people
Todos os usuários serão criados como subentradas dessa unidade organizacional.
Alguma consideração pode ser dada à classe de objeto a que seus usuários pertencerão. A maioria das ferramentas, por padrão, usará people
, o que é bom se você quiser simplesmente fornecer entradas para autenticar. No entanto, se você for armazenar informações do usuário no banco de dados LDAP, provavelmente usará inetOrgPerson
, que possui muitos atributos úteis. Em ambos os casos, os esquemas relevantes precisam ser carregados em slapd.conf
.
Para este exemplo, usaremos a classe de objeto person
. Se você estiver usando inetOrgPerson
, as etapas são basicamente idênticas, exceto que o atributo sn
é necessário.
Para adicionar um usuário 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 usuários LDAP em 10000 para evitar colisões com contas do sistema; você pode configurar o número que desejar aqui, desde que seja menor que 65536.
Também precisamos de entradas de grupo. Eles são configuráveis como entradas do usuário, mas usaremos os padrões 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, você pode usar slapadd
ou ldapadd
em um arquivo contendo essas entradas. Alternativamente, você pode usar o sysutils/ldapvi.
O utilitário ldapsearch
na máquina cliente deve agora retornar essas entradas. Em caso afirmativo, o banco de dados está configurado corretamente para ser usado como um servidor de autenticação LDAP.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.