Before you start globally managing your cardholders, read the rules and restrictions that apply when using Global cardholder management.
Rules concerning local and global partitions
- A sharing guest cannot have more than one host. Only one instance of the GCS role is allowed per system.
- A global partition cannot be modified on a sharing guest, but its members can. What the sharing guest is actually allowed to modify is subject to the privileges of user assigned to the GCS role.
- No system is allowed to share what it does not own. Two-tier sharing is not permitted. An effect of this rule is that a local partition cannot be converted into a global partition if it contains global entities, unless it is performed on the host system.
- Adding a local entity to a global partition transfers the ownership of that entity from its local owner (sharing guest) to the partition owner (sharing host).
- Deleting a global entity on a sharing guest also deletes it on the sharing host, unless that entity also belongs to another global partition, in which case, only its membership is removed from the first partition.
Rules concerning local and global entities
- An entity is global by virtue of its membership to a global partition. This means that a cardholder does not automatically become global simply because its parent cardholder group is global.
- Local access rules can apply to local and global cardholders alike. Access rules are never shared. This ensures that local administrators always have full control over the security of their local facilities.
- Global cardholders/groups can become members of local cardholder groups.
- Local cardholders/groups cannot become members of global cardholder groups. An exception to this rule is when both entities belong to the same system. In this case, the local cardholder cannot be shared, although the cardholder group can.
- Both global and local credentials can be assigned to global cardholders.
- Global credentials cannot be assigned to local cardholders.
- Global credentials using custom card formats can be used and edited on the sharing guest. However, the credential data would only be visible if the corresponding custom card format (XML file) is also defined on the sharing guest using the Custom card format editor tool.
Best Practice: It is always recommended to apply access rules to cardholder groups rather than individual cardholders. For this reason, it is recommended to share the cardholders along with their parent cardholder groups. If this is not feasible for any reason, then we recommend that you create a local cardholder group for the global cardholders.
Rules concerning global custom fields and data types
- Custom fields and data types defined for global entities are automatically shared when the global entities are shared.
- Global custom field and data type definitions cannot be modified on the sharing guest.
- Global and local custom fields remain separate. They are differentiated by their owner, which is the system that defines them.
- Global and local custom field and data type definitions cannot have the same names. Using the same names for custom fields or data types causes the synchronization of cardholders and credentials to fail.
- Global data types cannot be used to define local custom fields.
- Custom field values of global entities can be modified on sharing guests.
- Global custom fields also apply to local entities, but their values stay local.
- Local custom fields also apply to global entities, but their values stay local.
- When a guest system stops sharing a global partition, all local copies of the shared global entities, and the custom field values of the local entities are deleted.
Best Practice: If you are to implement GCM within your organization, we recommended that you define all custom fields and data types for global entities on the sharing host.
Rules concerning Federation™ and global entities
- If a sharing host also federates its sharing guest, only the local entities belonging to the sharing guest are federated. The entities that are shared will not be federated on the sharing host.
- The sharing host that also happens to be a federation host should not share the entities that it federates by adding them to a global partition, because it does not own the federated entities. An entity can only be shared by its rightful owner.For the federated entities to become shared, the federated system needs to be a sharing guest of the Federation™ host. This gives the Federation™ host the rights to share any of the federated entities.
- A sharing guest which happens to federate a third system cannot share its federated entities with the sharing host, because it is not the owner of the federated entities.
- If a sharing guest is federated by another system, both its local and global entities appear as federated entities on the Federation™ host.
Rules concerning Active Directory and global entities
- Cardholders and cardholder groups imported from an Active Directory can be added to a global partition on the sharing host.
- Cardholders and cardholder groups imported from an Active Directory that is local to the sharing guest cannot be added to a global partition because the Active Directory and the sharing host cannot both be owners of the shared cardholders.
- Global cardholders and cardholder groups imported from an Active Directory must only be modified through the directory service that owns them.
Although it is possible to modify global cardholders and cardholder groups imported from an Active Directory on the sharing guest, these changes are temporary. You lose the changes you made when the sharing host synchronizes with the Active Directory.
Best Practice: If all cardholder data entry must be centralized, the system that imports cardholders from your corporate Active Directory should act as the sharing host, and all modifications must be made using the directory service.