Mark Ziesemer
2015-04-29 04:33:24 UTC
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!
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!