• [SOLVED] Problems with access rights on Active Directory

  • OpenKM has many interesting features, but requires some configuration process to show its full potential.
OpenKM has many interesting features, but requires some configuration process to show its full potential.
Forum rules: Please, before asking something see the documentation wiki or use the search feature of the forum. And remember we don't have a crystal ball or mental readers, so if you post about an issue tell us which OpenKM are you using and also the browser and operating system version. For more info read How to Report Bugs Effectively.
 #16811  by fabpicca
 
hello everybody,
I'm trying to integrate OKM with our AD and I have to say that almost works pretty good.
The only real issue I have is with nested groups on Active Directory.
Let me explain.

Our AD structure is almost like this:
Code: Select all
dc=it
   dc=mycompany
      ou=authorizations
      ou=users
      ou=deparments
keep in mind that users are grouped by dept.

In the authorizations I've created two groups one for OKM admins and another for OKM Users, and changed web.xml in OpenKM.war accordingly.
Code: Select all
dc=it
   dc=mycompany
      ou=authorizations
         cn=OKM Admins
         cn=OKM Users
      ou=users
      ou=deparments
         cn=dept1
         cn=dept2
         cn=dept3
Now, since I don't want to put each user under this groups, but I want to move by deparments I did something like this:
Code: Select all
dc=it
   dc=mycompany
      ou=authorizations
         cn=OKM Admins
         cn=OKM Users
            cn=dept1
            cn=dept2
      ou=users
      ou=deparments
I've tried to write both login-config.xml and preferences accordingly. So:
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://myldapserver:389</module-option>
             <module-option name="java.naming.security.authentication">simple</module-option>
             <module-option name="bindDN">CN=ldapuser, OU=users, DC=mycompany, DC=it</module-option>
             <module-option name="bindCredential">ldappwd</module-option>
             <module-option name="baseCtxDN">ou=users,dc=mycompany,dc=it</module-option>
             <module-option name="baseFilter">(sAMAccountName={0})</module-option>
             <module-option name="rolesCtxDN">ou=authorizations,dc=mycompany,dc=it</module-option>
             <module-option name="roleFilter">(member={1})</module-option>
             <module-option name="roleAttributeID">cn</module-option>
             <module-option name="roleAttributeIsDN">false</module-option>
             <module-option name="roleRecursion">4</module-option>
             <module-option name="roleNameAttributeID">cn</module-option>
             <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
             <module-option name="allowEmptyPasswords">false</module-option>
          </login-module>
       </authentication>
    </application-policy>
while preferences are:
Code: Select all
principal.adapter = com.openkm.principal.LdapPrincipalAdapter	    
principal.database.filter.inactive.users = 
principal.ldap.mail.attribute = mail	    
principal.ldap.mail.search.base = ou=users,dc=mycompany,dc=it	    
principal.ldap.mail.search.filte r= (&(objectClass=person)(sAMAccountName={0}))	    
principal.ldap.referral = follow	    
principal.ldap.role.attribute = cn	    
principal.ldap.role.search.base = ou=departments,dc=mycompany,dc=it	    
principal.ldap.role.search.filter = (objectClass=group)	    
principal.ldap.roles.by.user.attribute = memberOf	    
principal.ldap.roles.by.user.search.base = dc=mycompany,dc=it	    
principal.ldap.roles.by.user.search.filter = (&(objectClass=person)(sAMAccountName={0}))	    
principal.ldap.security.credentials = ldappwd	    
principal.ldap.security.principal =  cn=ldapuse,ou=users,dc=mycompany,dc=it	    
principal.ldap.server	= ldap://myldapserver:389	    
principal.ldap.user.attribute = sAMAccountName	    
principal.ldap.user.search.base = ou=users,dc=mycompany,dc=it	    
principal.ldap.user.search.filter	= (objectClass=person)	    
principal.ldap.username.attribute =  cn	    
principal.ldap.username.search.base = OU=users, DC=mycompany, DC=it	    
principal.ldap.username.search.filter	= (&(objectClass=person)(sAMAccountName={0}))	    
principal.ldap.users.by.role.attribute	= member	    
principal.ldap.users.by.role.search.base = dc=mycompany,dc=it	    
principal.ldap.users.by.role.search.filter = (&(objectclass=group)(sAMAccountName={0}))	    
The explanation for this kind of setup is that I want just some departments to be OKM Users and then I want to create
at repository level department based access roles.

The issue here is that it seems that the login module of OKM doesn't allow users part dept1 and dept2 (thus OKM Users) to enter the application.
Opposite to this, if I give some users explicit memebership to OKM Users, they get to the app safe and sound (but don't respect my auth rules).

What I'm doing wrong here?
Thanks a lot for your support!
Last edited by fabpicca on Tue Jun 12, 2012 3:59 pm, edited 1 time in total.
 #16831  by jllort
 
First concentrate with login-config.xml

If you're on windows active directory ( ldap ) you get some properties like sAMAccountName={0} is this your scenarios

You should create UserRole and AdminRole and assign no user, I suggest for starting do not change web.xml, if you want to make this kind of changes do it after authentication will be correctly, otherside we're playing with so much variables at same time.

In job-log4j.xml ( at conf dir ) add to trace whatdo you get with login-config.xml ( remember each time you time this file should restart jboss )
Code: Select all
<category name="org.jboss.security">
    <priority value="TRACE" class="org.jboss.logging.XLevel"/>
</category>
 #16848  by fabpicca
 
We activated the trace as suggested, and what I can understand here is that if a user is member of let's say dept2 (following my previous example), the login module, assigns userRole, since it actually matches with the default user role. The point is that since that is the only membership that gets fetched, there's no way to work with other roles that are assigned to the user.

Is there a way to understand which roles a logged user has assigned after loigin?

Thanks!
 #16851  by fabpicca
 
We actually solved the problem reviewing the structure of our groups in AD, that seems to be the only viable options, since groups coming from different LDAP branches seems not to be retrieved correctly. This is definitively not an OpenKM issue, but rather an LDAP limitation.

About Us

OpenKM is part of the management software. A management software is a program that facilitates the accomplishment of administrative tasks. OpenKM is a document management system that allows you to manage business content and workflow in a more efficient way. Document managers guarantee data protection by establishing information security for business content.