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

Simo Sorce simo at redhat.com
Mon Oct 27 18:24:56 UTC 2014


On Fri, 24 Oct 2014 21:14:50 +0200
Jakub Hrozek <jhrozek at redhat.com> 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?

+1 to Jakub's argument.

If the LDAP server provides a capability we can use, we should use it.
We should override the LDAP server advertised capabilities only in the
negative, ie to disable them, if the client's admin know the server
misbehaves.

There is no reason to disable a feature by default if we know we can
use it.

> > Errors like the ones that my original (regression making)
> > patch tried to solve (id_mapping is set but ldap_*_objectsid
> > is not) should be detected by config file validator (once we
> > have it). Adding hacks to the code is not a good way (so
> > this patch was not good as well).
> 
> Yes, but what is even worse is users running a supported and valid
> configuration and having their setup broken with a yum upgrade.

Not only that, but the code should not break if 2 conflicting options
are set. Rather it should loudly warn at level 0, and then switch one
of the 2 options to a "working" state (possibly the 'safest' one,
where "safest" is both "mostly likely to work" and "more restrictive
security-wise" if applicable).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list