Active Directory basic configuration
Since version 8.1.12, the OpenLDAP integration has changed:
- The configuration parameters and login procedure remain the same.
- User data and roles are now managed in OpenKM administration and stored in the database.
- There is a cron job called "Sync LDAP users" which synchronizes user data from LDAP to the database.
- The current configuration can be found at Active Directory mixed configuration with LDAP synced.
This is the suggested configuration to be used when roles and users are both defined in the same node, otherwise refer to another example.
LDAP structure
dc=com
dc=company
cn=users
cn=ROLE_ADMIN
member=okmAdmin
member=user1
cn=ROLE_USER
member=user3
cn=ROLE_XXXX
member=user2
cn=ROLE_YYYY
member=user4
...
sAMAccountName=okmAdmin
memberOf=cn=ROLE_ADMIN,cn=users,dc=company,dc=com
userPrincipalName=okmAdmin@mail.com
cn=OpenKM Administrator
sAMAccountName=user1
memberOf=cn=ROLE_ADMIN,cn=users,dc=company,dc=com
userPrincipalName=user1@mail.com
cn=User Name 1
sAMAccountName=user2
memberOf=cn=ROLE_USER,cn=users,dc=company,dc=com
userPrincipalName=user2@mail.com
cn=User Name 3
The OpenKM integration with LDAP has two steps. In the first step, configure OpenKM to retrieve the list of users and roles from LDAP. This list is cached for 30-45 minutes by OpenKM to prevent overloading the LDAP server. You can clear the cache via Administration > Tools > Cache stats. In the second step, configure login; this configuration always works in real time.
Step 1 - configuration parameters
We suggest logging in to OpenKM with the admin URL (for example http://localhost:8080/openkm/admin/index) because in the next steps it will be necessary to restart the OpenKM service and you do not want to lose administrative access.
The first action should be to modify principal.adapter parameter value and restart OpenKM service. Because the session ID is kept in the browser, you should not lose the login after the service is restarted and you can continue working in the administration. After this change, the users and roles lists will be empty in the administration. Until you successfully configure the next parameters, these lists will remain empty.
- Users who are members of ROLE_ADMIN or ROLE_USER are created in the users node (these should be the distinguished names CN=ROLE_ADMIN,cn=users,DC=company,DC=com and CN=ROLE_USER,cn=users,DC=company,DC=com).
- Groups can be created on any Active Directory node, because DC=company,DC=com is set as the base filter, principal.ldap.role.search.base=DC=company,DC=com.
- All Active Directory groups will be listed because no filter restriction has been applied principal.ldap.role.search.filter=(objectclass=group).
Go toAdministration > Configuration parameters:
Field / Property | Type | Description |
---|---|---|
principal.adapter | String |
The parameter is deprecated since version 8.1.12 com.openkm.plugin.principal.LdapPrincipalAdapter |
system.login.lowercase | String |
true |
principal.ldap.server | String |
ldap://192.168.0.6:389 |
principal.ldap.security.principal | String |
CN=Administrator,cn=users,dc=company,dc=local |
principal.ldap.security.credentials | String |
password |
principal.ldap.referral | String |
|
principal.ldap.users.from.roles | Boolean |
false |
principal.ldap.user.attribute | String |
sAMAccountName |
principal.ldap.user.search.base |
List |
cn=users,dc=company,dc=local |
principal.ldap.user.search.filter |
String |
(objectclass=person) |
principal.ldap.username.attribute |
String |
cn |
principal.ldap.username.search.base |
String |
cn=users,dc=company,dc=local |
principal.ldap.username.search.filter |
String |
(&(objectClass=person)(sAMAccountName={0})) |
principal.ldap.mail.attribute |
String |
|
principal.ldap.mail.search.base |
String |
cn=users,dc=company,dc=local |
principal.ldap.mail.search.filter |
String |
(&(objectClass=person)(sAMAccountName={0})) |
principal.ldap.role.attribute |
String |
cn |
principal.ldap.role.search.base |
List |
cn=users,dc=company,dc=local |
principal.ldap.role.search.filter |
String |
(objectclass=group) |
principal.ldap.roles.by.user.attribute |
String |
memberOf |
principal.ldap.roles.by.user.search.base |
String |
DC=company,DC=com |
principal.ldap.roles.by.user.search.filter |
String |
(&(objectClass=person)(sAMAccountName={0})) |
principal.ldap.users.by.role.attribute |
String |
member |
principal.ldap.users.by.role.search.base |
String |
cn={0},cn=users,dc=company,dc=local |
principal.ldap.users.by.role.search.filter |
String |
(objectclass=group) |
Step 2 - configure login
Apply changes in the openkm.properties file.
The parameter "okm.authentication.database" is used to disable database login.
The parameter "okm.authentication.ldap" is used to enable LDAP login.
#Authentication
okm.authentication.database=false
okm.authentication.ldap=true
#LDAP
ldap.server=ldap://192.168.0.13
ldap.manager.distinguished.name=CN=Administrator,CN=Users,DC=openkm,DC=local
ldap.manager.password=*secret*
ldap.base=DC=openkm,DC=local
ldap.role.attribute=cn
ldap.user.search.filter=sAMAccountName={0}
ldap.role.search.filter=member={0}
After updating the openkm.properties file, you must restart the OpenKM service for the changes to take effect.
Another option to configure login
In some cases, you might be interested in setting the configuration in the file openkm.xml; please refer to Configuring openkm.xml documentation section for more information.
<security:ldap-server id="ldapServer"
url="ldap://192.168.0.6:389/DC=ldap,dc=company,dc=local"
manager-dn="CN=Administrator,cn=users,dc=company,dc=local"
manager-password="password"/>
<security:authentication-manager alias="authenticationManager">
<security:ldap-authentication-provider
server-ref="ldapServer"
user-search-base="cn=Users"
user-search-filter="(sAMAccountName={0})"
group-search-base="cn=Users"
group-search-filter="(member={0})"
group-role-attribute="cn"
role-prefix="none">
</security:ldap-authentication-provider>
</security:authentication-manager>
<beans:bean id="userDetailService" class="com.openkm.spring.UserTenantDetailsService"/>