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

buhorojo buhorojo.lcb at gmail.com
Wed Nov 4 08:31:19 UTC 2015

On 03/11/15 17:18, Ole Traupe wrote:
> Am 03.11.2015 um 16:44 schrieb buhorojo:
>> On 03/11/15 10:56, Ole Traupe wrote:
>>>>> 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. 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?
>> Hi
>> The upcall will maintain the validity of the mount for as long as it 
>> is accessed, so maybe a better question would be how long a ticket 
>> does your kdc issue for a user. The latter will be the determining 
>> factor, not the upcall.
> Up to 7 days if renewed within 24h, if I understand correctly 
> (ticket_lifetime = 24h,  renew_lifetime = 7d).
> Thanks for the clarification!
Sorry, we don't know what the renew_lifetime means. Ours last 8 hours, 
after which the mount is inaccessible.
>>> 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.
>> We think that the only way with cifs on Centos is to get the source 
>> and build it. If the rest of it is working but the upcalls are not 
>> then keep with what you have, uninstall the cifs utils making sure 
>> the binaries have been removed and are not at a non-standard 
>> location, then make install.
> So there will be no conflict with other samba components such as in 
> samba-common?
> And sorry for the typo, it is Samba 3.6.
>> Good luck and HTH
> Again, thank you very much!
No problem. Thank _you_ for the thread. We've an ongoing coursework on 
exactly this, except we have to automount it so most of the stuff we can 
test hands on. A lot of it we covered last year and we'd forgotten.  
Unfortunately although we have Fedora, opensuse and Ubuntu lab rigs, we 
don't do Centos.

More information about the samba mailing list