Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Samba] Samba 4 krb5.keytab confusion

111 views
Skip to first unread message

steve

unread,
Jan 8, 2012, 4:20:02 AM1/8/12
to
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/H...@HH3.HH1.SITE
2 host/H...@HH3.HH1.SITE
2 host/H...@HH3.HH1.SITE
2 host/hh3.hh3....@HH3.HH1.SITE
2 host/hh3.hh3....@HH3.HH1.SITE
2 host/hh3.hh3....@HH3.HH1.SITE
2 host/HH3.HH3....@HH3.HH1.SITE
2 host/HH3.HH3....@HH3.HH1.SITE
2 host/HH3.HH3....@HH3.HH1.SITE
2 host/HH3.hh3....@HH3.HH1.SITE
2 host/HH3.hh3....@HH3.HH1.SITE
2 host/HH3.hh3....@HH3.HH1.SITE
2 host/hh3.HH3....@HH3.HH1.SITE
2 host/hh3.HH3....@HH3.HH1.SITE
2 host/hh3.HH3....@HH3.HH1.SITE
2 host/h...@HH3.HH1.SITE
2 host/h...@HH3.HH1.SITE
2 host/h...@HH3.HH1.SITE
2 cifs/hh3.hh3....@HH3.HH1.SITE
2 cifs/hh3.hh3....@HH3.HH1.SITE
2 cifs/hh3.hh3....@HH3.HH1.SITE
2 cifs/HH3.HH3....@HH3.HH1.SITE
2 cifs/HH3.HH3....@HH3.HH1.SITE
2 cifs/HH3.HH3....@HH3.HH1.SITE
2 cifs/HH3.hh3....@HH3.HH1.SITE
2 cifs/HH3.hh3....@HH3.HH1.SITE
2 cifs/HH3.hh3....@HH3.HH1.SITE
2 cifs/hh3.HH3....@HH3.HH1.SITE
2 cifs/hh3.HH3....@HH3.HH1.SITE
2 cifs/hh3.HH3....@HH3.HH1.SITE
2 HH3$@HH3.SITE
2 HH3$@HH3.SITE
2 HH3$@HH3.SITE
2 host/H...@HH3.SITE
2 host/H...@HH3.SITE
2 host/H...@HH3.SITE
2 host/hh3.hh...@HH3.SITE
2 host/hh3.hh...@HH3.SITE
2 host/hh3.hh...@HH3.SITE
2 host/HH3.HH...@HH3.SITE
2 host/HH3.HH...@HH3.SITE
2 host/HH3.HH...@HH3.SITE
2 host/HH3.hh...@HH3.SITE
2 host/HH3.hh...@HH3.SITE
2 host/HH3.hh...@HH3.SITE
2 host/hh3.HH...@HH3.SITE
2 host/hh3.HH...@HH3.SITE
2 host/hh3.HH...@HH3.SITE
2 host/h...@HH3.SITE
2 host/h...@HH3.SITE
2 host/h...@HH3.SITE
2 cifs/hh3.hh...@HH3.SITE
2 cifs/hh3.hh...@HH3.SITE
2 cifs/hh3.hh...@HH3.SITE
2 cifs/HH3.HH...@HH3.SITE
2 cifs/HH3.HH...@HH3.SITE
2 cifs/HH3.HH...@HH3.SITE
2 cifs/HH3.hh...@HH3.SITE
2 cifs/HH3.hh...@HH3.SITE
2 cifs/HH3.hh...@HH3.SITE
2 cifs/hh3.HH...@HH3.SITE
2 cifs/hh3.HH...@HH3.SITE
2 cifs/hh3.HH...@HH3.SITE
1 ste...@HH3.SITE
1 ste...@HH3.SITE
1 ste...@HH3.SITE
2 ste...@HH3.SITE
2 ste...@HH3.SITE
2 ste...@HH3.SITE
1 ly...@HH3.SITE
1 ly...@HH3.SITE
1 ly...@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 ste...@HH3.SITE from ipv4:192.168.1.2:46577 for
host/steve-pc...@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....@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....@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?

Thanks
Steve.





--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Gémes Géza

unread,
Jan 9, 2012, 1:40:02 AM1/9/12
to
Hi,

/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

steve

unread,
Jan 9, 2012, 3:10:01 AM1/9/12
to
>> /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.

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

for nfs I did this:
samba-tool spn add nfs/HH3.SITE Administrator
samba-tool domain exportkeytab /etc/krb5.keytab --principal=nfs/HH3.SITE

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.
Thanks for your patience.
Steve

Gémes Géza

unread,
Jan 9, 2012, 3:50:03 AM1/9/12
to
Hi,

Comments in-line:
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

steve

unread,
Jan 9, 2012, 5:40:01 AM1/9/12
to
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

Michael Wood

unread,
Jan 9, 2012, 6:00:03 AM1/9/12
to
On 9 January 2012 12:34, steve <st...@steve-ss.com> wrote:
> On 01/09/2012 09:47 AM, Gémes Géza wrote:
[...]
>>> 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?

Don't bother trying to do that. Just create a new keytab file with
only the relevant stuff for NFS in it.

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

Try: samba-tool spn list ..., samba-tool spn delete ...

--
Michael Wood <esio...@gmail.com>

Michael Wood

unread,
Jan 9, 2012, 6:20:01 AM1/9/12
to
On 9 January 2012 12:56, steve <st...@steve-ss.com> wrote:
> On 01/09/2012 11:50 AM, Michael Wood wrote:
>>
>> On 9 January 2012 12:34, steve<st...@steve-ss.com>  wrote:
>>>
>>> On 01/09/2012 09:47 AM, Gémes Géza wrote:
>>
>> [...]
>>>>>
>>>>> 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?
>>
>> Don't bother trying to do that.  Just create a new keytab file with
>> only the relevant stuff for NFS in it.
>
> Hi
> Rename the keytab, touch /etc/krb5.keytab to start with a blank keytab and
> add only the nfs principal? What about all the other stuff about cifs and
> host that are in there. Are they not needed?

"samba-tool domain exportkeytab" creates a new keytab file, so no need
to create an empty file. i.e. you would not be "adding" only the NFS
principal. You would be creating a new keytab file with only the NFS
principal in it.

As for the other things in the keytab, I can't say off hand whether or
not you need them, but I suspect not.

Michael Wood

unread,
Jan 9, 2012, 8:00:02 AM1/9/12
to
On 9 January 2012 14:30, steve <st...@steve-ss.com> wrote:
> On 09/01/12 12:12, Michael Wood wrote:
>>
>> On 9 January 2012 12:56, steve<st...@steve-ss.com>  wrote:
[...]
>>> Hi
>>> Rename the keytab, touch /etc/krb5.keytab to start with a blank keytab
>>> and
>>> add only the nfs principal? What about all the other stuff about cifs and
>>> host that are in there. Are they not needed?
>>
>>
>> "samba-tool domain exportkeytab" creates a new keytab file, so no need
>> to create an empty file.  i.e. you would not be "adding" only the NFS
>> principal.  You would be creating a new keytab file with only the NFS
>> principal in it.
>>
>> As for the other things in the keytab, I can't say off hand whether or
>> not you need them, but I suspect not.
>
> Hi Michael
> I moved the old keytab just to be sure, made a user for nfs, as Geza
> suggested on list, recreated the keytab and added nfs to it:
>
> samba-tool user add nfs-service-account
> samba-tool spn add nfs nfs-service-account
>
> samba-tool domain exportkeytab /etc/krb5.keytab --principal=nfs/HH3.SITE
>
> I now have a brand new shiny keytab! Thanks so much for your help.

No problem.
0 new messages