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 :-) _______________________________________________ sssd-users mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-users
