Duas formas típicas para nomes principais Kerberos (v5) parecem ser:
username[/instance]@REALM
service/fully-qualified-domain-name@REALM
Também vi algo assim para serviços que poderiam existir em várias portas:
service/fully-qualified-domain-name:port@REALM
Tenho um aplicativo interno que agora está sendo Kerberizado e gostaria de entender como as entidades de serviço devem ser nomeadas. O serviço é distribuído, com diversas instâncias em execução em cada uma das diversas máquinas em cada um dos diversos subdomínios.
Por exemplo, digamos que meu nome de domínio sejazombo.com, e meu serviço Kerberizado, "tenaciousd", é executado em máquinas "www1" a "www5". Além disso, cada máquina possui dez instâncias em portas conhecidas, digamos 25001 a 25010.
Portanto, tenho cinquenta instâncias do servidor, todas basicamente iguais, o que me permite equilibrar a carga, implantar novas versões gradualmente e assim por diante.
Agora, como devo nomear as entidades de serviço no Kerberos? Deveria haver um para cada host que executa o serviço, como haveria no que parece ser a forma mais comum?
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
Ou é uma prática recomendada (e por que) ter uma entidade de serviço por instância de serviço?
tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
...
tenaciousd/www5.zombo.com:[email protected]
Finalmente, que tal ter apenas um principal de serviço, o que parece mais simples, mas menos comum?
[email protected]
Se for importante, o serviço Kerberizado (e os clientes) usam Cyrus SASL, GNU GSSAPI e MIT Kerberos 5. A API SASL usa um parâmetro de "nome de domínio totalmente qualificado" além do nome do serviço, mas suspeito que seja porque suporta mais do que apenas Kerberos, e provavelmente poderíamos passar outras coisas além dos FQDNs reais.
A maior parte da documentação que encontrei pressupõe que cada serviço é executado em um único host em um domínio ou, pelo menos, que os clientes se preocupam profundamente com a instância de serviço à qual se conectam. No meu caso, os serviços são praticamente iguais do ponto de vista do cliente, então qual seria a melhor prática aqui?
Responder1
Para coisas que não são exclusivas (isto é, serviços replicados, executando exatamente as mesmas funções), geralmente compartilho um servidor principal comum. Isto funciona bem se entidades externas virem o mesmo nome de domínio, por exemplo, pois mantém essa ilusão.
Isso também significa que se um usuário mudar da instância 1 para a instância 49, ele não precisará realizar outro handshake Kerberos, pois já possui um tíquete de trabalho válido. Eles usarão esse ticket para autenticar qualquer uma das instâncias sem precisar buscar um novo por instância.
Assim, eu usaria:
tenaciousd/[email protected]
como seu nome principal para este serviço, assumindo que www.example.com é a forma como este serviço é abordado pelos clientes.