[Samba] Samba 4 krb5.keytab confusion

steve steve at steve-ss.com
Mon Jan 9 03:34:23 MST 2012


On 01/09/2012 09:47 AM, Gémes Géza wrote:
> Hi,
>
> Comments in-line:
>> On 01/09/2012 07:38 AM, Gémes Géza wrote:
>>> 2012-01-08 10:13 keltezéssel, steve írta:
>>>> Hi
>>>> I have Samba 4 installed and working. I recently changed FQDN to dns
>>>> name hh3.hh3.site. It works OK and e.g. on a windows 7 box which
>>>> joined the domain, users can logon. But I have a mess in the keytab:
>>>>
>>>> klist -k /etc/krb5.keytab
>>>> Keytab name: WRFILE:/etc/krb5.keytab
>>>> KVNO Principal
>>>> ----
>>>> -------------------------------------------------------------------------- 
>>>>
>>>>     2 HH3$@HH3.HH1.SITE
>>>>     2 HH3$@HH3.HH1.SITE
>>>>     2 HH3$@HH3.HH1.SITE
>>>>     2 host/HH3 at HH3.HH1.SITE
>>>>     2 host/HH3 at HH3.HH1.SITE
>>>>     2 host/HH3 at HH3.HH1.SITE
>>>>     2 host/hh3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 host/hh3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 host/hh3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 host/HH3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 host/HH3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 host/HH3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 host/HH3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 host/HH3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 host/HH3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 host/hh3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 host/hh3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 host/hh3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 host/hh3 at HH3.HH1.SITE
>>>>     2 host/hh3 at HH3.HH1.SITE
>>>>     2 host/hh3 at HH3.HH1.SITE
>>>>     2 cifs/hh3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 cifs/hh3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 cifs/hh3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 cifs/HH3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 cifs/HH3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 cifs/HH3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 cifs/HH3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 cifs/HH3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 cifs/HH3.hh3.hh1.site at HH3.HH1.SITE
>>>>     2 cifs/hh3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 cifs/hh3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 cifs/hh3.HH3.HH1.SITE at HH3.HH1.SITE
>>>>     2 HH3$@HH3.SITE
>>>>     2 HH3$@HH3.SITE
>>>>     2 HH3$@HH3.SITE
>>>>     2 host/HH3 at HH3.SITE
>>>>     2 host/HH3 at HH3.SITE
>>>>     2 host/HH3 at HH3.SITE
>>>>     2 host/hh3.hh3.site at HH3.SITE
>>>>     2 host/hh3.hh3.site at HH3.SITE
>>>>     2 host/hh3.hh3.site at HH3.SITE
>>>>     2 host/HH3.HH3.SITE at HH3.SITE
>>>>     2 host/HH3.HH3.SITE at HH3.SITE
>>>>     2 host/HH3.HH3.SITE at HH3.SITE
>>>>     2 host/HH3.hh3.site at HH3.SITE
>>>>     2 host/HH3.hh3.site at HH3.SITE
>>>>     2 host/HH3.hh3.site at HH3.SITE
>>>>     2 host/hh3.HH3.SITE at HH3.SITE
>>>>     2 host/hh3.HH3.SITE at HH3.SITE
>>>>     2 host/hh3.HH3.SITE at HH3.SITE
>>>>     2 host/hh3 at HH3.SITE
>>>>     2 host/hh3 at HH3.SITE
>>>>     2 host/hh3 at HH3.SITE
>>>>     2 cifs/hh3.hh3.site at HH3.SITE
>>>>     2 cifs/hh3.hh3.site at HH3.SITE
>>>>     2 cifs/hh3.hh3.site at HH3.SITE
>>>>     2 cifs/HH3.HH3.SITE at HH3.SITE
>>>>     2 cifs/HH3.HH3.SITE at HH3.SITE
>>>>     2 cifs/HH3.HH3.SITE at HH3.SITE
>>>>     2 cifs/HH3.hh3.site at HH3.SITE
>>>>     2 cifs/HH3.hh3.site at HH3.SITE
>>>>     2 cifs/HH3.hh3.site at HH3.SITE
>>>>     2 cifs/hh3.HH3.SITE at HH3.SITE
>>>>     2 cifs/hh3.HH3.SITE at HH3.SITE
>>>>     2 cifs/hh3.HH3.SITE at HH3.SITE
>>>>     1 steve4 at HH3.SITE
>>>>     1 steve4 at HH3.SITE
>>>>     1 steve4 at HH3.SITE
>>>>     2 steve5 at HH3.SITE
>>>>     2 steve5 at HH3.SITE
>>>>     2 steve5 at HH3.SITE
>>>>     1 lynn2 at HH3.SITE
>>>>     1 lynn2 at HH3.SITE
>>>>     1 lynn2 at HH3.SITE
>>>>
>>>> This all seems OK:
>>>>
>>>> Kerberos: TGS-REQ steve-pc$@HH3.SITE from ipv4:192.168.1.2:46585 for
>>>> STEVE-PC$@HH3.SITE [canonicalize, renewable, forwardable]
>>>> Kerberos: TGS-REQ authtime: 2012-01-08T09:35:01 starttime:
>>>> 2012-01-08T09:35:16 endtime: 2012-01-08T19:35:01 renew till:
>>>> 2012-01-15T09:35:01
>>>>
>>>> Kerberos: TGS-REQ steve4 at HH3.SITE from ipv4:192.168.1.2:46577 for
>>>> host/steve-pc.hh3.site at HH3.SITE [canonicalize, renewable, forwardable]
>>>> Kerberos: TGS-REQ authtime: 2012-01-08T09:35:06 starttime:
>>>> 2012-01-08T09:35:06 endtime: 2012-01-08T19:35:06 renew till:
>>>> 2012-01-15T09:35:06
>>>>
>>>> Got user=[] domain=[] workstation=[STEVE-PC] len1=1 len2=0
>>>> auth_check_password_send: Checking password for unmapped user
>>>> []\[]@[STEVE-PC]
>>>> auth_check_password_send: mapped user is: [CACTUS]\[]@[STEVE-PC]
>>>>
>>>>
>>>> But I also get this:
>>>>
>>>> Kerberos: TGS-REQ steve-pc$@HH3.SITE from ipv4:192.168.1.2:46588 for
>>>> steve-pc$\@HH3.SITE at HH3.SITE [canonicalize, request-anonymous,
>>>> renewable, forwardable]
>>>> Kerberos: Bad request for constrained delegation
>>>> Kerberos: constrained delegation from steve-pc$@HH3.SITE
>>>> (steve-pc$@HH3.SITE) as steve-pc$@HH3.SITE to
>>>> steve-pc$\@HH3.SITE at HH3.SITE not allowed
>>>> Kerberos: Failed building TGS-REP to ipv4:192.168.1.2:46588
>>>>
>>>> Which I think is due to the keytab
>>>>
>>>> smb.conf contains:
>>>>
>>>> [global]
>>>>      server role = domain controller
>>>>      workgroup = CACTUS
>>>>      realm = hh3.site
>>>>      netbios name = HH3
>>>>      passdb backend = samba4
>>>>      template shell = /bin/bash
>>>>
>>>> So, 2 very newbie questions:
>>>>
>>>> 1. Is there anyway I can tidy up the keytab to see if removes that 
>>>> error?
>>>> 2. In the above example, steve-pc is a windows 7 client which is
>>>> joined to the domain called CACTUS. Why doesn't steve-pc$ appear in
>>>> the keytab listing?
>>>>
>>>>
>>>> /etc/krb5.keytab is a keytab you've created (e.g. with samba-tool 
>>>> domain
>>>> exportkeytab /etc/krb5.keytab) it is not used by Samba4 in any way. If
>>>> you need a keytab for any service you run (e.g. nfs) I would 
>>>> suggest to
>>>> extract a keytab only for the principal you've created for that 
>>>> service.
>>>> E.g.:
>>>>
>>>> samba-tool user create whateverserviceusername --random-password
>>>> samba-tool spn add previouslyusedusername servicename/hostname
>>>> samba-tool domain exportkeytab --principal=servicename/hostname
>>>> /path/to/the/keytab
>>>>
>>>> Regards
>>>>
>>>> Geza
>> Yeah, I can see I've not understood this. If I create a Samba 4 user 
>> using samba-tool, he has to have a keytab to be able to login on a 
>> Linux client.
>>
> NO NO NO
> You need a keytab for service accounts (e.g. nfs) not for normal user 
> accounts (e.g. steve4), except when you need to run something 
> non-interactively (e.g. from crontab) which need access to a 
> kerberized service.
>> For user steve4 on domain HH3.SITE I did this:
>>
>> samba-tool user add steve4
>> (the spn stuff you mention doesn't seem to be needed?)
>> samba-tool domain exportkeytab /etc/krb5.keytab --principal=steve4
> You don't need the last step (see before).

OK, I'm understanding this a little more. So how can I remove steve4 
from the keytab?

>> for nfs I did this:
>> samba-tool spn add nfs/HH3.SITE Administrator
>> samba-tool domain exportkeytab /etc/krb5.keytab --principal=nfs/HH3.SITE
>>
> That (the spn stuff) would work but it is BAD PRACTICE (it contradicts 
> the least privilege principle) you shouldn't give your nfs server the 
> right to administer your whole domain. You should create an account 
> for nfs (e.g. nfs-service-account or whatever) and for any kerberized 
> service/host  in your domain. I now it is more work, but security-wise 
> that is the right solution.

I can see your point. So I do:
samba-tool user add nfs-service-account
samba-tool spn add nfs/HH3.SITE nfs-service account
samba-tool domain exportkeytab /etc/krb5.keytab --principal=nfs/HH3.SITE

But it's going to tell me that the nfs is already there no? So the 
question is, how do I remove the nfs principal I created before as 
Administrator?
>> steve4 can login to the Linux client and is placed in his nfs4 
>> mounted /home directory (applause!). (The keytab  above was before I 
>> added nfs)
>>
>> What I don't understand is why I need the keytab at all and how the 
>> other stuff got in there.
> Previously explained.
>
> Just some side-notes:
> Currently at our network we use OpenLDAP backed Samba3 servers (for 
> Windows domain control) with (the same) OpenLDAP backed Heimdal KDC, 
> for the various kerberized services (password protected webpages, 
> databases, OpenAFS, etc.). The Linux clients authenticate with 
> kerberos, get account from ldap. In the test network I've set up for 
> Samba4 I could reproduce the same with some different settings. The 
> important thing is: don't give services access to accounts with 
> sensitive rights! They don't need it.
>> Thanks for your patience.
>> Steve
>>
> Best Regards
>
> Geza
Thanks Geza. I'm nearly there. The two questions above would be really 
helpful.
Steve


More information about the samba mailing list