Jespa Release Notes

The following exception could occur running HssSetup, Jespa Start and in other cases:

java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
        at jespa.msds.ModCldap.cldap(ModCldap.java:372)
        at jespa.msds.ModCldap.modSet(ModCldap.java:288)
        at jespa.msds.ModDcLocator.modSet(ModDcLocator.java:121)

An error in the Kerberos code could cause HMAC failure.

A NullPointerException would occur if the deprecated HttpSecurityService.init() method was used.

These issues have been fixed.

A new "Jespa Start" package has been added to the Downloads page. The Jespa Start executable jar is a quick and easy way to see SSO with SPNEGO / Kerberos working in your environment. See Run the Jespa Start Executable Jar for details.

A webapp version of Jespa Start is located in the jespa-start-webapp directory of the standard Jespa package. See Run the Jespa Start Webapp for details.

The LogStream class could close System.err. This issue has been fixed.

The HttpSecurityService can now use an external properties file when the HSS is packaged into a war or executable jar by adding code to resolve the properties.path relative to the application server context base.

The HttpSecurityService will now automatically add the fallback.location to the excludes list (taking into account the context path and only if it is not an absolute URL).

The Krb5SecurityProvider.getAcccount().getAuthType() method incorrectly returned "NTLM". This has been fixed to return "Kerberos".

The Krb5SecurityProvider.getAccount() userAccountControl property incorrectly returned the raw SAMR flags value. This has been fixed to return the much more common flag value used by AD DS and other Jespa code.

An idle timeout thread could delay java from exiting immediately. This issue has been fixed.

Significant new functionality has been added to Jespa including:

• SPNEGO and Kerberos implementations designed specifically to mimic Windows communication exactly (100% memory-safe Java, no JNA, no dependencies, no sun or javax Kerberos references)
• SPNEGO / Kerberos for the HttpSecurityService
• The new HssSetup console menu program can create and manage the HSS Computer account, password and SPNs in AD DS for the HttpSecurityService with no dependencies, no krb5.conf or keytab files and no cryptic Windows commands
• General purpose compatibility with GSS usage of AcceptSecurityContext, InitializeSecurityContext, EncryptMessage and DecryptMessage for the Kerberos, Negotiate and NTLM Windows SSPI security packages
• DC Locator protocol using SRV and CLDAP ping
• AES256, AES128, RC4 Kerberos encryption types
• Transparent forest traversal with RFC6806 Kerberos client and server referrals
• Automatically gets trust information using MSRPC
• Canonicalization of various Windows account name forms (backslash, principal, alternate UPN suffixes)

See the new online Jespa Technical Documentation for details.

Jespa 2.1 now requires Java >= 1.8 but is otherwise fully backward compatible with 2.0 (additional configuration is required to activate SPNEGO / Kerberos).

Prices have changed accordingly.

Note: Jespa 2.1.x does not support activation keys generated before approximately January of 2023. If you get an "Activation key not compatible with version" or "Failed to decrypt license key" error trying to upgrade, please contact sales@ioplex.com for assistance.

Multiple incorrect references to bindings.targetSpns, but without the trailing s, have been corrected in the Jespa Operator's Manual, the API documentation and in several examples/jespa/WEB-INF/*.prp files.

The HttpSecurityService could fail to correctly initialize EPA bindings. This issue has been fixed.

The Jespa 1.x series is discontinued.

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.