Authentication issue with Spark 2.6.3 and latest beta?

Current Setup: Openfire 3.7.1 on CentOS 6.2 with authentication against AD via LDAP and running Spark 2.6.3 with Java 6 Update 33 on Windows 7SP1 64-bit .

Issue: Several user accounts (but not all) are getting their credentials (which are valid) rejected by Openfire. This is not related to the users’ local machine or client installation or spark.properties. I tested two accounts on the same client and machine - one was able to login successfully, the other was not. I thought this might be a problem in AD but the failed account is not termed, expired, or locked. Even though the password is due to expire in 14 days, I’ve had many users already go through password change cycles without any problems.

What is showing up consistently in the logs with each failed attempt:

2012.08.21 14:52:22 org.jivesoftware.openfire.net.SASLAuthentication - User Login Failed. PLAIN authentication failed for: (userID)

What I’ve tried so far: Complete reinstall of Spark 2.6.3 (fail), update to Java 7 Update 5 (fail), update to 2.7.0 beta 1 (fail), deleted spark.properties (fail)

System Properties (first few lines omitted):

ldap.connectionPoolEnabled

true

ldap.debugEnabled

false

ldap.emailField

mail

ldap.encloseDNs

true

ldap.groupDescriptionField

description

ldap.groupMemberField

member

ldap.groupNameField

cn

ldap.groupSearchFilter

(objectClass=group)

ldap.host

10.0.32.150

ldap.ldapDebugEnabled

false

ldap.nameField

cn

ldap.override.avatar

true

ldap.port

389

ldap.posixMode

false

ldap.searchFilter

(objectClass=organizationalPerson)

ldap.sslEnabled

false

ldap.usernameField

sAMAccountName

ldap.vcard-mapping

<vCardxmlns=“vcard-temp”>

{cn}



{mail}

{givenName}
{SN}


{homePostalAddress}
{homeZip}
{co}



{streetAddress}
{l}
{st}
{postalCode}
{co}




{homePhone}




{mobile}




{telephoneNumber}




{mobile}




{facsimileTelephoneNumber}




{pager}

{title}

{department}

]]>

locale.timeZone

America/New_York

plugin.search.excludedFields

plugin.search.serviceEnabled

true

plugin.search.serviceName

search

provider.auth.className

org.jivesoftware.openfire.ldap.LdapAuthProvider

provider.group.className

org.jivesoftware.openfire.ldap.LdapGroupProvider

provider.user.className

org.jivesoftware.openfire.ldap.LdapUserProvider

provider.vcard.className

org.jivesoftware.openfire.ldap.LdapVCardProvider

register.inband

false

register.password

hidden

transfer.enabled

true

update.lastCheck

1345562755852

vcard.enabled

true

xmpp.auth.anonymous

true

xmpp.auth.sharedSecretEnabled

true

xmpp.client.idle

-1

xmpp.client.idle.ping

true

xmpp.client.tls.policy

required

xmpp.domain

servername.company.com <– deliberatelychanged

xmpp.filetransfer.enabled

true

xmpp.server.certificate.accept-selfsigned

false

xmpp.server.dialback.enabled

false

xmpp.server.permission

whitelist

xmpp.server.tls.enabled

true

xmpp.session.conflict-limit

0

xmpp.socket.ssl.active

true

Figured out the problem thanks to an LDAP error we found in the debug logs. The users experiencing the login failures were all members of a group that had a “/” in the DN. Once that was replaced with a “-”, the users were able to login successfully. Not sure if the inability to accept special characters is a known bug in the LDAPManager but wanted to raise awareness about the workaround anyway. Cheers.