SPN key kvno increasing once a week

[David Mansfield]

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?

--
Thanks,
David Mansfield
Cobite, INC.

[Andrew Bartlett]

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

Andrew Bartlett

--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org

[David Mansfield]

(BTW, all the SPN are added to the machine account where the service is
running, is that not normal procedure?)


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.

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.

So I'm left with either stopping winbind from changing the machine
password or figuring out a keytab distribution system... Yuk.


> Andrew Bartlett
>

[Andrew Bartlett]

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.

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

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.

[Matthieu Patou]

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

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

> So I'm left with either stopping winbind from changing the machine
> password or figuring out a keytab distribution system... Yuk.
>

By default winbindd change the password when it's about to expire for
the account of the machine. Have you looked at the net commands to
generate the keytab out of the password of the machine account of Samba ?

Matthieu

--
Matthieu Patou
Samba Team
http://samba.org

[Denis Cardon]

Hi Mathieu,

could you elaborate on that one? I have the same issue as David. I had
some partial success with k5start (or krenew, I don't remember), but I
am not very happy with the solution.

The "net ads keytab add HTTP" works fine, but I get everything in the
same keytab file. And I'd like to use the machine account rather than
another generic one.

Thanks,

Denis


>
> Matthieu
>


--
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr

[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:
>>>>

> 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

[Simo]

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.