trabalho elaborado por: ricardo nuno mendão da silva …rnsilva/ldap.pdf · 2007. 2. 1. · 2.1....
Post on 24-Aug-2020
0 Views
Preview:
TRANSCRIPT
Trabalho elaborado por: Ricardo Nuno Mendão da Silva rnsilva@student.dei.uc.pt Nº 501066530 Jorge Miguel Morgado Henriques jmmh@student.dei.uc.pt Nº501066554
Índice
1. Introdução ............................................................................................................................. 3
2. Objectivos .............................................................................................................................. 4
3. Configuração do servidor LDAP ............................................................................................. 4
3.1. Certificados .................................................................................................................. 4
3.2. Ficheiro slpad.conf ....................................................................................................... 5
3.3. Ficheiros. ldif ................................................................................................................ 6
3.4. IPTables ........................................................................................................................ 9
4. Configuração do cliente Linux ............................................................................................. 10
4.1. LDAP via PAM ............................................................................................................. 10
4.2. NSS ............................................................................................................................. 12
5. Testes .................................................................................................................................. 13
5.1. Servidor ...................................................................................................................... 13
5.1.1. LDAP ...................................................................................................................... 13
5.1.2. IPTables ................................................................................................................. 17
5.2. Cliente ........................................................................................................................ 21
6. Configuração SSL. ................................................................................................................ 25
7. Funcionalidades não cumpridas. ......................................................................................... 27
8. Conclusão ............................................................................................................................ 28
9. Bibliografia .......................................................................................................................... 29
1. Introdução
Nos anos 80, a ITU, International Telecommunication Unit, desenvolveu em parceria com a International Standards Organisation (ISO) e a European Computer Manufacturers Association (ECMA) um conjunto de protocolos, ao qual a ITU numerou por x500, cujo título era “Directório: Revisão de conceitos, m odelos e serviços”. O x500 reunia assim os protocolos DAP (Directory Access Protocol), DSP (Directory System Protocol), DISP (Directory Information Shadowing Protocol), o DOP (Directory Operational Bindings Management Protocol) e fora desenhado para funcionar sobre o modelo OSI. Destes quatro protocolos o DAP era o que mais sentido fazia. Imagine-se um directório como sendo uma lista telefónica. A lista apenas é escrita uma vez, mas é lida “n” vezes. Assim, acontece o mesmo com os directórios, o que obriga à existência de um protocolo de acesso rápido e simples, o que não era o caso do DAP. Perante tal situação e com o alargamento das redes globais e consequentemente dos directórios, foram aparecendo alternativas ao DAP, já prontas a funcionar sobre o modelo TCP/IP, sendo uma das alternativas mais populares a LDAP Lightweight Directory Access Protocol.
Os directórios LDAP podem se basear em aspectos políticos, geográficos e organizacionais, sendo actualmente o sistema mais comum, utilizarem a árvore do DNS, como base e crescer a partir desta. Grande utilidade actualmente do LDAP, reside no facto de permitir manter um servidor a alojar toda a informação, por exemplo, de contas de utilizadores/ máquinas de uma empresa e configurar as restantes máquinas para em ocasiões de autenticação, recorrerem ao directório do servidor remoto, evitando assim a necessidade de manter um registo individual em cada máquina, tornando toda a rede mais dinâmica, escalável e fácil de gerir.
Este relatório surge no âmbito do trabalho 4 da cadeira de Gestão de Sistemas e Redes e aborda precisamente a vertente LDAP. Assim, durante este documento, vão-se especificar todas as configurações efectuadas tanto no servidor ldap, como num cliente criado para teste, que acede remotamente. Demonstrar-se-ão ainda as componentes visuais resultantes dos testes efectuados.
2. Objectivos
2.1. Activação e configuração de um servidor LDAP em Linux, utilizando o OpenLDAP.
2.2. Configuração de uma máquina Linux como cliente LDAP, para obtenção de informação sobre utilizadores e autenticação de acessos.
2.3. Construção de uma configuração de firewall para protecção do servidor LDAP utilizando o IPTables.
3. Configuração do servidor LDAP
3.1. Certificados Para a utilização de TLS no acesso ao servidor LDAP, foi gerada uma CA através do com ando: “/etc/pki/tls/m isc/CA -new ca”, e um certificado para o servidor, com: “openssl req –new –nodes –keyout newreq.pem –out new req.pem ”, assinando-o de seguida com : “/etc/pki/tls/m isc/CA -sign”.
De seguida, moveu-se o certificado do servidor mais a chave gerada para /etc/openldap/ e definiu-se o modo 400 à chave. Moveu-se ainda o certificado da CA para /etc/openldap/cacerts.
Resumindo, utilizou-se o script existente na pasta misc para criar a CA e assinar o certificado, tomando como guia os paços descritos no site do openldap [openldap06].
3.2. Ficheiro slpad.conf
Figura 1 – Configuração base, slpad.conf
Ao iniciar a configuração do servidor LDAP, começou-se por definir um domínio base, nom eadam ente o dom ínio “gsr06.pt”, de seguida, configurou-se o LDAP para esse domínio, adicionando ao ficheiro slapd.conf a configuração apresentada na Figura 1. Em primeira entrada está o tipo de base de dados, Berkeley DB, que é uma base de dados de alta performance. Nas entradas seguintes, foram definidos o domínio base, gsr06.pt em “suffix”, o dom ínio do adm inistrador (root), e a passw ord do administrador, rootpw. Para inserir a password do administrador com a encriptação MD5, foi utilizado o comando apresentado na Figura 2.
Figura 2 – Comando para password md5.
O próximo passo foi configurar a secção para o servidor suportar ligações sobre tls, para tal, com base nos certificados criados no ponto anterior, criaram-se as seguintes entradas:
Figura 3 – Configuração TLS.
Como se pode observar pela Figura 3, apenas se indica o certificado da Autoridade, o certificado do servidor e a chave desse mesmo certificado.
3.3. Ficheiros. ldif
Para configurar o directório pretendido foram criados os ficheiros. ldif necessários, dando entrada para o sistema base, restantes ramificações e entidades. Assim, criaram-se os ficheiros:
Base.ldif – Ficheiro que constrói a plataforma base da árvore de
directório.
Figura 4 – Ficheiro base.ldif
O primeiro bloco de quatro linhas do ficheiro da figura 4 serve para adicionar o domínio base da árvore, salientando para tal o objectClass com o valor domain.
O segundo bloco vem adicionar uma Unidade Organizacional com o valor People, servindo como o ramo onde irão ser adicionados os utilizadores, como pessoas.
O terceiro ramo adiciona outra Unidade Organizacional, desta feita para Grupos.
Passwd.ldif – Ficheiro que adiciona uma conta para o uid=rmendao.
Figura 5 – Ficheiro passwd.ldif.
O ficheiro passwd.ldif contém uma entrada que serviu para testar o servidor montado. Adicionou-se então, um uid correspondente a um utilizador da rede, não existente em qualquer máquina. De notar que esse utilizador fica na base da OU People.
Assim , de m odo a “criar” este utilizador, foi necessário dar entrada no LDAP, dos valores que um utilizador normal possui nos ficheiros passwd e shadow. Como tal adicionou-se respectivamente, os objectClass posixAccount e shadowAccount.
Para o objectClass posixAccount foi necessário adicionar alguns atributos, como o objectClass que este herda (objectClass account), o Common Name (cn: rmendao), o Número do grupo (gidNumber), a directoria pessoal (homeDirectory) e o uid. Foi ainda adicionado por opção o atributo loginShell, o Gecos e a password do utilizador também no formato md5 e inserida sobre o mesmo método que o demonstrada na figura 2 deste documento.
Por fim, em relação ao shadowAccount, adicionaram-se os atributos uid (comum aos dois objectos) e a classe de herança (top). Adicionou-se ainda a password (comum aos dois objectos) e alguns valores como o shadowLastChange, shadowMax e shadowWarning que serviram para sistema de teste, nomeadamente sobre o comando “get ent”, com o se irá observar m ais à frente neste relatório.
Group.ldif
O ficheiro group.ldif serviu para adicionar o então utilizador à OU Group, criando um sistema organizacional mais completo. Para esta entrada recorreu-se ao objectClass posixGroup, inserindo os seus atributos obrigatórios cn (rmendao), gidNumber (511) e objectClass (top) e ainda a password como opcional.
Criados os ficheiros. ldif, resta adicioná-los ao serviço LDAP, o que foi realizado com os comando apresentados na figura seguinte.
Figura 6 – histórico do slapadd.
Criou-se ainda uma entrada no directório, directamente associado à base, para o administrador (root), correspondendo assim ao rootdn apresentado na Figura 1 deste relatório. Para tal criou-se o ficheiro:
Manager.ldif – ficheiro que define o Common Name de
administração.
Figura 7 – manager.ldif
É um objecto da classe organizationalRole, que define directamente, não uma unidade, não um utilizador, não uma conta, mas uma função dentro daquela unidade. De notar, que adicionou-se esta entrada da mesma forma que o demonstrado na Figura 6.
3.4. IPTables
Neste trabalho foi configurada uma firewall para proteger o servidor LDAP criado. Como tal, apenas foi permitida a entrada de tráfego proveniente de qualquer fonte com destino ao serviço ldap, do servidor de dns e do servidor ntp. Todo o resto do tráfego de entrada foi bloqueado, não tendo sido estabelecidas quais queres restrições ao tráfego de saída.
Na figura que se segue pode-se observar o script com as entradas para a configuração requerida.
Figura 8 – Ficheiro firewall.sh.
O script começa por bloquear todo o tráfego de entrada, não diferenciando a interface, de seguida dá permissão de entrada ao tráfego com destino ao servidor LDAP, com ou sem tls/ssl. De notar, que a porta 636 é para acesso sobre SSL, sendo que o TLS entra pela porta 389.
A próxima entrada permite receber respostas do servidor principal de dns do DEI. A seguinte permite receber dados do servidor para sincronização do relógio, ntp.dei.uc.pt.
A última entrada permite todo o tráfego realizado internamente. Foi adicionada pois a firewall estava a bloquear todo o tráfego incluindo processos como um simples switch user.
O resultado da entrada do script, segundo o comando “iptables –L” é:
Figura 9 – iptables –L
De notar que a entrada “ACCEPT all – anyw here anyw here” é referente à interface lo. Caso não o fosse, e do modo como o iptables a lista, fica a ideia que permite todo o tráfego de todo o lado, o que não acontece com irão comprovar os testes.
4. Configuração do cliente Linux
4.1. LDAP via PAM Para iniciar a configuração do cliente Linux a utilizar LDAP via PAM, correu-se o com ando “setup”, dando origem à sequência de eventos que se seguem.
Figura 10 – Menu principal de setup.
Figura 11 – Menu de autenticação.
Figura 12 – Propriedades LDAP
Pela sequência das últimas três figuras pode-se observar a configuração do processo de autenticação do cliente Linux. Ao entrar no menu de autenticação (Figura 11), seleccionam-se os m étodos para tal, neste caso a opção “Use LDAP”, “Use M D5 Passw ord” (Tipo de encriptação inserida nas passw ords dos ficheiros ldif), “Use shadow passwords” e “Use LDAP Authentication” perm itindo com este últim o autenticar o utilizador inserido no ldap. Os restantes autenticam-se pelo shadow.
Ao clicar em “Next”, passa-se para o menu da figura 12, onde se definem as propriedades do servidor LDAP. Selecciona-se o uso de TLS, indica-se o ip do servidor e a base do domínio, tal e qual a definida no servidor. Clica-se em “O K” e sai-se, ficando assim o Linux configurado para utilizar o LDAP via PAM. De notar que não foi introduzida a opção ldaps.
Também através deste “setup”, ficou configurado o ficheiro /etc/openldap/ldap.conf, como demonstra a seguinte figura.
Figura 13 – /etc/openldap/ldap.conf
Ao observar a figura 13, depara-se com uma última linha que foi adicionada manualmente e que indica que o cliente vai requerer o certificado ao servidor, mas permite que este seja inválido. Esta opção foi adicionada pois, o servidor LDAP efectuava a ligação desligando logo de seguida (Ver ponto 7). A solução encontrada foi a adição do comando referido, contudo algum problema ocorre com os certificados pois este “rem endo” não perm ite o acesso ldaps (ssl porta 636), funcionando apenas para ldap (com ou sem tls na porta 389).
4.2. NSS
Para instruir o NSS edita-se o ficheiro /etc/nsswitch.conf e adiciona-se a opção ldap às entradas passwd, shadow e group, tal como se observa na Figura 14. Assim, o nosso
cliente fica com a indicação que pode procurar pelas contas e respectivos atributos, nos ficheiros locais e no ldap definido anteriormente.
Figura 14 – Excerto de nsswitch.conf
5. Testes
5.1. Servidor
5.1.1. LDAP Depois de executada toda a configuração descrita no ponto 3, chegou a altura de arrancar o servidor, para tal executou-se o comando:
Figura 15 – Arranque do LDAP em modo Debug
Definiu-se o modo debug com o loglevel a 256, que permite obter informação sobre a ligação, operações e resultados. Uma outra forma de obter o log do LDAP seria adicionar a linha “loglevel 256” ao ficheiro slpad.conf, adicionar a linha “local4.* /var/log/ldap.conf” e reiniciar o serviço syslog. O log seria guardado no ficheiro ldap.conf.
Já com o LDAP a correr vai-se efectuar uma pesquisa na base do domínio definido.
Figura 16 – Resultado da pesquisa de base.
Ao observar este longo resultado, pode-se obter todas as entradas adicionadas pelos ficheiros ldif criados anteriormente. De notar, que se inseriu a tag –Z, forçando a utilização de acesso seguro com tls.
Figura 17 – log LDAP com TLS.
Assim, pode-se observar na figura 17 o resultado da pesquisa com TLS. Na figura que se segue e apenas para exemplo, encontra-se o resultado do log , quando se efectua uma pesquisa sem a opção –Z.
Figura 18 – Log LDAP sem TLS.
Com isto testou-se o funcionamento do servidor LDAP e das opções inseridas. De seguida vai-se observar o resultado do comando getent ao ficheiro passwd e ao ficheiro shadow, observando se o nosso utilizador rmendao, configurado no LDAP, se encontra disponível, como se de um utilizador com conta na máquina se trata-se.
Figura 19 – getent passwd
Figura 20 – getent shadow
Como se pode observar nas duas últimas figuras, o utilizador está operacional. Na figura 19, observa-se o utilizador, o seu uidNumber, o gidNumber, o common name, a
home directory e a shell. No shadow observa-se os valores dos atributos extra que se adicionaram propositadamente para este teste.
O s “getent’s” efectuados anteriorm ente produziram no ldap uma pesquisa, cujo resultado no registo foi respectivamente:
Figura 21 – log ldap para getent passwd.
Figura 22 – log ldap para getent shadow.
5.1.2. IPTables
Para testar o funcionamento da firewall, vai-se efectuar uma tentativa de ligação externa via ssh, sendo um protocolo bloqueado.
Dá origem a um connection timed out.
De seguida vai-se efectuar um acesso ao servidor ldap.
Figura 23 – Teste ao ldap com firewall.
Na figura 23 pode-se observar no quadrado preto o ip do servidor ldap (/etc/openldap/ldap.conf). Observa-se também os ips das interfaces, o teste anterior do ssh (a verde) e o acesso com sucesso, assinalado ao vermelho ao servidor LDAP, demonstrando assim o bloqueio ao ssh (como exemplo) e o acesso ao LDAP com sucesso. De seguida vai-se demonstrar o acesso com sucesso do servidor ao serviço dns do servidor dns.dei.uc.pt.
Figura 24 – Teste de funcionamento de dns via firewall.
Volta-se a relem brar que a entrada “ACCEPT anyw here anyw here” refere à interface lo, não interferindo neste processo.
Na próxima figura vai-se demonstrar a sincronização do relógio no servidor ntp.dei.uc.pt.
Figura 25 – Sincronização com ntpdate em modo debug.
Como se observa pela figura 25, foi efectuada uma sincronização com sucesso, utilizando também a resolução de nomes. Efectuou-se em modo debug, de forma a evidenciar todos os passos de comunicação com o servidor ntp.dei.uc.pt..
Para que não restem dúvidas quanto à entrada “ACCEPT all” para a interface lo, retirou-se a mesma e efectuou-se o mesmo teste ao ntp. Pode-se comparar a data devolvida pelo servidor nos dois testes, para comprovar a sua distinção.
Figura 26 – Teste ntp sem permissão lo.
Fica então demonstrada a firewall configurada. Não se considerou necessário um teste sem as entradas de permissão, pois seria obvio que apenas com a política da chain INPUT a drop, todos os serviços iriam ser negados.
5.2. Cliente
Para testar o cliente utilizou-se uma máquina na mesma rede, com o ip 10.254.0.21. Nesta máquina ira-se começar por realizar um simples switch user, para o utilizador rmendao, e depois efectuar um login de sessão. De notar, que devido ao problema com os certificados foi necessário inserir a entrada “TLS_REQ CERT never” no ficheiro /etc/openldap/ldap.conf, sendo que assim o cliente deixa de verificar o certificado do servidor (Ver ponto 7 deste relatório).
Figura 27 – switch user.
Para efectuar o switch user para o utilizador do LDAP, trocou-se primeiro de root para um utilizador local, de modo a que fosse pedida a password. Assim ao efectuar o “su rmendao” é pedida a passw ord, que é introduzida de seguida. Após a verificação da password entra-se no domínio do utilizador, como se pode ver pela mudança da prompt para o tipo definido para este utilizador. Agora vai-se analisar no lado do servidor que registo ficou.
Figura 28 – Excerto do log LDAP resultante do su.
Pode-se observar pelo longo registo, parte do processo, salientando-se todas as ligações sobre TLS, e as constantes pesquisas tanto com os filtros do posixAccount como do shadow, obtendo assim os dados requeridos.
De seguida vai-se exemplificar uma tentativa de login de sessão na mesma máquina, sem criar a pasta de homeDirectory do utilizador rmendao. Neste caso foi necessário adicionar ao ficheiro /etc/ldap.conf (ficheiro de configuração do nss_ldap e pam_ldap) a linha para indicar ao cliente que não deverá analisar o certificado do servidor, como tal descomentou-se a entrada “tls_checkpeer yes” e m udou-se o valor para “no”. Nas duas figuras que se seguem pode-se observar o resultado apresentado do lado do cliente e o registo do lado do servidor.
Figura 29 – Resultado de login do cliente.
Figura 30 – Registo no log do servidor ldap.
Ora, ao observar a figura 30, pode-se verificar a mensagem que indica ao utilizador rmendao que este não possui o directório home no servidor. Como está-se perante um cenário de teste, o exemplo serve para verificar o funcionamento do servidor LDAP.
Confirmando o acto, pode-se ainda observar a figura 30 que demonstra o respectivo login do utilizador rmendao, através da máquina 10.254.0.21, utilizando TLS (porto 389).
6. Configuração SSL.
Como foi seleccionado o acesso TLS nos settings de configuração do método de autenticação (figura 12), foi gerada um a entrada no ficheiro /etc/ldap “ssl start_tls”, que indica o tipo de acesso seguro. Como nem todos os clientes suportam TLS e SSL, o que acontece neste caso, quando se tentava aceder via ldaps originava ao registo da figura 31.
Figura 31 – Dupla Ligação segura.
Como se pode verificar é estabelecida uma ligação segura e depois arranca o STARTTLS para uma segunda, falhando. De notar ainda o porto 636, comprovando o acesso ldaps permitido com o arranque demonstrado na figura 32.
Figura 32 – Arranque do ldap com ldaps
Figura 33 – netstat -a | grep ldap
Assim, para permitir o acesso ldaps (porto 636) será necessário:
correr novam ente o “setup”.
Retirar a opção TLS nos settings do ldap.
Editar o ficheiro /etc/ldap.conf.
Alterar o valor de “ssl no” para “ssl on”.
Ao efectuar tais mudanças é então possível o demonstrado nas seguintes figuras.
Figura 34 – Teste ldaps do lado do cliente remoto.
Figura 35 – Registo da figura 31 no servidor ldap.
Pode-se então observar na figura 34 a mudança de utilizador com sucesso, sobre ssl e na figura 35 o registo dessa mudança, começando-se por verificar o porto 636, o estabelecimento da ligação segura e as normais pesquisas no directório, para o uid rmendao.
7. Funcionalidades não cumpridas.
Como se observou ao longo deste relatório, não foi possível implementar nos clientes ldap a funcionalidade de verificar o certificado do servidor. Realizaram-se várias tentativas, geraram-se vários certificados de modo diferente, copiando sempre o certificado da CA para o cliente, mas o resultado foi sempre o mesmo, o que pressupõe que se trate de um problema de permissões (owners) ou o mais provável, já que não foi detectada qualquer falha, que o problema resida mesmo na implementação local do LDAP. Contudo, deu-se a volta à situação indicando ao cliente que não seria necessário verificar o certificado. Para o cliente situado na mesma m áquina que o servidor, bastou adicionar a opção “TLS_REQ CERT allow ” ao /etc/openldap/ldap.conf. Para o cliente remoto não se permitiu mesmo nenhuma verificação, utilizando o com ando “TLS_REQ CERT never” para /etc/openldap/ldap.conf e “tls_checkpeer no” para /etc/ldap.conf, sendo este últim o utilizado para logins de sessão e o primeiro para “switch user”.
8. Conclusão
Com o constante crescimento das redes e aumento dos dados torna-se cada vez mais importante a existência de um sistema capaz de uma indexação fácil, devidamente organizado, que fornece um sistema de pesquisa rápido, eficaz e fiável. Assim, reforça-se a importância de um sistema como o LDAP, que utiliza uma organização intuitiva e que para além de ser uma ferramenta de acessível configuração, é suportado por um vasto conjunto de outras ferramentas, ou seja, existe uma interoperabilidade entre sistemas que reforça o poder do LDAP.
Em relação ao trabalho aqui desenvolvido, fica retido o conhecimento adquirido sobre tal ferramenta e seu potencial. Fica também a noção de que apenas foi explorada uma mínima parte, ou melhor, a parte mais básica deste sistema.
Concluindo, dada a carga momentânea de trabalhos, tentou-se desenvolver este último trabalho da melhor forma possível, respondendo directamente ao pedido no enunciado, ficando a ideia base do funcionamento do LDAP, resultante de um primeiro contacto.
9. Bibliografia
http://en.wikipedia.org/wiki/Berkeley_DB
http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
http://www.ldap.org.br/
http://sec.cs.kent.ac.uk/x500book/Chapter.1/Chapter1.htm#1.1%20EVERYONE%20NEEDS%20DIRECTORIES
http://ldap.akbkhome.com/index.php/
http://www.openldap.org/
[openldap06 ] http://www.openldap.org/faq/data/cache/185.html
top related