powered by Jive Software

LDAP authentication not working

I’m trying to set up Openfire with an LDAP server and everything seems to work until I try to test the admin login. When I click on test, I get the dialog that says

Test: Administrator Settings

Administrator: me@domain

Password:

when I enter my password, the dialog comes back as:

Test: Administrator Settings

Status: Authentication failed

Username not found

Administrator: me%40domain

Password:

Is there someting happening with the @ in my email address that is not making it correctly to the LDAP server? Any ideas on how to fix this?

What LDAP server are you trying to authenticate to? Does the server have a Fully Qualified Domain Name? Is name of your host server correct? Is the admin account contained within the Base DN you specified?

I’m trying to authenticate to my company’s internal LDAP server. Yes, the server has a fully qualified domain name, and yes I have the host name of the server correct. The admin account I created in Openfire is my personal company account.

When I set up Openfire, I tested each of the steps along the way and each one was successful except for authenticating my account as admin. Don’t know if this will help, but here is how we configure apache to authenticate:

<![CDATA[ I've obviously changed some identities to protect the guilty.

I just tried changing usernameField from mail to uid, then added me as an administrator using my uid. Using that configuration, the authentication test was successful. I’m starting to think there is a bug when using mail as the usernameField and id’s of the form user@domain

I would recommend not using mail as your usernameField. user@domain means something to Openfire, and I can see that causing problems for you.

I don’t have a choice in the matter. It must be mail, and the login id must be a user’s internal email address.

Is sAMAccountName different from the mail username?

I’m not sure what you mean my sAMAccountName. If you are referring to an LDAP field, that does not exist in our schema.

Sorry, I was thinking you were in Active Directory. Do you have a field other than mail that contains just the username?

No, mail is my only choice.

Hi BryanH,

hrothgar is correct in that user@domain means something to Openfire, which basically means that user names (or in XMPP terms the “node” portion of a jid) cannot contain the @ character, so unfortunately you won’t be able to use an email address for your users login id.

Regards,

Ryan

To follow up to my own reply, if you’re using POP3 for your email you could configure Openfire to use a POP3AuthProvider and POP3UserProvider instead which basically works just like the LDAP providers. Users would still have to use just the first portion of their email address but it might be a viable work around given your LDAP constraints.

Hope that helps,

Ryan

Ryan,

Do you think it would be a reasonable feature request to have a the option to rewrite the usernameField to strip anything past an @-sign? The code would be a trivial regex rewrite.

I don’t quite see how that would help. I must send the literal text "id@xx.yy.com" to our LDAP server for lookup, and striping off xx.yy.com would cause the lookup to fail. Maybe I’m not understanding the suggestion.

We don’t use POP3. Thanks for the suggestion.

I’m talking about stripping it off when it gets back to Openfire.

Ok, that makes sense. Thanks for clarifying.

Hey Guys,

While doing some investigation into this issue I discovered that the LDAP providers do look for the @ character and strip it and anything past it out. So I did a little testing and I was able to setup my openfire.xml config file to use the mail field for my username and I was able to login using Spark. Logging into the Admin Console proved to be a bit more difficult but I was also able to figure it out. What I did was in the section to look like this:

<admin>     <authorizedUsernames>ryan\40version2software.com</authorizedUsernames>   </admin>

When I sign into the Admin Console however I still use the "ryan@version2software.com" as the username. What I think is happening is that Openfire is escaping any html characters from the username field to prevent any cross-site scripting.

Give the above a try and see if it works for you.

Thanks,

Ryan

That works for logging to the admin console.

Now, when I try to log in using Adium with id@domain, it fails, and I get the following in the warning.log

2008.01.31 18:00:59 SaslException

javax.security.sasl.SaslException: PLAIN authentication failed Caused by javax.security.sasl.SaslException: PLAIN: user not authorized: id

at org.jivesoftware.openfire.sasl.SaslServerPlainImpl.evaluateResponse(SaslServerP lainImpl.java:144)

at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java :229)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:152)

at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:132)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:173)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 650)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)

at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)

at java.lang.Thread.run(Thread.java:613)

Caused by: javax.security.sasl.SaslException: PLAIN: user not authorized: id

at org.jivesoftware.openfire.sasl.SaslServerPlainImpl.evaluateResponse(SaslServerP lainImpl.java:127)

… 18 more

Hi Bryan,

In order to get Adium to work I had to replace the first @ character with \40, so my Jabber ID is “ryan\40version2software@localhost” (see attached). However, when I use Spark, which provides separate username and server fields I could leave the @ character in my username (see attached). I didn’t look through the Spark code but I would suspect that it is probably doing some sort of character encoding on the username field prior which would convert the @ character prior to using it login.

Hope that helps,

Ryan