I just installed Wildfire 3.1 (after deleting the 3.0 install) and configured the LDAP portion succesfully (test was succesfull). Now I cannot get into the admin console - with the userid and password that is specified in the “jiveuser” table on the Oracle Database that serves up this service.
can you login using a xmpp client like Spark into Wildfire? Then you may want to add your username in conf/wildfire.xml to the administrators and restart Wildfire. This should allow you to login http://server:9090/
I forgot to mention here that I used the LDAP option to setup authentication. Therefore, I can only assume that the valid domain admin accounts are the only one’'s that can login as admins into the admin console…
In that case, I believe that a local admin may not be possible/feasible - because the entries being read are not read from the jiveuser table - instead they are being populated from the AD domain controller.
Yes…I did remove the comment marks from both ends…saoracle is the domain admin on the AD side…and since the default ‘‘admin’’ username is not in AD (and authentication is not local anymore), using ‘‘admin’’ will not work anymore…
I think there are two issues here…quoting from the wildfire.xml file…
It appears that when wildfire is configured to authenticate against a remote domain controller (such as open LDAP - AD in my case), the default “admin” user is not recognized. Instead, the user account that has administrative privileges on the domain controller (in my case saoracle)
will have admin privileges to adminster the admin console on the IM server. Note the above (only local users)…In our new install (we had 3.0.1 with local users and without remote authentication and here the admin/passwd combination always worked), we don’'t have local users and as such the “jiveuser” table on the server end repository is not used for authentication.
Specifying comma delimited names will work only if all names are either 1) local and the authentication is local or 2) remote admin users and the authentication is remote (as in LDAP)
This may not be an LDAP bug - it may be the way the new version was designed to work.
I can be contacted at mathewj@chartersteel.com for further clarification from my end. I will be happy to provide any answers - because I think that the newest upgrade (3.1) is so cool - enabling almost instant LDAP authentication alleviating the need for user creation each time a new user requires IM access. This is a case of a excellent product being made even better.