Version upped

Parse AD bind error messages for more info for the user

This is mainly to tell users when their password expired or needs to be
changed.

Version upped

fix potential issue where attributes return null

Version upped

prefer userPrincipalName over samAccountName

This allows for longer usernames than 20 chars.

This assumes that all userPrincipalNames use the same Domain as
configured in the plugin. If that's not

prefer userPrincipalName over samAccountName

This allows for longer usernames than 20 chars.

This assumes that all userPrincipalNames use the same Domain as
configured in the plugin. If that's not the case things will probably
not work or behave strangely.

show more ...

automatic code style fixes

Version upped

better debugging and handling of suffix

People tend to configure the suffix with a prepended @. This will fail
logins in non-obvious ways. We now strip the @ prefix and also give the
connecting user

better debugging and handling of suffix

People tend to configure the suffix with a prepended @. This will fail
logins in non-obvious ways. We now strip the @ prefix and also give the
connecting user in the debug message

show more ...

Version upped

fix error when plugin is enabled but not configured

In this case the action handler should not be registered.

Version upped

implement password expiry warnings. fixes #4

update test action

Version upped

support password changes

Internally this also changes the behviour to stay authenticated as the
actual user if the user logged in. This is needed to allow self-service
password changes.

This commit

support password changes

Internally this also changes the behviour to stay authenticated as the
actual user if the user logged in. This is needed to allow self-service
password changes.

This commit also contains a few cleanups.

show more ...

dependencies updated

minor cleanup

Version upped

Delete PHILOSOPHY.md

this is now moved to a DokuWiki page

make use of file system caching optional

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 ...

fix the double call to getUserGroups()

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 ...

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 ...