Junho de 2008

Índice

Introdução .......................................................................................................................... 3

1 - Introdução ao kerberos ................................................................................................. 4

2 - Características kerberos ............................................................................................... 5

3 - Realms, Principals e Instâncias .................................................................................... 6

4 – KDC ............................................................................................................................. 7

4.1 - Base de Dados ........................................................................................................... 8

4.2 - Servidor de Autenticação .......................................................................................... 8

4.3 - TGS ........................................................................................................................... 9

5 – Tickets ......................................................................................................................... 9

6 – Funcionamento .......................................................................................................... 10

6.1 - Passo 1: Pedido de TGT do cliente ao AS .............................................................. 11

6.2 - Passo 2: Resposta do AS ao pedido do cliente ........................................................ 11

6.3 - Passo 3: Pedido de ticket de serviço ao TGS .......................................................... 12

6.4 - Passo 4: Resposta do TGS ao cliente ...................................................................... 12

6.5 - Passo 5: Acesso ao serviço ...................................................................................... 13

7 – Keytab ....................................................................................................................... 14

8 - Autenticação Cross-Realm ......................................................................................... 14

9 - Características do ambiente Kerberos ........................................................................ 15

10 - Instalação do Protocolo de Autenticação Kerberos ................................................. 16

11 -Instalação e configuração de máquinas clientes ....................................................... 21

Conclusão ........................................................................ Erro! Marcador não definido.

Bibliografia ...................................................................................................................... 24

Índice de Imagens

Imagem 1 - Os 3 elementos (servidor, cliente e servidor kerberos) ................................. 4

Imagem 2 - Componentes do KDC ................................................................................. 8

Imagem 3 - Detalhe das operações realizadas em cada passo [TANEMBAUM, 1996] 10

Imagem 4 - Requisição do cliente ao AS ....................................................................... 11

Imagem 5 - Resposta do AS ao cliente ........................................................................... 11

Imagem 6 - Requisição do cliente ao TGS .................................................................... 12

Imagem 7 - Resposta do TGS ao cliente ........................................................................ 13

Imagem 8 - Requisição do serviço pelo cliente .............................................................. 13

Imagem 9 - Confiança cross-realm entre dois realms Kerberos diferentes .................... 15

Imagem 10: Resultado do yum search kerberos ............................................................. 18

Imagem 11: download e intalação do pacote krb5-server .............................................. 18

Imagem 12: Exemplo do ficheiro krb5.conf ................................................................... 19

Imagem 13: Criação da base de dados............................................................................ 20

Imagem 14: conteúdo do ficheiro kadm5.acl ................................................................. 20

Imagem 15: Inicialização do Kerberos ........................................................................... 21

Introdução

Este documento apresenta apenas uma introdução inicial ao sistema de

autenticação Kerberos e as características específicas do sistema. São igualmente

apresentadas instruções de configuração para permitir configurar um sistema kerberos.

Neste sentido, embora se espere que este documento seja auto-contido para as

necessidades iniciais da maioria dos utilizadores, a utilização avançada exige a leitura

de documentação adicional.

1 - Introdução ao kerberos

O Kerberos foi desenvolvido pelo Massachussets Institute of Technology (MIT) como

parte do Projecto Athena [KERBEROS, 2004] e foi projectado para prover uma forte

autenticação para aplicações cliente/servidor, actuando como uma terceira entidade

nesse processo. A figura abaixo mostra a relação entre estes três elementos (servidor,

cliente e servidor Kerberos).

―O nome Kerberos vem da mitologia grega, onde Cerberus é um cão com três cabeças

que tem por missão proteger a entrada do inferno de Hades. [MUNIZ, 2004]. “

Imagem 1 - Os 3 elementos (servidor, cliente e servidor kerberos)

Desde que o Kerberos começou a fazer parte do projecto Athena, várias revisões já

foram realizadas. Os maiores avanços desde a versão inicial até a última abrangem as

características de extensibilidade e segurança. A versão 5 utilizada para a montagem dos

