powered by Jive Software

User Mapping (LDAP)


openfire works well, even with ldap. My problem: the user mapping with sAMAccountName is not very functional in my case (the sAMAccountName contains personal informations…). It would be better, to map the Username with the {mail}-Attribut in AD… But when I change sAMAccountName with mail i get no users at all :frowning:

Is there (an easy way?) to map the Jabber_Username with the mail-field in AD?


I think that would result in something like…


as a Jabber user id wouldn’t it? I would hazard a guess that having an @ sign in your Name field (coming from the email address) is illegal as a Jabber ID since the @ sign is used to seperate the Jabber domain.

In most Clients you can enter your username as Username (something beforde the @) and Domain (after the @) and add seperatly the jabber-server. I’ve seen those accounts, but it’s not very common, I guess :frowning:

the question is why would you have personal information in the username field in AD.

Well. That’s a historical problem. Not my fault :wink: But I have to live with it :-X…

you need to look at fixing your AD structure because technically it is wrong. Spark will not parse correctly the double @ symbol in a XMPP authentication. The first @ symbol is to deleniate the XMPP domain of the server.

Well, as postet here: http://www.igniterealtime.org/community/message/195454#195454 it should be possible to tell username and servername (username @ servername) and an other server to registrate…

But you’re right - I have to change history and work on better usernames ;-)!



still boils down to the fact that XMPP JIDs are comprised of 3 parts:

  1. username (johndoe)
  2. @
  3. servername (chatserver.domain.com)

if you add a second @ symbol to the mix most clients will assume that everything after the first @ symbol is the servername and try to resolve that name via DNS.

Those who ignore history, are doomed to repeat it.

Actually there is rudimentary subaddressing in addition to this which you could view as a fourth part.

It is there to allow you more that one connection with the same identity, for example at home and at office or on a mobile device.

If we consider username to represent your username, serverlocation to represent your @server.domain.com etc. then the resource bit gets added to the address like this.


You can set that identifier on spark using the advanced options and it defaults to ‘spark’ funnily enough.

Subscriptions are made on username@serverlocation but messages could be addressed specifically to clients specifying the resource as well. If available the server will route it to that resource otherwise it will ignore it and route it to the first available resource client.

All academic but worth noting.

In this case the issue that breaks the JID is as mentioned several times that you are pulling an email address back from the directory that is coming back as john.doe@company.com and then adding your XMPP domain/server which may be also like @company.com producing an illegal JID.


email address: john.doe@company.com

XMPP address (JID): john.doe@company.com@company.com

if what you actually wanted was…

email address: john.doe@company.com

XMPP address (JID): john.doe@company.com

Then you need to recognise that the OpenFire server is retrieving john.doe@company.com from your directory as your name and would need specific functionality to strip the @company.com off the value returned before it was useable as that part of the ID. This is not functionality that OpenFire has. The ldap.usernameField value simply identifies an LDAP attribute that it will use verbatim and doesn’t take additional formatting arguments to cook that to a more useful format.