I recently upgraded sssd on an Ubuntu 12.04 system to the 12.10 version of sssd, 1.9.0-0ubuntu1. This version of sssd exhibits the malfunction described in Ubuntu bug report #1049186. https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1049186 I noticed that whenever sssd starts issuing incorrect results for "groups", the following appears in samba's log file. [2012/10/02 21:16:55, 1] ../lib/ldb-samba/ldb_wrap.c:68(ldb_wrap_debug) ldb: ldb: unknown extended rule_id 1.2.840.113556.1.4.1941 [2012/10/02 21:16:55, 1] ../lib/ldb-samba/ldb_wrap.c:68(ldb_wrap_debug) ldb: ldb: unknown extended rule_id 1.2.840.113556.1.4.1941 Can someone enlighten me about this? Is sssd 1.9.0 requesting ldb operations that haven't been implemented yet in Samba 4? I am running samba4 4.0.0~beta2 packaged for Debian and Ubuntu.
I figured out how to fix this problem. Add ldap_initgroups_use_matching_rule_in_chain = False to sssd.conf.
Although the fix works, there is clearly something wrong with either Samba 4 or sssd such that the error condition gets lost, which makes it rather more difficult for the humble user to figure out what is going wrong. Although Samba 4 logs an error message, sssd reports success. Here is part of sssd's log output caused by doing "su -c groups foo", with incorrect results, at debug_level 0x0ff0: [be_get_account_info] (0x0100): Got request for [3][1][name=foo] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [dc=cmpny,dc=nl] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(msSFU30Name=foo)(objectclass=person))][dc=cmpny,dc=nl]. [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set [sdap_save_user] (0x0400): Storing info for user foo [sdap_get_ad_match_rule_initgroups_next_base] (0x0400): Searching for groups with base [dc=cmpny,dc=nl] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(member:1.2.840.113556.1.4.1941:=CN=Foo Doo,OU=Organization,DC=cmpny,DC=nl)(objectClass=group))][dc=cmpny,dc=nl]. [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success # dpkg -l sssd samba4 | grep ^.i hi samba4 4.0.0~beta2+dfsg1-2.dbg SMB/CIFS file, NT domain and active directory server (version 4) ii sssd 1.9.0-0ubuntu1 System Security Services Daemon
The problem can no longer be reproduced with sssd 1.9.1 which seems no longer to use LDAP operation 1.2.840.113556.1.4.1941. That means that this bug report now has very low urgency, but it may still be an issue that error values do not find their way from Samba to Sssd's log.
As of SSSD 1.9.1 we stopped using the matching rule by default. For the record, this should always have been a low priority bug, as our behavior was to test (upon connecting to the LDAP server) whether it had this functionality available. We would fire off a request and if the server returned an error, we would continue processing as if 'ldap_initgroups_use_matching_rule_in_chain = False' had been set in the configuration. The purpose of this was to use a feature that was supposed to be much faster for lookups, but was not available on all systems. However, we have subsequently replaced this with a lookup using tokenGroups instead.
> For the record, this should always have been a low priority bug Well, as I describe in Ubuntu bug #1049186, it was a significant problem with 1.9.0 that sssd failed to obtain the correct list of groups for a user. I eventually found a workaround (ldap_initgroups_use_matching_rule_in_chain = False) but this was far from obvious. :)
in [MS-ADTS] section 3.1.1.3.4.4.3 the OID 1.2.840.113556.1.4.1941 is called LDAP_MATCHING_RULE_TRANSITIVE_EVAL. This has been implemented in master with 2a22ba34cd6f28950246b54c6577c922c61f4fdb. First release containing this is 4.2.