question about service principals (samba4)

Andrew Bartlett abartlet at
Wed Sep 22 17:25:47 MDT 2010

On Wed, 2010-09-22 at 13:53 -0400, Aaron Solochek wrote:
> On 09/21/2010 07:39 PM, Andrew Bartlett wrote:
> > On Tue, 2010-09-21 at 16:58 -0400, Aaron Solochek wrote:
> >> I can see in ldap that computer objects have service principals associated with
> >> them, however, I can't seem to use them.
> >>
> >> I did a dump of the keys on the server with a net export keytab, and it didn't
> >> populate that keytab with the service principals as I'd hoped.  Thinking that
> >> the service principals might be aliases for the actual machine account
> >> principal, I tried renaming the key FOO$ to host/foo in that keytab and then
> >> tried authenticating with it, but it told me host/foo was not found in the
> >> database.
> >>
> >> My past experience with kerberos is all with heimdal and MIT krb, so I don't
> >> know in what ways I should expect things to be different with windows or samba
> >> KDC, but I do assume there is some way to get host/foo and nfs/foo keys so I can
> >> start deploying some kerberized services.  I was hoping the servicePrincipalName
> >> entries did some sort of magic for me, but failing that, I suppose I need to
> >> create completely separate accounts for each service principal I want.
> >>
> >> Also, what is the canonical way to extract a keytab containing only keys I
> >> specify?  
> > 
> > I hope to add extensions to our keytab management code to automatically
> > populate a keytab soon.  My idea is to allow servicePrincipalName to be
> > specified in the secrets.ldb entries. 
> > 
> But what about the service principals in the kdc?  Right now it seems that the
> kdc is not aware of them.  

You need to add servicePrincipalName entries on the records of the
account you wish to have these alases for. 

> Are they eventually going to be automatically
> generated based on the servicePrincipalNames on demand or something similar so
> they don't actually exist as individual objects in ldap?

host/dnsname is automatically generated, as is cifs/ and a number of
other entries.  ldap/ and others need to be added - when we are a DC, we
add those based a template file.  This file can be expanded if required
(it takes substitutions so that it follows DNS hostname updates)

>   Is my best temporary
> fix to manually create service principal 'computer' accounts, or will that cause
> me headaches later?

It depends exactly what you are trying to do.  If you duplicate the
host/ name, then it will cause problems, yes. 

> >> And related to that, will samba4 ever support a kadmin interface,
> >> because that would be awesome.
> > 
> > We could, quite easily actually, but I've avoided doing so.  It would
> > tie us to our current choice of Kerberos implementation in a way that is
> > exposed to our users.  If there is a real desire, then I'm willing to
> > allow it - it just means building a little more of Heimdal.
> > 
> > (The problem is that the kadmin tool and protocol is not the same
> > between MIT and Heimdal)
> > 
> Well, you could bundle the heimdal kadmin with samba4 too.  it will happily
> coexist on an MIT krb system if you rename it kadmin.samba or something.  The
> heimdal tools are better than the MIT ones anyway, imo.
It is more about what network protocols we choose to expose, as some
folks have a desire to build Samba4 against the MIT Kerberos libs, and
I've generally taken a position not to take actions that would so
explicitly prevent that.  Exposing different protocols dependent on our
build libraries is a step we may need to take, but as nobody has really
wanted kadmin so far, I've not done it yet.  Another option is that we
could expose the kadmin.local binary.

Andrew Bartlett
Andrew Bartlett                      
Authentication Developer, Samba Team 
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the samba-technical mailing list