archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Ziesemer <>
Subject Unable to integrate user authentication to Active Directory using LDAP in 2.2.0
Date Wed, 29 Apr 2015 04:33:24 GMT
I haven't been able to upgrade from 1.3.5 and find a working LDAP
configuration yet (with MS AD, anyway).  Giving 2.2.0 another go, and
running into issue after issue.  I'm hoping to collaborate to arrive at a
working configuration - and to also consider any improvements that can be
made here to result in a better experience for other such users as well.

batkinson was kind enough to spend some time looking at this with me on IRC
earlier this evening, and he asked that I provide this here.  It sounds like
some of Olivier Lamy's time would be much appreciated here.  To recap:

Caused by: java.lang.NullPointerException
  at javax.naming.NameImpl.<init>( ~[?:1.8.0_45]
  at javax.naming.CompositeName.<init>([?:1.8.0_45]
  at org.apache.archiva.redback.common.ldap.role.DefaultLdapRoleMapper

batkinson indicated that the offending line is  However,
we were both confused as to why getAllGroups is even being called here - or
DefaultLdapRoleMapper at all, for that matter.  Under the
"Redback Runtime Configuration" UI:
- UserManager(s) chosen
  - Database User Manager
  - LDAP User Manager
- Available User Managers: (None)
- RbacManager(s) chosen
  - Database RBac Manager
- Available RbacManagers
  - LDAP RBac Manager

A bunch of notes / process:

1) Fire up a new standalone instance using .
2) Create default admin user / password.
3) Under Users / Users Runtime Configuration ("Redback Runtime
Configuration") / LDAP:  Configure host, port, check "Writable LDAP",
baseDN, Base Dn for groups, bindDn, password, check "Enabled LDAP
authentication", and leave all other defaults.  Click "Verify LDAP changes",
see "Ldap connection verified".
4) Try "Verify LDAP configuration on server side."  See "An error has
happened you must contact the administrator to check the logs."  Save first,
try again, successfully verified.  (Should this be a separately tracked bug?)
5) Enable the LDAP User Manager.  Test, observe failing logins.  I've seen
this before, even in 1.3.5 - as some of the LDAP attribute mappings need to
be updated for AD.  Go to the "Properties" UI:
  - Update ldap.config.mapper.attribute.fullname to cn .
  - Update to sAMAccountName .
  - Update ldap.config.mapper.attribute.user.object.class to
organizationalPerson .
6) Re-enable the LDAP User Manager.  See "An error has happened you must
contact the administrator to check the logs.".  Again, worked-around by
simply restarting Archiva.
7) Archiva already starts failing with the getLdapGroups stack trace.
8) I had looked at something similar here with a prior release since 1.3.5,
and remembered tweaking some of the settings in archiva.xml.  Stop Archiva,
comment out the following lines, then restart:
9) Restart Archiva. "LDAP User Manager" can now be moved to "UserManager(s)
chosen" without any errors on UI or in archiva.log.
10) I can successfully login using my LDAP account.  ("Welcome mziesemer"
shows in header.)  However, this is followed by an error at the top of the UI:
[Unable to find RBAC Object 'mziesemer' of type
org.apache.archiva.redback.rbac.jdo.JdoUserAssignment using fetch-group 'null']
This correlates with an entry in archiva.log:

Caused by: javax.jdo.JDOObjectNotFoundException: No such database row
  at org.jpox.state.StateManagerImpl.loadFieldsInFetchPlan
  at org.jpox.state.StateManagerImpl.validate
  at org.jpox.AbstractPersistenceManager.getObjectById
  at org.jpox.AbstractPersistenceManager.getObjectById
  at org.jpox.AbstractPersistenceManager.getObjectById
  at org.apache.archiva.redback.rbac.jdo.JdoTool.getObjectById
  at org.apache.archiva.redback.rbac.jdo.JdoRbacManager.getUserAssignment
  ... 54 more

Not sure where to proceed from here.


A) The AD instance to which I'm connecting has well over 1,000 users in it,
scattered across multiple OU's.  In 1.3.5, I was able to apply a
ldap.config.mapper.attribute.user.filter to restrict this to users who were
members of a specified AD security group - but this no longer seems to be
working, either.
B) references a that no longer exists.

Thanks in advance!

View raw message