Managing rolemaps, policies, and object-rolemap bindings

There are several administrative consequences arising from the differences between policy mastership and rolemap mastership, and also from the replication mode of the VOB family.

Policies are managed with unshared mastership, which means that your replica must master the policy to make changes to it. This includes modifying the contents of a policy (adding or removing roles, modifing roles' permissions), adding new rolemaps that implement the policy, or switching rolemaps from one policy to another. To switch a rolemap to implement a new policy, your replica must master both policies and the rolemap. Also, your replica must master a policy when you remove it.

Rolemaps are managed with shared mastership. However, certain operations are permitted when your replica does not master the rolemap, for example, adding or removing objects from the rolemap's protection. Your replica must master the rolemap in order to modify the contents of the rolemap (to change role bindings) or switch it to implement a different policy. Because rolemaps use shared mastership, you cannot remove a rolemap in a replicated VOB family. To change the rolemap binding of an object, your replica must master the object.

In a MultiSite environment, you can manage ACLs once per VOB family if you use fully-preserving-mode replication. However, if you use non-preserving or permissions-preserving replication, you must manage ACLs at every replica of the VOB family.

Note: In the topics that follow, the term preserving refers to identity- and permissions-preserving replicas. The term non-preserving refers to both non-preserving replicas and permissions-preserving replicas.