cenários deste trabalho foi desenvolvida para corrigir deficiências da última versão,

acrescentar novas características e melhorar aspectos de segurança. Dentro das suas

características, destacam-se a utilização mais flexível de autenticação que envolve

vários domínios e a extensibilidade dos tipos de criptografia.

O Kerberos foi projectado de modo a resolver alguns problemas relacionados à

autenticação quando feita através de passwords em uma rede de computadores que

fornece diferentes tipos de serviço. Por exemplo, clientes podem utilizar como

passwords palavras comuns encontradas facilmente em dicionários, facilitando o ataque

de pessoas mal intencionadas. De acordo com estatísticas, quanto mais passwords uma

pessoa precisar de ter (devido à necessidade de autenticação em diferentes serviços para

aceder à rede), menor se torna a qualidade das passwords que são escolhidas. Um

segundo problema está relacionado com a transmissão da passwords através de uma

rede não segura.

Neste contexto, o sistema de autenticação Kerberos faz com que o número de passwords

que o utilizador precisa memorizar seja reduzido para apenas uma: a password do

Kerberos. Uma vez autenticado no Kerberos, o utilizador obtém o direito de aceder aos

serviços desejados (terminal remoto, servidor de correio ou servidor de directórios, por

exemplo) sem necessidade de re-autenticação.

Além disso, o Kerberos centraliza o processo de autenticação num servidor ou num

conjunto de servidores denominado KDC (Key Distribution Center). Cada KDC possui

uma base de dados com os nomes dos utilizadores e passwords. Essa centralização de

autenticação é desejada, pois diminui o número de máquinas que armazenam

informações confidenciais, permitindo que a segurança seja reforçada nessas máquinas.

2 - Características kerberos

Resumidamente, o serviço de autenticação do Kerberos possui as seguintes

características:

Seguro: O Kerberos é seguro, pois nunca transmite passwords sobre a rede em

texto simples. Aliás, as passwords não circulam na rede. Também utiliza

mensagens criptográficas com validade definida para provar a identidade do

utilizador para um dado servidor.

Autenticação única (single-sign-on): Os utilizadores finais precisam de se

autenticar uma única vez para poder aceder a todos os serviços registados no

Kerberos. Após a autenticação inicial, o utilizador obtém credenciais de forma

transparente, acedendo aos serviços desejados.

Terceirizado e confiável: A autenticação ocorre através de um servidor de

autenticação centralizado, no qual todos os clientes da rede confiam e no qual

fazem os seus pedidos de autenticação.

Autenticação Mútua: Garante que não, apenas o utilizador final é quem diz ser,

mas também garante a identificação do servidor com quem esse utilizador

comunica. É importante salientar ainda que todo o protocolo Kerberos é baseado

em criptografia simétrica, ou seja, as chaves secretas utilizadas pelo cliente e

pelo servidor devem ser as mesmas.

3 - Realms, Principals e Instâncias

Cada entidade que contém uma instância do Kerberos como computadores e serviços

em servidores, possui um principal associado. Cada principal possui um nome único e

global e é associado a uma chave que pode ser uma password, por exemplo.

Cada principal começa com o nome do utilizador, ou do serviço, seguido por uma

instância opcional. Esta instância é utilizada para criar principals especiais para uso

administrativo. Por exemplo, administradores podem possuir dois principals, um para

utilização no dia-a-dia (user) e outro que é utilizado para operações que exigem

privilégios administrativos (admin).

O nome do utilizador, em conjunto com a instância, que é opcional, forma uma

identidade única para um determinado realm. Um realm é uma espécie de domínio de

contas que está sob a responsabilidade de determinado servidor. Por convenção, o realm

de um servidor Kerberos é o próprio domínio DNS do qual o servidor faz parte, mas

com letras maiúsculas. Por exemplo, a Instituto Superior de Contabilidade e

Administração de Coimbra, que possui o domínio iscac.pt, deve criar o realm

ISCAC.PT no Kerberos.

