[Samba] krb5cc cache upon login. Possible?

[steve]

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