[Samba] Samba 4 krb5.keytab confusion
Gémes Géza
geza at kzsdabas.hu
Mon Jan 9 01:47:04 MST 2012
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).
>
> 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.
> 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
More information about the samba
mailing list