An example configuration followed by an explanation:

<ldap refreshIntervalMinutes="120" maximumDeletionPercentage="0">
 <ldap-provider
 url=ldap://server.example.com:389/dc=domain,dc=example,dc=com
 key="username"
 searchFilter="(objectClass=user*)"
 defaultRoles="true"
 adoptUsers="true"
 matchUsersMode="username">

 <ldap-authentication
 type="simple"
 principal="cn=%,ou=example,dc=test,dc=example,dc=com"/>
 <ldap-query-user name="queryuser" credentials="pass"/>
 <ldap-attribute name="username" id="sAMAccountName"/>
 <ldap-attribute name="fullname" id="displayName"/>
 <ldap-attribute name="email" id="mail"/>
 <ldap-ignore id="sAMAccountName" value="XYZ"/>
 </ldap-provider>
 ...
 </ldap>

Explanation:

Stages synchronizes every 120 minutes with the LDAP-provider. Of all Stages users that should have been synchronized, but could not, none is deleted. The Stages username is used for authentication with the LDAP-provider at the login (key=“username”). Every LDAP-object where the attribute “objectClass“ starts with the word “user“ is a candidate for synchronization (searchFilter=“(objectClass=user*)”). All imported users are assigned to the default role.

Existing Stages accounts that have not been synchronized with LDAP yet are adapted so that future authentications/synchronizations will be done via the LDAP-provider. These accounts are adapted, if the value of the attribute sAMAccountName matches the Stages username (adoptUsers=“true”, matchUsersMode=“username”). Further on the mapping between the LDAP sAMAccountName and the Stages username is defined (<ldap-attribute name=“username” id=“sAMAccountName”/>).

A schema defines how the name for the authentication is build (principal=“cn=%,ou=example,dc=test,dc=example,dc=com”). “%“ will be replaced by “username“.

The user for the LDAP-queries is named “queryuser“ and has the password “pass“ (<ldap-query-user name=“queryuser” credentials=“pass”/>).