On a whim I modified the jive_startup.xml file to re-run through the setup. It looks like the LdapAuth implementation changed in 1.3, so it's my guess that this was causing the issue (before it was calling the previous version of the class, not the "spi" version) -- some incompatibility between the old LDAP authenticator and the 1.3 version of the DbUserManager. In any case, everything seems to work fine now. Thanks -- perhaps this thread will be useful to someone else who runs into the same issue.
Just out of curiosity, what exactly was it that you changed? I am having a similar problem (http://www.jivesoftware.com/jive/thread.jspa?threadID=18940&tstart=15) wanting to use the mixed mode with LdapAuthFactory, DbUserManager, and DbGroupManager. 1.3 works correctly with LdapUserManager and LdapGroupManager but not with mixed mode.
I tried to rerun setup as you suggested by modifying jive_startup.xml but I only get a system error and I am dead in the water at that point. Does the "spi" refer to part of the system properties for AuthFactory? My previously working system properties (in 1.2) were:
AuthFactory.className = com.jivesoftware.base.ldap.LdapAuthFactory
GroupManager.className = com.jivesoftware.base.database.DbGroupManager
UserManager.className = com.jivesoftware.base.database.DbUserManager
Is this how you had your mixed mode previously working? And if yes, was it something in here that changed? Any help would be greatly appreciated.
After looking more carefully I should clarify what I said before. The LdapAuthFactory actually remains unchanged, however the screen that formerly would ask me to fill out three text fields for implementations (Auth Factory impl, Group Manager impl, and User Impl) had changed, where the first field was now a select box between two fixed implementations (both of which had ".spi" as part of the package name). That is where I got confused.
Now, I ran into a very similar error after that with the "people" screen. I debugged it by going into the admin "user picker" and deducing from there -- turns out the user that was created when I first installed the app (I created an "admin" user) that didn't exist in LDAP was causing the error. I ended up assigning my LDAP user account root permissions, then nuked the "admin" user. That seemed to fix things. My guess is that when the app binds to a given data source (say LDAP) it expects that source to be authority on user data, and when a user doesn't exist there but exists in the table (for example, an LDAP query for uid=admin would return nothing), everything got out of whack. Unfortunately it doesn't fail more gracefully and simply ignore the admin user, but this is one way of making sure the data is consistent.
In any case, review the records in your jiveUser table and see which ones do/don't correspond to your LDAP instance. You can always back up the data in that table and nuke away.
PS: personally I'm pushing for dual-mode AuthC/AuthZ so the data can be in either place (i.e. user data in LDAP, machine accounts in the app DB), but that's just me
I second the motion to allow users to have multiple authentication schemes like LDAP or on the local user DB. This helps greatly when you need a test accounts when testing different permissions but you don't want to ask a co-worker for their credentials. There is also the idea of utility accounts (admin) and in the case of a Enterprise Active Directory server it can be difficult to have non person accounts created.
The way I've seen it done is if an account is create with a password then use the local db account if it has no pwd then use LDAP or maybe an attribute on users so that they can have different authentication methods like OpenId, local db, unix, etc. I also have wrestled with the admin user problem when setting up LDAP auth with no write access to the Active Directory server.