Advanced Access Control known issues and solutions

Determine if an issue you are having has a fix or a workaround.

Troubleshooting PIP server connections

To troubleshoot connection errors, ensure that runtime tracing for the PIPs is enabled.

  1. In the local management interface, click AAC > Global Settings > Runtime Parameters > Runtime Tracing.
  2. In the Tracing Specification field, type the tracing specifications for the PIPs:
    For JNDI (LDAP PIP)
    com.tivoli.am.rba.pip.LdapPIP=FINE
javax.naming.*=FINE
    For JDBC (Database PIP)
    com.tivoli.am.rba.pip.JdbcPIP=FINE
java.sql.*=FINE
    Note: A trace level of FINE provides general trace, method entry, exit, and return values. For more detailed information, consider using FINER or FINEST as the trace level.
  3. Click Save.

Removal of a server connection defined for a PIP causes a problem

A problem with a policy information point (PIP) can be caused by:

  • Deleting a server connection, especially if it is defined by a PIP and being used to return attributes in a policy or risk score.
  • Updating the JNDI ID or host name of a server connection after it was already referenced in a PIP definition.
  • Updating any of the server connection properties that are not valid after it was already referenced in a PIP definition.

Solution:

Review the list of server connections to determine whether any were deleted, and re-create any deleted server connections.

Ensure that the PIP specifies the correct server connection:

  1. In the local management interface, click Secure Access Control.
  2. Under Policy, click Information Points.
  3. Select the server connection PIP and click Modify.
  4. In the Connection tab, locate the Server Connection field and determine whether it contains the correct server connection.
  5. Update the server connection, if necessary.

WebSEAL sends client certificate by default

The isamcfg tool can configure a WebSEAL or Web Reverse Proxy instance to use client certificate authentication to the run time. The run time can be configured to optionally accept client certificates. When configured in this mode, WebSEAL or the Web Reverse Proxy sends a client certificate regardless of whether a certificate label is specified in the configuration.

Solution:

If you require client certificate authentication, ensure that a valid client certificate is specified in the ssl-keyfile-label entry of the [rtss-cluser:<cluster name>] stanza. If you do not require client certificate authentication, either disable the optional acceptance of client certificates or specify an invalid client certificate label in the ssl-keyfile-label entry of the [rtss-cluser:<cluster name>] stanza. This method ensures that WebSEAL does not send a client certificate.

A junction error occurs when a duplicate dn or certificate label is detected

The isamcfg tool imports the Security Verify Access server certificate to the WebSEAL or Web Reverse Proxy keystore when it uses an SSL connection. If an entry exists in this keystore with the same dn or the same certificate label, an error can occur when it creates the junction to the Security Verify Access server.

Solution:

You must manually export the certificate that is presented by the run time and import it to the WebSEAL key database as a signer certificate. The junction then becomes accessible.

The appliance fails to connect to the authorization service endpoint

When the appliance is configured in FIPS and NIST SP800-131A compliant mode, the RBA EAS configured in the POC appliance fails to connect to the authorization service endpoint. This failure causes the RBA flow to fail. This issue also affects the ping call that is issued regularly. The connection fails because the authorization service EAS uses SSLv2, which is not supported by the appliance when it operates in the NIST SP800-131A strict compliant mode.

Solution:

  1. In the appliance local management interface, select Reverse Proxy Settings > <your instance> > Manage > Configuration > Edit configuration file. The Advanced Configuration File Editor opens.
  2. Add the parameter to the existing stanza.
    [rtss-cluster:cluster1]
gsk-attr-name = enum:438:1
  3. Click Save.
  4. Deploy the changes.
  5. Restart the instance.

Incorrectly formatted FORM or JSON data in custom attributes causes policy failure

If a policy contains a custom attribute with incorrect FORM or JSON data, the policy fails and the user is not permitted to access the resource. Specifically, all of the following conditions apply:
  • The WebSEAL configuration file contains a post-data entry in the [azn-decision-info] stanza.
  • The <post-data-name> value for the post-data entry is not formatted properly. For example, the date format is not correct.
  • The .datatype entry in the [user-attribute-definitions] stanza for this azn-decision-info attribute is a type other than string.

Solution:

Ensure that you specify the correct format for the data. For example:

  • Valid date format is: yyyy-mm-ddzzzzzz

    For example: 2013-05-20−06:00

  • Valid time format is: hh:mm:sszzzzzz

    For example: 13:12:36-06:00

Advanced Access Control cookies are not removed when a user logs out by using non-standard junction name or cookie names

The Advanced Access Control runtime sets cookies for attribute collection purposes. The isamcfg tool configures a WebSEAL or Web Reverse Proxy configuration option to clean these cookies upon session termination. It uses the Advanced Access Control advanced configuration to determine which cookie values to clear.

Solution:

