SPN key kvno increasing once a week

[Simo]

On 05/21/2013 09:06 AM, David Mansfield wrote:
> On 05/20/2013 08:55 PM, Andrew Bartlett wrote:
>> On Mon, 2013-05-20 at 20:28 -0400, David Mansfield wrote:
>>> On 05/20/2013 07:08 PM, Andrew Bartlett wrote:
>>>> On Mon, 2013-05-20 at 13:57 -0400, David Mansfield wrote:
>>>>> Hi All:
>>>>>
>>>>> I have a number of samba3 and samba4 based winbind clients (centos 
>>>>> 6 and
>>>>> Fedora 18 respectively, BTW)  connecting to a compiled-by-hand 
>>>>> samba4 DC
>>>>> running on centos6. The exported keytab for an SPN we use for 
>>>>> apache is
>>>>> becoming invalid every week due to  a bump in the kvno for the SPN
>>>>> "HTTP/myhost.domain.com".  This also affects the
>>>>> "host/myhost.domain.com" SPN key and probably all of the SPN keys for
>>>>> that host.  I can see from google that this is not a "new" 
>>>>> problem, but
>>>>> nowhere is there a note of the resolution.
>>>>>
>>>>> The winbind operation is unaffected (and is probably causing this
>>>>> problem) - it's internal keytab must be getting refreshed (or it's 
>>>>> not
>>>>> using a keytab or something).
>>>>>
>>>>> I have not modified/set "kerberos method" in smb.conf from the 
>>>>> defaults,
>>>>> but I do have "winbind refresh tickets = true" on.
>>>>>
>>>>> Can anyone tell me:
>>>>>
>>>>> 1) why is kvno getting bumped every week, who is responsible 
>>>>> (client or
>>>>> server), can it be configured and/or disabled?
>>>>>
>>>>> 2) if I can't fix #1, can I force winbind to create multiple 
>>>>> keytabs all
>>>>> over my filesystem and be sure to chown and set selinux context 
>>>>> for me?
>>>>
>>>> It might be best to allocate these services that you want to use a
>>>> different keytab for their own principals.  If you are giving them
>>>> different levels of privilege on your server, then they each need a
>>>> different account, as otherwise one could compromise the other by
>>>> creation of fake tickets (because they all know the secret key).
>>>>
>>>
>>> (BTW, all the SPN are added to the machine account where the service is
>>> running, is that not normal procedure?)
>>
>> It is, as long as all the services you are protecting are of the same
>> privilege level.
>>
>>> Yes, that's what I have: the HTTP/myhost.domain.com goes in
>>> /etc/httpd/conf/krb5.keytab (owned by apache), the imap/host.domain.com
>>> goes in /etc/krb5.keytab.cyrus (owned by cyrus), the
>>> smtp/myhost.domain.com goes in /etc/postfix/krb5.keytab (owned by
>>> postfix).  And all of them become invalid the moment winbind changes 
>>> the
>>> machine password.
>>
>> Indeed.
>>
>>> I've researched a bit more and discovered that #1 is definitely a
>>> winbind client changing the password issue.  But I don't understand why
>>> (not a kerb. guru) changing the password causes all the SPN keys
>>> regenerated, but it's probably a standard thing.
>>
>> It is - there is no such thing as SPN keys, they all share the same key,
>> that is the domain member account password that winbind is changing.
>
> I didn't realize that all SPN principal's keys generated from the same 
> account basically share the same private key, so a compromised keytab 
> exported with just one service principal compromises the account that 
> it is associated to.  Somehow I thought that the point of a service 
> principal was that it limited exposure to the service which it is used 
> for. That's a bummer.

In Microsoft's implementation they decided to share keys.
Other Kerberos implementations generally do not.
Unfortunately Microsoft clients sometimes depend on this now (for 
example they assume host/ machine$ and cifs/ SPNs to be all 
interchangeable).

You could look at gssproxy to do privilege separation, unfortunately it 
is not usable by all applications yet, as some violate the gssapi model 
by performing thir own krb5 calls before hands.
It should work with any app that uses SASL/GSSAPI though.

>>
>>> So I'm left with either stopping winbind from changing the machine
>>> password or figuring out a keytab distribution system...  Yuk.
>>
>> Or pointing all the services at the same keytab.  My point is that if
>> this is not desired (because you want privilege separation on your
>> system, quite reasonably) that you actually need to have a different
>> account per service, as otherwise they are equivalent to each other.
>>
>
> Ok.  Now I understand the crux of your point.  If I have, e.g. two 
> imap instances on two hosts (say load balancing or whatever) it 
> probably makes more sense to create 'imap' user in AD, create two SPN 
> from that, one for each host, rather than create each from the machine 
> account associated to the host they run on - i.e. do it by 
> service-account not by host-account.

This is a good way to do it, yes.

>> Sadly kerberos is a private-key based system, not a public-key based
>> system, so any service that has access to decrypt incoming tickets can
>> also encrypt a new fake ticket in any name, real or imagined, including
>> (say) root or a privileged user.
>>

FWIW, nothing sad about kerberos being a shared key system, there are 
advantages and disadvantages with public key systems as well.

Simo.