User Store replication and SiteMinder Authentication/Authorization

Products

• SITEMINDER
• CA Single Sign-On

Issue/Introduction

This article is to demonstrate how LDAP User Store configuration in SiteMinder and the LDAP Replication can cause Auth/Az issues in SiteMinder environment.

Use case:
Multiple LDAP instances in replication mode used as SiteMinder user store.
User Store configured with multiple banks to make more connections and to load balance.

Bank#0:
AD1:636
AD2:636
AD3:636

Bank#1:
AD2:636
AD3:636
AD1:636

Bank#2:
AD3:636
AD1:636
AD2:636

Issue:
User Authenticates(via custom authentication scheme) and Policy Server writes a value in the User Attribute for Authorization purpose. This is written to AD1.
Policy Server connects to AD2 and does not find the user attribute with specific value and fails.

 

Environment

Release : 12.8.x

Cause

LDAP replication is not happening fast enough.
User attribute Policy Server is querying for has yet to be replicated over.

Resolution

When you have custom code involving updating user attributes for authentication/authorization decisions, you may need to consider the following.

1. Replication occurs immediately in real-time.
2. If #1 is not possible then configure the User Directory to ensure the Policy Servers will go to the same LDAP instance to retrieve the updated user attribute.

This may require reconfiguring the LDAP Banks in the following way.

Bank#0:
AD1:636
AD2:636
AD3:636

Bank#1:

AD1:636
AD2:636
AD3:636

Bank#2:
AD1:636
AD2:636
AD3:636

 

This will ensure the Policy Servers will be connecting to AD1:636 for the updated user attribute.

If the replication is delayed then Policy Server may query the LDAP instance that has yet to receive the update resulting in Auth/Az failure.