Exemplo de um principal que pertence ao utilizador fictício António Faria (afaria), que

é docente no Instituto Superior de Contabilidade e Administração de Coimbra:

afaria@DOCENTE.ISCAC.PT

Esta é a forma mais simples que um principal pode assumir, é válida nas versões

4 e 5 do Kerberos. O principal acima representa o nome do utilizador afaria, que não

possui instância, e cujo realm é DOCENTE.ISCAC.PT.

Seguem-se outros exemplos de principals, onde afaria é o nome do utilizador;

admin é a instância; ISCAC.PT é o realm.

afaria@ISCAC.PT

afaria/admin@ISCAC.PT

host/maquinalocal.meu.domínio@ISCAC.PT

serviço/maquinalocal.meu.domínio@ISCAC.PT

No primeiro caso, afaria é o nome de um utilizador que faz parte do realm ISCAC.PT.

No segundo exemplo, afaria/admin é um principal especial para o utilizador afaria no

realm ISCAC.PT, utilizado quando afaria realizar alguma tarefa administrativa. No

terceiro exemplo, host/maquinalocal.meu.domínio é um principal de host no realm

ISCAC.PT, através do qual o servidor maquinalocal.meu.domínio é registado no

Kerberos. Por fim, o último principal é utilizado para registar um serviço que executa

em maquinalocal.meudominio.

4 – KDC

O KDC (Key Distribution Center) do Kerberos consiste em três componentes lógicos:

uma base de dados que contém todos os principals e as respectivas passwords em modo

criptográfico (passwords), o AS (Authentication Server) e o TGS (Ticket Granting

Server). Estes componentes são separados logicamente, porém são implementados num

único programa e correm juntos num único processo.

Imagem 2 - Componentes do KDC

Para um determinado realm deve existir pelo menos um KDC. Se houver mais do que

um, é recomendável que estejam instalados em máquinas diferentes. Trabalham num

esquema mestre-escravo para que a autenticação via Kerberos possa ser feita em mais

que uma máquina. Neste caso, a máquina master é o local que contém a base de dados

que armazena as passwords dos utilizadores; e as máquinas slaves contêm apenas cópias

autorizadas exclusivamente para leitura dessa base de dados, que devem ser

actualizadas, pela máquina master. A base de dados de cada KDC deve estar ainda

sincronizada com as outras para garantir uma autenticação unificada.

4.1 - Base de Dados

A base de dados do Kerberos armazena as passwords dos utilizadores e as passwords de

cada serviço de cada servidor. Estas passwords serão usadas pelo TGS para fazer toda a

troca de tickets e passwords de sessão. O ficheiro onde são guardadas as passwords de

serviço é chamado de keytab.

Cada realm possui a sua própria base de dados, contendo as informações sobre os

utilizadores e serviços. Portanto, em cada realm é necessário existir pelo menos um

servidor Kerberos, onde a base de dados master será guardada. A existência dos slaves é

opcional, sendo necessária quando o número de requisições para serviços no domínio é

muito grande. No entanto, como os slaves possuem cópias somente com autorização de

leitura.

O servidor KDBM, além de atender requisições administrativas, o que pode ser, por

exemplo, a adição de um novo principal, também deve realizar serviços como alteração

de passwords, utilizando respectivamente os programas kadmin e kpasswd .

Para realizar operações como essas, o ticket a ser utilizado não deve ser obtido com o

TGS, mas com o servidor de autenticação (AS), para obrigar que o utilizador digite

sempre a sua password.

4.2 - Servidor de Autenticação

O AS (Authentication Server) distribui TGTs (Ticket Granting Tickets) encriptado para

os utilizadores que se querem autenticar num realm do Kerberos. Os utilizadores não

precisam provar a sua identidade no KDC no momento em que requisitam o ticket

(basta informar o principal), porém o TGT enviado é encriptado utilizando a password

do utilizador requisitante como password secreta. Somente uma password correcta pode

desencriptar o ticket (tornando-o útil), e para que isso ocorra, ambos, AS e cliente,

