Post on 24-Jun-2015
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