Page 1 of 1

Working OpenLDAP configuration, some questions

Posted: Fri Apr 23, 2010 9:14 pm
by akorn
Hi,

based on the wiki and some posts in this forum I think I managed to configure OpenKM 4.1RC1 for LDAP based authentication. I'm now contributing my configuration because it wasn't easy to come up with; also, I have some questions about it.

My OpenKM.cfg reads as follows:

Code: Select all

default.user.role=UserRole
default.admin.role=AdminRole
system.ocr=/usr/bin/tesseract
system.openoffice=on
system.pdf2swf=/path/to/jboss-4.2.3.GA_OpenKM-4.1_RC1/bin/pdf2swf
system.demo=off
system.readonly=off
system.antivir=/usr/bin/clamscan
restrict.file.mime=off
restrict.file.extension=*~,*.bak,._*
max.file.size=25
principal.adapter=es.git.openkm.principal.LdapPrincipalAdapter
principal.ldap.security.principal=cn=admin,dc=mydomain,dc=net
principal.ldap.security.credentials=adminpassword
principal.ldap.server=ldap://ldap.mydomain.net
principal.ldap.search=dc=mydomain,dc=net
principal.ldap.user.search.base=ou=People,dc=mydomain,dc=net
principal.ldap.user.search.filter=(&(objectclass=inetOrgPerson)(memberOf=cn=UserRole,ou=Group,dc=mydomain,dc=net))
principal.ldap.role.search.base=ou=Group,dc=mydomain,dc=net
principal.ldap.role.search.filter=(objectclass=groupOfNames)
principal.ldap.role.atribute=cn
principal.ldap.user.atribute=uid
principal.ldap.mail.search.base=uid={0},ou=People,dc=mydomain,dc=net
principal.ldap.mail.search.filter=(objectclass=inetOrgperson)
principal.ldap.mail.atribute=mail
system.login.lowercase=off
Questions about this part:

* I can't just change default.user.role and default.admin.role, without modifying the web.xml file of the OpenKM webapp, right?
* What is principal.ldap.security.principal used/needed for? My directory allows anonymous binds. I'm not comfortable including the LDAP admin password in OpenKM.cfg. Maybe some restricted LDAP object would be sufficient? From what I saw so far, it's only used for searching, so perhaps an anonymous bind would work as well?

The relevant part of my login-config.xml reads as follows:

Code: Select all

    <application-policy name="OpenKM">
       <authentication>
          <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required" >
            <module-option name="java.naming.provider.url">ldap://ldap.mydomain.net:389</module-option>
            <module-option name="java.naming.security.authentication">simple</module-option>
            <module-option name="baseCtxDN">ou=People,dc=mydomain,dc=net</module-option>
            <module-option name="baseFilter">(&(uid={0})(memberOf=cn=UserRole,ou=Group,dc=mydomain,dc=net))</module-option>
            <module-option name="rolesCtxDN">ou=People,dc=mydomain,dc=net</module-option>
            <module-option name="roleFilter">(uid={0})</module-option>
            <module-option name="roleAttributeID">memberOf</module-option>
            <module-option name="roleNameAttributeID">cn</module-option>
            <module-option name="roleAttributeIsDN">true</module-option>
            <module-option name="roleRecursion">2</module-option>
            <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
            <module-option name="allowEmptyPasswords">False</module-option>
          </login-module>
       </authentication>
    </application-policy>
This assumes that:

* OpenLDAP is using the RFC2307bis schema instead of the nis schema (only required if you want your openkm roles to double as posix groups, or vice versa);
* you have enabled the "memberof" overlay in slapd.conf;
* the "roles" are represented by groupOfNames objects.

Note that, perhaps somewhat counter-intuitively, the base DN of the groups (which in my case would be ou=Group,dc=mydomain,dc=net) isn't referenced in the JAAS configuration at all; instead, rolesCtxDN must be set to the base DN of the subtree containing the users, because we're using their memberOf attributes to find out what roles they have.