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