Autenticação cross-realm é um termo utilizado para descrever situações em que os clientes (usuários comuns) de um território usam o Kerberos para autenticar serviços (geralmente processos de server rodando um um sistema server específico) que pertencem a um outro território.

No caso mais simples, para que um cliente de um território A.EXAMPLE.COM possa acessar um serviço no território B.EXAMPLE.COM, ambos devem ter uma chave de um principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM e ambas as chaves devem possuir o mesmo número de versão da chave associado a eles.

Para concluir esta tarefa, selecione uma senha segura e uma frase secreta, e crie uma entrada para o principal em ambos os territórios, usando o kadmin.

Use o comando get_principal para se certificar que ambas as entradas possuem números de versões de chaves que combinem (valores kvno) e tipos de criptografia.

Clientes do território A.EXAMPLE.COM podem agora autenticar serviços no território B.EXAMPLE.COM. Ou seja, o território B.EXAMPLE.COM pode agora confiar no território A.EXAMPLE.COM ou ainda em outras palavras, B.EXAMPLE.COM agora confia no A.EXAMPLE.COM.

Isto nos leva a um ponto crucial: a confiança cross-realm é unidirecional por padrão. O KDC do território B.EXAMPLE.COM pode confiar em clientes do A.EXAMPLE.COM para se autenticarem em serviços no território B.EXAMPLE.COM, mas na verdade não importa se os clientes no território B.EXAMPLE.COM são confiáveis para se autenticarem em serviços no território A.EXAMPLE.COM ou não. Para estabelecer confiança no inverso, ambos os territórios deveriam precisar compartilhar chaves para o serviço krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM (observe a ordem inversa dos dois territórios comparado ao exemplo acima).

Se o relacionamento de confiança fosse somente um método para oferecer confiança aos dois territórios, seria muito difícil configurar as redes de trabalho que contém territórios múltiplos. Felizmente, a confiança cross-realm é transitiva. Se clientes de um A.EXAMPLE.COM puderem autenticar serviços no B.EXAMPLE.COM, e clientes do B.EXAMPLE.COM puderem autenticar serviços no C.EXAMPLE.COM, então os clientes do A.EXAMPLE.COM também podem autenticar serviços em C.EXAMPLE.COM, até mesmo se C.EXAMPLE.COM não confiar em A.EXAMPLE.COM. Isto significa que, em uma rede de trabalho com territórios múltiplos que precisem confiar uns nos outros, fazendo boas escolhas sobre quais relacionamentos confiar para configurar, podem reduzir relativamente os esforços requeridos.

Agora, você tratará dos problemas mais convencionais: o sistema do cliente deve ser configurado para que deduza melhor o território que pertence a um serviço específico, assim como precisa ser capaz de determinar como obter credenciais para serviços neste território.

Antes de mais nada: o nome principal para um serviço fornecido por um sistema de servidor específico em um território se parece com este a seguir:

Neste exemplo, o serviço é o nome do protocolo em uso (outros valores comums incluem ldap, imap, cvs e HTTP), que pode ser substituído por host. O server.example.com é o nome do domínio do sistema totalmente qualificado, que executa o serviço e EXAMPLE.COM é o nome do território.

Para deduzir o território do serviço ao qual ele pertence, os clientes irão consultar o DNS ou a seção domain_realm do /etc/krb5.conf para mapear tanto um hostname (server.example.com) quanto um nome de domínio DNS (.example.com) para o nome de um território (EXAMPLE.COM).

Após determinar a que território o serviço pertence, um cliente precisa então determinar o conjunto de territórios que ele precisa para contatar, e em qual ordem ele deve fazê-lo para obter credenciais para o uso ao autenticar o serviço.

Isto pode ser feito de duas maneiras.

O método padrão, que não requer configuração explícita, deve nomear os territórios dentro de uma hierarquia compartilhada. Por exemplo, suponha que se tenha territórios chamados A.EXAMPLE.COM, B.EXAMPLE.COM e EXAMPLE.COM. Quando um cliente no território A.EXAMPLE.COM, tentar autenticar o serviço em B.EXAMPLE.COM, ele irá, por padrão, primeiro tentar obter credenciais para o território EXAMPLE.COM, e depois usar estas credenciais para obter outras, para usar no territórioB.EXAMPLE.COM.

O cliente nesta situação, trata o nome do território como se estivesse tratando de um nome DNS. Ele retira os componentes do seu próprio nome de território para gerar nomes de territórios que estejam "acima" dele na hierarquia até que alcance um ponto que também esteja "acima " do território dos serviços. Neste momento, ele começa a passar os componentes do nome do território do serviço na frente até que ele alcance o território do serviço. Cada território envolvido no processo é um outro "salto".

Por exemplo, usando credenciais em A.EXAMPLE.COM, autenticando um serviço em B.EXAMPLE.COM:

Outro exemplo usando credenciais em SITE1.SALES.EXAMPLE.COM, autenticando um serviço em EVERYWHERE.EXAMPLE.COM:

Outro exemplo, desta vez usando nomes de territórios que não compartilham de um sufixo em comum (DEVEL.EXAMPLE.COM e PROD.EXAMPLE.ORG):

O método mais complicado, porém mais flexível, envolve a configuração da seção capaths do /etc/krb5.conf, para que os clientes que tiverem credenciais para um território, possam procurar qual território é o próximo na corrente que irá finalmente levar à autenticação dos servidores.

O formato da seção capaths é relativamente direta: cada entrada na seção é nomeada com o nome de um território com cliente. Dentro desta subseção, o conjunto de territórios intermediários do qual o cliente deve obter credenciais, está listado como valores de chaves que corresponde a um território que possui um serviço. se não existir territórios intermediários, utiliza-se o valor "."

Segue abaixo um exemplo:

Neste exemplo, clientes no território A.EXAMPLE.COM podem obter credenciais cross-realm para B.EXAMPLE.COM diretamente do KDC A.EXAMPLE.COM.

Se estes clientes desejarem contatar um serviço no território C.EXAMPLE.COM, eles precisarão obter credenciais do território B.EXAMPLE.COM (a existência de um krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM é crucial) e então usar estascredenciais para obter credenciais a serem usadas no território C.EXAMPLE.COM (usando krbtgt/C.EXAMPLE.COM@B.EXAMPLE.COM).

Se estes clientes desejarem contatar um serviço no território D.EXAMPLE.COM eles primeiro precisarão obter credenciais do território B.EXAMPLE.COM, e então credenciais do território C.EXAMPLE.COM, antes de finalmente obter as credenciais para uso no território D.EXAMPLE.COM.