[PATCH] Fix salt principal generation for keytabs

[Andrew Bartlett]

On Thu, 2015-04-16 at 08:19 +0200, Andreas Schneider wrote:
> On Thursday 16 April 2015 14:25:16 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
> 
> No, the file I posted is the file which creates the dns account and the DNS 
> service principals. If you add another service principal in that file you will 
> find it in the dns.keytab ...

Sure, but that isn't where computer status is recorded, that is only
recorded in sam.ldb. 

> > > 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).
> 
> Ah ok, cause RC4 does not have a salt. MIT used DES so I run into the issue.
>  
> > 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.
> 
> Ok, that means we should use the salt from the database and not generate it.
> 
> The salt is part of the supplementalCredentials. We probably should get it 
> from there like samba_kdc_message2entry_keys() does.

Again, that is in sam.ldb, not secrets.ldb.

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