powered by Jive Software

[BUG] LDAP field "mail" cannot be used as ldap.usernameField

When trying to configure Openfire, it is not possible to use the LDAP “mail” field as the ldap.usernameField.

Firstly, most non-AD LDAP implementations are likely to use some variant of the InetOrgPerson RFC. Section 3 defines the LDAP attributes:
https://tools.ietf.org/html/rfc2798#section-3

Granted, “mail” is not a required field, but bear with me.

A decent-sized LDAP implementation may involve multiple companies or organizational units where the same UID may exist. Take this scenario:

ou=companyA,dc=domain,dc=com

ou=companyB,dc=domain,dc=com

If “uid” is simply used as the ldap.usernameField, the possibility of a name collision exists. For instance, if there is a uid=erik in both companies, Openfire cannot tell the difference. Effectively, you have a name collision.

Unfortunately, you cannot use “mail” as the ldap.usernameField. When trying to use this field during set-up, you cannot complete the “Administrator Account” section.

– Trying to add a user by email results in an “Illegal JID” error: http://pastie.org/2580421

– Trying to add a user by uid doesn’t work: “No username was provided or the specified username was not found.”

It makes sense that you get the “illegal JID” error, as legal JIDs may only have one “@” symbol. There does not appear to be any immediate work-around to this situation. There are a few threads that have been started discussing similar issues with no real resolution:

http://community.igniterealtime.org/thread/45942 (my original thread)

http://community.igniterealtime.org/message/177426#177426

The difficulty here is essentially the “@” sign and the way that Openfire wants to construct JIDs by appending the @systemdomain to the JID. In one of the threads, using concatenation of some fields was suggested as a work-around, but it is still conceivable to have two “Joe Smith” people in the directory, so that isn’t really a viable option.

This is somewhat the “virtual domain” or “virtual hosting” situation discussed here:

The following idea suggests a simple solution to the problem overall, and also ends up addressing the LDAP issue, too:

  1. During the initial server set up where the ports and system domain are verified, include a checkbox for “multiple domains” which essentially requires that all users created must have a legal JID specified (i.e. user@domain instead of just user)

  2. In the following set up dialogues, when it comes to the user store, LDAP could be selected, and then “mail” could be set for the username field.

Ultimately, in either scenario, a user would end up with a complete JID, either because manual creation would require one to be successful, or because the mail field would pull a complete user@domain string from LDAP.

Any thoughts on this?

I am surprised that you didn’t get any feedback on this as this seems quite a normal use-case for a proper deployment of openfire in a corporate environment.

Here the Active Directory username does not match the email adress and the standard XMPP way to confirue and XMPP client, as it is enough to supply the username and password and the client will be able to find-out the correct server and to connect to it.

So, this limitation of openfire prevents a proper deployment of the service.

Few hours later… I droped OpenFire completly and switched to ejabberd. All the problems solved, surprised how easy was to install and configure it.