question about service principals (samba4)

[Aaron Solochek]

On 09/22/2010 07:25 PM, Andrew Bartlett wrote:
> 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.

Those already exist, but I'm not able to see them when I do a keytab dump.  My
real issue is that I need a keytab with host/foo and nfs/foo keys in it.  so far
the only keys I've been able to get are FOO$ principals.


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

Something is broken for me then.  If I 'kinit FOO$' I get a password error
(since it's a randomly generated key), but if I 'kinit host/foo' I get the error
that host/foo at REALM is not found in the database.


>> 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
> 
> 
> 
> !DSPAM:4c9a907e298001491728689!