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 Global Cardholder Synchronizer (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 allowed to modify is subject to the privileges of the 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 and groups can become members of local cardholder groups.
- Local cardholders and 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 is only 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 are not 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 that 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.
CAUTION:
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 that 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.
Rules concerning the Mobile Credential Manager role and global entities
- The Mobile Credential Manager role must be on the sharing host to manage mobile credentials. The role is not designed to work on sharing guest systems.