Bug 12247 - Samba4 DC returns Kerberos TGTs for service principals
Samba4 DC returns Kerberos TGTs for service principals
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
All All
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2016-09-08 12:59 UTC by Daniel Kobras
Modified: 2016-09-08 17:39 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Kobras 2016-09-08 12:59:08 UTC
When requesting a Kerberos TGT for a service principal, the behaviour of a Samba4 DC differs from Active Directory. While usually not a problem in normal circumstances, it impedes debugging and may occasionally confuse services (like eg. rpc.gssd) that check for working user principals by requesting a TGT.

I've verified that this behaviour is present in current git master, but also noticed it on installations running Samba 4.4.x.

Assume someservice/somehost is a servicePrincipalName listed in somehost's machine account, and has a valid entry in /etc/krb5.keytab, then

* with Active Directory, requesting a TGT fails right away:

# kinit -k someservice/somehost
kinit: Client 'someservice/somehost@ADS.EXAMPLE.COM' not found in Kerberos database while getting initial credentials

The SPN is present and valid, as we can check with:

# kinit -k 'SOMEHOST$'                
# kvno -k /etc/krb5.keytab someservice/somehost
someservice/somehost@ADS.EXAMPLE.COM: kvno = 23, keytab entry valid

* with Samba4, the requested TGT is issued, but later on, it cannot be used to obtain any service tickets:

# kinit -k someservice/somehost
# kvno -k /etc/krb5.keytab someservice/somehost
kvno: Client not found in Kerberos database while getting credentials for someservice/somehost@SAMBA4.EXAMPLE.COM

Checking again that the SPN is present and valid:

# kinit -k 'SOMEHOST$'
# kvno -k /etc/krb5.keytab someservice/somehost
someservice/somehost@SAMBA4.EXAMPLE.COM: kvno = 42, keytab entry valid