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

[buhorojo]

On 04/11/15 13:36, mathias dufresne wrote:
> 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.
+1. Hence our advice to create a minimalist user solely for mounting the 
share. Although he must have a uidNumber, make sure that user cannot 
login. A good way to do that is to add
  loginShell: /bin/false
to his Distinguished Name in AD.
HTH

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