Conheça o Kerberos, o cão de guarda

O Kerberos versão 5, conforme definido pela RFC 1510, é o principal protocolo de segurança e autenticação/autorização do Active Directory. Além disso é um protocolo de segurança distribuido, ou seja, ele permite que os usuários acessem recursos em qualquer lugar da rede com um único logon.

O nome Kerberos parece meio assustador, não é mesmo ? Na mitologia grega, Kerberos (Cérbero, em português) é o cão de três cabeças que guarda os portões do Hades ( o mundo subterrâneo). O pessoal do desenvolvimento que trabalhava no MIT (Instituto de Tecnologia de Massaschusets) criou o protocolo Kerberos na década de 80 achou que era um nome apropriado para o novo protocolo de segurança. Eu não sei o quanto a você, mas não gosto da idéia de associar minha rede aos portões de Hades ! Apesar dessa associação o Kerberos é um protocolo padrão e maduro, adequado para computação distribuída.

Computadores que rodam Windows XP, Windows Vista, Windows 7 usam o Kerberos para se autenticar com um controlador de domínio. Os servidores executando Windows 2000 Server, Windows Server 2003 e Windows Server 2008 também usam o Kerberos para autenticação. O Kerberos exige que tanto o cliente quanto o servidor se autentiquem, impedindo assim que um intruso “finja” se passar por um cliente ou por um servidor.

• A seguir estão os recursos que o Kerberos traz para o Active Directory :
• Autenticação mais rápida em um ambiente de computação distribuída
• Relação de confiança transitiva entre domínios
• Autenticação delegada ( ou pass-through ) para aplicações distribuídas
• Interoperabilidade com sistemas Não Windows como o Linux que usem o protocolo Kerberos.

O Kerberos usa um segredo compartilhado, também conhecido como chave, de modo que tanto o cliente como o serviço que roda em cada controlador de domínio conhecido como KDC (Key Distribution Center, ou Centro de Distribuição de Chaves) compartilhem a mesma chave. No caso da autenticação de um usuário, essa chave é o hash da senha do usuário.

O KDC na verdade tem dois componentes : O Serviço de Autenticação (AS), que fornece os serviços iniciais de logon, e o Serviço de Garantia de Ticket (TGS), que fornece tickets para acessar os recursos da rede depois que o usu;ario tiver feito o login, por padrão cada ticket tem validade de 10 horas. O Kerberos age em seguida para autenticar as requisições de logon e autorizar o usuário a acessar um recurso de rede.

1. Um usuário se autentica com o KDC fazendo o login. ( o KDC roda como um serviço em cada controlador de domínio ). A mensagem de autenticação inclui o nome de login do usuário, o nome do domínio ao qual o usu;ário está se logando e uma marcação de data e hora. Essas informações são codificadas com o hash da senha do usuário. Assim, a senha do usu;ario jamais será enviada pela rede e continuará segura.
2. O componente AS do KDC recebe a requisição de autenticação e a valida para que possa ser decodificada com o hash da senha do usuário, acessada a partir do banco de dados do AD. Se a codificação for bem sucedida e a marcação de data e hora e até cinco minutos do horário do controlador de domínio atual, a autenticação será bem sucedida. o KDC retorna um Ticket que Garante o Ticket (TGT) para o cliente. O TGT contém o SID do usuário e as SIDs de todos os grupos a qual o usuário é membro.
3. O cliente coloca o TGT em cache até que ele precise acessar um recurso de rede. Neste momento, o TGT é apresentado ao componente TGS do KDC e requisita o acesso a um recurso do servidor.
4. O KDC retorna um Ticket de Sessão (ST) que contém um código em uma chave encriptada conhecida apenas por ele mesmo e pelo servidor de recurso.
5. O cliente apresenta o ST ao servidor do recurso
6. O servidor do recurso examina o ST em busca do código da chave, conhecido apenas por ele e pelo KDC.
7. Se o código da chave for igual ao código da chave existente no servidor de recursos, o cliente receberá acesso ao servidor de recursos. Se o código forem diferentes, o cliente terá acesso recusado.

Ilustração :

A teoria por trás dessa transação é que o servidor de recurso diz : “Hummm, Eu conheço e confio no KDC. O KDC deve conhecer e confia nessa conta porque deu o ST para ela. Se eu confio no KDC e o KDC confia na conta do usuário, logo eu também posso confiar nessa conta de usuário.