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

Lukas Slebodnik lslebodn at redhat.com
Mon Nov 3 19:18:06 UTC 2014


On (03/11/14 19:51), Jakub Hrozek wrote:
>On Mon, Nov 03, 2014 at 07:43:22PM +0100, Lukas Slebodnik wrote:
>> 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..
>> >
there's nothing about POSIX lookups.

>> >> 
>> >> 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.
>> >
there's nothing about POSIX lookups either.

>> >> 
>> >> 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.
>
>They are not. As I said above, tokengroups can be used to speed up POSIX
>lookups, too.
>
I read mails few times, but I didn't find anything about POSIX lookups.
Did I overlook something?

LS



More information about the sssd-devel mailing list