[Samba] Pam_mount not working with "sec=krb5"

Wed Nov 4 17:30:06 UTC 2015

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