Bug 9237 - Whereas Samba fails to perform extended rule_id 1.2.840.113556.1.4.1941, sssd reports success
Whereas Samba fails to perform extended rule_id 1.2.840.113556.1.4.1941, sssd...
Product: Samba 4.1 and newer
Classification: Unclassified
All All
: P5 normal
: 4.2
Assigned To: Andrew Bartlett
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2012-10-02 19:32 UTC by Thomas Hood
Modified: 2015-05-19 09:50 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Hood 2012-10-02 19:32:51 UTC
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.


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.
Comment 1 Thomas Hood 2012-10-02 19:59:08 UTC
I figured out how to fix this problem.  Add 

    ldap_initgroups_use_matching_rule_in_chain = False

to sssd.conf.
Comment 2 Thomas Hood 2012-10-03 08:13:03 UTC
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
Comment 3 Thomas Hood 2012-10-14 15:38:17 UTC
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.
Comment 4 Stephen Gallagher 2012-10-15 01:41:30 UTC
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.
Comment 5 Thomas Hood 2012-10-15 09:59:47 UTC
> 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.  :)
Comment 6 Björn Jacke 2015-05-19 09:50:21 UTC
in [MS-ADTS] section 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.