How to implement several Directories, Windows Domains or DSAs as a single unified User Directory (User_DIR) in SSO Server

Products

• CA Single Sign-On

Issue/Introduction

Description:

If you have more than one User Directory in place which all need to be made available as SSO User_DIR, it might be desirable to propagate the various directories as a single DSA, in order to avoid the need to implement separate AuthHost infrastructures for each of them which would be required if they were integrated as individual User_DIRs.

Solution:

There are two possibilities to approach this requirement:

1. Creating a cascaded DXLink Mesh - Proxy DSA
   
   In this example, we have two Windows Domains transitively trusting each other, implemented in a Parent / Child fashion in a single Domain Forest, i.e.
   Parent  Domain = AcmeCorp.com
   Child Domain = subdom.AcmeCorp.com
   
   The Proxy DSA allows to access both Directories and propagating them as a single Directory to the SSO Server
   
   

   <Please see attached file for image>

   
   
   
   1. Define the Proxy DSA
      
      
      • create a new textfile %dxhome%\config\knowledge\AcmeCorp.dxc and put the following in it

        set dsa AcmeCorp={  prefix        = <DC com><DC AcmeCorp>  dsa-name      = <DC com><DC AcmeCorp><cn AcmeCorp>  dsa-password  = "secret"  address       = tcp "SSO81Server" port 14389  disp-psap     = DISP  cmip-psap     = CMIP  snmp-port     = 14389  console-port  = 14379  ssld-port     = 1112  auth-levels   = anonymous, clear-password  trust-flags   = allow-check-password, trust-conveyed-originator};

      • create a new textfile %dxhome%\config\servers\AcmeCorp.dxi and put the following in it

        # logging and tracingsource "../logging/default.dxc"; # schemaclear schema;source "../schema/PolSrv.dxg"; # knowledgeclear dsas;source "../knowledge/PS_Servers.dxg"; # operational settingssource "../settings/AcmeCorp.dxc"; # service limitssource "../limits/default.dxc"; # access controlsclear access;source "../access/PS_Access.dxc"; # multiwrite DISP recoveryset multi-write-disp-recovery = false;

      • create a new textfile %dxhome%\config\settings\AcmeCorp.dxc and put the following in it

        # directory information baseset alias-integrity = true;set limit-list = false;set limit-search = false;set eis-count-attr = dxEntryCount; # distribution controlsset multi-casting = true;set always-chain-down = true;set multi-chaining = true; # security controlsset min-auth = clear-password;set allow-binds = true;set access-controls = false;set ssl-auth-bypass-entry-check = false; # general controlsset op-attrs = true;

      • modify / add the following statements in the existing %dxhome%\config\settings\PS_<Server>.dxc and %dxhome%\config\settings\PSTD_<Server>.dxc, respectively
        

        set always-chain-down = true;set multi-chaining = true

   2. Define a seperate DXLink (Router DSA) pointing to each individual Directory
      
      Each DXRouter points to the according Domain Controller or Directory Server, propagating the individual directory under a new name. In this example dom1.AcmeCorp.com and dom2.AcmeCorp.com
      
      
      • create a new textfile %dxhome%\config\knowledge\Router_AD1.dxc and put the following in it
        

        # Computer Associates DXserver/config/knowledge# Router_AD1.dxc# Routes to Active Directory on ACMECORP domainset dsa Router_AD1 ={prefix = <dc "com"><dc "AcmeCorp"><dc "dom1">native-prefix = <dc "com"><dc "AcmeCorp">dsa-name = <o AD_ACMECORP><cn Router_AD1>dsa-password = "secret"ldap-dsa-name = <dc "com"><dc "AcmeCorp"><cn "users"><cn "Administrator">ldap-dsa-password = "secret"address = tcp "Dom1Controller" port 389auth-levels = clear-password, ssl-authdsa-flags = read-onlytrust-flags = allow-check-password, no-server-credentialslink-flags = dsp-ldap, ms-ad};set transparent-routing = true ;

      • create a new text file %dxhome%\config\knowledge\Router_AD2.dxc and put the following in it

        # Computer Associates DXserver/config/knowledge# Router_AD2.dxc# Routes to Active Directory on SUBDOM domainset dsa Router_AD2 ={prefix = <dc "com"><dc "AcmeCorp"><dc "dom2">native-prefix = <dc "com"><dc "AcmeCorp"><dc subdom>dsa-name = <o AD_ACMECORP><cn Router_AD2>dsa-password = "secret"ldap-dsa-name = <dc "com"><dc "AcmeCorp"><dc subdom><cn "users"><cn "Administrator">ldap-dsa-password = "secret"address = tcp "Dom2Controller" port 389auth-levels = clear-password, ssl-authdsa-flags = read-onlytrust-flags = allow-check-password, no-server-credentialslink-flags = dsp-ldap, ms-ad};set transparent-routing = true ;

      
      Note:
      It is necessary for each router to authenticate separately to the respective directory.
      Hence the need to put the ldap-dsa-name and ldap-dsa-password in clear text in the knowledge file of the router.
      This might make it necessary to additionally secure the local host from unauthorized access to prevent theft of this information.
      
      
   3. Provide connectivity of the various UserDirectories to each other
      
      In order to to show all  UserDirectories as if they were under a single tree, ensure that all the knowledge files are sourced in the %dxhome%\config\knowledge\PS_Servers.dxg:
      

      # Computer Associates DXserver/config/knowledge/## PS_Servers.dxg written by eTrust PS Installation## Description:#   Use this file to group and share DSA knowledge.#   PS DSA's source this file#   from its initialization file.#source "../knowledge/PS_AcmeCorp.dxc";source "../knowledge/PSTD_AcmeCorp.dxc";source "../knowledge/Router_AD1.dxc";source "../knowledge/Router_AD2.dxc";source "../knowledge/AcmeCorp.dxc ";

   4. Limit Access Controls to the LoginInfos container
      
      Grant each DSA's bind user access to all the UserDirectories, as well as to the LoginInfos container in the embedded CA Directory by appending the following statements to the file %dxhome%\config\access\ PS_Access.dxc:
      

      ...set group = {name = "AD_Group"users = <dc "com"><dc "AcmeCorp"><dc dom1><cn "users"><cn "Administrator">,        <dc "com"><dc "AcmeCorp"><dc dom2><cn "users"><cn "Administrator">};set admin-user = {group = "AD_Group"subtree = <dc "com"><dc "AcmeCorp">};set admin-user = {group = "AD_Group"subtree = <o "PS"><ou "LoginInfos"><ou ad-AcmeCorp>};...

   5. Define the unified User_DIR in the Policy Manager
      
      • Point to the previously defined Proxy DSA
        
        

        <Please see attached file for image>

        
        
        
      • to bind to the Proxy DSA use any of the previously defined users that were enabled in the Access Controls of the DSA
        
        
      • Set the following list for the classes that are shown as containers in the Policy Manager / Configuration / User Datastores / AD-Store:   container, organization, organizationalUnit, builtinDomain, country, domain
        
        
        
      • specify the Login Info Container DN accordingly
        
        

        <Please see attached file for image>

        
   6. Verify overall functionality
      
      After restart of the DXServer as well as the SSO Server it should be possible to browse the unified User_DIR in the Policy Manager:
      
      

      <Please see attached file for image>

      
      
      
