Page 1 of 1

Roles not registering for users in some cases

PostPosted:Thu Jan 23, 2014 8:50 pm
by morganc
I'm new to OpenKM but seem to having a fully working install wired up except for this one (major) issue.

As I was populating the repository with new data everything looked great to me. The users and groups all mapped through from LDAP (more setup details below). The users show the appropriate group lists based on LDAP. The LDAP configuration seems quite complex in OpenKM, but it seemed like I gotten it. Folder/File permissions saved just fine and when I look at the Security tab it is all setup as expected.

Then I logged in as another user. No one else can see anything except the files they uploaded. Switched back to my admin account and on a whim gave ROLE_USER read permissions to some files. Just those files will show up to other users and then only with the permissions assigned to ROLE_USER, not to their respective groups. When I view Administration > Users I see all the users from LDAP. Under the "Roles" column I see a list of roles as I would expect them. If I click on Role List I see a correct list of LDAP groups. However, if I select a role from the dropdown on the User List page and click search I get nothing back.

Can anyone see any errors in the LDAP configuration or could this be a bug somewhere? I admit the LDAP configuration is a bit cobbled together as there seem to be limited resources and support for systems that don't have a "memberOf" variable on the users. I've reviewed all the setup material on the OpenKM wiki as well a lot of other Spring LDAP configuration guides and really anywhere I could find search string setups for LDAP without memberOf. This seems to work in all the UI, but not in the final lookup for permissions, so I believe it can be done I just must have missed something I'm not seeing.

Any help is greatly appreciated!

Software Versions
OpenKM 6.2.5
Tomcat 7.0.47
Java 1.7.0_51
Mac OS X 10.9.1 with Server 3.0.1
- bundled Open Directory (Based on OpenLDAP 2.4)

LDAP Properties in OpenKM
Code: Select all
principal.adapter = com.openkm.principal.LdapPrincipalAdapter
principal.database.filter.inactive.users = true
principal.hide.connection.roles = falsee
principal.ldap.mail.attribute = mail
principal.ldap.mail.search.base = cn=users,dc=myserver,dc=org
principal.ldap.mail.search.filter = (&(objectclass=inetOrgPerson)(uid={0}))
principal.ldap.role.attribute = cn
principal.ldap.role.search.base = cn=groups,dc=myserver,dc=org
principal.ldap.role.search.filter = (objectclass=posixGroup)
principal.ldap.roles.by.user.attribute = cn
principal.ldap.roles.by.user.search.base = cn=groups,dc=myserver,dc=org
principal.ldap.roles.by.user.search.filter = (&(objectclass=posixGroup)(memberUid={0}))
principal.ldap.security.credentials = XXXXXXXXX
principal.ldap.security.principal = uid=diradmin,cn=users,dc=myserver,dc=org
principal.ldap.server = ldap://127.0.0.1
principal.ldap.user.attribute = uid
principal.ldap.user.search.base = cn=users,dc=myserver,dc=org
principal.ldap.user.search.filter = (objectclass=inetOrgPerson)
principal.ldap.username.attribute = cn
principal.ldap.username.search.base = cn=users,dc=myserver,dc=org
principal.ldap.username.search.filter = (&(objectclass=inetOrgPerson)(uid={0}))
principal.ldap.users.by.role.attribute = memberUid
principal.ldap.users.by.role.search.base = cn{0},cn=groups,dc=myserver,dc=org
principal.ldap.users.by.role.search.filter = (objectclass=posixGroup)
principal.ldap.users.from.roles = false
Spring LDAP Configuration
Code: Select all
  <!-- Security configuration -->
  <security:authentication-manager alias="authenticationManager">
    <security:authentication-provider ref="ldapAuthProvider" />
  </security:authentication-manager>

  <beans:bean id="contextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
    <beans:constructor-arg value="ldap://127.0.0.1:389/dc=myserver,dc=org"/>
    <beans:property name="userDn" value="uid=diradmin,cn=users,dc=myserver,dc=org" />
    <beans:property name="password" value="XXXXXXXX" />
  </beans:bean>

  <beans:bean id="ldapAuthProvider" class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
    <beans:constructor-arg>
      <beans:bean class="org.springframework.security.ldap.authentication.BindAuthenticator">
        <beans:constructor-arg ref="contextSource" />
        <beans:property name="userSearch" ref="userSearch" />
      </beans:bean>
    </beans:constructor-arg>
    <beans:constructor-arg>
      <beans:bean class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
        <beans:constructor-arg ref="contextSource" />
        <beans:constructor-arg value="cn=groups" />
        <beans:property name="groupSearchFilter" value="(memberUid={1})" />
        <beans:property name="groupRoleAttribute" value="cn" />
        <beans:property name="searchSubtree" value="true" />
        <beans:property name="rolePrefix" value="" />
      </beans:bean>
    </beans:constructor-arg>
  </beans:bean>

  <beans:bean id="userSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
    <beans:constructor-arg index="0" value="" />
    <beans:constructor-arg index="1" value="uid={0}" />
    <beans:constructor-arg index="2" ref="contextSource" />
    <beans:property name="searchSubtree" value="true" />
  </beans:bean>

Re: Roles not registering for users in some cases

PostPosted:Sat Jan 25, 2014 11:46 am
by jllort
The difference between Postfix and MS ActiveDirectory is that there's a bidirectional relation between groups and users. In Postfix this is not mandatory. If there's no relation between groups and users then user has no grants for OpenKM. The relation can not be inheritable - AFAIK - must be directly, node group should have memberUuid=username

You have a misconfiguration problem in your postfix, see http://wiki.openkm.com/index.php/Ldap-example1 what a full example how you should get Postfix configured.

If it's not clear you should explain here with more detail with a LDAP diagram in similar way you see in previous page.