devem possuir a mesma password secreta. Uma vez desencriptado pelo utilizador, o

TGT retornado pelo AS, que pode expirar num tempo especificado, permite que o

utilizador obtenha tickets adicionais, os quais fornecem permissão para aceder a

serviços específicos. O TGT é o elemento principal que elimina a necessidade do

utilizador de informar a sua password mais do que uma vez durante a utilização dos

vários serviços da rede.

4.3 - TGS

O TGS (Ticket Granting Server) distribui tickets adicionais de acordo com a requisição

dos clientes. O TGS precisa de duas informações básicas para prover este serviço: um

ticket de requisição contendo o principal que representa o serviço que o cliente deseja

aceder, e um TGT fornecido pelo AS. O TGS verifica então se o TGT é válido caso em

que o utilizador foi devidamente autenticado e envia ao utilizador o ticket do serviço

requisitado.

5 – Tickets

Um ticket é um dado encriptado fornecido pelo KDC e que possui uma password

secreta que é única para cada sessão. Os tickets são utilizados para dois propósitos:

confirmar a identidade dos utilizadores finais e estabelecer entre o cliente e servidor

uma chave de criptografia de vida útil pequena (session key) que garante uma

comunicação segura.

A melhor maneira de entender o conceito de um ticket é compará-lo a uma carta de

condução que possui foto e informações como nome, validade e restrições de uso, e que

garante que o seu portador é quem diz ser, podendo exercer o direito de conduzir um

determinado tipo de veículo. Quando um TGT expira, é preciso fazer uma nova

autenticação no servidor Kerberos.

6 – Funcionamento

Primeiramente, antes de detalhar o funcionamento passo-a-passo do Kerberos, é

necessário esclarecer a diferença entre as terminologias (chave secreta, chave de sessão

e password) utilizadas nesta secção. Cada principal do Kerberos possui uma chave

secreta. Para um utilizador, a chave secreta é gerada através de uma função relacionada

à sua password. A password é uma sequência de caracteres escolhida pelo utilizador

para fazer o login. Ao usar-se o termo password, deve entender-se chave secreta

derivada da password, e não a password propriamente dita. Existe também a chave de

sessão, que é gerada pelo Kerberos, para ser usada temporariamente na comunicação

entre duas entidades.

O funcionamento do Kerberos pode ser visualizado numa sequência de passos e

operações, conforme mostra a imagem seguinte. Observe que, como dito anteriormente,

o AS e o TGS do KDC são separados logicamente e por esse motivo possuem chaves

secretas diferentes (KAS e KTGS).

Imagem 3 - Detalhe das operações realizadas em cada passo [TANEMBAUM, 1996]

6.1 - Passo 1: Pedido de TGT do cliente ao AS

Imagem 4 - Requisição do cliente ao AS

Quando um cliente deseja aceder a um serviço qualquer protegido pelo Kerberos, antes

de conseguir acede-lo, deve autenticar-se, obtendo um TGT. É importante lembrar que o

AS compartilha uma chave secreta (KA) com todos os clientes que realizam

autenticação num servidor Kerberos.

Deste modo, o cliente envia uma requisição de autenticação, contendo o seu principal,

para o AS. O AS pesquisa na sua base de dados as chaves secretas correspondentes ao

cliente (origem da requisição) e ao TGS (onde o cliente, de facto, deseja autenticar-se),

e cria uma chave de sessão (KAS) que será utilizada por ambos, cliente e TGS.

6.2 - Passo 2: Resposta do AS ao pedido do cliente

Imagem 5 - Resposta do AS ao cliente

O AS responde ao pedido de autenticação do cliente enviando uma chave de sessão

(KAS) e um TGT encriptado com a chave secreta do TGS.

Todos estes dados (chave de sessão e TGT) são encriptados utilizando a chave secreta

do cliente (KA). Sendo assim, somente o cliente pode desencriptar a mensagem.

A password é utilizada então para gerar a chave secreta do cliente que por sua vez é

