Clients cannot login after disabling plain text passwords

Hello,

I have installed Openfire 4.4.1 and it at first worked fine, but I wanted to disable plain text passwords due to security reasons, but after disabling it under Server settings/registration & login/ SASL Mechanisms, spark clients cannot login.

I’m using LDAP login and all other login mechanisms is enabled in the same section. But still, clients can only login with PLAIN enabled. What can be the issue and how can I solve it? Using Spark 2.8.3.

you’ll need to make sure that your ldap provider can use other login mechanisms. for example, Microsoft AD only supports a few mechanisms.

If your provider doesn’t not support a mechanism other than plain, then you can mitigate the issue by encrypting the transport using LDAPS.

Are you sure this is the reason? Yes it’s Microsoft AD, but we have never had this issue before with any other products.

In any case, I have tried using LDAPS using port 636 to our domain controller, but when pressing test settings, it fails.

I am a system administrator for most things in our organisation except the domain controllers which I have no access to. We are a very big global company with high security thinking so to me it sounds strange that nothing else than plain text would be supported by the domain controllers running server 2016.

In fact, since the security scan failed on the Openfire server due to plain text passwords, I am not allowed to put it into production until it’s solved.

So we now disabling this feature also disabled the possibility for clients to login.
We also know that trying LDAPS on port 636 fails.
I also know that NTLM is enabled in Openfire and NTLM works with other products we use in our organisation, but not for Openfire for some reason.

Here is the list of auth mechs supported by AD

iirc, I think the client needs to support the auth mech. for example. I have gssapi enable because I couldn’t find a xmpp client that supported ntlm. Which client are you using?

Spark

Anyway, I managed to enable LDAPS instead of LDAP as suggested in this thread, but Nessus security scans still complain about plain text passwords enabled to I need to disable that somehow without stopping logins for users.

As I said before, all login mechanisms is enabled like NTLM which work for other products against our domain controllers, but for some reason not for Openfire.

Spark does not support ntlm. it does support kerberos via gssapi. Would your company be open to sponsoring the development to add ntlm to spark? @Dele_Olajide or @guus might might be interested but they keep pretty busy with their regular gigs.

The problem is that Spark 2.9.0 has a lot of other issues, that needs to be fixed first. Because there is no use if someone adds a new feature, but there is no release to actually use it. I can file a ticket for that, but as there are no active developers, it won’t help much. https://issues.igniterealtime.org/browse/SPARK-2123
Also, it is a long term solution, but i believe Bejje needs a quick one. So, maybe speedy can share his tips on setting up gssapi.

I believe Pade supports ntlm. have you checked it out? it runs as a chrome extension

Thanks for all the replies. I just want to know, is there as of today no secure ways of authentication between Spark and Openfire?

Yes i did setup LDAPS, but still the Nessus security scan of the server complains about clear text passwords?

Is there any other client software to use with Openfire that will work better and more securely?

I like Openfire and Spark as well, but Openfire is the actual server that makes it happen so I’m open to other clients as well, but I prefer installable clients instead of web versions.

Nessus is giving you that message because the authentication is still being sent in “PLAIN”. Also make sure that in openfire, you have “require secure connections” enabled in both client and servers. By doing this, and by using ldaps, your transport layer will be encrypted, in turn helping to protect your credentials. This is really no different on how websites works with ssl/tls, or protecting traffic with a vpn.

If you want to use spark, and still disable “Plain” authentication, then your only option is to enable sso using gssapi (kerberos). This is really tricky to setup. It will only work for AD users that are connected and authenticated to the network (cached credentials will not work for offline users).

1 Like

Thank you speedy.

It was “require secure connections” that was missing. After enabling that the Nessus warnings went away.