CA Identity Manager - CA Directory Access Control Settings.

Document ID : KB000052447
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

In your CA Identity Manager implementation, you may want to protect your User Store, Policy Store as well as your Provisioning Directory from unauthorized CRUD operations that could happen outside of CA Identity Manager.

If your CA Identity Manager environment is using CA Directory for the above stores (note that Provisioning Directory is only supported in CA Directory), this can be easily achieved using Access Controls.

CA Directory Access Controls (ACLs) work by asking this question before performing an operation:

Is this client permitted to perform this operation, on this data, in this subtree, at this time?

where:

  • A client is a user, a role, a group of users, or a subtree of users.

  • An operation is one of the usual directory services, including compare, list, search, read, add, remove, modify, or modify-dn.

  • The data (protected item) is an entry, attribute, or attribute value.

  • A subtree is a particular area of the DIT.

  • The time is a particular minute of the day or a particular day of the week.

The aim of this document is to provide the minimum ACLs required by CA Identity Manager service accounts and limit all other access.

Solution:

Defining the minimum ACLs needed by CA Identity Manager requires that:

  1. In the case of the CA SiteMinder Policy Store and Key Store, the user defined in the connection credentials must have full access to both the Policy Store root DN and Key Store root DN.

  2. In the case of the CA SiteMinder User Store, the user defined in the connection credentials must have full access to the User Store root DN.

  3. In the case of the CA Identity Manager, the embedded user used by the Provisioning Server to connect to the Provisioning Directory must have full access to the Provisioning Directory root DN.

To define and activate CA Directory Access Controls, you would need to update the corresponding DSA's definition as described below:

Assuming that:

  • Policy Store root DN: o=SMPolicy,c=US

  • Policy Store Admin User DN: uid=SMAdmin,o=SMPolicy,c=US

  • User Store root DN: o=FwdCorp,c=US

  • User Store Admin User DN: uid=IMAdmin,o=FwdCorp,c=US

  • Provisioning Server Domain name DB suffix: dc=FWDCORPDOM,dc=etadb

  • The new ACL enabled CA Directory configuration files will be called:

    • SMPSAccessControl.dxc

    • IMUSAccessControl.dxc

    • IMPDAccessControl.dxc

On the CA Directory node(s), perform the following operations:

  • Go to %DXHOME%/config/access folder ($DXHOME for Unix and Linux)

  • Copy the default.dxc to SMPSAccessControl.dxc

  • Remove the Read-Only flag if set

  • Edit SMPSAccessControl.dxc

  • Replace the default content with
    #
    # Policy Store Access (#1)
    #
    set admin-user = {
    user = <c US><o SMPolicy><uid SMAdmin>
    subtree = <c US><o SMPolicy>
    };

    # static access controls
    set access-controls = true;
    # dynamic access controls
    set dynamic-access-control = false;
  • Save and close SMPSAccessControl.dxc

  • Copy SMPSAccessControl.dxc to IMUSAccessControl.dxc

  • Edit IMUSAccessControl.dxc

  • Replace the content with
    #
    # User Store Access (#2)
    #
    set admin-user = {
    user = <c US><o FwdCorp><uid IMAdmin>
    subtree = <c US><o FwdCorp>
    };

    # static access controls
    set access-controls = true;

    # dynamic access controls
    set dynamic-access-control = false;
  • Save and close IMUSAccessControl.dxc

  • Copy SMPSAccessControl.dxc to IMPDAccessControl.dxc

  • Edit IMPDAccessControl.dxc

  • Replace the content with
    #
    # Provisioning Directory Access (#3)
    #
    set admin-user = {
    user = <dc etadb><dc FWDCORPDOM><eTNamespaceName CommonObjects><eTDSAContainerName DSAs>
    subtree = <dc etadb>
    };

    # static access controls
    set access-controls = true;

    # dynamic access controls
    set dynamic-access-control = false;
  • Save and close IMPDAccessControl.dxc

  • Go to %DXHOME%/config/servers folder ($DXHOME for Unix and Linux)

  • Edit the dxi file corresponding to your Policy Store

  • Change the access controls section to "source" SMPSAccessControl.dxc like
    # access controls
    clear access;
    source "../access/SMPSAccessControl.dxc";
  • Save and Close the file.

  • Edit the dxi file corresponding to your User Store.

  • Change the access controls section to "source" IMUSAccessControl.dxc like
    # access controls
    clear access;
    source "../access/IMUSAccessControl.dxc";
  • Save and Close the file

  • Edit the dxi file corresponding to your Provisioning Directory

  • Change the access controls section to "source" IMPDAccessControl.dxc like
    # access controls
    clear access;
    source "../access/IMPDAccessControl.dxc";
  • Save the file

  • Edit the file sourced under "operational settings" section

  • If there is a line with "set access-controls = false;" then remove it
    Close the files

  • Run DXsyntax to ensure that there are no configuration errors with any of your ACL commands. If DXsyntax reports errors, then please re-edit the files indicated and resolve the ACL configuration errors.

  • Instruct the DSAs to reload their configuration:

    dxserver init all

From now on, the ACLs are activated and you can check them by using an LDAP Directory browser like JXplorer.

You should be able to connect to your User Store using the service account you have defined in your ACLs e.g. uid=IMAdmin,o=FwdCorp,c=US and navigate the whole DIT.

You should be able using any other user to connect to the User Store but you should receive an error saying e.g.

         unable to list o=FwdCorp,c=US

However, if you use this user to connect to your IME using the CA Identity Manager User Console then you should be able to do the same operations as before even if this user is not granted to access directly to the User Store.

The same tests can be performed with the Policy Store and Provisioning Directory assuming that you have several objects defined with a password into it.

If Anonymous access is allowed for these DSAs then connection will be allowed, however, navigation through the DIT will return a list error.

Additional Information:

  • If DSAs are sharing the same schema definition (could be the case with Policy Store and User Store) then you can define the ACLs in a single file and source the corresponding file name in the dxi files

  • When diagnosing ACL configuration issues, setting a trace=all can help to understand where the problem is. Looking at the corresponding diag log file can also help.

  • The CA Directory Administrator Guide contains details regarding Access Control capability.

  • When applying a CR or performing an upgrade of the Provisioning Server then it is strongly recommended to deactivate the access controls defined for the Provisioning Directory because the Installer can temporarily switch to anonymous access to perform maintenance and so, it will need a full access rights to the entire DIT. To do that, just edit the corresponding ACLs definition file, set access-controls to false and instruct the DSA to reload its configuration (dxserver init etrustadmin for instance). Once your update is over then you can reactivate the access controls.