LDAP directories
| Administration Page | Application/Contract | Syracuse/Collaboration | Class | ldaps | Representation | ldap |
|---|
When a user starts the application, the application must know whether the user is entitled to use the application and must identity the user. There are essentially four types of authentication:
This page describes the LDAP authentication setting.
| Principles of LDAP authentication | LDAP configuration | Connection test | User import from LDAP |
The user types a name and password in the application login screen (usually basic authentication). Then the following authentication steps are used:
If there is no instance in the users entity for the login name, the user cannot log in.
If there is an instance of the users entity, the system will perform an LDAP search for the user's distinguished name that identifies the user in the LDAP structure. If an authentication name is provided, this name will be used for the search; otherwise, the login name will be used.
If the entry is found, an LDAP authentication will be performed with the distinguished name and the password. If the authentication succeeds, the user can use the application.
The following information must be entered for the definition of an LDAP authentication server:
Name
The name used to reference the LDAP setup.
Display name
A user-friendly description.
Active
If the check box is cleared, the server is considered as inactive and no login is possible using this setup.
URL
Defines the LDAP server name, port, and protocol (for example,
ldap://vil-ldap:3268).DN for searching
This is the distinguished name of an LDAP user which has the right to search the LDAP tree. This user should not have more rights because it is more "public" than the usual users.
Note: anonymous binding is not supported.
Password for search DN
The password for the user in the previous field.
Search base
This field defines the root of the subtree within the LDAP structure in which the search will be performed.
Search filter
This field defines the search condition for the user for authentication. On an active directory server it will often look like
(sAMAccountName={{username}}). The substring{{username}}will automatically be replaced by the login name or the authentication name above to perform the search. The condition must be such that when{{username}}has been replaced (at run-time during authentication), the corresponding user must be uniquely determined (because otherwise, authentication will usually not work).Sync search filter
This field defines a search filter for importing user data from the LDAP (see below). This is quite different from "search filter" above - the "search filter" is to find a unique LDAP user, this filter will specify a range of users (in particular,
{{username}}does not make any sense here!). When it is empty, the value of "Search filter" above will be taken after replacing{{username}}with*.Mapping for authentication name
This field contains the name of the LDAP attribute which corresponds to the authentication name property (and in most cases, the login name) of the user entity. This must be set and must be an existing LDAP attribute of all users when you want to import users from LDAP. When you use Active Directory, the value is typically
sAMAccountName. You may select the name from a list of LDAP attributes which will be obtained from LDAP at runtime. For this, the above fields of the LDAP server have to be already saved in the database. You can also enter another LDAP attribute attribute directly. You may also enter another name which is not contained in the list.Mapping for first name
This field contains the name of the LDAP attribute which corresponds to the first name property of the user entity, when you want to import users from LDAP. You may select an attribute from a list in the same way as above for the mapping for the authentication name. The value is typically
firstName.Mapping for last name
This field contains the name of the LDAP attribute which corresponds to the last name property of the user entity, when you want to import users from LDAP. You may select an attribute from a list in the same way as above for the mapping for the authentication name. The value is typically
sn.Mapping for email
This field contains the name of the LDAP attribute which corresponds to the mail property of the user entity, when you want to import users from LDAP. You may select an attribute from a list in the same way as above for the mapping for the authentication name. The value is typically
Mapping for photo
This field contains the name of the LDAP attribute which corresponds to the photo property of the user entity, when you want to import users from LDAP. You may select an attribute from a list in the same way as above for the mapping for the authentication name. When you use Active Directory, the value is typically
thumbnailPhoto.
This service tries to connect to the LDAP server using the entered authentication data and then disconnects from the LDAP server. Any errors during this process (e. g. wrong password) will be shown.
An LDAP server contains more information about users than necessary for authentication. User data can be imported from an LDAP server into the user entity.
The attribute names in LDAP and in the user entity are different. Therefore, you have to enter the corresponding LDAP attribute names for the authentication name, given name, last name, email, and photo properties into the fields "Mapping for authentication name", "Mapping for given name", "Mapping for last name", "Mapping for email", "Mapping for photo" above.
To run this function, the current LDAP entry must be active and you must have write access to the user data. If this is the case, the program will perform the following processing:
Authentication name if the user has LDAP authentication selected by default and if the field is not empty; otherwise, it will be the login code.login name is the same as the value of the authenticationName, a login name will be created as follows: authenticationName will not be changed because it is used for LDAP authentication. The above mechanism for existing users guarantees that user data will be updated correctly when this function is called again. If a new user has been created by another connection while the searching user entity process is in progress, there will be an error message. There is no loop that tests each possible combined user name, whether it has already been created, so that endless loops will not be possible under all circumstances.At the end, when all users are managed, all error messages will be displayed.