[PATCH] Fix salt principal generation for keytabs

[Andrew Bartlett]

On Thu, 2015-04-16 at 08:33 -0400, Simo wrote:
> On Thu, 2015-04-16 at 14:25 +1200, Andrew Bartlett wrote:
> > On Wed, 2015-04-15 at 12:17 +0200, Andreas Schneider wrote:
> > > Hi,
> > > 
> > > I've run into an issue with MIT Kerberos that the keytab for bind dns used a 
> > > different salting principal as the KDC. So libkrb5 failed to decrypt tickets.
> > > 
> > > In source4/auth/kerberos/srv_keytab.c the function salt_principal generates a 
> > > principal in the form:
> > >     
> > >     host/<SAMAccountName-Without-$>.realm at REALM
> > >     
> > > This is correct for computer accounts, but user accounts like the
> > > account we use to create the dns keytab for.
> > >     
> > > Samba generates the following salt principals on startup:
> > >     
> > > setup_kerberos_keys: principal Administrator at CHGDCPASSWORD.SAMBA.EXAMPLE.COM
> > > setup_kerberos_keys: principal krbtgt at CHGDCPASSWORD.SAMBA.EXAMPLE.COM
> > > setup_kerberos_keys: host principal 
> > > chgdcpass.chgdcpassword.samba.example.com at CHGDCPASSWORD.SAMBA.EXAMPLE.COM
> > > setup_kerberos_keys: principal dns-chgdcpass at CHGDCPASSWORD.SAMBA.EXAMPLE.COM
> > >     
> > > So the salt principal created for dns-chgdcpass was not correct.
> > > 
> > > The attached patch fixes it.
> > > 
> > > However the question is:
> > > 
> > > a) Should dns-chgdcpass be a computer account?
> > 
> > No, I don't think it should be.
> > 
> > >    See source4/setup/secrets_dns.ldif
> > 
> > Just to be clear, that is the secrets.ldb LDIF, not the sam.ldb ldif. I
> > presume you mean source4/setup/provision_dns_add_samba.ldif
> > 
> > > b) Why does it work with Heimdal with and without the patch? What magic does
> > >    Heimdal that the salt matches or does it ignore it?
> > 
> > Perhaps it is only using the arcfour-hmac-md5 key?  You should only be
> > exposing AES in certain, very limited circumstances (right functional
> > level, right supported enc types et). 
> > 
> > I would like to think that having this code in srv_keytab.c is not
> > correct at all - it belongs in whatever code fills in secrets.ldb.
> > 
> > So, to get around the upgrade issue, I think we need to use the
> > user at REALM salt by default, and remove all the code for the
> > samAccountName-without-$ case, and handling that in the code that sets
> > the entry in secrets.ldb (secretsdb_self_join()).  
> > 
> > That is, I don't think the patch is correct as is.
> \
> I am surprised you need a salt at all for a service keytab (which
> supposedly is a random key and not a password ?), why is that ?

In AD, everything is a password, and then the keys derive from that.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba