Edit/Customize JID for users

Hello -

I am looking for tips on how to edit the Openfire JID that is automatically created for users.

Openfire is currently setup to query LDAP 3268 across our Active Directory forest for automatically enabling Openfire accounts.

I would like the JID (openfire user id) to include the child domain that our users reside in. Currently we have rolled out the application to our end users so hopefully this change will have little to no impact on their current configurations.

I am looking to do this because I have found that users in different child domains in the forest that have the same user id are not recognized/found in spark with our current setup. By providing the domain and user name in the JID, I am hoping that all users will be able to use the Spark app.

Some additional info:

  • The current JID’s appear as DomainUserName@im.domain.com

  • Example of current issue - John Doe in Domain A has username of ‘doej’ (domainA\doej) and Jane Doe in Domain B has username of ‘doej’ (domainB\doej). When Openfire queries AD over 3268 (global catalog) it will not create an account for either user and other employees can not perform a search for them in Spark (same result when searching in the Openfire Admin console). These ‘doej’ users also can not log into Spark since they are not authenticated by Openfire.

I am not sure if this is a bug of Openfire or just a mis-configuration on my end. I would have thought that Openfire would easily be able to differentiate between the two accounts as any other LDAP tool is able to.

Thanks for any input as always!

Hi,

do you use the same uid within different LDAP trees? Like

uid=joe,ou=foo,dc=example,dc=com
uid=joe,ou=bar,dc=example,dc=com

I do not think that this is a common setup or a good design. This requires that you set the search base to “dc=example,dc=com” and that the “Unique Identifier” uid is no longer unique while the DN of the two users is unique.

I have no idea whether the LDAP provider of Openfire can handle this.

LG

No. Active Directory will not allow you to have two accounts with the same User Id/pre-windows 2000 userid in the same domain. Your example below would not be possible, even if the user accounts are in different OU’s as you show in your example.

We have multiple domains that are members of an Active Directory forest. When using port 3268, I am able to query all of these users in the forest and allow them to access the Openfire solution.

As an organization, our policy is to create a user id with last name, first initial. This works great and every user in the domain is unique. As in my first post, John Doe in DomainA has doej as a username and Jane Doe in DomainB has a username of doej as well (keep in mind, different domains, same Active Directory Forest). So based on that, the accounts would look like

uid=doej,ou=foo,dc=A,dc=example,dc=com
uid=doej,ou=bar,dc=B,dc=example,dc=com

(Openfire over port 3268 sees the two accounts above as the ‘same’ based on the UID. They are clearly different and unique.)

Openfire completely ignores the Domain information and sees ‘doej’. Since there are multiple ‘doej’ accounts, Openfire ignores them. I know this is the case, because if I change one of the users userid to something else in the remote domain, force replication throughout the forest, they automatically are recognized by Openfire. This cant be my solution though as changing the pre-windows 2000 user id for a user requires some time consuming work - and would just be a poor ‘manual’ solution.

My personal thought is that Openfire should be aware of the domain and username instead of just creating a JID of USERNAME@im.domain.com

The only 2 completely unique things to a user account in an Active Directory forest (that I can think of) are Primary SMTP Address (email address) and SID.

Is it possible to force the JID to be the user’s full email address followed by the Openfire server domain? For example - John.Doe@example.com@im.example.com? To log in any way, the users dont have to provide the @im.example.com portion. We could just allow our users to log in with their email addresses… and of course specify the im.example.com in the server field.

I will test.

I tested using the ‘UserPrincipalName’ and ‘mail’ Active Directory attributes to create the JID. While this allows a user to log in and authenticate, there are issues… The clients lost all of their Spark history, rosters, etc. Also, these values have the potential to be changed and the user would once again lose their Spark roster, history etc.

Basically, I need to know if there is a way to have a JID include the ‘Domain and sAMAccountName’ included together in the logon name. Much like a user would log onto their pc using Domain\UserName. If I could find a way to have our users provide this in the JID field, it would be a good solution.

If not, Openfire really is not suited for organizations with more than one Domain in their Forest.

Openfire is a GREAT product and I would like to find a workaround to this.

Any ideas?

Hi,

I have no idea about the more advanced LDAP settings, so I’d say this is not possible. One would need to extend the LDAP auth provider.

How many domains do you have? With

uid=doej,ou=foo,dc=A,dc=example,dc=com
uid=doej,ou=bar,dc=B,dc=example,dc=com

I would simply setup two servers. One with xmpp.domain=foo.example.com and one with xmpp.domain=bar.example.com - also with a proper LDAP search base. So the uids are again unique within every LDAP tree and you get unique JIDs:

doej@foo.example.com and doej@bar.example.com.

LG

If i create a server per domain, would the users be able to search for and add users on the seperate Openfire server to their roster?

Thanks for the input.

Hi,

it should be possible. I do not know whether this is already fixed. former Openfire versions have problems with sub-domains and thus the server-2-server connections fails.

Search should also be possible by adding the search service “search.other-xmpp-domain” to your client if this is possible.

Anyhow I do not run multiple Openfire servers (one does need to use a unique IP for every server to avoid port conflicts) so you’d need to test this. Probably with a simple setup using the embedded database (without LDAP) on one server.

LG

Thanks LG. I am testing this over the coming days and will post my findings.

I appreciate the feedback.