On Fri, Apr 05, 2013 at 08:15:14PM +0100, Rowland Penny wrote: > On 05/04/13 19:46, Dmitri Pal wrote: > >On 04/05/2013 02:40 PM, Rowland Penny wrote: > >>On 05/04/13 19:00, Jakub Hrozek wrote: > >>>On Fri, Apr 05, 2013 at 05:36:32PM +0100, 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. > >>>> > >>>Truth be told, I've never compiled Samba from scratch myself, but the > >>>nssswitch libraries must be installed to /lib{,64}, are you sure there > >>>isn't just a configure time switch for that? > >>> > >>> > >>If you are talking about libnss_winbind.so, then as far as I know, no > >>there isn't, you just have to create the two symlinks and add > >>'winbind' to the passwd & group lines in /etc/nsswitch.conf and it works. > >>If you do add the links etc then sssd does not work on the S4 server. > >>As sssd seems to work better than winbind then I shall continue to use > >>it, but what I cannot understand is why do I seem to get the feeling > >>that you are trying to talk me out of using sssd. > >> > >>Rowland > >> > >> > >On the samba file server or DC there other things that file server gets > >directly from winbind that sssd does not have yet. > >We are concerned that this would cause issues for you that you yet have > >not seen. That would be the reason. > >If you are willing to continue trying and are prepared to encounter > >issues and report back then we are OK. > > > Could you give me some idea what sssd doesn't do that winbind does? > > As far as I can see, I get (via getent): > uidNumber > gidNumber > unixhomedirectory > loginShell >
There is an interface for SID to name conversion in Samba and currently only winbind implements the interface. We wanted to have a compatible implementation done for 1.10 but we're probably not going to make it. I don't know exactly from the top of my head what functionality the samba server uses this interface for. Maybe Andreas or Sumit know? > which as far as I can see is what winbind would give me. > > I can create directories & files and change ownership to a domain > user &/or domain group, or in other words, I cannot tell the > difference between using winbind or sssd except for the constant > uidnumbers & gidnumbers. _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
