Jespa Release Notes

When using DNS SRV lookups to locate domain controllers, Jespa will now reset using the dns.site when either an error occurs binding a DC or within a maximum time of 5 minutes. Prior to this release, if Jespa failed over to a DC not in the specified AD site, it could continue to use that possibly less performant DC for up to 2 hours or until the application was restarted.

A NullPointerException (which could only occur with log.level >= 4) has been fixed.

An unlikely NullPointerException introduced in the previous release has been fixed.

The following error could occur when authenticating userPrincipalNames longer than 20 characters:

jespa.io.EncodingException: Invalid userName: user.name@example.com
    at jespa.ntlm.NtlmsspAuthenticateMessage.decode(NtlmsspAuthenticateMessage.java:86)
    at jespa.ntlm.NtlmSecurityProvider.acceptSecContext(NtlmSecurityProvider.java:1485)

All users should upgrade.

Code has been changed that will improve performance of the HttpSecurityService.

If channel binding fails, the channel binding hash submitted by the client will be logged (with a log.level >= 2) so that it can easily be set using the bindings.cert.hash property. See the new Issue 16: SPN BINDINGS FAILURE and CHANNEL BINDINGS FAILURE Errors section in the latest Jespa Operator's Manual for related information.

An EncodingException: Invalid userName: user.name@example.com error could occur when authenticating userPrincipalNames longer than 20 characters. This issue has been fixed.

An issue specific to the linux-cifs client has been fixed.

This issue is not applicable to conventional HttpSecurityService installations.

If an NTLM initiator did not supply a MIC, the following error would occur:

jespa.security.SecurityProviderException: MIC failure
    at jespa.ntlm.NtlmSecurityProvider.acceptSecContext(NtlmSecurityProvider.java:1583)
    at jespa.http.HttpSecurityService.doFilter(HttpSecurityService.java:2241)

This issue has been fixed.

This issue was specific to non-browser clients like Apache HttpClient and curl.

The exportState and importState methods of NtlmSecurityProvider could throw a NullPointerException. This issue has been fixed.

This issue is not applicable to conventional HttpSecurityService installations.

The NTLMSSP session key is now available through the NtlmSecurityProvider as the ntlmsssp.sessionKey property.

When using the NtlmSecurityProvider as it's own domain authority, as described in the Providing NTLM Services without Active Directory section in the Jespa Operator's Manual, the following exception could occur:

java.lang.NullPointerException
  at jespa.ntlm.HMAC_MD5.<init>(HMAC_MD5.java:21)
  at jespa.ntlm.NtlmSecurityProvider.acceptSecContext(NtlmSecurityProvider.java:1627)
  at jespa.http.HttpSecurityService.doFilter(HttpSecurityService.java:2241)

This issue has been fixed.

This issue is not applicable to conventional HttpSecurityService installations.

A very minor change has been applied to an undocumented part of the API (the jespa.util.NtException.getNtStatus() method has been changed to public).

This release generates a more informative error message when the AD DS server does not support AES Secure Channel NETLOGON (such as Windows Server 2008). Another minor issue was fixed.

This release is fully backward compatible with 1.x. All installations should upgrade.

Note: Jespa 2.x does not support activation keys generated before approximately December of 2018. If you get a "Failed to decrypt license key" error trying to upgrade, please contact sales@ioplex.com for assistance.

The HttpSecurityService now supports SPN and channel bindings (also known as Extended Protection for Authentication or EPA).

The NTLMSSP code has been significantly updated to more closely mimic newer Windows behavior.

Microsoft has released a security policy update that can trigger the following AD DS event log warning:

5840 The Netlogon service created a secure channel with a client with RC4.

This issue has been fixed. All installations should upgrade to avoid any possible issues with future enforcement of security policy associated with CVE-2022-38023.

The HTTP client now fully supports and uses SPN and channel bindings by default. Numerous significant issues with the HTTP client have been fixed.

The LDAP client now fully supports and uses SPN and channel bindings by default.

Note: Jespa has always satisfied AD DS LDAP signing requirements by using confidentiality by default. However, Jespa 2.x is required if you wish to use the LDAP client with TLS (using a CA trustStore and flags.confidentiality = true) because AD DS now requires channel bindings when using TLS with LDAP.

This release fixes a long-standing issue where the LDAP client could become dysfunctional if code was re-loaded in a new ClassLoader (such as when re-loading a webapp in reaction to modifying a JSP). This could result in exceptions like the following:

SecurityProviderException: Failed to acquire credentials for authentication
...
SecurityProviderException: Failed to decrypt property: service.password

The HttpSecurityService will not create a new HTTP session if one is not absolutely required such as because the resource is not protected (isProtected returns false). Previous versions would create HTTP sessions unnecessarily.

This release fixes an issue where the Jespa HttpSecurityService could reach an unrecoverable state resulting in the following exception being repeatedly printed in the log:

java.net.SocketTimeoutException: connect timed out 
  at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)
  ...
  at java.base/java.net.Socket.connect(Socket.java:608)
  at jespa.dcerpc.DcerpcTcpHandle.bind(DcerpcTcpHandle.java:109)
  ...

This issue would occur if the port of a service such as NETLOGON or lsarpc changed but the port in the EPM cache was used. This issue occurs only very sporadically but all installations should update when convenient.

A Jakarta EE jar (named jespa-jakarta-<version>.jar) is now included in the Jespa package. Use this jar with Jakarta EE servers like Jetty 11 and Tomcat 10. Other than changing package names in the Jakarta jar, there have been no changes to code.

A change in 1.2.8 may result in a "The user name or password is incorrect" error when running the SetupWizard.vbs script. This issue has been fixed. Only the SetupWizard.vbs script has been modified in this release.

