Things to know regarding Replication of Security Objects

Products

• IT Management Suite

Issue/Introduction

 

Resolution

The following information is provided as reference on how Replication of Security Objects works.

Security related Resource Types:

1.    Role
2.    Trustee
3.    Credential
4.    Authentication Server
5.    Internal Credential
6.    Password Policy
7.Account
8.LDAP
9.LDAP Credential
10.Windows Credential

 

Replication of Security Objects

 

The concept of differential replication does not apply to Security objects, these objects are always sent on each replication regardless of whether they have changed since the last time replication occurred.

 

Security Roles -

 

·          Replicated Security Roles are not Read Only at the destination NS, unlike Items.

 

·          By default if a Security Role is deleted at the source NS it will not be deleted at the Destination NS. However the privilege assignments on the role at the destination NS will all be disabled.

 

·          A core setting has been recently introduced (SMP 7.0 Sp3) called ‘TrackRoleDeletionForHierarchy’, by default this core setting is disabled.
When enabled it will cause any ‘Hierarchy managed’ security role that is deleted on the parent NS, to also be deleted at the child NS.
The setting requires that it be enabled at each parent NS for the delete tracking to flow down through the hierarchy.
The deletion of security roles is tracked in the same way as item deletion via the ‘HierarchySingularTask’ task table. The ‘Type’ column is set to a value of ‘Role’ in this case. See HOWTO42295 for more detail on the HierarchySingularTask table functionality.

 

Merging of Security Roles -

 

When replicating Security Roles, merging of duplicate roles occurs when any of the three below things match.

 

1.    SID of the role

Note: the SID for the security role can be found by querying the SecurityRole table to get the GUID inside the trustee column. Then query the SecurityTrustee table, using the trustee GUID obtained from the SecurityRole table, and the SID will be listed.

2. Name of the role

3. GUID of the role

 

Security Role memberships -

 

·          If servers in the hierarchy are in trusted domains then security roles containing memberships of domain users/groups will replicate.

 

·          If servers in the hierarchy are in non-trusted domains, then the role and privileges will replicate, but not the listing of user/group memberships for the role.

 

·          By default Security Role membership is only additive – e.g. If a Security Role is replicated to a child node with a group or user membership included, and the role is later modified at the parent and a user/group is removed from the membership, this removal will not be seen at the child NS on next replication.

 

·          A core setting has been recently introduced (SMP 7.0 Sp3) called ‘SyncRoleMembershipExactlyDuringReplication’, by default this core setting is disabled. When enabled it will cause all ‘Hierarchy managed’ Security Role memberships to be synchronized, so that after replication completes the role membership at the child will be identical to that of the parent.
The core setting requires that it be enabled at each parent NS for role membership synchronization to flow down through the hierarchy.

 

 

Security Role Privilege assignment –
 

·          The parent NS will overwrite the privilege assignments on the given Security Role at the child so that they exactly match the parents assignments.

For example; if a Security Role exists at both parent and child NS and a user enables the ‘Change Security’ privilege on the Role at the child NS yet it is disabled at the parent, the expected result is that when Privilege Replication next occurs the ‘Change Security’ privilege be disabled at the child.

 

·          When privileges are replicated, it sends a list of all (or selected) privileges and which Security Roles have the particular privilege assigned to it.
If security privileges are replicated but the applicable Security Role is not, the information for what role the privilege is assigned to is still stored in the database. Later if the applicable Security Role is replicated, these privileges are joined up to the appropriate Role.

 

Item permissions -

 

·          The Item permissions sent from the parent will apply directly to the Item at the child NS, overwriting any existing permissions on the item at the child that may differ from that of the parent.

 

·          Security permission changes on items are replicated in all scenarios so long as the Core Hierarchy Item replication rule is not disabled entirely. The NS does not provide a way for the user to choose which items that security changes will replicate for. (Since security is often done by inheritance, and user may want to replicate security but not an entire branch of the tree, we have to send security information for items which are not selected)

 

Note: There is currently a known issue around this area, which is that we never perform a ‘Complete’ security replication so until the security first changes for a given item the security is out of sync between the parent and the child NSs.