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

Wed Nov 4 13:49:20 UTC 2015

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.

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
>