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 <onl...@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! > >