utilizada para desencriptar a mensagem de resposta do AS e obter a chave de sessão

(KAS) e o ticket (TGT) para o TGS.

6.3 - Passo 3: Pedido de ticket de serviço ao TGS

Imagem 6 - Requisição do cliente ao TGS

Neste passo, o cliente precisa informar que quer utilizar determinado serviço e pedir um

ticket para este serviço. O cliente envia, então, uma mensagem para o TGS contendo o

nome do serviço o TGT e um timestamp que é encriptado com a chave de sessão (KAS)

fornecida pelo AS. O elemento chave nesta requisição é o TGT, que volta encriptado

com a chave secreta do próprio TGS e é usado para provar que o cliente é quem diz ser.

Por exemplo, caso um cliente copie de outro cliente a mensagem de requisição de

serviço feito para o TGS, a tentativa de utilizar esta mensagem será frustrada, pois,

como não possui a chave de sessão (KAS) fornecida originalmente pelo AS, não será

possível substituir o timestamp por um mais recente.

6.4 - Passo 4: Resposta do TGS ao cliente

Imagem 7 - Resposta do TGS ao cliente

Ao receber a requisição, o TGS utiliza a sua chave secreta para desencriptar o TGT, e

utiliza a chave de sessão (KAS) fornecida pelo AS para desencriptar o timestamp.

O TGS então envia como resposta para o cliente um ticket (KAB) para que o cliente

possa aceder ao serviço. Agora o cliente pode utilizar este novo ticket (KAB) para

estabelecer uma sessão com o servidor do serviço. Esta troca também é acompanhada

por um timestamp.

6.5 - Passo 5: Acesso ao serviço

Imagem 8 - Requisição do serviço pelo cliente

Por fim, o cliente faz uma requisição ao serviço desejado enviando o ticket encriptado

com a chave do serviço (KSERV, de acordo com a figura). A partir de agora, o cliente

será capaz de comunicar com o servidor e utilizar o serviço solicitado.Note que o cliente

envia a versão do ticket que veio encriptada com a chave do servidor.

Caso o cliente precise aceder a outro serviço, basta repetir o passo 03 e enviar uma nova

requisição ao TGS, especificando assim o novo serviço. O TGS irá responder com um

ticket encriptado (KNOVO_AB) o qual será utilizado para que o cliente aceda a este

serviço.

A grande questão é que, a partir deste momento, o cliente pode aceder a qualquer

serviço da rede através de um caminho seguro, sem se preocupar com a password nem

envio da mesma através da rede (pelo menos enquanto durar o prazo de validade do

TGT). Cada servidor, entretanto, faz seu próprio controlo de acesso (autorização).

7 – Keytab

Para cada serviço deve existir uma chave de serviço (service key) conhecida apenas pelo

Kerberos e pelo serviço. Num servidor Kerberos, a chave de serviço é armazenada na

base de dados do próprio Kerberos. Em servidores de aplicação, estas chaves de serviço

são armazenadas em key tables, que são ficheiros conhecidos como keytabs. Estas

chaves de serviço são como uma password do serviço e devem ser mantidas em

segurança.

Todo servidor de aplicação que precise autenticar-se no KDC deve possuir um ficheiro

keytab localizado em /etc/krb5.conf. Para que seja possível gerar keytabs, o servidor, ou

um host, precisa ter um principal na base de dados do Kerberos.

8 - Autenticação Cross-Realm

Um único AS e um único TGS funcionam bem se o número de requisições for pequeno,

mas com o crescimento da rede, cresce o número de requisições de serviços, e o

conjunto AS/TGS passa a ser um guardado no processo de autenticação, o que é muito

ruim para um sistema distribuído como o Kerberos.

Entretanto o Kerberos oferece a vantagem de dividir a rede em realms onde cada realm

tem seu próprio AS e seu próprio TGS. Esta divisão muitas vezes é feita sobre limites

organizacionais. Como consequência, surge a necessidade de implementar uma

autenticação crossrealm, isto é, uma autenticação que envolve vários KDCs conforme