Jespa does not use and has never used log4j and is therefore unaffected by any vulnerabilites in log4j. However, Jespa does generate a log (using a trivial PrintStream class). If your application makes it possible for the Jespa log stream or log file to be consumed by a log4j installation that has "lookup" vulnerabilites, this release includes code that attempts to detect and exclude malicious lookup expressions in HTTP parameters, headers, domain names, account names, group names and authentication protocol message fields from being written to the Jespa log stream. This release is not a substitute for identifying and fixing vulnerable log4j installations.

This release adds the DuoHttpSecurityService and DuoHttpSecurityFilter for combining Windows builtin SSO with the 2FA functionality of the Duo service from duo.com / duosecurity.com. See the JAN110 application note for a detailed description of this new functionality and how to use it.

This release fixes an issue where Jespa could reach an unrecoverable state resulting in the following exception being repeatedly printed in the log:

java.io.IOException: Unexpected DCERPC PDU header
  at jespa.dcerpc.DcerpcTcpHandle.doReceiveFragment(DcerpcTcpHandle.java:164)
  at jespa.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:221)

until the webapp is reloaded (or the Java application service or server host is restarted). This issue will only occur if Jespa is configured to use only one domain controller and Jespa actively tries to validate NTLMSSP credentials (such as in reaction to clients performing SSO with the HttpSecurityService) while the DC is being rebooted. This issue may occur only sporadically. The changes in this release are not extensive. All installations should update.

The Jespa Operator's Manual has been updated extensively. The changes are applicable to all versions of Jespa.

An extremely rare and low-impact NullPointerException has been fixed. This exception could only occur when the idleTimeout logic closed the NETLOGON connection at the same moment a caller was trying to aquire it.

If an LDAP attribute has no AttrDef entry, the default will be a single-valued string (whereas previously it was a multi-valued string). This change should have no impact on applications that do not use custom attribute definitions (meaning HTTP NTLM SSO components will not be affected).

This release eliminates the dependency on the JCIFS library. Jespa 1.2.5 or later does NOT require the JCIFS library. Because these changes are somewhat pervasive, operator's should carefully monitor the Jespa log file for exceptions and generally be conscientious of any change in behavior.

There are two exceptional considerations regarding JCIFS:

1) If the Jespa property msrpc.useNamedPipe = true is set, the JCIFS library IS required and must be present in the application classpath. Note that is it not possible to set JCIFS properties through Jespa properties even if msrpc.useNamedPipe is set. See the MSRPC TCP Transport Properties section in the latest Jespa Operator's Manual for details.

2) The removal of the dependency on JCIFS should be completely transparent provided that your application does not have any references to JCIFS library classes. For example, prior to Jespa 1.2.5, Jespa could throw a jcifs.smb.SmbException. There should never have been any instance where an application would want or need to catch a jcifs.smb.SmbException but if your code does it will be necessary to remove (or perhaps adjust) such instances to function properly with Jespa 1.2.5 or later. If your code has any references to JCIFS classes for any other purposes, it may be necessary to remove or change them for Jespa 1.2.5 to function properly with your application. For example, if you used a utility class like jcifs.util.Base64, you can switch to jespa.util.Base64 (although technically classes that do not appear in the API documentation are not supported and may change at any time and without notice).

Note: The JCIFS project has moved to https://www.jcifs.org/.

Some performance improvements have been applied in this release (related to new encryption Cipher and digest implementations, Cipher caching, faster Base64 encoding / decoding and several other instances where the corresponding JCIFS code was not efficient).

The Jespa Operator's Manual and API documentation have been updated.

This release fixes an NDR encoding issue that causes Jespa to fail with the following exception in the Jespa log:

jespa.dcerpc.DcerpcException: DCERPC_FAULT_NDR
  at jespa.dcerpc.DcerpcMessage.getResult(DcerpcMessage.java:26)
  at jespa.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:241)

This release fixes a minor issue regarding the msrpc.tcp.idleTimeout property being ignored.

This release fixes a minor issue with the HTTP client and chunked encoding.

This release fixes a moderately serious read buffering issue in the new MSRPC TCP transport that can prevent Jespa from reading domain information from DCs with many trusts (20+ domains).

This release fixes a "Read timed out" delay that could occur on networks that actively close idle TCP connections. Jespa will now proactively close idle TCP connections to the NETLOGON service (controlled using the new msrpc.tcp.idleTimeout property). An ArrayIndexOutOfBounds bug has also been fixed. The Jespa Operator's Manual has been updated.

With the release of 1.2.0, Jespa now uses TCP transport and not SMB for MSRPC communication (such as with the NETLOGON and LSA services of domain controllers). If SMB1 is disabled in the target environment, Jespa versions prior to 1.2.0 will yield an error like the following:

NETLOGON: Connecting DCERPC handle to ncacn_np:192.168.10.20[\PIPE\NETLOGON] with identity mega.corp\jespa1$
  jcifs.smb.SmbException: Failed to connect: 0.0.0.0<00>/192.168.10.20
  jcifs.util.transport.TransportException
  java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(SocketInputStream.java:196)

If SMB1 is diabled, using Jespa 1.2.0 or later should be successful and log entries like the following:

NETLOGON: Connecting DCERPC handle to ncacn_ip_tcp:192.168.10.20[netlogon] with identity mega.corp\jespa1$
DcerpcTcpHandle: soTimeout=60000,connTimeout=30000
NETLOGON: Bind successful

IMPORTANT: Port requirements have changed. See the Jespa 1.2.0 Port Requirements section in the latest Jespa Operator's Manual.

Although this release represents a significant change to the communications layer, upgrading should be fully backward compatible (minus port requirements mentioned above) with previous releases and completely transparent to users.