[Samba] krb5cc cache upon login. Possible?

[steve]

On 04/13/2013 05:13 PM, Rowland Penny wrote:
> On 13/04/13 15:43, steve wrote:
>> On 04/13/2013 03:41 PM, Rowland Penny wrote:
>>> On 13/04/13 14:12, steve wrote:
>>>> On 04/13/2013 11:26 AM, Rowland Penny wrote:
>>>>> On 12/04/13 22:31, steve wrote:
>>>>>> On 04/12/2013 06:15 PM, Rowland Penny wrote:
>>>>>>> On 12/04/13 17:01, steve wrote:
>>>>>>>> openSUSE 12.3 clients joined to a Samba4 Domain
>>>>>>>>
>>>>>>>> Hi everyone
>>>>>>>>
>>>>>>>> We are using the cifs multiuser option with sec=krb5. This 
>>>>>>>> requires the user to have a ticket cache under /tmp
>>>>>>>> I know we can get that by using kinit, but I hear rumours that 
>>>>>>>> pam can do it upon successful authentication.
>>>>>>>>
>>>>>>>> Can anyone point me in the right direction?
>>>>>>>> Cheers,
>>>>>>>> Steve
>>>>>>> Hi Steve, libpam-script, you need three scripts an auth script 
>>>>>>> to get the ticket cache, then a script to do something with it 
>>>>>>> when the user logs in and another to do something when they log 
>>>>>>> out, I seem to have this working. I tried libpam-mount, but it 
>>>>>>> had a nasty habit of not removing the mount on log off.
>>>>>>>
>>>>>>> Rowland
>>>>>>>
>>>>>> Hi Rowland
>>>>>> I may have some good news: with recent versions of pam_krb5 and 
>>>>>> cifs it shouldn't be necessary to do anything. You just get the 
>>>>>> cache when you go to the share. If you can get that far of 
>>>>>> course. The reason for our failure was:
>>>>>> <feel thick>
>>>>>> common-auth has: auth [success=2 default=ignore] pam_krb5.so 
>>>>>> minimum_uid=1000000
>>>>>> Our test user was 20000
>>>>>> </feel thick>
>>>>>>
>>>>>> So, users in the normal 3000000+ AD range get there fine:)
>>>>>> Cheers,
>>>>>> Steve
>>>>>>
>>>>>
>>>> Hi Rowland
>>>>> Hi Steve, ok I tried libpam-krb5 and whilst it gets the user 
>>>>> logged in, in my instance it did not mount any shares.
>>>> Ah, no. We use the automounter to mount directories on demand, 
>>>> either the user's home folder at login or other shares when the 
>>>> user attempts to enter them. With a lot of users, autofs is great 
>>>> because it mounts only what is requested, not the whole lot.
>>>>> You are also using nss-ldapd but I am using sssd instead, this 
>>>>> also gets the cache but I was putting it somewhere else, so I have 
>>>>> changed sssd to put the cache back into its default location /tmp 
>>>>> , turned off pam_krb5 and the shares now get mounted again.
>>>> Actually I think it's the cifs-utils which create the cache as it's 
>>>> needed because we tested it without the automounter running: the 
>>>> user can still log in but he does not get the cache until he 
>>>> attempts to go into a cifs mounted share. Maybe the cifs gurus 
>>>> could tell us whether it is pam or cifs which creates the cache?
>>>>>
>>>>> There is possibly another difference between our setups, I mount 
>>>>> the shares at login and I think that you mount them after login, 
>>>>> is this correct? also how do you unmount the shares after the user 
>>>>> has logged of?
>>>>>
>>>>> Rowland
>>>> Yes, that's correct. The automounter mounts then as and when they 
>>>> are requested.
>>>>
>>>> Question: is sssd instead of nss-ldapd or instead of pam. Or both? 
>>>> IOW, does it pull stuff from ldap? Maybe it does both. Although we 
>>>> share the relief of having got rid of winbind from the equation, 
>>>> we're always looking for alternatives to our ldapd setup.
>>>> Cheers, Steve
>>>>
>>> Hi Steve, sssd is instead of nss-ldapd but you still need pam, at 
>>> the moment I am using it to pull from ldap but they are working on 
>>> an ad backend. I tried the ad backend on both the server and a 
>>> client and whilst it seemed to work, I found that users on a client 
>>> couldn't write to their own directories.
>>>
>>> To use sssd, you set the S4 server as normal, with rfc2307, then on 
>>> the client, set up samba without all the winbind settings and edit 
>>> one conf file, thats it, no extra keytabs, users etc.
>>>
>>> I can confirm that if you add a user to Domain Admins and mount the 
>>> share with cifs, the user gets the same uidNumber as the 
>>> Administrators group but only when they write to the share, at any 
>>> other time they have the same uidNumber that is in the users ldap. 
>>> It is clearly a bug, but whose, Samba's or cifs.
>>>
>>> whilst writing this I am beginning to wonder if the problem I had 
>>> with the sssd ad backend is related?
>>>
>>> Rowland
>>>
>>>
>> Hi Rowland
>> Thanks for the sssd info.
>>
>> I think what you're saying is what is confirmed by the cifs guys in 
>> my recent thread over on the cifs list:
>> http://article.gmane.org/gmane.linux.kernel.cifs/8088
>>
>> <quote>
>> So, for the record, to pull uid:gid from AD and_not_  idmap:
>> [global] in smb.conf needs this syntax:
>> idmap_ldb:use rfc2307 = Yes
>>
>> Personally, I think that all uid:gid should come from AD by default.
>>
>> Note that it's not necessarily wrong for them to be mapped
>> inconsistently -- it just looks weird from the client. When you use
>> "multiuser" then it also turns off client-side permission checking and
>> leaves it up to the server.
>>
>> If you were to change the ownership on the directory to 3000019 on the
>> server, then everything will likely also work correctly. It's just that
>> stat() calls would show the ownership as something else on the client.
>>
>> </quote>
>>
>> Anything which makes the idmap nightmare simpler: if the cifs 
>> multiuser option takes the client out of the equation then that 
>> narrows down debugging.
>> Steve
>>
> If/when sssd get the ad backend working it will be better still, no 
> winbind and everything pulled from AD.
>
> Rowland
>
Hi Rowland
Good luck with the sssd and please keep us posted.
Steve