os realms envolvidos, já que um cliente num realm pode precisar de um serviço em

outro realm. Tal autenticação é feita através da compartição de uma password de

criptografia entre cada realm participante.

Para a utilização do cross-realm, principals são criados em cada realm participante do

processo de autenticação. Por exemplo, para dois realms (UM.COM e DOIS.COM), os

principals devem ser:

krbtgt/DOIS.COM@UM.COM

krbtgt/UM.COM@DOIS.COM

Imagem 9 - Confiança cross-realm entre dois realms Kerberos diferentes

Estes principals, conhecidos como Remote Ticket Granting Server, precisam de ser

criados em ambos os realms. Uma vez presentes, um utilizador do realm UM.COM

pode aceder a serviços no realm DOIS.COM como se estivesse acedendo a um serviço

do seu próprio realm.

9 - Características do ambiente Kerberos

Dentre as várias características do Kerberos, as que mais se destacam são:

Proporciona maior segurança na rede, pois evita que a password do utilizador transite

muitas vezes pela rede e seja ‘captada’ por um sniffer;

Proporciona uma verificação da autenticidade, não só do utilizador, mas também do

serviço, ou seja, uma autenticação mútua;

Na versão 5 pode ser utilizados vários algoritmos de criptografia, como, DES, 3DES,

AES, entre outros;

Suporta grandes quantidades de clientes e serviços;

Altamente escalável e replicável e

Administração simples.

O Kerberos está em constante evolução, porém ainda possuí pontos negativos

[GARMAN 2003], como:

O sistema deve ser extremamente seguro, pois se um invasor conseguir acesso a base de

dados das chaves de encriptação, todo o processo está comprometido;

As aplicações que desejam utilizar o Kerberos devem ser reconstruídas para dar o

suporte ao mesmo;

Não está protegido contra password’s fracas, ou seja, password’s que podem facilmente

ser descobertas com um ataque de dicionário [TANENBAUM 2003];

Problemas com estações que possuem mais de que um IP;

As diferenças nos relógios envolvidos no processo de autenticação podem gerar

problemas na validação do timestamp;

10 - Instalação do Protocolo de Autenticação Kerberos

A seguir serão demonstrado todos os aspectos de instalação e configuração das três

entidades (cliente, servidor e Kerberos) para que a autenticação possa ser realizada.

10.1 - Configuração do Servidor Kerberos

Segue-se um guia de instalação do protocolo de autenticação em rede Kerberos, para

funcionar no sistema operativo Linux Fedora.

A versão do protocolo utilizada foi o MIT Kerberos V5 Release 1.3.5, uma

implementação gratuita do protocolo desenvolvida pelo Massachusetts Institute of

Technology.

O protocolo Kerberos foi desenvolvido para prover uma forte autenticação para

aplicações cliente/servidor utilizando criptografia de chave secreta, onde o cliente pode

provar a sua identidade a um servidor e vice-versa sobre uma conexão de rede não

confiável. Depois de ter as suas identidades provadas através do uso de Kerberos,

cliente e servidor podem também encriptar toda a comunicação garantindo a

confidencialidade e também a integridade dos dados.

Para a correcta instalação do protocolo Kerberos sigam-se os passos

Passo 1: Abrimos a consola de comandos do sistema operativo Linux. Como referimos

nos pontos anteriores a autenticação do Kerberos é baseada no tempo de expiração dos

tickets, o que torna o sincronismo dos relógios dos servidores e dos clientes um ponto

crítico a ter em conta. Por isso, o sincronismo dos horários entre as máquinas que

utilizam o Kerberos deve estar configurado correctamente ou o Kerberos não irá

funcionar. Uma forma de manter os relógios das máquinas sincronizados é utilizar um

protocolo como o Network Time Protocol (NTP) compatível com a rede cliente/servidor

mesmo que o Kerberos não esteja a ser utilizado. O Red Hat Enterprise Linux inclui o

pacote ntp para este propósito. Consulte o /usr/share/doc/ntp-<version-

