Select Access cannot use a read-only User Store on Active Directory (and probably all other Directory Servers). The policy builder logs a NullPointerException on the java console:

Exception caught in com.hp.ov.selectaccess.policybuilder.MainPanelRemote method:getSubjectTreeData
java.lang.NullPointerException
at com.hp.ov.selectaccess.util.LDAPServer.isCanCreateSubentry(LDAPServer.java:2624)
at com.hp.ov.selectaccess.adminserver.SubjectCache.getCanCreateSubjects(SubjectCache.java:394)
at com.hp.ov.selectaccess.adminserver.SubjectCache.initializeSubjectCacheNode(SubjectCache.java:612)
at com.hp.ov.selectaccess.adminserver.SubjectCache.getSubjectTreeData(SubjectCache.java:1246)
at com.hp.ov.selectaccess.adminserver.MainServer.getSubjectTreeData(MainServer.java:1746)
at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.hp.ov.selectaccess.simplermi.MethodInvocationHandler.invokeMethod(MethodInvocationHandler.java:199)
at com.hp.ov.selectaccess.simplermi.ServerServlet.doPost(ServerServlet.java:167)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:405)
at org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:622)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1457)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1409)
at org.mortbay.http.HttpServer.service(HttpServer.java:889)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:829)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:998)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:846)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:345)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:530)
    

Select Access validator configured to use an Oracle Internet Directory as a Policy Store.

During normal use, users are suddenly forced to re-authenticated because their cookies are invalid.

The Oracle Internet Directory can not apply matching rules correctly on attributes with syntax "Octet String"(1.3.6.1.4.1.1466.115.121.1.40) or "Binary""(1.3.6.1.4.1.1466.115.121.1.5).

The fix changes nxNonceSecret syntax to "IA5 String"(1.3.6.1.4.1.1466.115.121.1.26) when importing schema into OID, and wraps nonce secrets in BASE64 encoding ssaving/loading data from the LDAP server.

When Identities are contained within Groups (Static or Dynamic), and those Groups are contained within other groups (Static or Dynamic), then the policy grid displayed in the user interfaces does not match the policy enforced by the validator.

In an earlier release, the validator was modified so that only Identities can be inherit from groups; groups cannot inherit policy from other groups. This change was made to fix a severe performance problem reported by a customer.

A configuration switch (in the Custom Settings screen) has been added to allow administrators to select the old behaviour (groups can be members of other groups for policy inheritance) and the new behaviour (policy does not inherit through nested groups).

The policy builder has been modified to display the appropriate policy inheritanced based on the setting of this global configuration switch.

The problem is caused by the OpenLDAP directory server's quoting rules for "," within a DN. OpenLDAP appears to have changed their quoting rules across several releases, explaining why this works (for example) with 6.1 against OpenLDAP 2.0.27, but fails when using OpenLDAP 2.2.27.

The adminserver has been modified to adapt to the OpenLDAP quoting rules properly.

in a weblogic cluster environment, the Select Access Weblogic integration is sending badly formatted XML queries to the validator. The validator rejects the queries, and the enforcer returns the error to Weblogic, causing Weblogic internal processes to fail.

The badly formatted data is a copy of the POST data sent by the WL client. It is not being properly converted to UTF-8 (since it is really binary data) before being sent to the validator.

The problem is within the code that detects the Active Directory version. The code was erroneously searching the entire directory for entries containing the attribute "operatingSystemVersion". This has two problems: the entry set returned can be large, and the entries returned are for hosts in the domain, not for the domain controller itself.

The adminserver has been patched to find the specific entry in the directory that corresponds to the Active Directory server when determining the server's version.

This is an enhancement request to have SA password reset unlock an account (on Active Directory or ADAM) that has been locked by the Windows account management system.

Active Directory can be configured to lock an account after failed login attempts. This is indepedent of Select Access Account Management, which uses a private facility that is identical on all directory servers.

SA Password reset knows to unlock an account that has been locked by SA Account management. However, When an account has been locked by Active Directory (outside of Select Access), SA Password Reset does not remove the Windows account lockout.

