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