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).

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).

The 1.0.16 package was at some point incorrect 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.

Significant NTLM functionality from JCIFS has been re-written in Jespa to more closely emulate observed Windows behavior. As a result of this work, the iPhone and BlackBerry (through the BlackBerry Enterprise Server) is now known to work with the NTLMv2 Single Sign-On (SSO) functionality of the HttpSecurityService. The HTTP client now uses NTLMSSP flags more consistent with those used by Internet Explorer. The HttpSecurityService will now set the Content-Length header in authentication related 401 Unauthorized responses to stop servlet containers (like Coyote) from using Transfer-Encoding: chunked because using chunked encoding during authentication can confuse clients such as those based on AppleWebKit (the iPhone and BlackBerry).

The jespa.io.ByteBuffer.ensureSpace() method incorrectly computed the remaining space of derived buffers. This issue has been fixed (although it did not cause issues with other functionality of Jespa).

The last release broke the MyNtlmSecurityProvider example which resulted in a SecurityProviderException: Property not set or constructed: domain.dns.name error. This has been fixed.

If no credentials are supplied, the LdapSecurityProvider was supposed to use Context.SECURITY_AUTHENTICATION = none to perform an anonymous bind. This was not the case and could result in a NullPointerException. This has been fixed but a simple work-around for older releases is to set Context.SECURITY_AUTHENTICATION = none or java.naming.security.authentication = none (same thing) to explicitly request an anonymous bind.

The MyHttpSecurityFilter example now includes an inner FilterChain class that demonstrates how to perform work after the request has passed through the HttpSecurityService. This is useful for performing work with the SecurityProvider and Account of the authenticated user after authentication has occurred but without using an extra Filter in the chain. There have been other minor fixes and improvements to this example.

Under certain conditions, the identity returned by NtlmSecurityProvider.getIdentity() (and thus getRemoteUser()) could return an incorrect value. Specifically, if the principal name form of an account in a domain other than the Jespa service account domain (like abaker@b.busicorp.local) is used to perform a non-SSO authentication (meaning with a login form or password dialog) and account.canonicalForm = 3 (backslash form) is set, the domain in the identity would always incorrectly be the service account domain and not the real user's domain. This would make it appear as though cross-domain authentication failed when in fact it was actually successful - the user's name was simply canonicalized incorrectly. This issue has been fixed.

The Account object returned by NtlmSecurityProvider will now include domain.dns.name and domain.netbios.name properties representing the domain of the authenticated user. Previously it was difficult or impossible to retrieve the domain of the authenticated user. Note that the ntlmsssp.domain.* properties of the NtlmSecurityProvider class should not be used (anything that is not documented is not supported). These properties were intended to indicate the client's domain before SSO authentication completed but clients do not reliably supply this value. In fact the ntlmssp.domain.dns.name property of NtlmSecurityProvider has been removed because the value was incorrect - it was the NetBIOS domain name. Anyone using these properties should instead use NtlmSecurityProvider.getAccount() to retreive the above mentioned domain properties of the Account class.

The src/jespa/examples/MyHttpSecurityFilter.java example has been revisited and now directs Jespa log messages to a log4j Logger.

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

This release addresses the following minor issues:

• The Jespa HTTP client did not correctly handle valueless Cookie attributes (such as "HttpOnly" which is shorthand for "HttpOnly=") emitted by servers like ASP.NET. This issue has been fixed.
• The Jespa HTTP client now supports an http.tls.sslsocketfactory.classname property which can be set using a header property (see examples/HttpGetWithHeaderProperties.java) to the name of an SSLSocketFactory class. This would be required to install a custom TrustManager for example. The Jespa HTTP client does not implement HttpsURLConnection.
• The HttpSecurityService could incorrectly write a "MaxInactiveInterval is short" log entry even with log.level = 0. This errant log entry will now be written only with a log.level >= 3

