So finally here is the solution that works for me. If you have any
questions, just ask.
I use pam_mount with the following volume definition in the
"/etc/security/pam_mount.conf.xml":
<volume fstype="cifs" server="server"
path="home/%(USER)"
mountpoint="/home/%(USER)" sgrp="domain users"
options="sec=krb5,cruid=%(USERUID),uid=%(USERUID),gid=someLiteralGroupID,nosuid,nodev"
/>
But this wouldn't work initially, I got the
# mount error(126): Required key not available
However, once the respective user had logged in, I could use these
parameters for a manual mount as root:
# mount.cifs //server/home/userxyz /home/userxyz -o
sec=krb5,cruid=uid_of_userxyz,uid=uid_of_userxyz,gid=someGroupID
In another attempt, I could also hard code the "cruid=12345" for
pam_mount, and then log into the same machine twice. The second time the
home share was mounted correctly
So I figured, that PAM should do kerberos first. Therefore, I swapped
these two lines in the "/etc/pam.d/password-auth" (this is the
result):
session optional pam_krb5.so
session required pam_mount.so
Pam_mount can do password authentication, as well, but I don't need it.
So I commented this line out:
# auth required pam_mount.so
Now I was able to use this volume definition for pam_mount (but not the
one at the top):
<volume fstype="cifs" server="server"
path="home/%(USER)"
mountpoint="/home/%(USER)" sgrp="domain users"
options="sec=krb5,cruid=12345,uid=%(USERUID),gid=someLiteralGroupID,nosuid,nodev"
/>
Interestingly, the %(USERUID) worked for the "uid=..." option, but not
for "cruid=...". I tested this many times. So I figured that somehow
the
"cruid=..." use by pam_mount happens too early at a stage where this
request returns empty (or something else). To test this, I put the same
volume description _TWICE_ into the
"/etc/security/pam_mount.conf.xml".
And voilà: pam_mount works!
So as a temporary solution I have a dummy mount in the
pam_mount.conf.xml to make sure that the %(USERUID) variable is set
correctly when it is needed:
<volume fstype="cifs" server="server"
path="home/dummy"
mountpoint="/home/%(USER)" sgrp="domain users"
options="sec=krb5,cruid=%(USERUID),uid=%(USERUID),gid=someLiteralGroupID,nosuid,nodev"
/>
<volume fstype="cifs" server="server"
path="home/%(USER)"
mountpoint="/home/%(USER)" sgrp="domain users"
options="sec=krb5,cruid=%(USERUID),uid=%(USERUID),gid=someLiteralGroupID,nosuid,nodev"
/>
It's not beautiful, but it seems to work fine.
Ole
Am 04.11.2015 um 15:46 schrieb Davor Vusir:> Very interesting thread! Thank you all for sharing your thoughts and
knowledge.
>
> Regards
> Davor
>
> -- Skickat från mobilusken! --
>
>
> ----- Ursprungligt meddelande -----
> Från: "Ole Traupe" <ole.traupe at tu-berlin.de>
> Skickat: 2015-11-04 15:29
> Till: "samba at lists.samba.org" <samba at lists.samba.org>
> Ämne: Re: [Samba] Pam_mount not working with "sec=krb5"
>
>
>
> Am 04.11.2015 um 14:49 schrieb mathias dufresne:
>> 2015-11-04 13:58 GMT+01:00 Ole Traupe <ole.traupe at
tu-berlin.de>:
>>
>>> Mathias, thanks again! This sounds like a very reasonable approach.
I know
>>> that with remote ssh and public key authentication you can set the
limit to
>>> a single possible command. is this also possible with AD users?
>>>
>> I'm interested by the restriction to only one command for users.
The only I
>> see that possible is to place that only command in place of the shell
in
>> user declaration.
>>
>> Now to answer to question, AD from Linux systems point of view is a
>> database in which Linux systems can get users information to create
system
>> users (using tools as winbind or sssd...). These tools generate system
>> users using information from AD.
>> The point here is there is no difference between system users (from
>> /etc/passwd) and system users (from AD). They both are system users,
they
>> must react identically. Modulo the fact as they are AD users AD can
give
>> them access to AD resources. But once you removed the access to AD
>> resources, system users are system users, coming from AD or not :)
>>
>>
>>> Unfortunately, I don't have 'multiuser' support in my
current cifs-utils
>>> version 4.8. So I would end up with your designated user being the
owner of
>>> all the files and folders created by my AD users. Because he is the
one
>>> having mounted the resource.
>> Unfortunately I can't help you more on that as I have no knowledge
about
>> CIFS + Kerberos or NFS + Kerberos.
>> I spoke about NFS + Kerberos because it seems you want to mount users
home
>> directories on Linux boxes when these home directories are hosted by
>> another Linux box. File sharing between Linux can be performed through
NFS
>> and NFS also supports Kerberos.
> Mathias, thank you for your extensive thoughts. I will have a thorough
> look at it!
>
> However, I have two objections at first glance:
> a) if you remove AD access for an AD user, this user can't mount samba
> shares, because he won't get authenticated correctly (on the Samba file
> server sharing the homes), no?
> b) if you use NFS, and I tried that, and a user creates subfolders and
> files in his nfs-mounted home share, these subcontainers won't have the
> correctly inherited Windows ACLs (ergo problems with these shares when
> accessing them from Windows AD clients)
>
>
>> As I said, I have no knowledge at all on that subject so I can't do
more
>> than that...
>>
>> Best regards,
>>
>> mathias
>>
>>
>>
>>> Am 04.11.2015 um 13:36 schrieb mathias dufresne:
>>>
>>>> First please note the following is not really linked to your
NFS question,
>>>> it's more related to automation, credentials everywhere and
how to secure
>>>> them a little bit.
>>>>
>>>> The point dealing with keytab or credentials in general when
used for
>>>> automation, as these credentials can potentially used by some
attacker, is
>>>> to create dedicated user which can perform only what it is
supposed to
>>>> perform.
>>>>
>>>> To say that differently, now I'm using Samba test platform
and the keytab
>>>> I
>>>> use contains MY.DOMAIN\administrator credentials. This account
is member
>>>> of
>>>> "domain admins" group so it can do almost everything
and so using that
>>>> user
>>>> for automation is potentially dangerous. If someone get that
keytab, it
>>>> can
>>>> authenticate against my test AD and perform everything he wants
to.
>>>> I should create one user for (almost) each action which
requires
>>>> credentials, creating users which can perform only one action,
the action
>>>> they would perform.
>>>>
>>>> So in your case you need one user able to mount shares. Create
a user
>>>> which
>>>> can do that and apply on that user restrictions for he can
perform only
>>>> that. Then if some attacker get the keytab of that user, this
attacker
>>>> will
>>>> be able to mount shares, nothing else.
>>>>
>>>> Having users passwords wandering everywhere is not a real issue
finally,
>>>> when these users are well configured.
>>>>
>>>> 2015-11-04 12:33 GMT+01:00 Ole Traupe <ole.traupe at
tu-berlin.de>:
>>>>
>>>>
>>>>> If by "key" you meant keytab then you were right.
A keytab is a file
>>>>>> dedicated to contains credentials
(https://kb.iu.edu/d/aumh or
>>>>>>
http://web.mit.edu/Kerberos/krb5-1.12/doc/basic/keytab_def.html).
>>>>>>
>>>>>> Keytab are used when you want to automate actions which
need
>>>>>> authentication. When some automated action requires
credentials you
>>>>>> have to
>>>>>> provide these credentials so some where you will need a
couple
>>>>>> user/password. Without keytab you would need a clear
text password, or a
>>>>>> hashed one if it is possible. With a keytab you have
encrypted
>>>>>> credentials
>>>>>> which not worst than clear text.
>>>>>>
>>>>>> Of course it is a security hole: someone can use that
keytab to
>>>>>> authenticate. Today, next week... until contained
credentials are valid.
>>>>>> The point, for me, is this hole does not comes from the
keytab but from
>>>>>> automation which needs credentials stored somewhere.
>>>>>>
>>>>>> Mathias, thank you for making the purpose and
functioning of the keytab
>>>>> clearer for me!
>>>>>
>>>>> I think it is possible to have automation without storing
credentials.
>>>>> That is what kerberos authentication is for.
>>>>>
>>>>> Before compiling a more recent version of cifs-utils to get
the
>>>>> 'multiuser' option, I tested this
'sec=krb5' option more thoroughly. If
>>>>> my
>>>>> observations were correct, it turns out: if you use it
(together with
>>>>> 'cruid=12345'), you can't have
'username=user_xyz' as an option, too. You
>>>>> do either (username and) password-based authentication, or
you use an
>>>>> existing kerberos cache for that. This was formerly
acquired
>>>>> interactively
>>>>> via username/password, and that way you have something like
a single
>>>>> sign-on.
>>>>>
>>>>> This is what works so far:
>>>>>
>>>>> 1. log in as the domain user 'userxyz' (id=12345)
via ssh to a Linux
>>>>> member server -> the kerberos cache file is created in
/tmp
>>>>> ("krb5cc_12345_afcdeb")
>>>>> 2. while the user is logged in (and the cache exists), use
this command
>>>>> to
>>>>> mount his home share (as root):
>>>>> # mount.cifs //server/home/userxyz /home/userxyz -o
>>>>> sec=krb5,cruid=12345,uid=12345,gid=someGroupID
>>>>>
>>>>> So, users' krb5 cache files are actually used by the
cifs mount upcall. I
>>>>> made sure that no other cache file was present, and I never
put anything
>>>>> into keytab.
>>>>>
>>>>> What isn't working so far, is automating this mount via
pam_mount.
>>>>> Pam_mount of cifs on this member server is working with
explicit
>>>>> credentials, so far. But if I use
'sec=krb5,cruid=12345' I get the
>>>>> # mount error(126): Required key not available
>>>>> which is what I also get, when I try to mount without
logging in as
>>>>> 'userxyz', first.
>>>>>
>>>>> Here is my volume definition from the
'/etc/security/pam_mount.conf.xml'
>>>>> file:
>>>>>
>>>>> <volume fstype="cifs"
server="server" path="home/userxyz"
>>>>> mountpoint="/home/userxyz"
>>>>>
options="sec=krb5,cruid=12345,uid=12345,gid=someGroupID,nosuid,nodev"
/>
>>>>>
>>>>> I figure, that I have to adjust my pam configuration to
perform kerberos
>>>>> authentication _before_ doing the pam_mount.
>>>>>
>>>>> I will report back with more results.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list go to the following URL and
read the
>>>>> instructions:
https://lists.samba.org/mailman/options/samba
>>>>>
>>>>>
>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions: https://lists.samba.org/mailman/options/samba
>>>
>