¿En qué circunstancias obtendré tickets de servicio aparentemente válidos que son duplicados y que no tienen un reino asociado? Es decir, ¿esto indica una configuración incorrecta en alguna parte? ¿Representa una capacidad u oportunidad interesante? ... una ineficiencia o una vulnerabilidad?
Por ejemplo, si kinitobtengo con éxito mi TGT, SSH en un host kerberizado, luego ejecuto klist, veo esta salida (desinfectada):
Ticket cache: KCM:503
Default principal: neirbowj@EXAMPLE.COM
Valid starting Expires Service principal
01/24/2016 18:17:40 01/25/2016 04:17:40 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 01/25/2016 18:17:33
01/24/2016 18:17:45 01/25/2016 04:17:40 host/foo.example.com@
renew until 01/25/2016 18:17:33
01/24/2016 18:17:45 01/25/2016 04:17:40 host/foo.example.com@EXAMPLE.COM
renew until 01/25/2016 18:17:33
¿Qué significa que tengo ambos host/foo.example.com@y host/foo.example.com@EXAMPLE.COMboletos de servicio?
Estoy ejecutando OS X Yosemite 10.10.5 y estoy usando el puerto kerberos5 1.13.2_2 y el puerto openssh 7.1p2_0 + kerberos5 + ldns + xauth de MacPorts 2.3.4. Mi (desinfectado) /etc/krb5.conftiene:
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
admin_server = kerberos.example.com
}