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

mathias dufresne infractory at gmail.com
Wed Nov 4 10:18:07 UTC 2015


2015-11-03 10:56 GMT+01:00 Ole Traupe <ole.traupe at tu-berlin.de>:

>
> I mean, putting the key in the keytab looks like a security risk to me.
>>>
>> In what way does it appear any more of a risk than having the keys which
>> you have there already? Even if someone steals the keytab, they're gonna be
>> hard pressed to crack the key in the few hours before the tgt expires. Do
>> you have very sensitive data maybe?
>>
>
> Ok. And maybe I misunderstood something: I thought the key would be valid
> indefinitely, while the ticket expires.


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.


> But then there is the Ticket-Granting-Ticket (TGT). And if also the TGT
> expires after a few hours, for how long will a share mounted with
> "sec=krb5,multiuser" be accessible to the user?
>
> I am sorry for all these dummy questions, but I really find this matter
> hard to understand.
>
> Thank you very much for your help!
>
>
> Would be nice if you could use kerberos on the fly.
>>>
>>
>> You _are_ using it on the fly.The tgt is obtained without any interaction
>> on the part of the user.
>>
>>>
>>> Unfortunately, I don't find such a detailed log in /var/log/messages.
>>>
>>>
>>>>> Also, if the user is not mounting his home share, but somebody else,
>>>>> this _other_ user will be the owner of newly created files and folders,
>>>>> right
>>>>>
>>>> No. With multiuser, acl and permissions are respected. If the user
>>>> would normally be the owner of newly created files, then he will be also
>>>> over cifs.
>>>>
>>> Great, that sounds exactly as I would like it to be.
>>>
>>>
>>>> One other thing, you need a recent version of cifs utils (we don't
>>>> think Centos has)
>>>>
>>> Mine is cifs-utils.x86_64    4.8.1-20.el6
>>>
>> We can confirm it works with 6.2.
>> HTH
>>
>
> Thanks. So migrating the server to CentOS 7 would be advised here if one
> is afraid of bad interactions of Samba 3.1 with later (and potentially
> buggy) experimental cifs-utils versions for CentOS 6.
>
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>


More information about the samba mailing list