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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
