[SSSD] [REGRESSION] [PATCH] LDAP: Change defaults for ldap_user/group_objectsid

Lukas Slebodnik lslebodn at redhat.com
Mon Nov 3 18:43:22 UTC 2014


On (03/11/14 17:10), Jakub Hrozek wrote:
>On Sat, Oct 25, 2014 at 11:59:36PM +0200, Lukas Slebodnik wrote:
>> On (24/10/14 21:14), Jakub Hrozek wrote:
>> >On Fri, Oct 24, 2014 at 07:57:29PM +0200, Michal Židek wrote:
>> >> On 10/24/2014 07:09 PM, Jakub Hrozek wrote:
>> >> >On Fri, Oct 24, 2014 at 02:55:44PM +0200, Lukas Slebodnik wrote:
>> >> >>>>-    { "ldap_group_objectsid", NULL, SYSDB_SID, NULL },
>> >> >>>>+    { "ldap_group_objectsid", "objectSID", SYSDB_SID, NULL },
>> >> >>>>     { "ldap_group_modify_timestamp", "modifyTimestamp", SYSDB_ORIG_MODSTAMP, NULL },
>> >> >>>>     { "ldap_group_entry_usn", NULL, SYSDB_USN, NULL },
>> >> >>>>     { "ldap_group_type", NULL, SYSDB_GROUP_TYPE, NULL },
>> >> >>>These changes in rfc2307_user_map and rfc2307bis_user_map caused regression,
>> >> >>>which was fixed by ticket https://fedorahosted.org/sssd/ticket/2383
>> >> >>>
>> >> >>>Dereference failed with openldapserver.
>> >> >>>[sdap_nested_group_process_send] (0x2000): Dereferencing members of group [cn=topgrp,ou=Groups,dc=example,dc=com]
>> >> >>>[sdap_deref_search_send] (0x2000): Server supports OpenLDAP deref
>> >> >>>[sdap_x_deref_search_send] (0x0400): Dereferencing entry [cn=topgrp,ou=Groups,dc=example,dc=com] using OpenLDAP deref
>> >> >>>[sdap_print_server] (0x2000): Searching 10.16.64.191
>> >> >>>[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [no filter][cn=topgrp,ou=Groups,dc=example,dc=com].
>> >> >>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
>> >> >>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
>> >> >>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword]
>> >> >>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber]
>> >> >>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member]
>> >> >>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID]
>> >> >>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp]
>> >> >>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp]
>> >> >>>[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid]
>> >> >>>[sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 3
>> >> >>>[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
>> >> >>>[sdap_get_generic_op_finished] (0x0400): Search result: Protocol error(2), Dereference control: attribute decoding error
>> >> >>>[sdap_get_generic_op_finished] (0x0040): Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding error
>> >> >>>[generic_ext_search_handler] (0x0040): sdap_get_generic_ext_recv failed [5]: Input/output error
>> >> >>>[sdap_deref_search_done] (0x0040): dereference processing failed [5]: Input/output error
>> >> >>>[sdap_nested_group_deref_direct_done] (0x0020): Error processing direct membership [5]: Input/output error
>> >> >>>[sdap_nested_done] (0x0020): Nested group processing failed: [5][Input/output error]
>> >> >>>
>> >> >>>
>> >> >>>SSSD did equivalen of next command line search:
>> >> >>>[root at host ~]# ldapsearch -x -LLL -h $SERVER -b 'dc=example,dc=com' \
>> >> >>>    -E '!deref=member:objectClass,cn,userPassword,gidNumber,objectSID,modifyTimestamp,uid' \
>> >> >>>    cn=topgrp
>> >> >>>Protocol error (2)
>> >> >>>Additional information: Dereference control: attribute decoding error
>> >> >>>
>> >> >>>Dereferencing failed because attribute objectSID isn't in any objectclass on
>> >> >>>openldap server.
>> >> >>>
>> >> >>>Summary:
>> >> >>>We should revert this patch. ObjectSID should not be set by default
>> >> >>>in rfc2307 or rfc2307bis scheme.
>> >> >>>
>> >> >>BTW we had the same problem with nonstandard UUID attribute
>> >> >>https://git.fedorahosted.org/cgit/sssd.git/commit/?id=dfb2960ab251f609466fa660449703835c97f99a
>> >> >>
>> >> >>LS
>> >> >
>> >> >OK, this is bad, thanks a lot for catching the problem.
>> >> >
>> >> >I agree that we should revert the patch as a first step. But at the same
>> >> >time, the changes in 1.11 caused problems for several users running with
>> >> >id_provider=ldap enrolled with an AD server.
>> >> >
>> >> >In retrospective, I wish we limited some of the AD-specific features to
>> >> >the AD provider only, but in order to mitigate the problem, what about
>> >> >setting the defaults if (and only if) we detect the server is an AD
>> >> >server from rootDSE? We already do that for tokenGroups..
>> >> 
>> >> After discussion with Lukas I think we should not do this.
>> >> Not even for tokenGroups. If user specifies his provider
>> >> as ldap, we should not do background magic that changes
>> >> defaults behind the scenes (based on rootDSE or anything
>> >> else).
>> >
>> >I totally agree, see my previous mail -- "In retrospective, I wish we
>> >limited some of the AD-specific features to the AD provider only".
>> >
>> >But I don't think we can do backwards-incompatible changes so easily
>> >now. It's completely out of question for a minor update (1.12.x) and must
>> >be handled with extreme care in major update (1.13).
>> >
>> >Additionally, we already detect search bases and other config from
>> >rootDSE, what makes the default SID values any different?
>> The problem was automatic enabling of features based on rootDSE.
>> User used ldap provider with AD but without idmapping. The root of problem was
>> that tokengroups were enabled by default (based on rootDSE) and SIDs could not
>> be downloaded. Even if they were downloaded id mapping is disabled
>> It would not spped upa anything.
>
>It wouldn't speed up anything for the first run, true, but there is a
>big potential benefit for lookups of other users.
>
>Consider Alice and Bob are both members of two same groups. Alice logs
>in first, the cache is empty, so we look up both sids. So we have a base
>search for the user, a base search for the tokenGroups and then two searches
>based on SID. Then Bob comes in, we check his tokenGroups attribute and
>see that both SIDs are already cached, so we just link Bob's user entry
>with the SIDs and we're done -- total of two lookups with scope=base.
>
>So this change /does/ have a nice speed benefit, however, see below..
>
>> 
>> We tried to solve it with this patch, but there is another solution.
>> To disable tokengroups for ldap provider (rfc2307, rfc2307bis).
>
>I spent pretty much the whole day today triaging issues after users
>upgraded to RHEL-6.6. And I tend to agree we should revert this change
>for id_provider=ldap && ldap_id_mapping=False.
>
>Setting the SID attribute values to the AD defaults as I proposed earlier
>is still something that might make sense and would solve maybe 50% of
>issues. But the other 50% are strange errors like looking
>up SIDs from another subdomain, where the LDAP provider has no access etc.
>
>> 
>> If someone wants to use AD as any other ldap server we should not enable ad
>> features by default.
>  ^^^^^^^^
>I disagree, we should take advantage of whatever features we have at
>our disposal. But tokenGroups along with the LDAP provider proved to be
>too fragile..
>
>So after experiencing the breakage from downstream, I also vote for
>enabling tokenGroups if:
>    * id_provider = ad, with or without ID mapping
>    * ldap_provider = ldap, without ID mapping
>
>To make sure id_provider=ldap && mapping=true we should also set the user
>and group SID attribute defaults.
>
It is clear that tokengroups and id mapping are related options.

I would prefer to merge boolean options ldap_id_mapping, ldap_use_tokengroups
(and deprecated one option).

IMHO, it is better solutions than auto-enabling features based on rootDSE.

LS



More information about the sssd-devel mailing list