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:
java.io.IOException: Unexpected DCERPC PDU header
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.
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).
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 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.
September 26, 2018
This release fixes an NDR encoding issue that causes Jespa to fail with the following exception in the Jespa log:
November 7, 2017
This release fixes a minor issue regarding the |
msrpc.tcp.idleTimeout property being ignored.
November 7, 2017
This release fixes a minor issue with the HTTP client and chunked encoding.
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).
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.
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: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
java.net.SocketException: 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:192.168.10.20[netlogon] with identity mega.corp\jespa1$
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.
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.
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 |
localhost.netbios.name you will likely receive the following error:
jcifs.smb.SmbException: Logon failure: unknown user name or bad password.
With the release of MS15-027 / KB3002657 (see also http://www.ioplex.com/d/Jespa_MS15-027_KB3002657.pdf) the
localhost.netbios.name 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.
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
LdapSecurityProvider API documentation for details.
The API documentation has been updated which now uses the new Java 7 stylesheet.
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.
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.
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'.
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.
November 28, 2012
This release now includes a domain.trust.cache.values 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 jespa.domain.trust.cache.values 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.
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.
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).
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).
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).
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.