Hello all,
Since upgrading to Openfire 3.6.0a, I see that the Openfire.xml file no longer holds the Configuration information. Can any one tell me what the table name is that holds this information?
I am running SQL 2005 as a backend (if that info helps).
Also, is there a document that explains the Tables used on the backend for Openfire?
Regards
Wall
You do not need to adjust the settings via the SQL table. All settings are now listed in the system properties, of the openfire admin web page.
I understand, but I am still troubleshooting why a few users are not found in Spark throught the Global Catalog search.
I can successfully find these 3 or 4 people when searching just port 389, but not over 3268. (see prior post at http://www.igniterealtime.org/community/thread/36712?tstart=0)
I am looking for the actual query / search filter that Openfire uses to search for the users in the Global Catalog.
The accounts are not corrupt as suggested in prior posts and the accounts can be found through any other 3rd party utility querying the Global Catalog.
Even after installing a development version of Openfire, to a seperate database, the accounts are not found when doing a user search through spark. If I change the LDAP port to 389, I can find only that child domain. so, I still need to figure out what is preventing openfire from seeing them over 3268 and the Table descriptions would definately come in handy for testing.
the field for the settings is ofproperty, but this does not hold any information regaring LDAP users.
Hello all - I have found the issue… And it is due to the way Openfire Auto creates accounts when performing LDAP lookups.
I have figured out why random users are not found in the LDAP search with Spark/Openfire. I have configured Openfire to search the entire forest (port 3268) for users in our organization - obviously this includes all of our child domains in the forest.
When Openfire queries AD, it completely ignores the child domain and only looks at the pre-windows 2000 user id. If there are two user id’s that match identically, Openfire does not know what to do with them, so the application simply does not return a result for that person.
For Example - John Doe in Child domainA would have the pre-Windows login of ‘domainA\doej’. Jane Doe in Child domainB would have the pre-windows login of ‘domainB\doej’. Openfire ignores the ‘domainX’ information and will not create an Openfire account for the users since they both have the ‘doej’ username.
I am working to configure Openfire to include the domain in the Openfire login name, but havent tested as of yet, nor know what implications this will have to existing users. I will update at a later date when I have that information.