Advanced Access Control known issues and solutions

  1. Troubleshoot PIP server connections
  2. Removal of a server connection defined for a PIP causes a problem
  3. WebSEAL sends client certificate by default
  4. A junction error occurs when a duplicate dn or certificate label is detected
  5. The appliance fails to connect to the authorization service endpoint
  6. Incorrectly formatted FORM or JSON data in custom attributes causes policy failure
  7. AAC cookies are not removed when a user logs out by using non-standard junction name or cookie names
  8. Access tokens are not cleared in a failed resource owner password credential flow
  9. The one-time password value cannot be validated
  10. Attributes cause errors when hashed in attributeCollection.attributesHashEnabled
  11. Policies with X.500 names
  12. IP addresses are granted access despite their IP reputations
  13. Authentication alias message in startup log
  14. Create access control policies during switch between daylight saving time and standard time
  15. Filter stops working after changing a parameter on the Advanced Configuration panel
  16. Reverse proxy user password page is inaccessible
  17. Database failover capabilities vary during a cluster upgrade
  18. Error occurs after switching the runtime database in the appliance
  19. Error code does not display for type mismatch of RESTful PIP
  20. Firmware version and Last update information not displayed in Update History and Overview section
  21. Deploy request fails
  22. Runtime server unable to obtain federated directory information from the local management interface


Troubleshoot 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

    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:

Solution:

Review the list of server connections to determine whether any were deleted, and re-create any deleted server connections. In the local management interface, click...

...and determine whether it contains the correct server connection. 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 we 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 we 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 ISAM 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 ISAM server.

Solution:

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

  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:

Solution:

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


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, we must run the isamcfg tool so these changes are picked up.


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

The access tokens 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 using a public client.

Solution:

In the pre-mapping rule, make a validate request to the user directory with the user name and password 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 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:


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:


Policies with X.500 names

If your LDAP root DN is secauthority=default, we 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 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:

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.


Create 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 we 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 to use after 1:45 am standard time.


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

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

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.

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 Upgrade 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, we might see messages without an error code from com.tivoli.am.rba.pip.RestPIP.

This problem occurs during RESTful PIP configuration if:

Solution:


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, we 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 ISAM appliances and one of them has Advanced Access Control.

Solution: Consider the following situation:

The following table lists the default port numbers that we must be aware of when configuring components on an ISAM appliance that also has Advanced Access Control. Do not assign them to other 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:

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 the runtime server can communicate with the local management interface so that it can obtain all of the necessary federated directory information.

Parent topic: Troubleshoot Advanced Access Control