Searched hist:a1128cc0f2573cbe769f582d613c9ccb9fc94dee (Results 1 – 3 of 3) sorted by relevance
| /plugin/pureldap/ |
| H A D | auth.php | a1128cc0f2573cbe769f582d613c9ccb9fc94dee Thu Jul 08 09:33:55 UTC 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 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.
|
| /plugin/pureldap/classes/ |
| H A D | Client.php | a1128cc0f2573cbe769f582d613c9ccb9fc94dee Thu Jul 08 09:33:55 UTC 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 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.
|
| H A D | ADClient.php | a1128cc0f2573cbe769f582d613c9ccb9fc94dee Thu Jul 08 09:33:55 UTC 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 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.
|