The LdapSecurityProvider now supports an ldap.tls.trustall property which disables server certificate verification and thus eliminating the requirement for exporting and configuring a server certificate. Similarly an ldap.tls.sslsocketfactory.classname property has been added (see the LdapSecurityProvider API documentation for details). All references to a ldap.useStartTls property have been removed from the LdapSecurityProvider API documentation and examples because no such property exists and never existed in a production release of Jespa. The correct method for enabling START_TLS is to set flags.confidentiality = true.

The license key update routine now accepts lowercase 'y' as well as uppercase 'Y'.

The Javadoc API documentation on the website has been updated.

The properties.path changes in the previous release could trigger the following error with Tomcat:

javax.servlet.ServletException: jespa.security.SecurityProviderException:
Failed to read properties.path file: /localhost/jespa/WEB-INF/example_ntlm.prp
    at jespa.http.HttpSecurityFilter.init(HttpSecurityFilter.java:125)

Note: The most reliable way to specify an absolute path (such as when accessing a properties file outside of a WAR archive) is to use the file:/ prefix like file://myapp/ntlm.prp. The file:/ prefix indicates to the HttpSecuritySerivce that the path should not be resolved relative to the webapp base. Therefore on Windows, properties.path values like file:/H:/myapp/ntlm.prp and file:///s1.busicorp.local/dev/myapp/ntlm.prp should also work.

If the properties.path property value beings with a '/', the HttpSecurityService will attempt to load the specified file using the absolute path (after trying to first load it as a resource of the webapp). This permits loading HttpSecurityService properties files that are external to WAR packages. DNS routines have been adjusted to be more compatible with GlassFish 3.

• The HTTP client now supports chunked POST requests. It will also automatically handle authentication and redirection in streaming mode provided that the caller has not written more than one segment / chunk of data (an HttpRetryException will be thrown if data has been committed such that the client cannot retry the request automatically).
• The HTTP client will now accept Jespa properties, such as the service.acctname and service.password, using conventional request properties prefixed with "jespa." (see examples/HttpGetWithHeaderProperties.java).
• The NtlmResponse class, which is used to implement custom NTLM authorities without Active Directory, and the corresponding MyNtlmSecurityProvider example did not work correctly with newer versions of Windows such as Windows 7 and in some cases Windows Vista. This issue has been corrected.
• The MyNtlmSecurityProvider example has been revisited and improved (and may have been defunct in some scenarios).
• The NtlmSecurityProvider now supports a flags.capabilities.accept.ntlmssp property which when set to false will indicate to the HttpSecurityService that SSO should not be attempted (so that secondary NtlmSecurityProviders can be used in a chain with the ChainSecurityProvider).

At some point the SetupWizard.vbs and SetComputerPassword.vbs scripts were excluded from some Jespa packages. The version number has been changed only to ensure that these errant packages are purged from browser caches. There have been no changes to the code.

Some automatic conversions of multi-valued LDAP attributes did not work as specified in the documentation. The LdapEntry.toArray() method was not implemented correctly. These issues have been corrected. These issues should have no impact on NTLM HTTP authentication.

An invalid NTLMSSP token could trigger an ArrayIndexOutOfBoundsException. This issue has been fixed. Only the builtin Java HTTP client has been observed to send the invalid NTLMSSP tokens that trigger this error. Conventional browsers should not be affected.

The 1.1 HttpSecurityService could fail to return HTTP content. More specifically, the HttpSecurityService could incorrectly return a status of 200 Ok without a request body such as when the status should have been 304 Not modified. This resulted in browsers sporadically failing to load content, browsers failing to run JavaScript loaded from separate files, and general odd behavior. This bug has been fixed. This bug is not a security issue and does not effect the 1.0 HttpSecurityService.

Jespa 1.1 is no longer BETA and is now stable for production use. This release includes some minor fixes and improvements.

