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.