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.

automatic code style fixes

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

remove basically unused filter converter

remove commented default methods

disable logout for SSO setups

first go at SSO

This basically copies the functionality from authAD

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

some cleanup for the options

actually use the bulk retrieval in usermanager

added bulk data retrieval

added group reading

first working login with active directory

wizard generated