On Tue, 2012-06-05 at 03:21 +0000, GOLLSCHEWSKY, Tim wrote:
> In the generic case, the DN might simply look like
"cn=name,ou=accounts,dc=example,dc=com" and then only a lookup can tell
if it's a user or a group. > What I was telling Tim earlier was that we
might want to do the LDAP-search based heuristics also in cases when
the group and user containers are distinct, > such as
"ou=Users,dc=example,dc=com" and "ou=Groups,dc=example,dc=com".
Just to add to this, I think a lot of organisations with largeish AD
directories would have their set up like this (Accounts and Groups in
separate OUs). It's just too messy to do it otherwise.
It sounds like this happens by default with IPA, if there was some way
we could enable this for AD as well (perhaps with a config option that
specified the OUs for Accounts and Groups), this would save SSSD from
doing the ldap searches just to distinguish if the record is a user or
group, and would be a huge win for performance.
Well, as Jakub suggested, one thing that might be possible is to examine
the user and group search bases[*] to see if there is zero overlap. If
this is the case, then we can optimize by checking the member DN against
those bases. However, if there is any overlap (e.g. they are both set to
the generic ldap_search_base) then we have to take the slower approach.
I've opened https://fedorahosted.org/sssd/ticket/1366
to track this
[*] The catch here is that we support multiple search bases for users
and groups, so this means we would need to ensure that there was no
overlap among ANY of them.