archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harris, Christopher P" <>
Subject Re: Unable to integrate user authentication to Active Directory using LDAP in 2.2.0
Date Wed, 29 Apr 2015 11:03:07 GMT
Hi, Mark.

I'm a fellow Archiva user, and you have described my Archiva/AD woes down to the exact details.
 Our AD instance is huge (80,000) and users are scattered all over the place according to
region instead of following a hierarchy.  I can log into Archiva using LDAP auth, but I can't
view any links due to my group role auth mapping not being honored.

The reason that I'm chiming in to the conversation is because I have a JIRA (MRM-1876) already
filed that seems to fit this situation.  Perhaps you, Brett, and Olivier can piggyback off
of it and use it while resolving this issue.

Good luck.  I hope you guys can figure this issue out.

Btw, if you also create Archiva accounts, within a database, with usernames that match your
AD username, you end up with MRM-1816.  You can log in and actually gain auth to restricted
UI sections for a short time that ranges from 5-15 minutes, but you eventually end up with
the error message described in that JIRA.

 - Sent from my iPhone

Chris Harris

> On Apr 28, 2015, at 11:36 PM, Mark Ziesemer <> wrote:
> 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
>    ([?:1.8.0_45]
>  at org.apache.archiva.redback.common.ldap.role.DefaultLdapRoleMapper
>      .getAllGroups
>  ([redback-common-ldap-2.3.jar:2.3]
>  at
>      .getLdapGroups
>    (
>      ~[redback-rest-services-2.3.jar:2.3]
> 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:
> <groups>
> <member>uniquemember</member>
> <class>groupOfUniqueNames</class>
> </groups>
> 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
>    ([jpox-1.1.9-1.jar:1.1.9]
>  at
>    ([jpox-1.1.9-1.jar:1.1.9]
>  at
>    ([jpox-1.1.9-1.jar:1.1.9]
>  at org.jpox.state.StateManagerImpl.loadFieldsInFetchPlan
>    ([jpox-1.1.9-1.jar:1.1.9]
>  at org.jpox.state.StateManagerImpl.validate
>    ([jpox-1.1.9-1.jar:1.1.9]
>  at org.jpox.AbstractPersistenceManager.getObjectById
>    ([jpox-1.1.9-1.jar:1.1.9]
>  at org.jpox.AbstractPersistenceManager.getObjectById
>    ([jpox-1.1.9-1.jar:1.1.9]
>  at org.jpox.AbstractPersistenceManager.getObjectById
>    (.java:2580)~[jpox-1.1.9-1.jar:1.1.9]
>  at org.apache.archiva.redback.rbac.jdo.JdoTool.getObjectById
>    ([redback-rbac-jdo-2.3.jar:2.3]
>  at org.apache.archiva.redback.rbac.jdo.JdoRbacManager.getUserAssignment
>    ([redback-rbac-jdo-2.3.jar:2.3]
>  at
>    ([archiva-web-common-2.2.0.jar:2.2.0]
>  ... 54 more
> Not sure where to proceed from here.
> Also:
> 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