The jespa.License -u option to update the license.key resource in a JAR could report failure on Windows (even though it was actually successful). The SetupWizard.vbs script could emit a dialog that was too large for low resolution displays for the user to access the dialog's buttons. An ArrayIndexOutOfBoundsException could occur if a client submitted an invalid NTLMSSP token. These issues have been fixed. The status code of the exception thrown when trying to create an LDAP entry that already exists has been corrected to match the documentation. The jespa.security.JCAProvider is now loaded only just before the LDAP client is about to initiate NTLM authentication with Active Directory. The LDAP API will emit exceptions if the authentication mechamism is "simple" and the service.acctname is not a DN or if a password is an empty string.

This BETA 2 release of the 1.1 branch of the Jespa library includes the following significant fixes and improvements:

• The API documentation has been significantly improved. In particular, the jespa.ldap package is now well documented.
• Jespa now includes many sophisticated fully-functional examples. All examples (in the examples/ directory) have been re-written. The API documentation has been greatly improved with many example code fragments.
• The HTTP client could fail to report a non-200 status, it could incorrectly throw an exception trying to flush the output stream and it could throw a NullPointerException trying to close the output stream. These issues have been fixed.
• If authentication with the HttpSecurityService failed (such as because the client tried to negotiate NTLMv1 whereas domain security policy required NTLMv2), it could incorrectly re-challenge the client in a way that caused a Not a Type 1 message error on the subsequent request. This error has been fixed.
• The LdapSecurityProvider could fail to correctly canonicalize and compare DN values if they included space characters around equals signs. This provider could fail to properly compute a DN based on an RDN. The issues have been repaired. The special service.password.encrypted property is now removed when LdapSecurityProvider.dispose is called. A warning is logged if GSSAPI authentication is used with the LdapSecurityProvider regarding the lack of proper DNS PTR records. This provider will now throw an exception if the supplied password was NULL. The LdapSecurityProvider will now retry to locate a suitable LDAP server if the supplied dns.site property did not connect to a suitable server. The logic to retrieve account information (such as for the authenticate method) did not correctly process the search filter expression as advertised in the API documentation (the uid attribute was hard-coded into the filter). Numerous other issues have been fixed in the LdapSecurityProvider.
• The LdapAccount.setPassword method did not correctly encode password hashes commonly used by RFC-based LDAP servers. This issue has been repaired.
• The LdapAccount.changePassword method did not correctly catch the LDAP_CONSTRAINT_VIOLATION condition when trying to modify the Active Directory specific unicodePwd attribute. This method also incorrectly modified state of the LdapSecurityProvider. These issues have been fixed.
• The type, flags and conv members of the LdapAttrDef class are now public as advertised in the API documentation.

The 1.1 branch is still in BETA status and as such it is currently not recommended for production environments.

A deadlock in the Account.isMemberOf method (which is called by HttpServletRequest.isUserInRole) has been fixed. Jespa would not properly failover gracefully to another DC if an "All pipe instances are busy" error occured (because of contrary server stickiness logic). This issue has been fixed. The API documentation incorrectly included a class that was not intended to be public. This class is now properly excluded.

This is the first BETA of the 1.1 branch of the Jespa library. Some of the major new functionality included in this release is:

• The security functionality defined by the SecurityProvider and Account interfaces have been expanded to include creating, updating, deleting, searching and querying accounts and setting or changing passwords on accounts.
• The HttpSecurityService can now load properties from a properties file and will automatically reload the properties within 5 seconds if the file is modified at runtime.
• An LDAP API is included which is designed to make performing common LDAP operations as simple as possible, efficient and with a minimal amount of code
• A new complete LdapSecurityProvider may be used with other Jespa components like the HttpSecurityService. The LdapSecurityProvider may be used to create, uptdate, delete, search and query Active Directory accounts and change or set Active Directory account passwords. The LdapSecurityProvider also supports RFC-based LDAP servers such as OpenLdap.
• The HttpSecurityService has been completely re-written to better support the ChainSecurityProvider, LdapSecurityProvider and other new functionality (although the 1.0 version of the HttpSecurityService is not known to have any significant issues).
• An LdapSearch commandline utility is now included that permits any Java enabled system to query LDAP servers including Active Directory using NTLMv2 and 128 bit session security. This eliminates the need for TLS / SSL and Kerberos (although both features are also supported).
• A very complete example SecurityProvider with source code is included that illustrates how to build a SecurityProvider on top of an existing SQL database (the WordPress MySQL database in this case).
• The Jespa Operator's Manual and API documentation have been completely revisited to reflect the major new functionality of Jespa 1.1 (only updated within the .zip and .tar.gz packages for now - the website will continue to host the 1.0 documentation).

