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

Lukas Slebodnik lslebodn at redhat.com
Sat Oct 25 21:59:36 UTC 2014


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.

We tried to solve it with this patch, but there is another solution.
To disable tokengroups for ldap provider (rfc2307, rfc2307bis).

If someone wants to use AD as any other ldap server we should not enable ad
features by default. If someone wants extra ad features (tokengroups, id
mapping) then they can use ad provider or ldap provider and enable all options
manually. We should not be smart in ldap provider. The smart provider(s)
is(are) ad(,ipa).

LS



More information about the sssd-devel mailing list