number>/index.html (onde <version-number> é o número da versão do pacote ntp

instalado no sistema) para obter detalhes sobre a configuração de servidores de

Protocolo de Horário de Rede vá a http://www.ntp.org para informações adicionais

sobre NTP.

Passo 2: Com a inserção da instrução yum search kerberos encontramos os seguintes

pacotes e serviço krb5-libs, krb5-server, e krb5-workstation, procedemos ao download

dos respectivos ficheiros e de seguinda fizemos a sua instalação na máquina dedicada

que executa o KDC. Essa máquina precisa ser muito segura — se possível, não deve

executar nenhum outro serviço além do KDC. O Yum é um acrónimo para Yellow dog

Updater, Modified. É uma ferramenta utilizada para gerir a instalação e remoção de

pacotes em distribuições Linux, trabalha com formato .rpm de pacotes de arquivos. O

Yum faz o download do pacote especificado de algum repositório. Possui um simples

arquivo de configuração.

Imagem 10: Resultado do yum search kerberos

Imagem 11: download e intalação do pacote krb5-server

Passo 3: Edite os ficheiros de configuração /etc/krb5.conf e

/var/kerberos/krb5kdc/kdc.conf para refletir o nome do realm. Um realm simples pode

ser construído substituindo as instâncias de EXEMPLO.COM e exemplo.com pelo nome

de realm correcto — certificando-se de manter os nomes em letras maiusculas ou

minusculas — e alterando o KDC de kerberos.exemplo.com para o nome do servidor do

Kerberos. Por convenção, todos os nomes do realm são escritos em letra maiuscula e

todos os nomes DNS de máquinas e de domínio são escritos em letra minuscula.

A imagem seguinte apresenta um exemplo do arquivo /etc/krb5.conf. A secção

[libdefaults] define que o realm exemplo.com é o realm padrão e que o DNS não será

utilizado para pesquisa de configurações do Kerberos. Na secção [realms] estão

definidos, para o realm EXEMPLO.COM, os nomes dos servidores KDC, qual deles é o

KDC mestre e quais as portas de acesso. A secção [domain_realm] faz o mapeamento

entre domínios DNS e realm Kerberos e a secção [logging] determinam a localização

dos ficheiros de login do Kerberos.

Imagem 12: Exemplo do ficheiro krb5.conf

Passo 4: O proximo passo é criar a base de dados usando o comando kdb5_util na

janela de comandos:

/usr/kerberos/sbin/kdb5_util create -s

O comando create cria a base de dados de dados usado para armazenar as chaves para o

Kerberos. A opção -s força a criação do ficheiro stash no qual a chave do servidor

mestre está armazenada. Se não houver nenhum arquivo stash a partir do qual se possa

ler a chave, o servidor do Kerberos (krb5kdc) pede ao utilizador a password do servidor

mestre.

Imagem 13: Criação da base de dados

Passo 5: Edite o ficheiro /var/kerberos/krb5kdc/kadm5.acl. Neste ficheiro devem estar

especificadas as políticas de controlo de acesso à base de dados. Deve existir, pelo

menos, a política de acesso relativa aos administradores do Kerberos. O kadm5.acl é

usado pelo kadmind para determinar quais principals têm acesso administrativo à base

de dados do Kerberos e qual o nível de acesso.

Imagem 14: conteúdo do ficheiro kadm5.acl

Passo 6: Inserindo o comando kadmin.local onde se encontra o KDC criamos o

primeiro principal, através da seguinte linha de comando:

/usr/kerberos/sbin/kadmin.local -q "addprinc nome-do-utilizador/admin"

Passo 7: Em seguida teremos de criar o ficheiro para o KDC (keytab), cada servidor

KDC (mestre ou escravo) precisa de uma chave para desencriptar o tickets. Isto é feito

através do programa kadmin executado no próprio servidor para o qual se quer gerar a

chave. A chave é lida da base de dados do Kerberos e armazenada localmente no