There have been no code changes in this release.

The Jespa Operator's Manual has been updated regarding HttpSecurityService excludes, the DNS records file, the service.acctname and localhost.netbios.name properties, the jar command, and new issues in the Possible Issues section.

If an HttpSecurityService client supplied incorrect NTLM credentials, the HttpSecurityService would return the expected 401 Unauthorized status but it would not challenge the client with the WWW-Authenticate: NTLM header. This is not consistent with the HTTP specification and it would prevent the password dialog box from reappearing. This issue has been fixed. The user will continue to be challenged with the password dialog until either correct credentials are supplied or the user clicks Cancel.

The HttpSecurityService logout feature using the http.parameter.logout.name parameter did not work correctly. It would not always properly remove security provider state from the HTTP session. This issue has been fixed.

The DNS records file now supports A records (in the format <name> A <ipaddress>) allowing a records file to completely bypass DNS lookups throughout the Jespa library. Under certain conditions, Jespa could attempt to lookup an IP address in DNS (such as when trying to use an IP address in an HTTP URL with the Jespa HTTP client). This issue has been fixed - a dot-quad address will be converted directly into an IP without attempting to communicate with DNS.

The NtlmSecurityProvider can now authenticate clients by userPrincipalName. For example, it is not uncommon to use the userPrincipalName attribute of an account for an email address with an SMTP domain and not the user's AD DNS domain. Previously Jespa simply failed to authenticate clients that supplied their userPrincipalName. This issue has been fixed. The Jespa Operator's Manual has been updated.

This release includes the following improvements and fixes:

• The HttpSecurityService excludes list now accepts wildcard expressions.
• The HttpSecurityService can now better suppress IE's network password dialog (in favor of redirecting to the fallback.location).
• Numerous problems with the HTTP client have been resolved.
• The HTTP client now automatically handles 301 and 302 redirects.
• All HTTP examples have been modified to use jespa.http.HttpURLConnection directly (using the java.protocol.handler.pkgs System property is clumsy and should not be used wherever possible).
• The "Property required" error message has been changed because it was believed to have encouraged operators to incorrectly set properties.
• Several types of shared objects are now gradually expired and disposed whereas previously they could accumulate and waste resources. They include SID cache entries, HTTP peers, HttpSecurityService authentication contexts and NETLOGON and DNS contexts.
• NETLOGON contexts are now indexed using a combination of the domain name and local NetBIOS name thereby improving the ability to safely share these contexts under sophisticated threading scenarios.
• The Jespa Operator's Manual has been updated significantly.
• Warning constants have been added to all undocumented public classes and interfaces to emphasize that undocumented APIs are not supported and may change without notice.

This release fixes the following issues:

• Failover did not work correctly. If the domain controller Jespa was communicating with suddenly became unavailable, exceptions could be thrown from the Jespa library and it could take as long as 5 minutes to correctly acquire a new domain controller. This issue has been fixed. It should now take no longer than 60 seconds for Jespa to recover from a domain controller failure and it should be completely transparent to users.
• The dns.servers property could be ignored in certain cases. This issue has been fixed. The Jespa library will only use the DNS servers supplied with the dns.servers property.
• DNS properties could not be changed at runtime. This issue has been fixed. If DNS properties are changed, new DNS contexts will be created as necessary.
• Windows 2000 clients could fail to authenticate using NTLMv1. This issue has been fixed.
• The service account password could be recorded in the log if it contained regular expression characters. This issue has been fixed.
• A carriage return in the license.key file could cause an ArrayIndexOutOfBoundsException. This issue has been fixed.

