Dos formas típicas de los nombres principales de Kerberos (v5) parecen ser:
username[/instance]@REALM
service/fully-qualified-domain-name@REALM
También he visto algo como esto para servicios que podrían existir en múltiples puertos:
service/fully-qualified-domain-name:port@REALM
Tengo una aplicación interna que ahora se está kerberizando y me gustaría saber cómo se deben nombrar los principales de servicio. El servicio se distribuye, con varias instancias ejecutándose en cada una de varias máquinas en cada uno de varios subdominios.
Por ejemplo, digamos que mi nombre de dominio eszombo.com, y mi servicio Kerberizado, "tenaciousd", se ejecuta en las máquinas "www1" a "www5". Además, cada máquina tiene diez instancias en puertos conocidos, digamos del 25001 al 25010.
Entonces tengo cincuenta instancias del servidor, todas básicamente iguales, lo que me permite equilibrar la carga, implementar nuevas versiones gradualmente, etc.
Ahora bien, ¿cómo debo nombrar las entidades principales de servicio en Kerberos? ¿Debería haber uno para cada host que ejecute el servicio, como sería lo que parece ser la forma más común?
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
tenaciousd/[email protected]
¿O es una mejor práctica (y por qué) tener una entidad de servicio por instancia de servicio?
tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
tenaciousd/www1.zombo.com:[email protected]
...
tenaciousd/www5.zombo.com:[email protected]
Por último, ¿qué tal tener una sola entidad de servicio, lo que parece más sencillo pero se hace con menos frecuencia?
[email protected]
Si es importante, el servicio Kerberizado (y los clientes) usan Cyrus SASL, GNU GSSAPI y MIT Kerberos 5. La API SASL toma un parámetro de "nombre de dominio completo" además del nombre del servicio, pero sospecho que es porque admite más que solo Kerberos, y probablemente podríamos pasar otras cosas además de los FQDN reales.
La mayor parte de la documentación que he encontrado supone que cada servicio se ejecuta en un único host en un dominio, o al menos que a los clientes les importa profundamente a qué instancia de servicio se conectan. En mi caso, todos los servicios son prácticamente iguales desde la perspectiva del cliente, entonces, ¿cuál sería la mejor práctica aquí?
Respuesta1
Para cosas que no son únicas (es decir, servicios replicados que realizan exactamente las mismas tareas), normalmente comparto un servidor principal común. Esto funciona bien si entidades externas ven el mismo nombre de dominio, por ejemplo, ya que mantiene esa ilusión.
También significa que si un usuario cambia de la instancia 1 a la instancia 49, no tendrá que realizar otro protocolo de enlace de Kerberos, ya que ya tiene un ticket válido y funcional. Utilizarán ese ticket para autenticarse en cualquiera de las instancias sin necesidad de buscar uno nuevo por instancia.
Por lo tanto, usaría:
tenaciousd/[email protected]
como su nombre principal para este servicio, suponiendo que www.example.com es la forma en que los clientes abordan este servicio.