To start, our implementation of Openfire works fine for most users.
However, we are configured to use Smartcard Authentication tied to LDAP (CN) and some users, due to their legal names, contain spaces and other special characters. When they attempt to log in, the server produces an error stating:
SASL negotiation failed for session:
Above this error I see
org.jivesoftware.util.CertificateManager - CertificateManager: Common Name Mapping returned[FOSTER COLE.JACOB.NICHOLAS.1234567890]
org.jivesoftware.openfire.auth.AuthorizationManager - AuthorizationManager: Trying Default Policy.authorize(foster\20cole.jacob.nicholas.1234567890, FOSTER COLE.JACOB.NICHOLAS.1234567890)
Through research I have found that spaces are not accepted by OpenFire and XMPP in general but it should attempt to escape to \20, which I see above on half of the authentication attempt. I am currently assuming that the cause of the error is a failure of CertManager to add the \20 escape to authentication but I don’t know how to modify this to correct this issue. The LDAP side appears to be using the escape but the username presented due to the cert isn’t.
Is there any way to get this to work as we have a little over a dozen users effected by this issue and reissuing the certificates requires quite a bit of work involving several offices for every user we get and will keep happening as we have no control over certificate processing. This is why I am trying to find a server side solution rather than just correcting the certs as I cannot make that fix permanent.
Any help is appreciated as I have been searching for a while and couldn’t find any previous user with this issue.
NOTE: Changes to anything other than the cert would likely be fine. We can adjust ActiveDirectory, User accounts, Configurations on the server, SQL connectors, etc. I cannot install plugins though as that would require approval from a higher level office which would make validating fixes difficult.
I did come across some information that seems to indicate you can have the cert logon validate using a different field in the certificate instead of the Common Name.
If this is the case, switching to the SubjectAlternativeName would work well for our implementation but I can’t find anything about directing Openfire to do this. Our SANs are very standard and are setup to look like this: 12345678990.a@domain.com
In this field we will never have special characters outside of what is above (Ignore spaces as I put those there to prevent link creation). Changing to use the PrincipleName in SAN mapped to SAMAccountName in AD would work great if someone knows how to implement this.
Hi Adam! Oof. This is tricky one. Given the very specific use-case and the time involved to fix an issue like this, you could consider enlisting paid support, from anyone in our directory of service providers (for total transparancy: I’m in there myself).
As a best-effort, untested attempt at a solution: The mapper that is used to distill identities from certificates is indeed configurable.
For clients, the property that is used for that is provider.clientCertIdentityMap.classList. This property takes a list of (whitespace or comma) separated full class names). It’s default value is org.jivesoftware.util.cert.CNCertificateIdentityMapping (which uses the CN, as you’ve found). You could try to change this into org.jivesoftware.util.cert.SANCertificateIdentityMapping, which uses the SAN. That would be close to the approach that you described in your last comment.
Alternatively, you could implement a different mapper, package it in a JAR file that you place in Openfire’s lib directory, and use its name in that property. That would allow you to implement better escaping of characters.
I’m wondering if that should be applied to Openfire’s implementation, but I’m also worried about introducing a breaking change for people that are working with this. Maybe Openfire should make this configurable?
Thanks for the reply. I’ve been reading through the source code and I noticed those classes. I did conclude the SAN will not work unfortunately as the structure of the san includes a mandatory @ character which creates the same escape character issues.
I am still digging but I don’t have authority to hire support as that is handled by a different branch of my organization that I have a separate ticket with. This post was due to me becoming impatient with our internal support. I appreciate the advice and I will be sure to provide a solution if I find one. I am currently looking at a few options that involve tweaking the way SQL handles the request but I don’t have full testing ability so this will be challenging.