Error handling has been improved. Errors for conditions like an expired password, account lockout, invalid login hours, etc, will no longer result in an uncaught exception. These errors will now be quietly logged along with the account name.

NtlmSecurityProvider properties used by the NETLOGON service may now be changed at runtime without restarting the JVM.

The following error could occur if domain security policy does not permit "anonymous" binding to the NETLOGON service:

jcifs.smb.SmbException: 0xC0000199 
  at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:539) 
  at jcifs.smb.SmbTransport.send(SmbTransport.java:641) 
  at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:361)

The following error could occur when using the explicit login feature of the HttpSecurityService in conjunction with some versions of IE which proactively reauthenticate POST requests:

jespa.security.SecurityProviderException: Not a Type 3 message.
  at jespa.ntlm.NtlmSecurityProvider.acceptSecContext(NtlmSecurityProvider.java:1082)
  at jespa.http.HttpSecurityService.doAuthenticate(HttpSecurityService.java:688)
  at jespa.http.HttpSecurityService.doFilter(HttpSecurityService.java:782)

A NullPointerException could be thrown if DNS did not return any records (because dns.servers was not set and the default DNS server is not an authority for AD services). This issue has been fixed (Thanks MT).

The NtlmSecurityProvider did not always correctly handle the NTLMSSP TargetInformation. This isssue has been fixed (although it is unknown if this bug could cause an error with any real clients or servers).

Account information was incorrectly being written to the log. This log statement has been removed.

The MyNtlmSecurityProvider example did not work with Windows Vista clients. This issue has been fixed. Additionally, the domain name was required to be supplied in uppercase. This issue has been fixed but also requires upgrading to JCIFS 1.3.11. The explicit login form would not install the authenticated user's identity. This issue has also been fixed.

The Jespa Operator's Manual has been updated regarding validating the license key of a Jespa jar file, the NETLOGON service, JCIFS requirements and the ScriptPW.Password error running SetComputerPass.vbs.

The displayName account attribute (representing the user's full name) has been removed from the list of default Account attributes because it was discovered that the NETLOGON service always returns an empty string even if displayName has a value in AD. All references to the displayName / full name have been removed from the documentation.

The HttpURLConnection class has been modified to create an SSL socket if the protocol supplied in the URL is "https". The jespa.https.Handler URL protocol handler has also been added so that both NTLMv2 and SSL can be used together with other Java components as the default HTTP/HTTPS implementation.

The example webapp was accidentally distributed with the jespa.authority.dns.names.resolve init-param set to false and jespa.log.level set too high. This has been corrected.

The following error could occur sporadically:

jcifs.smb.SmbException: The parameter is incorrect.
  at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:542)
  at jcifs.smb.SmbTransport.send(SmbTransport.java:644)
  at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:372)
  at jcifs.smb.SmbSession.send(SmbSession.java:235)

http://jcifs.samba.org/src/

No logical changes to the Jespa package have been applied - only the JCIFS library must be updated. The Requirements section in the Jespa Operator's Manual has been updated to reference JCIFS 1.3.10.

The example webapp was accidentally distributed with an init-param for netlogon.useSecureChannel set to false. If you happen to be using the example webapp from 1.0.0 please remove this bad init-param or you may receive an error.

The BETA testing period is complete. No significant issues have been reported and no sigificant changes have been made in several weeks. IOPLEX Software is very grateful to all of you who have helped test what we hope will be a robust and useful solution.

The documentation has been updated slightly. A minor bug in the SecurityProvider.getAccount method has been fixed.