When you try to determine what is functioning incorrectly in a policy, you need to turn on policy tracing and understand the evaluation traces. See the following:
The CO entry line of a policy trace identifies when a policy condition evaluates to False or True. The PA entry line indicates whether the Action was applied or ignored. If the results of the policy trace are not what you expected for the user, the next step is to determine why the policy isn’t behaving the way you want it to. Check for the following problems:
If you are using roles in your authorization policies, you need to make sure that the role is enabled for the Identity Server configuration. You can create roles and authorization policies independently of assigning them to protect a resource or to an Identity Server configuration.
If you haven’t enabled the role, users are not assigned the role when they log in, even when they meet all the criteria for the role.
If the Authorization Policy is an Allow policy, the users might be denied access because they haven’t been assigned the role.
If the Authorization Policy is a Deny policy, the users might be allowed access because they haven’t been assigned the role.
Whenever an Authorization Policy is not producing the expected results and the policy contains a role, the first troubleshooting step should always be to check whether the role has been enabled for the Identity Server configuration. Click > > Edit > . If the role is not enabled, the Identity Server cannot assign the role to the user.
The second step should be to ensure that the roles are transferred from for Identity Server to the Embedded Service Provider. Click > > Edit > > . The needs to be enabled in order for Embedded Service Providers to evaluate roles in policies. This profile is enabled by default, but it can be disabled. When it is disabled, all devices assigned to use this Identity Server cluster configuration cannot determine which roles a user has been assigned, and the devices evaluate policies as if the user has no roles.
If you use an LDAP attribute as the condition for a Role policy or an Authorization policy and your users are not being assigned the role or are denied access to a resource, the most likely cause of the problem is the LDAP attribute name used in the policy. Some administration tools for the LDAP user stores display a UI name or an eDirectory™ name rather than the LDAP attribute name. Access Manager policies require the LDAP attribute name.
Use the following steps to identity whether the Access Manager policy has been configured for the LDAP attribute name, a UI name, or an eDirectory name:
Use an LDAP browser to view one of your users in your LDAP user store.
You can download a Java-based tool from the Internet.
Verify the LDAP name of the attribute and that the user has the expected value.
In the Administration Console, click > > > .
View the attribute name and value for the LDAP Attribute condition.
Verify the following:
The name of the attribute should match the name as displayed in the LDAP browser. The attribute name is not case sensitive, but it should not contain any spaces. If you need to modify the attribute used by the policy, click the attribute name, then select an attribute from the list or select to add one.
The value can be case sensitive, depending upon how you have configured the for the policy. If you have selected case sensitive for the , make sure the case in the policy matches the case in the LDAP user store.
If the attribute is multi-valued and your users typically have multiple values, select as the type.
If these steps have not solved the problem, see Section 6.3.3, Result on Condition Error Value.
If you incorrectly set the value of the field, you create a policy that allows an action that you want the policy to deny or that denies an action that you want allowed. You must carefully evaluate whether you want the action applied or ignored when an error occurs during the evaluation of the condition. For positive conditions, the following rules apply:
For the action to be applied, either the user must match the condition or the must be set to True.
For the action to be ignored, either the user must not match the condition or the must be set to False.
The logic is harder to follow when you start adding “if not” to the conditions. The user then matches the condition by not matching the condition. For this type of condition, you need to ask whether you want the action applied to any user when an error occurs evaluating the condition.
The logic is even harder to following when you start adding multiple condition groups that can also have “or nots” and “if nots”.
If you have a policy that uses “if not” conditions or uses multiple condition groups and it is not producing the expected results, you might want to rewrite the policy so that it contains only positive conditions. You might want to modify the condition groups so that the policy uses multiple rules, with each rule containing one condition group with the conditions you want the user to match for the action you assign to the rule.
When you create a user store on the Identity Server ( > ) and define it as an external Secret Store ( > > ), some attributes are not being created properly on the SAML affiliate object. The workaround is to access the user store configuration page ( > ), then exit. This action results in a check to verify that the schema, objects, and attributes exist, and the affiliate object is then re-created from scratch, if necessary.
The following affiliate objects must exist:
authsamlCertContainerDN (container holding trusted certificates, for example: SCC Trusted Root.Security) authsamlProviderID authsamlTrustedCertDN (list of trusted certificate(s)) authsamlValidAfter (180 seconds default) authsamlValidBefore (180 seconds default)
If these attributes exist, the system works normally. However, if your Identity Server and Secret Store server are not configured to use the same NTP server, time synchronization can be a problem. If time synchronization is an issue, you can change the 180-second default validity times as a workaround.
If your LDAP user store and the Administration Console have a firewall separating them, TCP ports 524 and 636 must be open to allow for the creation of the required objects. For more information about ports and firewalls, see Setting Up Firewalls
in the Novell Access Manager 3.1 SP2 Setup Guide.