IOPLEX Communications Software

Jespa Release Notes

2.0.2March 8, 2023
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).
2.0.1February 4, 2023
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.
2.0.0January 31, 2023

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 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
1.2.13January 3, 2023
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.
1.2.12September 13, 2022
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: connect timed out 
  at java.base/ Method)
  at java.base/
  at jespa.dcerpc.DcerpcTcpHandle.bind(
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.
1.2.11May 5, 2022
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.
1.2.10April 1, 2022
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.
1.2.9December 20, 2021
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.
1.2.8November 24, 2021
This release adds the DuoHttpSecurityService and DuoHttpSecurityFilter for combining Windows builtin SSO with the 2FA functionality of the Duo service from / See the JAN110 application note for a detailed description of this new functionality and how to use it.
1.2.7August 6, 2021
This release fixes an issue where Jespa could reach an unrecoverable state resulting in the following exception being repeatedly printed in the log: Unexpected DCERPC PDU header
  at jespa.dcerpc.DcerpcTcpHandle.doReceiveFragment(
  at jespa.dcerpc.DcerpcHandle.sendrecv(
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.
1.2.6February 10, 2020
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).
1.2.5October 19, 2018
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

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.
1.2.4September 26, 2018
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(
  at jespa.dcerpc.DcerpcHandle.sendrecv(
1.2.3November 7, 2017
This release fixes a minor issue regarding the msrpc.tcp.idleTimeout property being ignored.
1.1.24November 7, 2017
This release fixes a minor issue with the HTTP client and chunked encoding.
1.2.2August 15, 2017
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).
1.2.1June 30, 2017
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.
1.2.0March 24, 2017
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:[\PIPE\NETLOGON] with identity mega.corp\jespa1$
  jcifs.smb.SmbException: Failed to connect:<00>/
  jcifs.util.transport.TransportException Connection reset
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:[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.