The adminserver has been patched to remove the Active Directory account lockout when the user password is changed.

To enable this, the administrator must enable the "accountLockoutTime" attribute for Select Access, and then delegate control over the attribute to Password Reset users.

Customer has a validator plugin that after authenticating users, redirects to another page from within the validator.

When using IIS, validator authentication cookies are not set in the browser when the validator returns the redirect. When browser arrives at the destination page, the user is not authenticated because the cookies have not been set.

This does work with Apache, because Apache *always* sets validator cookies on every response.

The enforcer logic has been rewritten to:

• handle the pool of network connections to each validator better
• handle network errors better; the enforcer does not reconfigure itself after every error
• handle reconfiguration better: the enforcer only reconfigures when the configuration has changed.
• some performance improvements.

If the java logging subsystem encounters certain errors (e.g. File not found) and throws an exception, the exception is thrown all the way through the logging and enforcer libraries and is caught by the top-level of the Enforcer, which then returns an ERROR result to the caller (usually resulting in an error page being displayed to the end user.)

Exceptions should be caught inside the Logger subsystem instead.

The policy builder "Identity Location" screen allows configuration of an SSL-protected LDAP server. The validator can optionally configure the CA certificate used to verify the LDAP server's SSL certificate.

Unfortunately, the Certificate Import function on the Identity Location screen does not work; it reports that the CA certificate is invalid.

The policy builder applet running inside the browser did not properly initialize the crypto libraries. This prevented the policy builder from loading and parsing certificates.

The Policy builder code has been patched to properly initialize the crypto library at startup.

The problem is a combination of two things:

1) the Adminserver fetches the group membership list, then fetches the full LDAP entry for each individual group member. Since this extra information isn't required, there's no reason to fetch it when opening a group.

2) the cache invalidation interval is short enough that by the time the group properties screen is opened, the cache has been invalidated, so switching to the group membership tab means that the same refresh operation (group membership list, then all individual group members) is performed *again*.

The adminserver has been patched to load the initial group properties quickly. When the membership tab is selected, if the group is large enough the user is asked to enter a filter string to display a subset of the group membership.

The original log message was only output if the main validator thread tried to exit before all of the worker threads. On different threading implementations these steps happen in different orders, and so the message does not always appear.

Two messages are added to the validator log stream, both at Operation / INFO level:

• validator %s is initializing...
• validator %s is shutting down...

In both cases, '%s' is replaced with the validator ID (validator.example.com:9988)

The single LDAP connection has been replaced with an LDAP "pool" (really thread-local storage) mechanism, which will remove the serialisation.

Performance testing shows reasonable improvement under heavy load (30% in long trials). However, the surprising result is that performance of basic login operations is now much more consistent between tests. Prior to these changes we would see widely varying performance data for the same test run. Presumably random timing differences would change the locking interactions; since those interactions are now gone, performance is consistently high.

In a weblogic cluster environment, the Select Access Weblogic integration is sending badly formatted XML queries to the validator. The validator rejects the queries, and the enforcer returns the error to Weblogic, causing Weblogic internal processes to fail.

The badly formatted data is a copy of the POST data sent by the WL client. It is not being properly converted to UTF-8 (since it is really binary data) before being sent to the validator.

The Weblogic integration was reading the HTTP POST data. None of our other enforcers do so. This code has been removed from the Weblogic plugin.

Use of OpenLDAP as a policy store or user store requires that the OpenLDAP administrator disable schema checking. This can cause problems with other parts of the directory, so Select Access needs to function with OpenLDAP schema checking enabled.

Select Access does not write the OU attribute into the object when it is creating LDAP entries with OU as the child RDN. This is a violation of the OpenLDAP schema checks, though none of our other directory servers complain about it.

Some objects that are already defined in the nis.schema file shipped with OpenLDAP were removed from the sa.schema file. Administrators must now manually enable the nis.schema file, if it is not already included.

