Communications Software
1.2.11 May 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.10 April 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.9 December 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.8 November 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.7 August 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.6 February 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.5 October 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.4 September 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.3 November 7, 2017

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

1.1.24 November 7, 2017

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

1.2.2 August 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.1 June 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.0 March 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.

1.1.23 November 7, 2016

There have been no changes to the code in this release. The build environment has been migrated to a new environment. Upgrading is not necessary as it should have zero effect.

1.1.22 July 7, 2016

There have been no changes to the code in this release. Only the Jespa Operator's Manual has been updated.

If you set the property you will likely receive the following error:

jcifs.smb.SmbException: Logon failure: unknown user name or bad password.
       at jespa.ntlm.Netlogon.validate0(
With the release of MS15-027 / KB3002657 (see also the property is now deprecated. If you remove that property (and create separate Computer accounts to compensate), the error will be resolved. See the updated Jespa Operator's Manual for details.
1.1.21 December 12, 2014

This release adds support for single-label domain names (even though it is deprecated in AD). See the authority.dns.names.resolve.sld property description in the NtlmSecurityProvider or LdapSecurityProvider API documentation for details.

The API documentation has been updated which now uses the new Java 7 stylesheet.

1.1.20 November 26, 2013

There are no code changes in this release. However, this package was created in a completely new build environment on new machines with Java 7 using compiler parameters for compatibility with Java 1.5 or later.

1.1.19 June 4, 2013

Using an ldaps:// bindstr with the LdapSecurityProvider (or LdapSearch) was broken in a previous release. This release fixes this issue. This issue is in no way related to the NtlmSecurityProvider or NTLM over HTTP authentication.

A call to super.destroy() was added to to the MyHttpSecurityFilter example. This is necessary to close the log file descriptor when re-initializing the webapp without restarting the JVM.

1.1.18 April 3, 2013

The License utility used to re-license jar files will now ignore extraneous carriage-returns which have a tendency to leak into license key files and result in a StringIndexOutOfBoundsException. The previous release introduced a typo in the example webapp web.xml referring to 'example_ntlm.alt'. This has been corrected to be 'example_ntlm.prp'.

1.1.17 February 11, 2013

The HttpSecurityService could leak a file descriptor if it was destroyed and reloaded without restarting the JVM (such as by recycling a webapp without restarting the application server). This issue has been fixed. The file descriptor is now properly closed within HttpSecurityService.destroy(). Note that if you have overridden HSS.destroy(), you must call super.destroy() for the log file descriptor to be properly closed.

The HTTP client will now not throw an Exception for the return status code 201 CREATED. All other status codes greater than 201 are still considered exceptional and as such the Exception must be caught if it is to be ignored.

1.1.16 November 28, 2012

This release now includes a property that may be used to artificially insert data about foreign domains into the local domain info cache. This property is known to successfully work-around problems retrieving foreign domain data. If you have trouble authenticating users in other domains, this property may help. For details, see the NtlmSecurityProvider Properties section of the latest Jespa Operator's Manual. Note that when setting this property in your HttpSecurityService properties file, it must be prefixed with "jespa." like or it will not be passed to the NtlmSecurityProvider.

The Jespa HTTP client (exposed through the jespa.http.HttpURLConnection class) had significant logical errors handling and parsing cookies. The HTTP cookie handling code in the HTTP client has been largely re-written in this release. If you have tried and failed to use the HTTP client before, please try this package.

1.1.15 August 20, 2012

If a user being authenticated is a member of a large number of groups (thousands) the following exception could occur:

This issue occured because of a signedness bug encoding and decoding group SIDs. This issue has been fixed.

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

1.1.14 May 15, 2012

A protected jespa.http.HttpSecurityService.onException method has been added to make it easier for custom extensions to display meaningful context specific error information to users. See the associated API documentation and examples for details.

The NTLM implementation has been adjusted to work with cURL (note however that cURL does not support NTLMv2).

1.1.13 February 1, 2012

Canonicalizing domain names of users from domains in external forests / domains could fail if the Computer account was in a sub-domain of the forest root. Jespa will now query the forest root if possible to resolve these names. For cases where domain name canonicalization still fails, a new property has been added to artifically inject domain trust information into the cache (which might also be used to work around firewalls or improve performance over distant networks).

1.1.12 January 3, 2012

NTLM authentication could fail if the clients domain did not have a direct trust with the domain of the Jespa Computer account and backslash style name canonicalization was used. This issue has been fixed.

Group based access control checking could fail if the Jespa instance was isolated from domain controllers such as by a firewall because the code that resolves group names into their corresponding SID is in the JCIFS library which has no knowledge of Jespa's DNS subsystem. This issue has beed fixed (server names are converted to IP before JCIFS is queried for a SID).

1.0.17 January 3, 2012

The 1.0.16 package was at some point incorrectly compiled with Java 1.6 during a build server migration. This would result in the binaries failing to load on Java 1.5 platforms. The 1.0 package is now correctly compiled with Java 1.5. Note that Jespa 1.1 was always correctly compiled with Java 1.5 and was totally unaffected by the migration. There have been no changes to the code itself. The version number was incremented only to clearly identify the correctly compiled package.

© 2022 IOPLEX Software | Contact Us | Policies