CA Identity Manager - CA Directory Access Control Settings.

Products

CA Directory CA Identity Manager CA Identity Governance CA Identity Portal CA Risk Analytics CA Secure Cloud SaaS - Arcot A-OK (WebFort) CLOUDMINDER ADVANCED AUTHENTICATION CA Secure Cloud SaaS - Advanced Authentication CA Secure Cloud SaaS - Identity Management CA Secure Cloud SaaS - Single Sign On CA Security Command Center CA Data Protection (DataMinder) CA User Activity Reporting

Issue/Introduction

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.

Environment

Release: ESPDIR99000-8.1-Extended Support Plus-for CA Directory
Component:

Resolution

Solution:

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

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.
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.
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.