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

Jakub Hrozek jhrozek at redhat.com
Mon Nov 3 18:51:55 UTC 2014


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..
> >
> >> 
> >> 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.

They are not. As I said above, tokengroups can be used to speed up POSIX
lookups, too.

> 
> 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.

I disagree.



More information about the sssd-devel mailing list