2. Pointing the DXLink to the Windows Domain's Global Catalog (GC) Server
   
   In this example, we have two Windows Domains transitively trusting each other, implemented in a Parent / Child fashion in a single Domain Forest, i.e.
   Parent  Domain = AcmeCorp.com
   Child Domain = subdom.AcmeCorp.com
   
   Pointing the DXLink to the Domain Forest's Global Catalog Server's LDAP port 3268 allows to make the complete Forest available as a single DSA.
   
   
   1. Follow the Configuration Scenario Outline "SSO with Active Directory" as described in the CA SSO Implementation Guide
      
      
   2. Modify the Configuration by pointing to the Forest's Global Catalog
      
      

      # Computer Associates DXserver/config/knowledge # Router_AD.dxc # Routes to Active Directory on ACMECORP and SUBDOM domain set dsa Router_AD = { prefix = <dc "com"><dc "AcmeCorp"> native-prefix = <dc "com"><dc "AcmeCorp"> dsa-name = <o AD_ACMECORP><cn Router_AD> dsa-password = "secret" address = tcp "GCDomController" port 3268 auth-levels = clear-password, ssl-auth dsa-flags = read-only trust-flags = allow-check-password, no-server-credentials link-flags = dsp-ldap, ms-ad }; set transparent-routing = true ;

      Since the Child Domain is transitively trusting the parent domain no changes are necessary to the CA Directory Access Controls in order to allow the DXlink accessing the  Active Directory Child Domain, provided that the admin-user has been authorised to the Parent Domain as described in the SSO Implementation Guide.
      
      Set the following list for the classes that are shown as containers in the Policy Manager / Configuration / User Datastores / AD-Store: container, organization, organizationalUnit, builtinDomain, country, domain
      
      

      <Please see attached file for image>

      
      
      Once all has been set and the SSO Server restarted, verify in the Policy Manager that it is possible to browse the Child Domain's directory structure.
      
      

      <Please see attached file for image>

      
      
      
   Limitations:
   
   
   • Typically any SSO Authentication Agent is configured to utilise the attribute "sAMAccountName" to search for user objects while pointing to AD User DataStores.
     
     Note that sAMAccountName is unique only in a single Windows Domain, however multiple user objects with the same attribute value can exist in various Domains
     
     
   • The SSO LDAP Auth Agent cannot display extended Windows messages while pointing to a virtual DSA.

Environment

Release: SOASA199000-12.1-SOA Security Manager-w/ SOA Agent Addl CPUs
Component:

Resolution

.