When the junction name attributeCollection.serviceLocation or cookie name attributeCollection.cookieName in the advanced configuration changes, you must run the isamcfg tool so that these changes are picked up.

Access tokens are not cleared in a failed resource owner password credential flow

The access tokens that are generated from resource owner password credential flow are not cleared when resource owner password validation fails. These tokens must be removed so that malicious users cannot use the resource owner password credential flow to fill up the token cache by using a public client.

Solution:

In the pre-mapping rule, make a validate request to the user directory with the user name and password that you want to verify. This method stops the resource owner password credential flow before it generates the access token if the user name and password verification fails.

For more information, see OAuth 2.0 mapping rule methods.

The one-time password value cannot be validated

Policies that permit one-time password obligations might result in an error if the user who made the access request did not set a secret key on the self-care secret key page.

Solution: To ensure that users who encounter this error are directed to create their secret key, edit the error_could_not_validate_otp.html file and add a link that opens the self-care secret key page at /sps/mga/user/mgmt/html/otp/otp.html. For example, add the following link: 
<a "href="/sps/mga/user/mgmt/html/otp/otp.html">
Generate your Secret Key..</a>

Attributes cause errors when hashed in attributeCollection.attributesHashEnabled

In the Advanced Configuration settings, any attribute that uses a matcher other than the exact matcher causes an error if it is hashed.

Solution: Do not hash the following attributes with the attributeCollection.attributesHashEnabled setting of Advanced Configuration:
  • ipAddress
  • geoLocation
  • accessTime

Policies with X.500 names

If your LDAP root DN is secauthority=default, you can use the = (equal) operator only in policies that use X.500 names userDN and groupsDN.

IP addresses are granted access despite their IP reputations

Despite their IP reputation classifications, IP addresses are granted access. When the appliance cannot resolve the domain name for the license server, the IP reputation database cannot update. When the IP reputation database cannot update, it either contains inaccurate IP reputation data or no IP reputation data.

You know that the IP reputation database cannot contact the license server when all IP addresses are granted access despite their IP reputations. If the following conditions are true, the IP reputation policy information point (PIP) might return an incorrect reputation:
  • An administrator writes a policy that denies access based on IP reputation.
  • The database cannot contact the license server.

Solution: Configure direct access to the license server or indirect access to the license server. See the Administrating topics about the license server for more information.

Authentication alias message in startup log

The following message might be displayed in the runtime server startup log:

I J2CA8050I: An authentication alias should be used instead of defining a user name and password on com.ibm.ws.jdbc.dataSource-config/properties-0

Solution: Ignore this message.

Creating access control policies during switch between daylight saving time and standard time

If you create an access control policy when the appliance clock switches from daylight saving time (DST) to standard time (ST), the policy might not work as you expect. For example:
  1. Create an access control policy at 1:45 am on the Sunday when DST returns to ST.
  2. Modify the policy at 2:15 am DST, which is 1:15 am ST and within 1 hour of the creating the policy. The policy that you created in step 1 is used because it is newer (more recently created) than the modified policy in step 2.

Solution: To correct this issue, modify and republish the policy that you want to use after 1:45 am standard time.

Filter stops working after changing a parameter on the Advanced Configuration panel

You can filter the data displayed on the Advanced Configuration panel. After you change a parameter and click the Change button, the filter is no longer applied to the displayed data.

Solution: Click Enter next to the filter field to reapply the filter.

Reverse proxy user password page is inaccessible

After authenticating with the authentication mechanisms, the reverse proxy user password change page (/pkmspasswd) becomes inaccessible.

Solution:This page is working as designed. The reverse proxy makes this page inaccessible for users who are authenticated with the External Authentication Interface (EAI). The authentication service relies on EAI to establish the authenticated session.

Database failover capabilities vary during a cluster upgrade

The distributed session cache, runtime database, and configuration database have different failover capabilities during cluster upgrades.

Table 1. Database capabilities
Database Behaviour
Distributed session cache

Runtime database

 If the primary master fails, failover goes to secondary master. Changes are done in the secondary master and reconciliation occurs when primary master is restored.
Configuration database If the primary master fails, there is no failover to the secondary master. No changes are possible on the primary or secondary master until the primary master is back online.
Issue 1
When a high availability cluster is active, a situation exists during the firmware upgrade on the primary node where the configuration database is read-only.
A read-only database prevents the upgrade process from writing to the configuration database when creating new tables, modifying schema of existing tables, and inserting or updating rows on tables.
The reason the database on the primary node becomes read-only is the firmware upgrade requires the appliance to be rebooted. During a reboot, the high availability controller switches the secondary master to be read-write and act as the temporary primary master.
When the primary node reboots and the database starts:
  1. It recognizes that the secondary node is in control and starts in read-only mode.
  2. The appliance cluster manager includes a background thread which will eventually switch the primary node to resume its role as the primary master database.
  3. The database on the primary node becomes writeable.
However, during an upgrade, the database upgrade scripts are executed before the primary database has become writeable.
Issue 2
For the distributed session cache and runtime database, a situation exists where changes to the secondary databases are not reflected in the primary database after the completion of a cluster upgrade.
Solution:

To address Issue 1, make the cluster a single master cluster for the duration of the firmware upgrade. For detailed instructions, see the Use the local management interface for a cluster of appliances section in Upgrading to the current version.

To address Issue 2, stop traffic to the cluster before starting the upgrade.

Error occurs after switching the runtime database in the appliance

After you switch the runtime database from local to remote and deploying the pending changes, SQL-related runtime errors occur in the appliance.

Solution: Restart the runtime.
  1. In the local management interface, select AAC > Global Settings > Runtime Parameters > Runtime Status.
  2. Click Restart All Clustered Runtimes.

Error code does not display for type mismatch of RESTful PIP

The message.log contains an error message without an error code when the response type does not match the RESTful web service type. In the message log, you might see messages without an error code from com.tivoli.am.rba.pip.RestPIP.

This problem occurs during RESTful PIP configuration if:

  • You manually type a response type instead of selecting a predefined type.
  • The type that you entered does not match the type received from the RESTful web service.
Solution:
  • Correct the RESTful PIP configuration in the local management interface.
  • Verify that the response type you specify is correct for the PIP.
  • Whenever possible, select a predefined type from the list instead of typing the response type.

Firmware version and Last update information not displayed in Update History and Overview section

Firmware information is not displayed in the Update History section of the user interface. Information on Last update is not displayed in the Overview section of the user interface. This is the case for firmware upgrades and fixpacks.

The firmware version can be determined using the Firmware Settings user interface on the appliance.

To determine the firmware version:
  1. Logon to the appliance as the administrator.
  2. Click System > Firmware Settings. The active partition is reported. The Details column includes the firmware version.
Alternatively, you can verify the firmware version from System > Updates and Licensing > Overview.

Information on Last update not displaying is a known limitation.

Default component port number usage

When you assign port numbers during installation or configuration, do not use port numbers already assigned to other components. You might see unpredictable behavior if the same port number is assigned to multiple components.

This is important when there are two Security Verify Access appliances and one of them has Advanced Access Control.

Solution: Consider the following situation:

  • If you set up external WebSEAL servers as part of the cluster configuration, do not assign port 9080 to the cluster configuration if the Support internal and external clients option is selected. Port 9080 is the default port assigned to WebSphere Application Server.

The following table lists the default port numbers that you must be aware of when configuring components on a Security Verify Access appliance that also has Advanced Access Control. Do not assign them to other components.

Table 2. Default port numbers for Verify Access components
Component Port number
WebSphere Application Server 9080, 9443
Security Verify Access Policy Server 7135
Security Verify Access Authorization Server 7136, 7137
WebSEAL listening port 7234
Cluster configuration 2020-2050
LDAP server, SSL port 636
Remote syslog 514
Local management interface (LMI) 443
WebSEAL HTTPS 443
LDAP server, non-SSL port 389
WebSEAL HTTP 80

Deploy request fails

A call to the Deploy the pending configuration changes web service (pending_changes/deploy) might fail.

A call to the Deploy the pending configuration changes (pending_changes/deploy) web service returns an HTTP Internal Server Error.

Solution: Retry the operation.

Runtime server unable to obtain federated directory information from the local management interface

If the runtime server cannot contact the local management interface (LMI) under the following configuration settings, federated directory users cannot authenticate:
  • Federated directories are used for username and password authentication.
  • Resource owner password credentials (ROPC) are used for API protection.

A user whose information is housed in a federated directory cannot authenticate through the username and password authentication mechanism or access API protection definitions that use resource owner password credentials.

The runtime server attempts to contact the local management interface one time to obtain all federated directory information to authenticate federated directory users. If the runtime server cannot contact the local management interface for any reason, it cannot obtain the required federated directory information to authenticate federated directory users. For example: If the local management interface server is not running, the runtime server cannot obtain the necessary federated directory information to authenticate users in a federated directory.

Solution: Follow these steps to ensure that this issue is resolved:
  1. Restart the local management interface:
    1. Use an ssh session to access the local management interface.
    2. Log in as the administrator.
    3. Type lmi and press Enter.
    4. Type restart and press Enter.
    5. Type exit and press Enter.
  2. Restart the runtime server:
    1. Log in to the local management interface.
    2. Select AAC > Global Settings > Runtime Parameters > Runtime Status.
    3. Click Restart Local Runtime.
  3. Ensure that the runtime server can communicate with the local management interface so that it can obtain all of the necessary federated directory information.