In certain high-load situations, customers may notice a large number of LDAP MODify operations logged by their directory server, coming from the validator. These typically show up in rapid succession, and often fail (either "attribute value doesn't exist" on a delete, or "attribute value already exists" on an add.)

These only show up for user accounts that have account management and/or password management enabled. The validator is attempting to update fields like "failed login count" or "last login time", but is generating incorrect MODify requests because the validator cache is out-of-sync with the directory.

Update: In some cases, the validator will also return a DENY instead of an ALLOW for otherwise valid login attempts, because it repeatedly tries (and fails) to modify the LDAP account management attributes.

The validator has been fixed to perform cache invalidations where needed, to keep the cache in sync with LDAP, and to replace several LDAP_MOD_DELETE/LDAP_MOD_ADD pairs with more reliable LDAP_MOD_REPLACE operations.

The Select Access enforcer treats "http://example.com/dir/page.html;parameter=value" and "http://example.com/dir/page.html" as two different resources, and so policy cannot properly be assigned to "page.html".

The enforcer currently removes ";jsessionid=value" from URLs; this is an enhancement request to strip all semicolon-delimited paramters from URLs.

Select Access enforcer has been enhanced to (conditionally) remove semicolon-delimited parameters. The settings for this can be found on the "Enforcer Tuning Parameters" screen in the setuptool and PolicyBuilder component configuration screens.

A single "service" entry in the Select Access Policy can have multiple names. The most common source of this would be an SSL-enabled webserver, which could serve the same content to both SSL and non-SSL clients. In this case, the service would be named both "http://host.example.com:80" and "https://host.example.com:443". Another example would be an environment where a service is accessed by both short and log names.

If enforcers are sending a steady stream of queries using both (all) names for a service, the validator will continuously reload the entire rule tree for that service into the cache, instead of finding the previously loaded copy.

This would be seen in a DEBUG level validator log, or in validator TRACE messages, or in the LDAP server logs.

validator logic has been updated to prevent the unecessary cache reloads.

Select Access on RedHat AS 3.0 cannot be configured using OpenLDAP 2.0.27; errors are reported by the adminserver, and it will not start.

schemacheck can now be on by default.

Tested 2.0.27 on RH AS 3.0, plus 2.2.27.

The schema change requires nis.schema to be loaded due to RedHat using it as a default schema, removed the nis attrs/oc's from our sa.schema and use the ones from nis.schema

The java enforcer logs an exception and refuses to work on some installations of Windows 2003 Server. The Operating System ID string has changed from "windows 2003 server" to "windows server 2003", which caused the OS matching code in the enforcer to fail.

The OS match code in the enforcer is redundant, since we do not support Windows 95/98, and so it has been removed entirely.

When using a single service that has multiple names (eg. http://SOAM:8080/ and https://SOAM:8443/), validator performance is very slow (10s of transactions per second instead of 100s of transactions per second).

The problem was that the validator cache of services was not correctly indexed. Accessing the validator with requests for the same service with two different service names would cause the validator service cache to thrash, severely affecting performance.

The cache has been fixed to properly index all names for a service, eliminating the thrashing.

When using the Windows Sharepoint integration, a user will be prompted for their username and password after several minutes of continuous use, even though their Select Access credentials have not expired.

Specifically, the problem occurs when the Select Access cookie is updated.

The customer is using two-factor authentication; certificates and username password. They would like to have the certificate plugin fetch the userID from the LDAP record, and send it back to the enforcer so that it can be filled into a password login form; that way, the end-user cannot attempt to use a userid that doesn't match their certificate.

There is no security advantage to doing this; the validator properly rejects authentication requests for two different users in multi-auth rules. This is purely a end-user usablility enhancement.

certificate plugin is modified to add the userid (extracted from the user's LDAP record) to the "user" field of the form_data blob in the validator response object. This will allow any client-side authentication forms to pick up the userid automatically, if they desire.

1. In the SelectAccess installation, create the directory Select Access\jre\lib\endorsed.
2. Copy the file Select Access\shared\jetty\policy_builder\protected\xalan.jar to Select Access\jre\lib\endorsed\xalan.jar.