Description of problem: Setting ldap_id_mapping true in the sssd.conf sssd generates a bad ldap-filter: (Thu Jun 5 11:13:33 2014) [sssd[be[ldap]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=test)(objectclass=user)(sAMAccountName=*)((null)=*))][dc=suse,dc=de]. With the version of 1.11.3. it worked fine: (Thu Jun 5 11:10:25 2014) [sssd[be[ldap]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=test)(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0))))[dc=suse,dc=de]. The same configuration with ldap_id_mapping= false works fine. Version-Release number of selected component (if applicable): sssd 1.11.5.1 How reproducible: Set ldap_id_mapping true in sssd.conf when id provider is ldap. Steps to Reproduce: 1. 2. 3. Actual results: sssd can not find the ldap user. Expected results: sssd must find the user. Additional info:
I suspect you are using id_provider=ldap and not id_provider=ad man sssd-ldap says: ldap_id_mapping (boolean) Specifies that SSSD should attempt to map user and group IDs from the ldap_user_objectsid and ldap_group_objectsid attributes instead of relying on ldap_user_uid_number and ldap_group_gid_number. Currently this feature supports only ActiveDirectory objectSID mapping. Default: false There are mentioned two other configure options: ldap_user_objectsid, ldap_group_objectsid. One more time, man sssd-ldap says: ldap_user_objectsid (string) The LDAP attribute that contains the objectSID of an LDAP user object. This is usually only necessary for ActiveDirectory servers. Default: objectSid for ActiveDirectory, not set for other servers. ldap_group_objectsid (string) The LDAP attribute that contains the objectSID of an LDAP group object. This is usually only necessary for ActiveDirectory servers. Default: objectSid for ActiveDirectory, not set for other servers.
I would recommend to configure sssd with id_provider=ad. It is simpler. http://jhrozek.livejournal.com/2801.html http://jhrozek.livejournal.com/3019.html You can use realmd to join your machine into AD http://www.freedesktop.org/software/realmd/
Thank you for your quick reaction! It is about a report of our customer how is testing our next product. The configuration is very strange to me too. But it has worked with the "old" sssd and does not work with the new one. It is not simple to explain a customer such a situation even what he makes is wrong :-) But the question finally is if there is a bug with ldap_id_mapping=true in the actual sssd version.
I checked source code of sssd-1.9 and it could not work at least with enabled enumeration. Documentation for ldap_id_mapping, ldap_user_objectsid, ldap_group_objectsid is the same.
(In reply to Lukas Slebodnik from comment #4) > I checked source code of sssd-1.9 and it could not work at least with > enabled enumeration. > Documentation for ldap_id_mapping, ldap_user_objectsid, ldap_group_objectsid > is the same. I think we should 1) set the values of ldap_user_objectsid and ldap_group_objectsid to some sensible value by default or 2) error out if ID mapping is set and SID mapping is not. I'm personally leaning towards 1) because our ID mapping only works with MS-AD servers, so I think it would be OK to to set the LDAP provider defaults to the AD provider defaults.
Upstream ticket: https://fedorahosted.org/sssd/ticket/2361
Options ldap_user_objectsid and ldap_group_objectsid have right value with id provider ad. Documentation is clear for ldap provider. Configuration with id_provider ad is simpler. I would prefer do not change anything.
OK, I re-checked the maps in the code (should have done it right away, sorry) and it seems that if id_provider is set to LDAP and schema is set to AD, then we already use objectSID. So I would only amend the man page and maybe add a warning. But I agree now that the maps should stay the same.
I believe this is the issue I reported to the downstream vendor. Since then I have done further research myself and have found that the following commit introduced the problem for me. I know this commit was to fix a regression, but it caused a regression for me. This commit causes "malformed search filter" errors in my setup: 507c0d939b7882e5708ac2c7589f67be2af89892 diff --git a/src/providers/ldap/sdap_idmap.c b/src/providers/ldap/sdap_idmap.c index 249201d..b6455b8 100644 --- a/src/providers/ldap/sdap_idmap.c +++ b/src/providers/ldap/sdap_idmap.c @@ -522,6 +522,11 @@ bool sdap_idmap_domain_has_algorithmic_mapping(struct sdap_idmap_ctx *ctx, int ret; TALLOC_CTX *tmp_ctx = NULL; + if (dp_opt_get_bool(ctx->id_ctx->opts->basic, SDAP_ID_MAPPING) + && 0 == strcmp("ldap", ctx->id_ctx->be->bet_info[BET_ID].mod_name)) { + return true; + } +
Could you tell me version of sssd? It would be good to see your sssd configuration file and debug log files.
Created attachment 938204 [details] sssd log file showing Malformed search filter
Created attachment 938205 [details] requested conf file
SSSD version 1.11.3 works, version 1.11.5 does not. I did a git bisection to narrow the problem down to the above commit. I also compiled a version of 1.11.5 taking out the above patch and it worked, confirming that the above patch does cause a problem in my setup. I have attached the requested files.
I think everything is already tracked in upstream ticket #2361. This bug slipped in because the userbase that is using both ldap_id_mapping=True and id_provider=ldap is very small. I agree it's a regression, though and we'll fix it during the 1.12.2 maintenance window. btw we also accept patches, so maybe the suse developers can fix the issue? I'll be happy to review a fix. But really, the configuration should be changed to use id_provider=ad if the back end used is AD.
(In reply to aryan1 from comment #13) > SSSD version 1.11.3 works, version 1.11.5 does not. I did a git bisection > to narrow the problem down to the above commit. I also compiled a version > of 1.11.5 taking out the above patch and it worked, confirming that the > above patch does cause a problem in my setup. > > I have attached the requested files. I would like to apologize for late response. I can see in your configuration file that you have enabled ldap_id_mapping with id_provider "ldap", but you didn't configured options ldap_user_objectsid and ldap_group_objectsid. See long description of ID mapping in manual pages (man sssd-ldap -> ID MAPPING) Another part of manual page (sssd-ldap -> ID MAPPING -> Configuration) suggests to use minimal configuration. (which you don't have) ldap_id_mapping = True ldap_schema = ad You have configured "ldap_schema = rfc2307bis". In this case, You have to manually configure options ldap_user_objectsid, ldap_group_objectsid to value "objectSid". It is mentioned in manual pages (man sssd-ldap -> ldap_id_mapping) ldap_id_mapping (boolean) Specifies that SSSD should attempt to map user and group IDs from the ldap_user_objectsid and ldap_group_objectsid attributes instead of relying on ldap_user_uid_number and ldap_group_gid_number. Currently this feature supports only ActiveDirectory objectSID mapping. Default: false With old version of sssd, it worked for you just *by chance* and it was never guaranteed that id maping will work with rfc2307bis. You should either use ldap_schema = ad or configure options to use objectSID See my 1st comment in this BZ (Comment 1). Summary: It might look like regression, but it isn't. Actually, it isn't bug at all. It worked for you just *by chance* with older version of sssd. I plan to close this ticket as not a bug. Do you agree?
The default has changed upstream in commit f834f712548db811695ea0fd6d6b31d3bd03e2a3
sssd-1.12.2-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/sssd-1.12.2-1.fc21
Package sssd-1.12.2-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sssd-1.12.2-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13383/sssd-1.12.2-1.fc21 then log in and leave karma (feedback).
sssd-1.12.2-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/sssd-1.12.2-2.fc21
sssd-1.12.2-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Jakub Hrozek from comment #16) > The default has changed upstream in commit > f834f712548db811695ea0fd6d6b31d3bd03e2a3 This patch caused critical regression with OpenLDAP server and thus it was reverted in upstream (master and 1-11). https://git.fedorahosted.org/cgit/sssd.git/commit/?id=30c964ac455a9c26cdc391e849505b4312f733ae
As I mention in Comment 15, it is not a bug. ID mapping should be configured for ldap provider as it is documented in manual pages. We tried to simplify configuration and change default value for some options, but it caused regressions in ldap provider with ldap_schema rfc2307bis. This is a reason why I changed this ticket to NOT A BUG