#1355 ldap_schema = ad performance issue
Closed: Fixed None Opened 11 years ago by myllynen.

On an AD domain both winbind/idmap_rid and winbind/idmap_autorid provide an expected reply for "id testuser" in less than a second. However, for sssd-1.9 nightly git snapshot with ldap_schema = ad in use the same operation takes over six minutes.

Logs with confidential information sent in private e-mail.


Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.0
rhbz: => 0

Fields changed

milestone: SSSD 1.9.0 => SSSD 1.9.0 RC1

Fields changed

owner: somebody => sgallagh
proposed_priority: => Blocker
status: new => assigned

Fields changed

proposed_priority: Blocker => Undefined

We suspect that the issue here is that the customer in question is running AD in its default mode, which does not provide LDAP indexes for the {{{member}}} and {{{memberOf}}} attributes. We have asked the customer to enable these indexes. We're awaiting the results, but we expect this to provide several orders of magnitude of improved performance.

In that case, we'll change this to a documentation bug to recommend enabling these indexes.

I've done limited testing of this on my own AD setup (which is much smaller than this customer's setup) and found a sizeable performance boost by indexing.

I don't think this can be relegated to a documentation bug. A goal is to make RHEL work out of the box with Active Directory.

It would be one thing if the sssd fails with some esoteric AD configuration. But if it falls over with a default AD setup, and requires changes on the AD side to fix it, then that can't really be considered 'work out of the box'.

Is there another way to fix this issue?

Yes, there is another way to fix this issue, but it's very complicated. AD provides much faster responses for requests coming in via MSRPC communication. It appears that the internal mechanism used to answer such requests are indexed (and very fast) when coming through that channel, but a default AD install uses no indexing in the LDAP implementation.

So yes, we can eventually support communication via MSRPC, but this is a major undertaking.

The alternative to consider is the global catalog. The use of the MSRPC or global catalog falls into the feature parity effort with Winbind so it is a core requirement for the next release.

milestone: SSSD 1.9.0 beta 7 => Temp milestone
proposed_priority: Undefined => Core

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: Temp milestone => SSSD 1.10 beta

Fields changed

priority: blocker => critical

It seems clear that there's evidence (tests run at the customer, 1) that indexing doesn't change much on AD, that's not a solution here. And there is also evidence that LDAP_MATCHING_RULE_IN_CHAIN (2) doesn't scale even in environments with thousands of users and groups (3) and we're talking about magnitudes larger environment here.

However, Token-Groups (4) would seem to be potential candidate to solve the issue, few Windows developers have blogged about good results with it in the past (3,5) and initial testing at the customer shows that it provides the expected group membership results in a fraction of a second.

1) http://us.generation-nt.com/answer/scared-index-attributes-help-37304842.html [[BR]]
2) http://msdn.microsoft.com/en-us/library/aa746475%28v=vs.85%29.aspx [[BR]]
3) http://www.funkycoding.com/?p=345 [[BR]]
4) http://msdn.microsoft.com/en-us/library/windows/desktop/ms680275%28v=vs.85%29.aspx [[BR]]
5) http://explodingcoder.com/blog/content/how-query-active-directory-security-group-membership [[BR]]

Patch submitted that allows the use of tokenGroups for lookups when SSSD is configured for ID-mapping. We cannot currently support this option for non-id-mapped configurations because the tokenGroups are stored as SIDs, not DNs.

patch: 0 => 1

Fields changed

milestone: SSSD 1.10 beta => SSSD 1.9.0

master:
- e6ba224
- d0e0e73

resolution: => fixed
status: assigned => closed

Metadata Update from @myllynen:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.9.0

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2397

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata