gnh1201/seeddms-code
1
0
Fork 0
mirror of https://git.code.sf.net/p/seeddms/code synced 2025-09-06 18:11:55 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

better formating, more info for AD

Browse Source
This commit is contained in:
Uwe Steinmann 2025-07-18 10:14:12 +02:00
parent 911684f37f
commit 82d24098aa
1 changed files with 67 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

82
doc/README.Ldap
View File

@ -10,25 +10,27 @@ regular ldap server, e.g. openldap
The location of the ldap server is specified in two parameters: `host` and The location of the ldap server is specified in two parameters: `host` and
`port`. `host` can be either a plain hostname or an ldap URI, including the `port`. `host` can be either a plain hostname or an ldap URI, including the
protocol, the host and optionally the port, e.g. ldap://localhost:389. In case protocol, the host and optionally the port, e.g. `ldap://localhost:389`. In case
of an URI the port in the configuration must remain empty. of an URI the port in the configuration must remain empty.
The authentication itself is a two step process which differs, depending on how The authentication itself is a two step process which differs, depending on how
to bind to the server. If the configuration sets 'bindDN' and 'bindPW', those to bind to the server. If the configuration sets `bindDN` and `bindPW`, those
values will be used for a initial non anonymous bind to the ldap server values will be used for a initial non anonymous bind to the ldap server
otherwise an anonymous bind is executed. otherwise an anonymous bind is executed.
After the initial bind, a ldap search for either 'uid=<username>' (ldap) or After the initial bind, a ldap search for either `uid=<username>` (ldap) or
'sAMAccountName=<username>' (AD) below basedn is done. The purpose of this `sAMAccountName=<username>` (AD) below basedn is done. The purpose of this
search is to retrieve a working bindDN which is then used to actually search is to retrieve a working bindDN which is then used to actually
authenticate the user. In case of an anonymous first bind the search will authenticate the user. In case of a successful anonymous first bind but a
likely fail and the bindDN for the second bind will be either failed search (this seems to be the case when connecting to an AD), a second
'uid=<username>,<basedn>' (ldap) or '<username>@<accountDomainName>' (AD). If non anonymous bind is tried. The bindDN for that second bind will be either
the search succeeds the bindDN will be taken from the user's data in the ldap `uid=<username>,<basedn>` (ldap) or `<username>@<accountDomainName>` (AD).
If the search after the first anonymous bind succeeds, the bindDN will be
taken from the user's data in the ldap
server. This bindDN will be used for a second bind using the users password. server. This bindDN will be used for a second bind using the users password.
If the second bind succeeds the user could be successfully authenticated. If the second bind succeeds the user is successfully authenticated.
The data from the ldap server can be used to create an account in SeedDMS The data from the ldap server can be used to create or update an account in SeedDMS
if the user trying to login does not exist yet, but was able to authenticate. if the user trying to login does not exist yet, but was able to authenticate.
This will only be done if 'authentication->restricted' in the configuration This will only be done if 'authentication->restricted' in the configuration
is set to false. In that case the common name (cn) and email address is taken is set to false. In that case the common name (cn) and email address is taken
@ -41,12 +43,37 @@ can be set with the attribute `mailField`. If it is not set it defaults to `mail
Since version 5.1.34 and 6.0.27 the groups of a user stored in the ldap directory Since version 5.1.34 and 6.0.27 the groups of a user stored in the ldap directory
can be synchronised with the groups in SeedDMS. The ldap field storing can be synchronised with the groups in SeedDMS. The ldap field storing
the groups can be configured with the attribute `mailField`. This will add the groups can be configured with the attribute `mailField`. This will add
new groups in SeedDMS and aѕsign them to the user. new groups in SeedDMS and assign them to the user.
Using email address for authentication
---------------------------------------
Since version 5.1.34 and 6.0.27 the email can be used for authentication
(requires `enableLoginByEmail` to be set in the configuration).
This only works if the search after the first bind succeeds, which is usually
only the case if it is a none anonymous bind.
Notes on connecting to an AD
-----------------------------
The ldap authentication was originally implemented for classic LDAP servers
like openldap. Before doing the actual authentication the user was searched
by combining the user's login name and the configured baseDN. This search was
preceded an anonymous or non anonymous bind (depending on wether bindDN and
bindPWD are set). The only purpose of that search was to retrieve the
distinguished name of the user, which was used in a second non anonymous bind
for authenticating the user. If that search fails or didn't return a record
(which seems to be always the case for an anonymous bind to an AD)
a second non anonymous bind with the user's credentials is tried. That bind
uses a dn which is quite different for classic ldap and AD (see examples
below). The dn for an AD is of the form '<username>@<domain>'. '<domain>' is
the string configured in the parameter `accountDomainName`.
Examples Examples
--------- ---------
Anonymous bind to openldap on localhost, port 389 ### Anonymous bind to openldap on localhost, port 389
- type = "ldap" - type = "ldap"
- baseDN = "ou=users,dc=mycompany,dc=de" - baseDN = "ou=users,dc=mycompany,dc=de"
- host = "ldap://localhost" - host = "ldap://localhost"
@ -55,12 +82,37 @@ During authentication as user 'admin' the following steps are executed
1. connect to ldap server at localhost:389 1. connect to ldap server at localhost:389
2. do an anonymous bind 2. do an anonymous bind
3. search for 'uid=admin' below basedn 3.1 if the bind succeeds, search for `uid=admin` below basedn
3.2 if the bind fails use `uid=admin,<basedn>` as dn and continue with step 5
4.1. if search succeeds use the dn from the user 4.1. if search succeeds use the dn from the user
4.2. if search fails use 'uid=admin,<basedn>' as dn 4.2. if search fails use `uid=admin,<basedn>` as dn
5. do a non anonymous bind with dn and password entered by user 5. do a non anonymous bind with dn and password entered by user
6. if step 5. succeeds the use is authenticated 6. if step 5. succeeds the user is authenticated
7. if `restricted` in the settings is *not* set another ldap search for the
user is executed to retrieve the full name, and the email and if
8.1 the user doesn't exist in SeedDMS, the user will be created or
8.2 the user exists in SeedDMS, the use will be updated
If bindDN and bindPW are specified in the configuration, the second step If bindDN and bindPW are specified in the configuration, the second step
will be a non anonymous bind. will be a non anonymous bind.
### Connecting to an AD
- type = "AD"
- baseDN = "ou=users,dc=mycompany,dc=de"
- accountDomainName=mycompany
- host = "ldap://localhost"
During authentication as user 'admin' the following steps are executed
1. connect to AD server at localhost:389
2. do an anonymous bind (which usually succeeds)
3. search for `uid=admin` below basedn (which usually returns an empty record)
4. if search returns no data use `admin@<accountDomainName>` as dn
5. do a non anonymous bind with dn and password entered by user
6. if step 5. succeeds the user is authenticated
7. if `restricted` in the settings is *not* set another ldap search for the
user is executed to retrieve the full name, and the email and if
8.1 the user doesn't exist in SeedDMS, the user will be created or
8.2 the user exists in SeedDMS, the use will be updated