SPN key kvno increasing once a week

[David Mansfield]

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.

>
>> 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.

> 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.
>

Thanks for your help. I will stew on this awhile.

David