SSO - Basic Password service integration with Active Directory

[Anon Anon]

Hello,

I've been doing research on SSO - Basic Password Service (BPS) integration with Active Directory. Essentially looking to trigger an action based on BPS configuration policy ex: lock user after 5 failed attempts, force user to change password....

 

 * Has anyone successfully used BPS with AD?

 

Any documentation or articles would be appreciated.

 

Thanks in advance for sharing your knowledge!

[Ujwol]

Hi Trevon,

 

CA SSO BPS + AD is one of the most commonly used combination and has worked very well.

 

The way BPS works is by mapping user attributes used for enforcing password policy :

 

and , defining the actual password policy :

 

The “Password Data” user attribute value is commonly called the “Password Blob”. It is an enciphered collection of several virtual user attributes used by SiteMinder Basic Password Services.

These virtual attributes are:
 

• Current Login Failure Count
• Last Login Timestamp
• Previous Login Timestamp
• Disabled Timestamp
• Password History
• Last Password Change Timestamp (from the most recent entry in the Password History)
   

More on the blob and how to decrypt the blob here :

Tech Tip - CA Single Sign-On:Policy Server: Read Password Blob Utility 

 

Particularly, for AD, we would also recommend to enable Enhanced Active Directory integration functionality :

Configure an Active Directory User Store Connection - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 

 

This option improves the integration between the user management feature of the Policy Server and Password Services with AD by synchronizing AD user attributes with CA Single Sign-On mapped user attributes.

 

Let me know if you have any questions.

Regards,

Ujwol

 

 

[Anon Anon]

Thank you Ujwol for the fast response. One final question;

Do we absolutely have to map to the (3) attributes, carLicense, unicodePwd and audio?

or can we select any other attribute that's unused by AD?

 

 

Thank you!

[Ujwol]

For the Password Attribute, it has to be actual attribute used by LDAP to store user password. For AD, this is unicdoePwd so this is must.

 

You can use any attribute for Disabled Flag and Password Data but with some limitation as specified below :

 

From the doco :

 

• Disabled Flag
  Specifies an Active Directory attribute that CA Single Sign-on uses to track disabled users.
  Example: carLicense
  Limit: Requires a string attribute.
• Password Attribute
  Specifies an Active Directory attribute that CA Single Sign-on uses to authenticate a user’s password. The attribute name you enter in this field must correspond to the location in the LDAP directory that contains user passwords.
  Example: unicodePwd
  Limit: Requires a binary attribute.
• Password Data
  Specifies an Active Directory attribute that CA Single Sign-on uses for Password Services data, such as old passwords.
  Example: audio
  Limit: Requires a binary attribute.

[Anon Anon]

Good day Ujwol,

Thanks for the follow-ups, I've successfully tested this is my DEV environment and it's working well, only item that I've noticed is an intermittent "Write" issue for the disabled attribute (ie: audio attribute) where there are no relevant error logs on the Siteminder side.  Have you ever seen this before? 

 

I've opened a case to get this tracked.

 

Thanks again for your help.

[Ujwol]

Hi Trevon,

 

For the Disabled attribute , you would need to map an attribute of type "String" like carLicense.

"audio" is a binary attribute which needs to be mapped to "Password Data" attribute.

 

Regards,

Ujwol

[Anon Anon]

Thanks Ujwol. - I found the root cause, it's was due to a delay in AD (Intrasite/Intersite) replication .