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.

fix potential issue where attributes return null

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

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

implement password expiry warnings. fixes #4

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

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

first go at recursive group memberships

disable logout for SSO setups

first go at SSO

This basically copies the functionality from authAD

another workaround for preg quoting

avoid duplicating defaults

We need the defaults in the Client for better testability, but instead
of defining them twice, we can simply load the defaults file ourselves.

make the primary group configurable

Because the Domain Users group can be localized, this makes it
configurable. The authAD library had a config to use "real" primary
groups where it would look up t

make the primary group configurable

Because the Domain Users group can be localized, this makes it
configurable. The authAD library had a config to use "real" primary
groups where it would look up the primary group by calculating the SID
and doing another check. We could copy that mechanism if needed later
on.

show more ...

group handling improvements

* properly handle uppercase group names
* use constants for filter types
* properly handle Domain Users lookups

improve logging mechanisms

Makes use of the new error logging mechanism when running on master,
uses allowdebug to print end user messages.

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

only fetch the attributes we need

this should lower the memory requirements and might speed things up a
bit

allow fetching of additional user attributes

Currently we reuqest all attributes from the server and only filter
later. This needs fixing.

clean up group filter strings

As mentioned in splitbrain/dokuwiki#3028 the data passed in filters is
ill defined currently. This is a very very simple workaround for strings
passed by cosmocode/grou

clean up group filter strings

As mentioned in splitbrain/dokuwiki#3028 the data passed in filters is
ill defined currently. This is a very very simple workaround for strings
passed by cosmocode/groupusers

show more ...

fix admin user access