You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@archiva.apache.org by Mark Ziesemer <on...@mark.ziesemer.com> on 2015/04/29 06:33:24 UTC
Unable to integrate user authentication to Active Directory using LDAP in 2.2.0
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>(NameImpl.java:283) ~[?:1.8.0_45]
at javax.naming.CompositeName.<init>(CompositeName.java:231)~[?:1.8.0_45]
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search
(PartialCompositeDirContext.java:341)~[?:1.8.0_45]
at org.apache.archiva.redback.common.ldap.role.DefaultLdapRoleMapper
.getAllGroups
(DefaultLdapRoleMapper.java:148)~[redback-common-ldap-2.3.jar:2.3]
at org.apache.archiva.redback.rest.services.DefaultLdapGroupMappingService
.getLdapGroups
(DefaultLdapGroupMappingService.java:79)
~[redback-rest-services-2.3.jar:2.3]
batkinson indicated that the offending line is http://goo.gl/BHYixD. 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 apache-archiva-2.2.0-bin.zip .
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 ldap.config.mapper.attribute.user.id 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 org.jpox.store.rdbms.request.FetchRequest.execute
(FetchRequest.java:194)~[jpox-1.1.9-1.jar:1.1.9]
at org.jpox.store.rdbms.table.ClassTable.fetch
(ClassTable.java:2552)~[jpox-1.1.9-1.jar:1.1.9]
at org.jpox.store.StoreManager.fetch
(StoreManager.java:959)~[jpox-1.1.9-1.jar:1.1.9]
at org.jpox.state.StateManagerImpl.loadFieldsInFetchPlan
(StateManagerImpl.java:1820)~[jpox-1.1.9-1.jar:1.1.9]
at org.jpox.state.StateManagerImpl.validate
(StateManagerImpl.java:4499)~[jpox-1.1.9-1.jar:1.1.9]
at org.jpox.AbstractPersistenceManager.getObjectById
(AbstractPersistenceManager.java:2726)~[jpox-1.1.9-1.jar:1.1.9]
at org.jpox.AbstractPersistenceManager.getObjectById
(AbstractPersistenceManager.java:2600)~[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
(JdoTool.java:315)~[redback-rbac-jdo-2.3.jar:2.3]
at org.apache.archiva.redback.rbac.jdo.JdoRbacManager.getUserAssignment
(JdoRbacManager.java:571)~[redback-rbac-jdo-2.3.jar:2.3]
at org.apache.archiva.web.security.ArchivaRbacManager.getUserAssignment
(ArchivaRbacManager.java:742)~[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) https://archiva.apache.org/redback/integration/ldap.html references a
security.properties that no longer exists.
Thanks in advance!
Re: Unable to integrate user authentication to Active Directory
using LDAP in 2.2.0
Posted by "Harris, Christopher P" <ch...@baxter.com>.
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 <on...@mark.ziesemer.com> 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>(NameImpl.java:283) ~[?:1.8.0_45]
> at javax.naming.CompositeName.<init>(CompositeName.java:231)~[?:1.8.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search
> (PartialCompositeDirContext.java:341)~[?:1.8.0_45]
> at org.apache.archiva.redback.common.ldap.role.DefaultLdapRoleMapper
> .getAllGroups
> (DefaultLdapRoleMapper.java:148)~[redback-common-ldap-2.3.jar:2.3]
> at org.apache.archiva.redback.rest.services.DefaultLdapGroupMappingService
> .getLdapGroups
> (DefaultLdapGroupMappingService.java:79)
> ~[redback-rest-services-2.3.jar:2.3]
>
> batkinson indicated that the offending line is http://goo.gl/BHYixD. 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 apache-archiva-2.2.0-bin.zip .
> 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 ldap.config.mapper.attribute.user.id 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 org.jpox.store.rdbms.request.FetchRequest.execute
> (FetchRequest.java:194)~[jpox-1.1.9-1.jar:1.1.9]
> at org.jpox.store.rdbms.table.ClassTable.fetch
> (ClassTable.java:2552)~[jpox-1.1.9-1.jar:1.1.9]
> at org.jpox.store.StoreManager.fetch
> (StoreManager.java:959)~[jpox-1.1.9-1.jar:1.1.9]
> at org.jpox.state.StateManagerImpl.loadFieldsInFetchPlan
> (StateManagerImpl.java:1820)~[jpox-1.1.9-1.jar:1.1.9]
> at org.jpox.state.StateManagerImpl.validate
> (StateManagerImpl.java:4499)~[jpox-1.1.9-1.jar:1.1.9]
> at org.jpox.AbstractPersistenceManager.getObjectById
> (AbstractPersistenceManager.java:2726)~[jpox-1.1.9-1.jar:1.1.9]
> at org.jpox.AbstractPersistenceManager.getObjectById
> (AbstractPersistenceManager.java:2600)~[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
> (JdoTool.java:315)~[redback-rbac-jdo-2.3.jar:2.3]
> at org.apache.archiva.redback.rbac.jdo.JdoRbacManager.getUserAssignment
> (JdoRbacManager.java:571)~[redback-rbac-jdo-2.3.jar:2.3]
> at org.apache.archiva.web.security.ArchivaRbacManager.getUserAssignment
> (ArchivaRbacManager.java:742)~[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) https://archiva.apache.org/redback/integration/ldap.html references a
> security.properties that no longer exists.
>
> Thanks in advance!
>
>