[PATCH] Fix salt principal generation for keytabs

[Simo]

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 ?

Simo.