Jespa Release Notes
NullPointerException(which could only occur with
log.level >= 4) has been fixed.
NullPointerExceptionintroduced in the previous release has been fixed.
jespa.io.EncodingException: Invalid userName: email@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.hashproperty. See the new Issue 16: SPN BINDINGS FAILURE and CHANNEL BINDINGS FAILURE Errors section in the latest Jespa Operator's Manual for related information.
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.
NtlmSecurityProvidercould throw a
NullPointerException. This issue has been fixed. This issue is not applicable to conventional
ntlmsssp.sessionKeyproperty. When using the
NtlmSecurityProvideras 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
jespa.util.NtException.getNtStatus()method has been changed to
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 firstname.lastname@example.org for assistance.
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
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
HttpSecurityServicewill not create a new HTTP session if one is not absolutely required such as because the resource is not protected (
false). Previous versions would create HTTP sessions unnecessarily.
HttpSecurityServicecould 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.
PrintStreamclass). 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.
DuoHttpSecurityFilterfor 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.
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.
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).
msrpc.useNamedPipe = trueis 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.useNamedPipeis 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.SmbExceptionbut 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.
jespa.dcerpc.DcerpcException: DCERPC_FAULT_NDR at jespa.dcerpc.DcerpcMessage.getResult(DcerpcMessage.java:26) at jespa.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:241)
msrpc.tcp.idleTimeoutproperty being ignored.
ArrayIndexOutOfBoundsbug has also been fixed. The Jespa Operator's Manual has been updated.
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 successfulIMPORTANT: 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.