powered by Jive Software

NTLM Authentication

Hi,

I’m doing auditing on our security and I’ve noticed that OpenFire seems to authenticate against our domain controller using NTLMv1. This is an outdated authentication protocol, which I’d like to eventually disable. Is there a way to have it use NTLMv2? Here is the log.

An account was successfully logged on.

Subject:
Security ID: SYSTEM
Account Name: DOMAINCONTROLLER
Account Domain: DOMAINNAME
Logon ID: 0x3E7

Logon Information:
Logon Type: 3
Restricted Admin Mode: -
Virtual Account: No
Elevated Token: Yes

Impersonation Level: Impersonation

New Logon:
Security ID: DOMAINNAME\ADMIN
Account Name: ADMIN
Account Domain: DOMAINNAME
Logon ID: 0x17D478ED
Linked Logon ID: 0x0
Network Account Name: -
Network Account Domain: -
Logon GUID: {00000000-0000-0000-0000-000000000000}

Process Information:
Process ID: 0x3a0
Process Name: C:\Windows\System32\lsass.exe

Network Information:
Workstation Name: DomainController
Source Network Address: 10.0.0.234
Source Port: 57069

Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

Hi Chris,

I’m not much of a NTLM expert and have no practical experience with using that, but this is what I found while digging through Openfire’s code: Openfire does not actually implement the NTLM protocol at all. Instead, it depends on the SASL NTLM implementation that is provided by the Java virtual machine that is used to run Openfire. That suggests that your mileage may vary, depending on what make/model/version of Java you’re using.

When looking at the relevant documentation of Oracle’s implementation, then NTLM v2 should be available in at least version 11 (I can’t easily find that same document for Java 8 - but it might also be in there). When I look at the source code of Open JDK versions 11 and 8, there does seem to be support for NTLM v2 too.

That documentation (available at https://docs.oracle.com/en/java/javase/11/security/java-sasl-api-programming-and-deployment-guide1.html#GUID-681CD78D-D2E4-43DE-9225-249AA83FF177) suggests that you can configure what version you want to use by setting the com.sun.security.sasl.ntlm.version property (again, this might be specific to what Java vendor you use). It confusingly also seems to suggest that v2 is the default - which begs the question why your instance does not seem to use that.

I am using Oracle’s Java 8, so that suggests that maybe that is the issue. I’ll look at getting onto OpenJDK 11 if that is compatible and stable. I would also consider Java 11 too, but I understand that there may be licensing issues with it… It was on my To-Do list anyway, and this is extra reason to do so.

Maybe it’s worth trying to set that com.sun.security.sasl.ntlm.version property and try and force using the protocol version that you want only?

I’m not sure how you audited the software, but there might be a difference in “Openfire supports V1” and “Openfire uses V1” ?

I audited by viewing these events in the domain controller event log. I found a Powershell script that would search the log for examples to make it easier.

I’m not totally clear where I would edit that line to use NTLM version 2 however.

I updated to OpenJDK 11, so I’ll see how it goes using that and see if those events are still present next week. Thanks for the help Guus!

This would go in the script that starts Openfire, the same script where you can tweak the amount of memory that Openfire can use (which script that is depends a bit for each distribution). You’d need to add the value in a -D argument, like -Dcom.sun.security.sasl.ntlm.version=SOMEVALUE

update: needs a capital D, not a lower-case one.

I’m still seeing the events, so I may need to add this. I’m using Windows Server and I’m not tweaking the memory in a script to my knowledge. Are you referring to the files within the Openfire conf directory?

EDIT: Nevermind, I guess I need to edit the openfire.bat file. I guess I need to put that in here somewhere?

start "Openfire" "%JAVA_HOME%\bin\java" %debug% -server -Djdk.tls.ephemeralDHKeySize=matched -Djsse.SSLEngine.acceptLargeFragments=true -DopenfireHome="%OPENFIRE_HOME%" -Dlog4j.configurationFile="%OPENFIRE_HOME%\lib\log4j2.xml" -Dopenfire.lib.dir="%OPENFIRE_HOME%\lib" -jar "%OPENFIRE_HOME%\lib\startup.jar"

Yup, that’s right. You can add it somewhere in that list of pre-existing -D arguments

I added this line to my openfire.bat file and restarted my OpenFire service.
-Dcom.sun.security.sasl.ntlm.version=NTLMv2

I’ll see what happens tomorrow. Thanks for the continued help.

This did not fix it unfortunately. I still see this:

Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

Sadly, this isn’t my area of expertise - nor do I have access to a setup that I can test this on (if I’d know how to). One last thing that you could try is use a different JVM (either a higher version, or one of a different make/model).

Also: Paging @speedy, our resident Windows expert. @speedy, to the airport information desk please!

Just to add a little color here… The account generating the event in the logs is an admin account. It is the same one defined in the Server Settings > Profile Settings > Directory Server (LDAP) > Administrator DN.

Hopefully that information may help. As for your suggestion, OpenJDK 11 should be able to use NTLMv2. I’m wondering if this is just defined somewhere else (either configurable or not) in Openfire.

sorry for the delay. its been a hell of a year and I’ve really be lacking my responsibilities to the community!

I’ll spin up my lab tonight and see what I can find out. I didn’t even know that openfire could us ntlm. Is this for the ldap lookup account or user accounts as well? what client are you using so that I can better replicate your setup?

ugh…life got in the way yesterday and I didn’t get this done. I’ll try again this afternoon!

I have a feeling this is for the LDAP lookup since that account is defined as the account for that. We use Spark as our client, mostly 2.7, but some other versions as well. If you figure it out, that would be great!

I’m going to have to take a deeper dive into this. I’ve set my policy in my lab to only reply to ntlmv2 and to refuse lm and ntlm yet I’m getting the same thing you are. I’m probably overlooking something obvious…

1 Like

Thank you! It’s possible I’m also missing something obvious too, but it seems we are both seeing the same thing at least. It’s interesting why that is happening.

Hi, did you ever get a chance to test this further? I’m curious what you may have uncovered.

Hi @speedy,

Have you dug into this at all? I’m circling back on this because there is now an NTLM vulnerability in Windows that would be nice to be able to get rid of this. Any help would be appreciated.