DominioLivre
De Gtmsl
Kerberos com LDAP e Servidor SAMBA
Kerberos
O Kerberos foi desenvolvido para fornecer um sistema de autenticação de rede, ou seja, prover uma autenticação única para os serviços de rede. Para isso, o processo de autenticação baseiase na existência de uma terceira parte confiável. O método ocorre de maneira segura, sem a transmissão da senha pela rede. Este é realizado por intermédio de tickets, o quais podem ser de dois tipos:
- Ticket Granting Ticket (TGT) e
- Ticket Granting Service (TGS);
O Ticket Granting Ticket (TGT), como o nome propõe, garante ao usuário a solicitação de tickets de serviços. O TGT é solicitado pelo usuário, pela passagem de sua identificação, de seu horário e de um código de desafio.
O KDC, Key Distribution Center, responde com o TGT criptografado simetricamente a partir de chave baseada na senha do usuário. A simples recuperação do TGT garante a autenticação sem a necessidade de transmissão da senha pela rede, o que reforça o caráter seguro do sistema.
O Ticket Granting Service (TGS), é solicitado ao KDC para que o cliente se autentique para um servidor desejado. A obtenção se inicia com o envio da solicitação de acesso a um serviço especifico para o KDC. É encaminhado em anexo o TGT do interessado.
O KDC gera um TGS, o qual contem as informações do cliente criptografado com a chave entre o KDC e Servidor. Este ticket é enviado para o cliente. Em virtude deste não conhecer a chave, o qual o ticket foi criptografado, o impede de modificá-lo.
Então o TGS é anexado à solicitação de serviço, a qual será enviada ao servidor. Este recuperará as informações do cliente por meio de sua chave com o KDC. Caso o processo termine com sucesso, ambas as partes estão autenticadas mutuamente. [2]
- Cliente solicita um TGS para o KDC, enviado seu TGT em anexo;
- Kerberos retorna ao cliente o TGS requisitado;
- Cliente inicia o processo de autenticação com o Servidor pelo envio do TGT;
- Servidor informa ao cliente que a autenticação foi bem sucedida;
- Cliente, já autenticado, acessa o serviço.[3]
Embora a autenticação ocorra a partir de uma informação a qual usuário conhece, o processo de autenticação para utilização dos serviços é feito por algo o que o usuário tem, o ticket de serviço.
O Serviço de Diretório
Um diretório é uma base de dados especializada em consultas, assim como uma lista de telefones que contém informações sobre assinantes em que são constantemente pesquisadas,porém raramente modificadas. [4]
O serviço de diretório, é o serviço mais importante de uma rede sob esse ponto de vista, pois é o pilar sobre o qual todos os demais se relacionam. Trata-se de uma base única de informações logicamente centralizadas na rede.
O Protocolo LDAP
O Protocolo LDAP (Lightweight Directory Access Protocol) surgiu como uma alternativa mais leve, como o nome sugere, para acesso ao diretório através da pilha TCP/IP e rapidamente tornou-se padrão de mercado sendo adotada pela Microsoft, Novell e a maioria dos fabricantes de switchs e roteadores.
O LDAP define o protocolo de acesso às informações entre o cliente e o servidor, não se preocupando como o servidor tratará as requisições. É um padrão aberto definido pela IETF (The Internet Engineering Task Force) (Força tarefa de engenharia da Internet).[6]
O protocolo define uma arquitetura flexível em que cada objeto, regido por um esquema de definição, pode representar um objeto do mundo real ou virtual. As informações são armazenadas em atributos, presente nos objeto.
Com o sucesso do protocolo LDAP, vários desenvolvedores adicionaram, ao seu diretório, comunicação por meio deste. Algumas comunidades desenvolveram versões livres de servidores de diretório que implementassem apenas o protocolo, como é o caso do OpenLDAP.
A filosofia do LDAP foi diminuir eficientemente o processamento ocorrido nos servidores, transferindo sua inteligência para os clientes, inclusive aumentando o throughput do servidor.
Se o servidor não consegue responder uma consulta, este repassa ao cliente o endereço do próximo servidor na hierarquia, conhecido referral. Existem três aspectos básicos na proteção da informação no diretório: AAA (Acesso, Autenticação e Autorização).
Os dois primeiros fazem parte da definição do protocolo,enquanto o último, implementado por meio de ACLs (Lista de Controle de Acesso), é comumente fornecida pelos desenvolvedores de diretório padrão LDAP.
CLASSES
Cada classe define os atributos pertencentes a esta determinando seus nomes, tipos de valores válidos, bem como se suportam apenas um ou vários valores.[7]
SCHEMA
O schema define os atributos e as classes onde estes estão presentes e a relação de dependência entre as classes
OBJETOS
Cada objeto é univocamente identificado por um nome distinto (Distinguish Name). Este nome é formado por um nome relativo seguido por seu caminho, o qual é constituído por todos os nomes relativos a partir da origem.
O objeto deve pertencer a pelo menos uma classe,representando um objeto real ou virtual no diretório.
Igualmente, deverá ter todos os atributos necessários para os serviços em execução na rede. Esse processo, conhecido como modelagem de dados, é fundamental para a construção de um diretório eficiente.
PARTIÇÃO
Uma partição é definida como uma porção do diretório hospedada em um servidor. Para que um diretório distribuído seja visto logicamente centralizado, as partições devem ser referenciadas a partir de objetos especiais chamados de referral.
RÉPLICAS
Uma partição pode ser hospedada em mais de um servidor com a finalidade de distribuir carga ou de tolerância à falhas. Cada cópia de uma partição é definida como réplica.
PADRÃO LDIF
O padrão LDIF (LDAP Data Interchange Format) define o formato como os dados são importados e exportados do diretório, sempre através de arquivo texto ASCII.
Por este padrão uma linha em branco define um novo objeto, e linhas iniciadas por espaço são continuação da linha anterior.
Exemplo: <verbatim> dn: dc=prba,dc=mpf,dc=gov,dc=Br objetcClass: top objetcClass: dcObject objectClass: Organization o: mpf dc: prba </verbatim> A linha começa com o nome do atributo seguido de ":" ou "::".
Quando utilizado o símbolo ":" a string a seguir será o valor do atributo.
O símbolo "::" indica que a string a seguir encontra-se codificada em base64.
Caracteres especiais exigem este tipo de codificação.
ARQUITETURA DA SOLUÇÃO
A solução proposta passa pela implementação e configuração de três novos serviços permanentes na rede: diretório OpenLDAP, sistema de autenticação de rede MIT Kerberos e serviço de rede Windows para Linux, SAMBA.
O serviço de diretório visa consolidar as bases de informações dos serviços fornecidos na rede. O diretório habilita qualquer usuário consultar organizações, indivíduos e outros recursos como dispositivos em uma rede, seja em uma intranet ou na Internet.
O projeto OpenLDAP, vide em [7], é uma implementação aberta e confiável do LDAP (Lightweight Directory Access Protocol).
O LDAP foi escolhido porque ele é um uma versão otimizada do DAP (Directory Access Protocol), que é parte do X.500, um padrão para serviços de diretório em rede.
O LDAP foi desenvolvido na Universidade de Michigan e é amplamente adotado no mundo.
Como exemplos, o serviço de diretório da Novell (Novell's NetWare Directory Services) opera com o LDAP; diversos produtos CISCO suportam LDAP; a Microsoft inclui este padrão no seu diretório do Windows 2000/2003, o Active Directory, vide em [8].
Mais próximo da prática na rede PRBA, o diretório fornecerá, aos usuários, um catálogo de informações sobre todos os recursos disponíveis no departamento bem como potencialmente conter os certificados digitais dos usuários para que possam usufruir uma infra-estrutura de chaves públicas, criptografando e assinando e-mails, tendo acesso seguro as páginas hospedadas na rede e, futuramente, autenticação nas páginas do departamento por meio de certificado digital.
O sistema de autenticação escolhido foi o MIT Kerberos - padronizada na RFC 1510 -, em virtude de sua segurança e processo de autenticação único, carente no Linux.
Diferentemente dos sistemas operacionais Microsoft que possuem a funcionalidade de pass-throw4, o Linux não faz cache das informações de login. Logo, sem a implementação de um sistema de autenticação de rede não haveria como prover um processo de autenticação único.
Outro ponto importante na adoção do Kerberos como sistema de autenticação nesse projeto é a funcionalidade conhecida como autenticação cross-realm5.
Essa funcionalidade permite que clientes cobertos por um determinado realm possa se autenticar em um serviço localizado em um outro realm. Um aplicação possível bem próximo da realidade da rede PRBA seria a seguinte.
Suponha que a rede de computadores do departamento de engenharia elétrica do PRM-ILHEUS possua pastas, com arquivos restritos, que deveriam ser compartilhados apenas entre um determinado grupo de pesquisa do PRBA e do PRM-ILHEUS. Através de uma configuração no Kerberos dos dois sites, é possível estabelecer uma relação de confiança entre os realms, permitindo que as estações de trabalho no PRBA acessem os arquivos de maneira transparente.
O reverso também é válido, ou seja, compartilhar serviços do PRBA para um ou mais realm externo através da Internet.
Completando a arquitetura proposta, temos o serviço de SAMBA, compondo a arquitetura final por meio de suas funcionalidades integradas com o OpenLDAP e o Kerberos.
O SAMBA é um software livre [9] que pode rodar em outras plataformas não-Microsoft, como Linux, UNIX, FreeBSD, OpenVMS e outros sistemas operacionais. O SAMBA é baseado nos protocolos cliente/servidor SMB (Server Message Block) e CIFS (Common Internet File System). Esses são os padrões adotados pela Microsoft para acesso a arquivos, impressoras e outros dispositivos.
A tecnologia usa o protocolo TCP/IP para se comunicar entre o cliente (estação de trabalho) até o servidor SAMBA.
Quando corretamente configurado, permite que uma estação de trabalho faça a interação com uma outra estação (ou servidor) Microsoft Windows como se fosse uma estação operando também em Microsoft Windows.
A maior motivação para a implementação de um SAMBA nesse projeto é o fato de que a sua base de usuários irá residir no diretório OpenLDAP. Note que omitir a implementação de um servidor SAMBA iria obrigar a existência de duas bases distintas para armazenar as contas de usuários; uma pertencente ao OpenLDAP e outra no(s) controlador(es) de domínio NT.
Sem contar com a complexidade de gerir a sincronização de contas em bases distintas. O diretório irá unificar o repositório de dados da rede, trazendo vantagens quanto a segurança e organização da rede.
Em razão das estações Windows não poderem participar, mutuamente, de um domínio SAMBA e com autenticação Kerberos não-Microsoft, foi preterido o Kerberos ao domínio para estas estações apenas, caso contrário seria necessário criar as contas de usuários em todas as estações.[11]
IMPLEMENTAÇÃO
Este capítulo irá descrever a implementação do projeto, tanto em nível de servidores fundamentais (OpenLDAP, Kerberos e SAMBA), como as configurações das estações de trabalho (Windows e Linux). Eventualmente, será abordado outros serviços de rede importantes para o projeto como um todo, como a correta configuração do serviço de domínio de nomes (DNS). Procedimentos estritamente técnicos serão isolados em forma de apêndice, localizados ao final do documento.
Inicialmente, a seção “Considerações Iniciais” visa motivar, sob o ponto de vista técnico, as diretivas de implementação da solução, explorando as vantagens e limitações da proposta tal como foi implementada.
A próxima seção, intitulada “Ambiente de Implementação Prática do Projeto” descreve o arranjo de computadores, sistemas operacionais e demais técnicas utilizadas no ambiente de validação. Seguem as três seções mais importantes desse capítulo, respectivamente, as que tratam da configuração dos serviços fundamentais: Kerberos, diretório LDAP e SAMBA.
Para completar o capítulo, duas seções descrevem as configurações das estações Windows e Linux, respectivamente.
CONSIDERAÇÕES INICIAIS
De início, deve-se ver o diretório como um catálogo de informações. Estas informações serão acessadas por todos os outros serviços da rede, cada qual procurando informações necessárias ao seu funcionamento. Uma conseqüência direta seria, por exemplo, permitir que os professores acessem dados de alunos, como telefones ou e-mail a partir de uma ferramenta de catálogos de endereços (e.g. Cliente de E-mail Outlook Express) que consulte o diretório.
Estes contatos podem ser utilizados por uma autoridade certificadora para publicação de seus certificados, oferecendo assim uma infra-estrutura de chaves públicas. Os usuários do diretório poderão assinar digitalmente, ou criptografar mensagens para outro usuário, sem a necessidade de solicitar ao destinatário cópia de seu certificado.
Para que os usuários presentes neste diretório possam autenticar-se nas estações Linux, é necessário que seus objetos possuam as informações de conta de usuá¡rio a este sistema.
Conseqüentemente, os objetos, que até então existiam apenas como contatos, passam ser utilizados como contas do sistema operacional.
A proposta contempla um controlador de domínio provido pelo SAMBA, que por sua vez utiliza o diretório como base de dados. Sendo assim, os objetos de usuário do Linux devem ser estendidos para conter as informações necessárias de forma que o usuário possa participar de uma rede Windows.
Embora o serviço de diretório possa ser utilizado como meio para outros serviços de autenticação difusos, isso não é desejado, em virtude de não ser um serviço de autenticação de rede, não sendo possível, neste caso, oferecer um serviço de autenticação Única (SSO).
Para prover esta funcionalidade, faz-se uso do Kerberos, retirando, do diretório, as informações de senha, altamente recomendável pelo fator segurança da rede. Em resumo, ao adotar o Kerberos ganha-se pela funcionalidade de autenticação única e pelo maior grau de segurança ao armazenar senhas na rede, entre outras vantagens contempladas no capítulo 2.
AMBIENTE DE IMPLEMENTAÇÃO PRÁTICA DO PROJETO
Os serviços de sincronismo de tempo, serviço de domínio de nomes (DNS), Kerberos, diretório LDAP e SAMBA foram instalados em um servidor chamado afrodite.prba.mpf.gov.br. O sistema operacional escolhido foi o Conectiva 10.
Foi instalado o servidor truta.prba.mpf.gov.br, com o serviço de e-mail configurado de forma básica. Duas estações de trabalho, uma Linux, tainha.prba.mpf.gov.br, e outra Windows XP, orca.prba.mpf.gov.br, ilustram o processo de autenticação e utilização dos serviços integrados nesta solução.
O Linux utilizado por este projeto foi o Conectiva 10, em virtude de ser uma das homologadas pelo *GTMSL/MPF* e seus pacotes estarem bem integrados com o sistema de autenticação escolhido. Pode-se utilizar ainda o SUSE-LINUX, o FEDORA Core 3, sem grandes alterações nos procedimentos aqui descritos.
Em termos de uma implementação real (não-teste), serviços que rodam em um mesmo sistema operacional poderiam estar aglutinados no mesmo servidor, uma vez obedecidos os critérios adequados de recursos computacionais para uma implementação com bom desempenho.
CONFIGURAÇÃO DO SERVIÇO KERBEROS
Para implementar segurança contra ataques do tipo Homem no meio do caminho (man-in-themiddle), o serviço Kerberos depende que os serviços de sincronismo de tempo (NTP) e o serviço de domínio de nomes (DNS) estejam bem configurados na rede.[11]
Uma diferença acima de trezentos segundos (300s) entre as partes envolvidas no mecanismo de autenticação é suficiente para que o ticket seja considerado inválido, isso para evitar que um atacante pegue o ticket através da rede e tente-o utilizar mais tarde.[12]
Para resolver este problema, foi instalado um servidor NTPD no servidor de Kerberos.
As estações de trabalho fazem consultas à cada hora.
O Serviço de nomes (DNS) é fundamental, tanto sua zona direta como a inversa, pois no ticket de serviço consta o endereço IP (Internet Protocol) dos envolvidos, devendo ser traduzidos para o mesmo nome de DNS, identificando o principal(domínio) para o qual será gerado o ticket de serviço(TGS), garantindo assim que outra máquina não tente se passar por uma das partes.
Para o ambiente de testes foram criadas duas zonas, sendo uma de pesquisa direta, prba.mpf.gov.br, e outra de pesquisa reversa, 15.142.200.in-addr.arpa.
Todos os servidores e estações de trabalho possuem registros no DNS em ambas as zonas acima descritas. As entradas de DNS foram registradas manualmente. Em redes demasiadamente grandes, este serviço pode ser implementando por meio de um DNS dinâmico, devidamente integrado com o DHCP (Dynamic Host Configuration Protocol).
Tendo estes requisitos prontos, a instalação do Kerberos no Fedora Core 3 foi realizada a partir do pacote RPM (Red-Hat Packet Manager) krb5-server.
O Domínio (realm) Kerberos foi batizado como PRBA.MPF.GOV.BR e suas configurações encontram-se no arquivo _/var/kerberos/krb5kdc/kdc.conf_.
Para cada estação cliente, é recomendável, a criação de um principal, no Kerberos, com o nome obedecendo a sintaxe host/nomeCompletoDoHost.
A chave deste principal deve ser exportada para o arquivo _/etc/krb5.keytab_ de cada estação.
O mesmo deve ser realizado para cada serviço que utilizar o Kerberos, como mecanismo de autenticação, substituindo a palavra host pelo nome do serviço.
Para uma maior flexibilidade de administração da rede, foram registrados no DNS as entradas correspondentes aos módulos (servidores) que compõem o Kerberos como um todo, como o KADMIN e o KDC.
CONFIGURAÇÃO DO SERVIÇO DE DIRETÓRIO
O Servidor de diretório escolhido foi o OpenLDAP, e sua instalação pode ser realizada pelo pacote RPM, disponível nos cds da sua distribuição escolhida, openldap-servers.
O diretório responde pela partição dc=prba,dc=mpf,dc=gov,dc=br. Esta configuração é feita no arquivo _/etc/openldap/slapd.conf_.
Para que o diretório aceite autenticação do Kerberos, foi criado um principal no Kerberos chamado *ldap/afrodite.prba.mpf.gov.br*. A chave deste principal deve ser exportada para o arquivo _/etc/krb5.keytab_, sendo atribuído direito de leitura ao usuário ldap.
O tratamento dos tickets de serviço para o diretório é feito pela biblioteca SASL (Simple Authentication and Security Layer), sendo necessária a instalação do pacote cyrus-sasl-gssapi.
O mapeamento entre o usuá¡rio do Kerberos e o objeto do OpenLDAP foi configurado para pesquisar no diretório um objeto que tenha a mesma string no valor do atributo UID e nome do principal do Kerberos (atributo UID = login do usuário), este mapeamento é realizado pela diretiva sasl-regex presente no arquivo de configuração do servidor de diretório.
Uma consulta ao diretório com autenticação no Kerberos segue o seguinte processo:
- Realiza uma pesquisa anônima sobre os mecanismos SASL suportados;
- Compara o resultado da pesquisa com os seus mecanismos de autenticação
disponíveis;
- Solicita ao KDC um ticket de serviço para acesso ao ldap/afrodite.prba.mpf.gov.br;
- O KDC retorna o ticket de serviço;
- A estação de trabalho inicia o processo de autenticação, bind, com o diretório enviando ticket de serviço;
- O OpenLDAP repassa o ticket para o SASL;
- O SASL, por meio do módulo gssapi, valida o ticket com a chave entre o kdc e o
serviço ldap/afrodite.prba.mpf.gov.br, retornando sucesso ou falha;
- Em caso de sucesso o SASL retorna um DN(sasl):
uid=principal,cn=prba.mpf.gov.br,cn=gssapi,cn=auth;
- Por meio da diretiva sasl-regex, o OpenLDAP converte o DN(sasl) no DN(ldap);
- O servidor retorna a estação bind ok;
- A estação solicita consulta;
- O LDAP compara o DN(ldap) com a ACL (Access Control List);
- Caso tenha permissão, retorna o resultado da consulta.
Uma das premissas do projeto foi evitar a existência de dados repetidos, desta forma a senha dos usuários não está armazenada no diretório, salvo usuários especiais que não possuem contas no Kerberos.
Embora deva ser evitado, em alguns casos é necessário realizar consultas no diretório com autenticação simples, ou seja, o par usuário e senha. Para resolver este problema e evitar colocar a senha no diretório, é necessária a criação do arquivo _/usr/lib/sasl2/slapd.conf_.
Seguindo pela configuração do serviço saslauthd para utilizar o mecanismo kerberos5.
Uma vez definido o valor do atributo userPassword pela sintaxe {SASL}principal @ prba.mpf.gov.br. O processo de autenticação simples deste objeto é regido pelos seguintes passos:
- Em relaçã à sintaxe acima, o parâmetro entre chaves indicará para o serviço de
diretório que este deverá utilizar a biblioteca SASL com o par principal@ prba.mpf.gov.br e a senha;
- O SASL consultará o arquivo _/usr/lib/sasl2/slapd.conf_ e verificará que deve utilizar o saslauthd;
- O saslauthd fará a consulta ao Kerberos, por meio da biblioteca gssapi.
- Por último, se o processo for bem sucedido, o SASL retornará um sinal de sucesso para o diretório, que por sua vez retornará também sucesso na autenticação.
CONFIGURAÇÃO DO SERVIÇO DE REDES WINDOWS PARA O LINUX (SAMBA)
As configurações necessárias realizadas no servidor SAMBA são:
- Controlador de Domínio para o domínio PRBA.MPF.GOV.BR;
- Utilização do OpenLDAP local como base de dados;
- Sincronização de senhas com o UNIX;
- Programa de troca de senha é um script que sincroniza a senha com o kerberos
A definição do nome do usuário a ser utilizado no LDAP é feita no interior do arquivo de configuração do SAMBA, _/etc/SAMBA/smb.conf_, enquanto sua senha permanece armazenada em um banco de senhas, sendo inserida por meio do comando smbpasswd -w.
Para que o SAMBA utilize o LDAP, é necessário que o serviço de nomes do servidor esteja configurado para pesquisa no diretório pelas contas do sistema.
Ao criar um usuário no SAMBA, este verifica se a conta existe no sistema, então procura o usuário no LDAP estendendo sua classe para SambaSAMAccount.
Em virtude do SAMBA utilizar dois atributos no LDAP, SAMBANTPassword e SAMBALMPassword, para as senhas, foi necessária a criação de um script sincronizador de senhas com o LDAP.
Para que este script possa modificar a senha no Kerberos, foi criado um principal com direitos administrativos, embora fosse necessá¡rio apenas o direito de troca de senhas.
Foi necessário, também, o mapeamento dos grupos padrões do Domínio, Domain Admins e Domain Users, em grupos do Linux, os quais devem estar armazenados no diretório.
Para criar uma conta de estação de trabalho, tanto para windows baseados em NT quanto para Linux com SAMBA, deve-se criar uma conta com o nomeDoHost$.
Em seguida, deve-se proceder à criação no SAMBA, a partir do comando smbpasswd –m. Por último, a adição da estação ao domínio como se o servidor de Domínio fosse Windows.
ESTAÇOES DE TRABALHO WINDOWS
As estações de trabalho Windows devem ser configuradas para pesquisar nomes na zona prba.mpf.gov.br do DNS. Esta configuração é realizada na guia DNS do serviço de TCP/IP.
Após a criação da conta orca$ no servidor de domínio, a mesma foi anexada ao domínio PRBA.
No momento em que o sistema operacional da estaçao é iniciado, este procura o controlador de domínio realizando sua própria autenticação a partir da conta orca$.
Quando o usuário digitar seu par de usuário/senha, a estação o busca o controlador de domínio para validar o usuário, que por sua vez consultará a base de dados do OpenLDAP, procedendo o login normal.
PROCESSO DE LOGON
Com a nova arquitetura, as estaçõess Windows passam a ser autenticados no servidor SAMBA (Linux).
ESTAÇÕES DE TRABALHO LINUX
As estações Linux foram configuradas para consultar sua base de dados no LDAP.
É necessário a modificação do arquivo _/etc/krb5.conf_ para configurações dos clientes Kerberos para o realm PRBA.MPF.GOV.BR.
O Processo de autenticação, no momento do logon, ocorre pelo módulo pam_krb5.so, configurado no arquivo _/etc/system-auth_ contra o Kerberos, caso a autenticação falhe, o PAM (Pluggable Authentication Modules) continua o processo procurando na base de dados locais
Após o logon, o usuário possui um TGT para solicitar tickets de serviço e acessar outros serviços.
ALTERAÇÃO DE SENHA NA ESTAÇÃO DE TRABALHO
O processo de alteração de senha pode ser dado pelo administrador de redes diretamente no SAMBA ou pelo usuário na estação de trabalho. É válido destacar que agora a estação solicita ao SAMBA a alteração de senha, que por sua vez sincronizada a nova senha com o Kerberos por meio do script SAMBASync.
ESTAÇÕES DE TRABALHO LINUX
Em nível prático, as estações Linux são mais versáteis que as estações Windows por serem além de clientes SAMBA, também clientes Kerberos.
PROCESSO DE LOGON
Diferentemente do Windows, uma estaçãoo Linux efetua seu logon no Kerberos.
CONFIGURAÇÕES DO DNS
Para proceder a instalação do servidor de DNS, execute o comando: [root] # apt-get install bind bind-chroot bind-utils
A configuração do servidor de nomes é feita no arquivo: _/var/named/var/etc/named.conf_
<verbatim> options { directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; }; include "/etc/rndc.key"; zone "prba.mpf.gov.br" { type master; file "/var/named/data/prba.zone"; }; zone "15.142.200.in-addr.arpa" { type master; file "/var/named/data/prba.arpaZone"; }; zone "." { type forward; forwarders { 200.142.15.15; }; }; </verbatim>
Segue os arquivos com as configurações da zonas de DNS no servidor:
· Domínio prba.mpf.gov.br arquivo _/var/named/var/named/data/prba.zone_ <verbatim> $TTL 1D @ IN SOA ns.prba.mpf.gov.br. root.prba.mpf.gov.br. (
2005050809 ; nro. Serial eu uso yyyy yy mm dd
8H ; atualizar em segundos
2H ; tentativas em segundos
1W ; expiração em segundos
1D ) ; maximo em segundos
NS ns.prba.mpf.gov.br.unb.
MX 0 baco
; Informacoes sobre o kerberos
_kerberos TXT "PRBA.MPF.GOV.BR"
kerberos CNAME afrodite
_kerberos._udp SRV 0 0 88 afrodite
_kerberos-master._udp SRV 0 0 88 afrodite
_kerberos-adm._tcp SRV 0 0 749 afrodite
_kpasswd._udp SRV 0 0 464 afrodite
; Informacoes sobre as maquinas
ns CNAME afrodite
ntp CNAME afrodite
ldap CNAME afrodite
apt CNAME apolo
mail CNAME truta
ca CNAME afrodite
apolo A 200.142.15.1.1
afrodite A 200.142.15.254
truta A 200.142.15.34
orca A 200.142.15.41
tainha A 200.142.15.42
</verbatim>
Domínio reverso: arquivo /var/named/chroot/var/named/data/prba.arpaZone <verbatim> $TTL 1D @ IN SOA ns.prba.mpf.gov.br. root.prba.mpf.gov.br. (
2004112206 ; nro. serial, data de hoje + serial
8H ; atualizar em segundos
2H ; tentativas em segundos
1W ; expiração em segundos
1D ) ; maximo em segundos
NS ns.prba.mpf.gov.br.
1 PTR apolo.prba.mpf.gov.br.
254 PTR afrodite.prba.mpf.gov.br.
34 PTR truta.prba.mpf.gov.br.
40 PTR tainha.prba.mpf.gov.br.
41 PTR orca.prba.mpf.gov.br.
</verbatim>
INSTALAÇÃO E CONFIGURAÇÕES DO NTP (SERVIÇO DE SINCRONIZAÇÃO DE TEMPO)
Para proceder a instalação do servidor NTPD (NTP Daemon), execute o comando:
[root] # apt-get install ntp
O arquivo de inicialização do serviço, /etc/init.d/ntpd, foi modificado:
NtpConf
A configuração do servidor foi realizada de modo a assumir o seu relógio como o correto e aceitar as requisições dos outros computadores da rede. Esta configuração foi realizada no arquivo _/etc/ntp.conf_, que segue abaixo:
<verbatim> restrict default nomodify notrap noquery restrict 127.0.0.1 restrict 192.168.46.0 mask 255.255.255.0 nomodify notrap server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift broadcastdelay 0.008 keys /etc/ntp/keys </verbatim>
INSTALAÇÃO E CONFIGURAÇÃO DO KERBEROS
Para proceder a instalação do servidor KERBEROS, execute o comando:
[root] # apt-get install krb5-server
Proceder a configuração dos arquivos _/etc/krb5.conf_,_/var/kerberos/krb5kdc/kdc.conf_ e _/var/kerberos/krb5kdc/kadmin.acl_.
Segue os arquivos finais abaixo:
- /etc/krb5.conf:
<verbatim> [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = prba.mpf.gov.br dns_lookup_realm = true dns_lookup_kdc = true [domain_realm] .prba.mpf.gov.br = prba.mpf.gov.br prba.mpf.gov.br = prba.mpf.gov.br [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } </verbatim>
- /var/kerberos/krb5kdc/kdc.conf
<verbatim> [kdcdefaults] acl_file = /var/kerberos/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab v4_mode = nopreauth [realms] prba.mpf.gov.br = { master_key_type = des-cbc-crc supported_enctypes = arcfour-hmac:normal arcfour-hmac:norealm arcfour-hmac:onlyrealm des3- hmac-sha1:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3 } </verbatim>
- /var/kerberos/krb5kdc/kdc.conf
<verbatim>
- /admin@prba.mpf.gov.br *
</verbatim>
Para iniciar a base de dados do Kerberos, é necessário iniciar o realm PRBA pelo seguinte comando:
[root] # kdb5_util -s create
É necessária a criação do principal para o servidor por meio do comando:
<verbatim> [root] # kadmin.local -q "ank -randkey host/afrodite.prba.mpf.gov.br" e exportá-lo para o arquivo _/etc/krb5.keytab_:
[root] # kadmin.local -q "ktadd -k /etc/krb5.keytab host/afrodite.prba.mpf.gov.br"
definir os serviços do Kerberos para iniciar automaticamente:
[root] # chkconfig –level 345 krb5kdc on
[root] # chkconfig –level 345 kadmin on
</verbatim>
CONFIGURAÇÕES DO OPENLDAP
Para proceder a instalação do servidor OpenLDAP e bibliotecas necessá¡rias, executa-se o comando:
[root] # apt-get install openldap-servers cyrus-sasl-gssapi
Configurar o arquivos slapd.conf segundo o exemplo abaixo:
SldapConf
Os arquivos _cacert.crt_, _server.crt_ e _server.key_ devem ser gerados por uma autoridade certificadora.
Criar o arquivo _/usr/lib/sasl2/slapd.conf_ com a seguinte linha:
pwcheck_method:saslauthd
Editar o arquivo _/etc/sysconfig/saslauthd_ segundo o modelo registrado no arquivo abaixo:
<verbatim>
- Directory in which to place saslauthd's listening socket, pid file, and so
- on. This directory must already exist.
SOCKETDIR=/var/run/saslauthd
- Mechanism to use when checking passwords. Run "saslauthd -v" to get a list
- of which mechanism your installation was compiled to use.
MECH=kerberos5
- Additional flags to pass to saslauthd on the command line. See saslauthd(8)
- for the list of accepted flags.
FLAGS= </verbatim>
Criar um principal no Kerberos e exportá-lo para o arquivo /etc/krb5.keytab, atribuindo o direito de leitura para o usuário ldap:
<verbatim> [root] # kadmin.local –q “ank -randkey ldap/afrodite.prba.mpf.gov.br”
[root] # kadmin.local –q “ktadd -k /etc/krb5.keytab ldap/afrodite.prba.mpf.gov.br”
[root] # chown ldap /etc/krb5.keytab
Configurar os serviços para que iniciem de forma automática:
[root] # chkconfig --level 345 ldap on
[root] # chkconfig --level 345 saslauthd on </verbatim> Criar um arquivo prba.ldif para popular a base do ldap com o seguinte conteúdo:
LdapConf
Para adicionar a base de dados no LDAP, segue o comando:
$ ldapsearch -x –h 127.0.0.1 -D “cn=Admin,dc=prba,dc=mpf,dc=gov,dc=br” –w prba –f prba.ldif
Cada usuário deverá ser criado utilizando o usuario.ldif, conforme exemplo abaixo:
<verbatim>
- gazola, alunos, prba
dn: uid=gazola,ou=CPD,dc=prba,dc=mpf,dc=gov,dc=br objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount sn: Campos cn: Roosevelth Gutenberg uid: gutenberg uidNumber: 500 gidNumber: 100 homeDirectory: /home/gutenberg loginShell: /bin/bash telephoneNumber: XXXX-XXXX title: Técnico de Informática street: AV Sete de Setembro postalCode: 41500-082 ou: CPD st: ENDERECO l: Salvador givenName: Gutenberg homePhone: XXX-XXXX initials: Gazola labeledURI: http://www.prba.mpf.gov.br mail: gutenberg@prba.mpf.gov.br mobile: XXXX-XXXX dc: Procuradoria da Republica no Estado de Bahia userPassword: {SASL}gutenberg@prba.mpf.gov.br </verbatim>
Utilize o comando anterior para adicionar o usuário no LDAP. É necessário lembrar o passo para criar o principal no Kerberos com o nome igual ao atributo UID do usuário:
[root] # kadmin.local -q “ank uid”
INSTALAÇÃO E CONFIGURAÇÃO DO SAMBA
Para proceder a instalação do servidor SAMBA, execute o comando:
[root] # apt-get install SAMBA
A configuração do SAMBA se concentra no arquivo _/etc/SAMBA/smb.conf_, conforme exemplo abaixo:
SambaConf
O script de sincronização de senha criado encontra-se ilustrado abaixo:
<verbatim>
- !/bin/bash
echo -n "New password : " read PASS1 echo -n "Retype new password : " read PASS2 if [ "$PASS1" = "$PASS2" ] then /usr/kerberos/sbin/kadmin -s kerberos.prba.mpf.gov.br -k -t /etc/SAMBA/SAMBAAdmin.keytab -p SAMBA/admin -q "cpw -pw $PASS1 $1" > /dev/null 2>&1 echo "all authentication tokens updated successfully" else echo "Passwords do not match" fi
- END
</verbatim>
CONFIGURAÇÕES DAS ESTAÇÕES LINUX
Existe a necessidade de instalar o pacote cyrus-sasl-gssapi, que não é instalado por padrão, segue o comando de instalação:
[root] # apt-get install cyrus-sasl-gssapi
O primeiro passo para configurar a estação de trabalho Linux é configurar o arquivo /etc/ldap.
Este arquivo, por sua vez, informará ao sistema onde o como consultar o ldap, segue o seu modelo: <verbatim> host ldap.prba.mpf.gov.br base dc=prba,dc=mpf,dc=gov, dc=br binddn uid=nss-proxy,ou=system,dc=prba,dc=mpf,dc=gov,dc=br bindpw prba pam_password md5 </verbatim>
É necessário configurar o serviço nsswitch para informar ao sistema a montagem da lista de usuários, grupos e informações de senhas no ldap. O seu arquivo de configuração é o /etc/nsswitch.conf, segue o modelo:
NsSwitch
Utiliza-se o comando: “getent passwd” em comparação com o arquivo /etc/passwd para verificar se o sistema está gerando a lista de usuário com os objetos presentes no LDAP.
É necessário informar aos clientes Kerberos a sua configuração, sobre servidores e o realm que irá utilizar. Estas configurações serão realizadas no arquivo /etc/krb5.conf e está ilustrada abaixo:
KrbConf
Note que a relação dos KDCs não constam na lista, pois esta será verificada por meio de DNS.
Para finalizar a configuração da estação de trabalho, faz-se necessário a configuração do arquivo _/etc/pam.d/system-auth_ de forma que o PAM realize a autenticação do sistema contra o Kerberos, obtendo, um TGT para solicitação de tickets de serviço pelo usuário:
