I noticed this today while struggling to setup SSO on my Active Directory domain. Windows allows you to use setspn to create a Service principal without mapping it to a specific user account. This is normal operations for a Kerberos installation – if you review the Kerberos Protocol, there is no reason for the actual service principal to communicate directly with the KDC – it merely has to decode a valid looking ticket from the client to prove the client is who he says he is. In AD, if you don’t bother mapping a princ to a user account, you can’t actually get a TGT with that princ, only a TGS for it. If during the authentication process the service principal requests a TGT from the KDC, and refuses login to the client if it is unable to obtain one.
The only reason I can think that SSO is requiring the TGT is if is attempting to perform its own authorization – utilizing the TGT to get a TGS for the AD LDAP server to perform a GSSAPI login to it. However, this seems counter-intuitive, as authorization is handled by the LDAP directory, configured with a binddn elsewhere in Openfire, no?
If authorization HAS to be performed by the service via GSSAPI, could one specify seperate service and host princs for the purposes of service authentication and authorization?