[Samba] Samba 4 and GSSAPI kerberos ldap connect

[steve]

On 20/01/12 18:19, steve wrote:
> On 01/20/2012 04:09 PM, Michael Wood wrote:
>> On 20 January 2012 15:23, steve<steve at steve-ss.com>  wrote:
>>> On 20/01/12 12:41, Michael Wood wrote:
>> [...]
>>> I did this:
>>>
>>>   samba-tool user add nslcd-service
>>> New Password:
>>> User 'nslcd-service' created successfully
>>> kinit nslcd-service
>>> Password for nslcd-service at SITE:
>>> Warning: Your password will expire in 41 days on Fri Mar  2 13:47:22 
>>> 2012
>>> hh3:/tmp # chown nslcd-user:nslcd-user krb5cc_0
>>>   rcnslcd restart
>>> redirecting to systemctl
>>> hh3:/tmp # getent passwd steve2
>>>
>>> steve2:x:3000000:100:steve2:/home/CACTUS/steve2:/bin/bash
>>>
>>> Seems to work OK.
>> OK.
>>
>>> I know I should use a keytab, then presumably I'd not need to keep
>>> refreshing the ticket using k5start. I really would like like to 
>>> find out
>>> how to do that.
>> I'm starting to think that maybe a keytab is not the answer and
>> k5start is.  Maybe someone that knows more about Kerberos will
>> enlighten us, but it might make more sense to ask the question on a
>> Kerberos mailing list/forum.
>>
>>> I've tried before. Thinking out loud, maybe this:
>>>
>>> with getent passwd, samba gives this:
>>> ldb_wrap open of secrets.ldb
>>> Kerberos: TGS-REQ nslcd-service at SITE from ipv4:192.168.1.3:50765 for
>>> ldap/hh3.site at SITE [canonicalize, renewable]
>>>
>>> I tried removing /tmp/krbcc_0 and doing this:
>>>
>>> hh3:/tmp # samba tool spn add ldap/hh3.site nslcd-service
>>>
>>> hh3:/tmp # samba-tool domain exportkeytab /etc/ldap.keytab
>>> --principal=ldap/hh3.site
>>> hh3:/tmp # chown nslcd-user:nslcd-user /etc/ldap.keytab
>>>
>>> But:
>>> Jan 20 14:16:15 hh3 nslcd[3575]: GSSAPI Error: Unspecified GSS failure.
>>>   Minor code may provide more information (Credentials cache file
>>> '/tmp/krb5cc_0' not found)
>>>
>>> So the next qn. would be how do I tell nslcd to look in the keytab 
>>> rather
>>> than the cache file?
>> I don't know.  Maybe it can't use a keytab.  Perhaps the nslcd
>> developers could clarify this?
>>
>>> Or maybe go the k5start way. Don't know!
>> Since the ticket cache works, I think k5start should work too, but
>> I've not tried it myself.
>>
>>>>> Next stage: getting nslcd-user to be able to read the ticket and 
>>>>> keep the
>>>>> ticket up to date.
>>>> Well, /tmp/krb5cc_0 is root's ticket cache.  Since you're running
>>>> nslcd as "nslcd-user", that's not the ticket cache you should be
>>>> using.
>>> Actually, kinit nslcd-service produced a file with the same name.
>> That's because you were logged in as root when you ran kinit.  That's
>> what I meant when I said it was "root's ticket cache".
>>
> This seems to be better:
> Extracted the keytab using samba-tool spn and k5start'ed from it:
> k5start -v -f /etc/nslcd.keytab -U -o nslcd-user -K 360 -k /tmp/krb5cc_0
>
> -v verbose
> -f use keytab, not password
> -o the user the file should be chown'ed to
> -U Use the first principal in the keytab as the client principal
> -K run as daemon <minutes between ticket updates>
> -k name of ticket cache
>
> The alternative would be:
> k5start -v -u nslcd-service -U -o nslcd-user -K 360 -k /tmp/krb5cc_0
> -u the user who needs to get the ticket
> But this prompts for a password. I suppose the power of the keytab is 
> the kerberos magic that does it for you.
>
> Next episode:
> How to create the keytab on a Linux client without samba-tool installed.
> Cheers,
> Steve
However, this only works if the realm is NOT the dns name.
This is with:
realm=site
  rather than
  realm=hh3.site
and the kerberized bind to the ldap works but nothing else on the 
network. e.g. you cannot join machines to the domain because dns does 
not find the realm. Is it a rule that the Kerberos realm has to be the 
same as the dns name?

Back provisioning with realm=hh3.site (the fqdn), dns is working again 
and I can join boxes to the domain again BUT the kerberized bind will 
not work anymore and I'm back to:

ldb_wrap open of secrets.ldb
Kerberos: TGS-REQ Administrator at HH3.SITE from ipv4:192.168.1.3:48616 for 
ldap/hh3.site at HH3.SITE [canonicalize, renewable]
Kerberos: TGS-REQ authtime: 2012-01-20T07:48:01 starttime: 
2012-01-20T07:53:37 endtime: 2012-01-20T17:48:01 renew till: 
2012-01-21T07:47:56
GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see 
text): Decrypt integrity check failed

even though I've made a ldap/hh3.site principal:
hh3:/tmp # samba-tool spn add ldap/hh3.site Administrator
hh3:/tmp # samba-tool domain exportkeytab /etc/ldap.keytab 
--principal=ldap/hh3.site

Why do I get the
Decrypt integrity check failed
error?

(I can still connect un-kerberized by simply specifying the binddn and 
bindpw in /etc/nslcd.conf)
Cheers,
Steve