ILIAS can directly use LDAP services for authentication and transfer of some configuration settings. This can be useful if the user accounts are managed in a central LDAP store like Active Directory ® . Some basic knowlege of LDAP, LDAP naming conventions and your LDAP Service and its implementation are more than useful for successful activation of this authentication method.
 
To prepare for this configuration, you need:

• The LDAP server's URL with DNS name or IP address
• The distinguished name of the Container that holds the user accounts
• The distinguished name of the Container for group accounts, if used
• A user account that is allowed to read LDAP data and this account's password, if anonymous bind is not allowed
• A list of ilias-roles that are to be used by the LDAP users

Configuration is done on the LDAP tab of the authentication page.
The steps required are:

In this settings you configure basic connectivity and enable LDAP authentication.  Name the configuration (this has no effect on authentication) and fill in the Server URL. Both IP and DNS name should work the standard LDAP port is 389. If the LDAP source is on a non-local net security issues have to be considered and lpaps should be used.
The BaseDN must reflect the top container that holds any objects such as users and groups. We use our Active Directory DNS Domain Name in LDAP-notification (DC=mydomain,DC=mySecondLevelDomain,DC=myTLD) in our configuration to be able to see all domain objects in our Ilias installation. Remember: LDAP uses "," as separator!

Since our LDAP Service is reached by a secured server network, TLS is not required. We have created a "LDAP-Proxy-user" who is allowed to see all Objects to authenticate to the Active Directory ® service, the complete distinguished Name (cn=Myuser,ou=Myou,DC=mydomain...) is needed here. The password must be entered twice, too.
On the Active Directory ® side the user account was created with no time restrictions, user cannot change password, no password change required as settings. Tha password must be documented but kept in a safe place, of course.
The user-login should be testet before continuing.

Here you need to fill in the top container holding the user accounts. Search setting "sub" tells to recursively serarch the container tree.
You have to know which attribute holds the (unique) user account name, in case of Active Directory ® this is "samaccountname". I got the advice not to use a spelling with capital an small letters.

The group filter can restrict the creation of ILIAS accounts to a group membership. Use this if you have users in various containers, but not all users may use ILIAS. If you dont have requirements here you can leave everything empty.

At last standard roles are assigned to LDAP users, and here you decide if ilias user accounts are created by cron-job or at first login to ILIAS.
There are some design considerations for this entry:

• cron-jobs may automatically create user-accounts even if there is no login, so roles can be assigned or course- and groupmemberships created in advance.
• account creation on login avoids creation of unused accounts but requires users to login prior to assignments

After these settings are completed, switch to the authentication tab. Here you decide, if users can select their authentication method or if a fixed order of methods is used. If you use a fixed order of login methods, usually place ILIAS database behind LDAP so ILIAS tries to use LDAP before checking locally stored passwords.

LDAP queries can be used in a multi-domain environment within a forest. To bring this to work, select a domain controller working as "global catalog" an use port number 3268 instead of 389.