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

Wed Nov 4 14:46:01 UTC 2015

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

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