ficheiro /etc/krb5.keytab, conforme ilustrado na seguinte imagem.

Passo 8: È chegada a altura de iniciarmos o Kerberos através dos seguintes comandos:

/sbin/service krb5kdc start

/sbin/service kadmin start

/sbin/service krb524 start

Imagem 15: Inicialização do Kerberos

11 -Instalação e configuração de máquinas clientes

A configuração de um cliente Kerberos 5 é menos complexo que a do servidor. Após a

sincronização de horários entre o cliente Kerberos e o KDC. Instalamos os pacotes

krb5-libs e krb5-workstation em todas as máquinas cliente. Atribuimos um ficheiro

/etc/krb5.conf válido para cada cliente (geralmente este pode ser o mesmo ficheiro

krb5.conf usado pelo KDC).

Para a correcta configuração de um cliente que fará uso da autenticação via Kerberos e

uso de um serviço, é preciso seguir os seguintes passos:

Passo 1: Instalar os pacotes krb5-libs e krb5-workstation na máquina cliente;

Passo 2: Manter uma cópia do ficheiro /etc/krb5.conf, normalmente o utilizado no

KDC; Os passos 3 e 4, apesar de serem efectuados na máquina Kerberos, são listados

nesta secção pois se relacionam-se mais com o cliente do que com o servidor Kerberos.

Passo 3: Adicionar na base de dados Kerberos, um principal para o utilizador que fará a

requisição do TGT antes que pedir o ticket de serviço, através da directiva addprinc do

comando kadmin. O comando deve ser executado no servidor Kerberos da seguinte

forma:

/usr/local/sbin/kadmin.local addprinc nome_do_cliente

Passo 4: Adicionar na base de dados Kerberos, um principal para o serviço que o

cliente deseja aceder, através da directiva addprinc do comando kadmin . O comando

deve ser executado no servidor Kerberos, e no caso do serviço a ser aceder, ser o LDAP,

o comando seria:

/usr/local/sbin/kadmin.local addprinc -randkey ldap/fqdn onde -randkey significa que a

password será aleatória e não precisará ser digitada pelo utilizador, pois o mesmo a

armazenará na forma de uma keytab em disco. O principal criado téra o formato:

ldap/fqdn@REALM com fqdn sendo o fully qualified domain name da máquina

servidora LDAP.

Passo 5: Extrair a password para o principal do serviço e armazena-la em disco através

da diretiva ktadd do comando kadmin na própria máquina cliente, através do comando:

kadmin ktadd -k /etc/krb5.keytab ldap/fqdn

Passo 6: Sincronização de relógios entre as máquinas cliente e servidor Kerberos, pois

o servidor Kerberos rejeita qualquer pedido de ticket de um host que não esteja dentro

de um limite de atraso de tempo tolerável. Portanto é fundamental que os relógios das

máquinas envolvidas na autenticação estejam sincronizados. Uma alternativa mais

simples é utilizar o comando date nas máquinas envolvidas, garantindo uma mínima

sincronização entre os relógios. Outra alternativa mais robusta é a utilização de um

protocolo de tempo, como o NTP [NTP, 2004] que foi desenvolvido com o propósito de

manter a sincronização de relógios de computadores em uma rede.

Passo 7: Garantir que o DNS está correctamente configurado, através do ficheiro

/etc/hosts de cada máquina. É importante garantir que cada máquina participante da

autenticação reconheça o nome DNS ou fully-qualified-domain-name de todas as

outras. O comando /<directório_de_instalação>/krb5-1.3.5/src/tests/resolve/resolve

mostra a saída no ecrã do hostname e do fqdn da máquina, se a saída apresentada não

estiver de acordo, as configurações do ficheiro /etc/hosts devem ser verificadas.

Bibliografia

http://gentoo-wiki.com/HOWTO_NTP

http://tldp.org/HOWTO/TimePrecision-HOWTO/ntp.html

http://www.ntp.org/ntpfaq/

http://www.linux.com/base/ldp/howto/Kerberos-Infrastructure-HOWTO/cl