[Samba] krb5cc cache upon login. Possible?

[Rowland Penny]

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

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.