| e7339d5a | 29-Jul-2021 |
Andreas Gohr <andi@splitbrain.org> |
Local handling of nested groups
All previous attempts to handle nested groups in a performant matter
failed. Neither recursive requests nor using the
LDAP_MATCHING_RULE_IN_CHAIN mechanism were suffi
Local handling of nested groups
All previous attempts to handle nested groups in a performant matter
failed. Neither recursive requests nor using the
LDAP_MATCHING_RULE_IN_CHAIN mechanism were sufficently fast enough to do
bulk requests on users.
This now takes a completely different approach. When recursive groups
are enabled, a single (paged) request for all groups is done. The list
of these groups together with their parent info is then used to resolve
any nested group memberships.
The group cache is saved in filesystem for the duration of the security
timeout configuration.
Future enhancements should:
* see if the cache class could also be used for other caches currently
implemented in Client.php
* make the use of filesystem caching configurable
show more ...
|
| 7a36c1b4 | 28-Jul-2021 |
Andreas Gohr <andi@splitbrain.org> |
add support for nested groups when filtering users by group
And this is where we hit the performance problems. A naive approach is
to simply run a query using LDAP_MATCHING_RULE_IN_CHAIN on the memb
add support for nested groups when filtering users by group
And this is where we hit the performance problems. A naive approach is
to simply run a query using LDAP_MATCHING_RULE_IN_CHAIN on the memberOf
attribute. But this is super slow (thanks Microsoft!)
Instead we first look up the given filter groups (to allow for substring
matching), then resolve them recursively and then build a or filter for
all found groups.
Still takes about 3 to 4 seconds :-/
show more ...
|
| f17bb68b | 28-Jul-2021 |
Andreas Gohr <andi@splitbrain.org> |
new approach for recursive groups
Instead of implementing the recursion client side, we ask the AD server
to resolve nested group memberships for us. This saves potentially many
network requests but
new approach for recursive groups
Instead of implementing the recursion client side, we ask the AD server
to resolve nested group memberships for us. This saves potentially many
network requests but may have performance penalties on the AD server
side. However it ensures, we can't make a mistake and thus makes our
code safer to run - also turns out my first attempt was checking nested
groups backwards.
See https://stackoverflow.com/q/40024425 for more discussions on
performance for this.
A config option allows to use the former much faster approach for setups
without nested groups.
Still to do: supporting user lookups by group this way.
show more ...
|
| a1128cc0 | 08-Jul-2021 |
Andreas Gohr <andi@splitbrain.org> |
rework username handling
Background Info
---------------
Active Directory has at least three different way how users are
identified:
1) sAMAccountName: user
The sAMAccountName is what users usual
rework username handling
Background Info
---------------
Active Directory has at least three different way how users are
identified:
1) sAMAccountName: user
The sAMAccountName is what users usually know as their username. It's
what they usually log in with on their workstation. It is however
lacking the actual domain to which to login. Typically it is prefixed by
a netbios domain for login. Eg. DOMAIN\user
Note: The samaccount name is also limited to 20 characters because of
legacy reasons.
2) userPrincipalName: user@domain.something
The userPrincipalName contains something that looks like a domain. But
it may be actually different to the Domain managed by the AD. Because
of... reasons? See https://serverfault.com/a/928116
3) bind ID: user@domain.ext
Now, loggin in (eg. doing a LDAP bind) can use different mechanisms. The
userPrincipalName works, user@domain (different from the UPN) should
work too.
DokuWiki requirements:
----------------------
In DokuWiki we need a unique username, that stays the same on every
login. (logging in with or without the domain part should identify the
same user).
We also need this name to be usable to run additional LDAP queries. Eg.
find groups with this user name.
We also want users to be able to login without having to type the domain
part.
This patch
----------
So with this patch we use the samaccount name to identify a user. For
logging in, we add the configured account suffix (aka the domain). After
that we only use the domainless user name everywhere.
In a future update we may (re)introduce the multidomain support from
authAD. When we do, this will probably force us to use the suffix part
in the usernames to different different domain users (something the
authAD plugin doesn't do which is probably wrong). But for most people
the single suffix approach should be fine.
show more ...
|