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