On 04/05/2013 12:36 PM, Rowland Penny wrote: > On 05/04/13 17:05, Andreas Schneider wrote: >> On Friday 05 April 2013 15:54:41 Rowland Penny wrote: >>> On 05/04/13 15:35, Jakub Hrozek wrote: >>>> On Wed, Apr 03, 2013 at 11:20:44AM +0100, Rowland Penny wrote: >>>>> On 02/04/13 22:39, Jakub Hrozek wrote: >>>>>> On Tue, Apr 02, 2013 at 01:42:46PM +0100, Rowland Penny wrote: >>>>>>>> With the AD provider you shouldn't be needing any of the options >>>>>>>> below. >>>>>>>> The AD provider should just default to them. >>>>>>>> >>>>>>>> Is there a reason you are using password binds and not GSSAPI? >>>>>>> OK, I have removed all the lines you suggested and getent stopped >>>>>>> working, examining /var/log/sssd/sssd_DOMAIN.log gives the reason: >>>>>>> >>>>>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_send] >>>>>>> (0x0400): SRV resolution of service 'AD'. Will use DNS discovery >>>>>>> domain 'DOMAIN' >>>>>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_cont] >>>>>>> (0x0100): Searching for servers via SRV query '_ldap._tcp.DOMAIN' >>>>>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolv_getsrv_send] >>>>>>> (0x0100): Trying to resolve SRV record of '_ldap._tcp.DOMAIN' >>>>>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] >>>>>>> [request_watch_destructor] (0x0400): Deleting request watch >>>>>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [resolve_srv_done] >>>>>>> (0x0020): SRV query failed: [Domain name not found] >>>>>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [fo_set_port_status] >>>>>>> (0x0100): Marking port 0 of server '(no name)' as 'not working' >>>>>>> (Tue Apr 2 12:52:55 2013) [sssd[be[DOMAIN]]] [set_srv_data_status] >>>>>>> (0x0100): Marking SRV lookup of service 'AD' as 'not resolved' >>>>>>> >>>>>>> It is trying to look up the samba domain name instead of the the >>>>>>> DNS >>>>>>> domain.name, re-adding the following line cures this: >>>>>>> >>>>>>> dns_discovery_domain = domain.lan >>>>>> I see, this is interesting. Does the value of dns_discovery_domain >>>>>> differ from the value of ad_domain? If not, then I would consider >>>>>> it a >>>>>> bug. >>>>> I must have misunderstood you, because I turned off 'ad_domain = >>>>> domain.lan'. I have now turned it back on again and turned off the >>>>> dns_discovery_domain line and it still works. >>>>> >>>>>>>>> Rowland >>>>>>>> I think there are two options: >>>>>>>> 1) keep using the ID mapping and tailor the configuration of >>>>>>>> the ID >>>>>>>> mapper in the SSSD so that it generates the same output as the >>>>>>>> winbind >>>>>>>> mapper. We've done this before, it's not the nicest looking >>>>>>>> configuration, but it works. >>>>>>> What sssd ID mapping seems to do is, get the last part of the SID >>>>>>> and add a number to the front of it, is this correct? and if so >>>>>>> where does the number come from? and is this the way Windows does >>>>>>> it? >>>>>> Correct, The first number is a hashed value of the domain part of >>>>>> the >>>>>> SID >>>>>> and the "last part of the SID" is usually called the RID. >>>>>> >>>>>> Can you check if setting ldap_idmap_autorid_compat to True would >>>>>> yield >>>>>> the same IDs as winbind does? (Sorry I don't have a box with winbind >>>>>> handy and I always forget the details). >>>>> I have tried it and no it wouldn't, with S3 winbind I got: >>>>> >>>>> uid=21105(user) gid=20513(domain_users) groups=20513(domain_users) >>>>> >>>>> With the line added into sssd.conf and winbind turned off, I now get: >>>>> >>>>> uid=201105(user) gid=200513(domain_users) groups=200513(domain_users) >>>>> >>>>>>> When you say 'the same output as the winbind mapper', which winbind >>>>>>> are you refering to, the winbind on the Samba 4 server or the >>>>>>> winbind on the Samba 3 client? >>>>>> Both actually. You really want to have the IDs consistent >>>>>> everywhere. >>>>> That is the problem, the built into samba4 winbind returns different >>>>> results: >>>>> >>>>> uid=3000016(DOMAIN\user) gid=100(users) groups=100(users) >>>>> >>>>>>>> 2) Switch to using POSIX IDs instead of mapping them from SIDs >>>>>>>> with >>>>>>>> both >>>>>>>> winbind and SSSD. All that should be needed on the SSSD side is >>>>>>>> set: >>>>>>>> ldap_id_mapping = False >>>>>>>> to sssd.conf and restart the SSSD (you might need to rm the >>>>>>>> cache as >>>>>>>> SSSD doesn't really handle UID/GID changes very well yet). >>>>>>>> >>>>>>>> On the winbind side, I'm a little fuzzy on the details, but I >>>>>>>> believe >>>>>>>> this could be done with "winbind nss info" configuration option. >>>>>>> The problem here is the use of winbind, I cannot get the idmap_ad >>>>>>> backend to work at all, and idmap_rid gives a different uid from >>>>>>> the >>>>>>> Samba 4 server >>>>>> So which mapper does the S4 server use? >>>>> I do not know, I only know it is different from the S3 winbind. >>>>> >>>>>>>> From where I am 1) sounds like easier to implement since all >>>>>>>> you'd be >>>>>>>> >>>>>>>> changing is sssd.conf >>>>>>> I am being to think that the way forward is to stop winbind on the >>>>>>> Samba 4 server and use sssd instead. >>>>>> That is a noble goal and one which we wanted to accomplish in the >>>>>> upcoming 1.10 release, but it was postponed to the next one: >>>>>> https://fedorahosted.org/sssd/ticket/1534 >>>>>> >>>>>> The Samba server seems to be leveraging an interface only winbind is >>>>>> able to serve at the moment to convert SIDs to GIDs on the server >>>>>> side. >>>>>> >>>>>> I don't know all the details, sorry, maybe on of the Samba >>>>>> developers >>>>>> lurking on this list would chime in. >>>>> I don't understand this, by removing the S4 winbind links on the >>>>> server and installing sssd 1.9.4, I appear to have got it to work, >>>>> I now have consistent uid's & gid's without any real effort. >>>> I had a short chat with the Samba Red Hat maintainer Andreas Schneider >>>> (CC-ed) and he advised against removing winbind from the server, too. >>>> >>>> I'm sure he'll provide a more qualified answer than I can :-) >>> Hi, on Samba 4 you get 2 winbind's, one is based on the S3 code base >>> and >>> I think that I am right in saying that it will not start if the samba >>> (AD) daemon is run. >> That's correct and the DC needs the 'builtin' winbind daemon for the >> DC to >> function. It will not work with the s3fs winbind. >> >>> The other is built into the samba daemon and >>> requires the creation of a couple of symlinks to use winbind in >>> /etc/nsswitch. >> What do you mean here? > If, as I do, you compile Samba 4, you have to create a couple of > symlinks: > > ln -s /usr/local/samba/lib/libnss_winbind.so.2 /lib/libnss_winbind.so > ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2 > > Without these, you do not get any domain users etc from getent. > >> >>> So you cannot remove either of the winbind's, I just >>> choose not to create the symlinks, that way the samba daemon winbind >>> cannot interfere with getent. >>> As I said, using sssd with samba 4 is the only easy way that I have >>> found to get consistent uid's etc, there is another way using nslcd, >>> kstart etc but it is not really as easy as sssd. >> Why not? To have consitent uid/gid you just set them for each user or >> let S4 >> do it for you (autoincrement). Then all you have to to on the client >> is to >> read them from the AD. You can do the same with windows and unix >> extensions >> ... >> >> >> -- andreas >> > I have tried to use winbind with idmap_rid, but I got different > results from the server. I was then advised to try idmap_ad, with this > I could not get any results at all, no matter what ranges etc I put > into smb.conf. > > In my opinion, for what it is worth, If Samba want people to use > winbind, they need to sort out winbind for the clients, perhaps base > it on whatever S4 uses, reduce the choices of backend to one and make > it pull the info from the S4 database and store it locally with little > modification to the smb.conf > > But then again, this is what sssd seems to do, with sssd running on > the server & linux clients I get consistent uid's etc with less in the > clients smb.conf, seemingly no ranges to worry about and just one > extra conf file to set and there is very little to set if you use the > sssd ad backend. > > I am not claiming that using sssd is perfect, but it is a darn sight > better than the mess winbind is at the moment. > > Rowland > The funny thing is that SSSD uses a lot of samba code under the hood ;-) It seems to do it better than winbind itself...
-- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
