Before you start globally managing your cardholders, read the rules and restrictions that apply when using Global cardholder management (GCM).
Rules concerning local and global partitions
- A sharing guest cannot have more than one sharing host. Only one instance of the Global Cardholder Synchronizer (GCS) role is allowed per system.
- A sharing guest cannot modify the global partition; it can only modify the members of the global partition.
- What a sharing guest is allowed to modify is subject to the privileges of the user account assigned to the GCS role by the sharing host.
- Adding a local entity to a global partition transfers ownership of that entity from its local owner (sharing guest) to the partition owner (sharing host).
- If a sharing guest adds, modifies or deletes an entity from a global partition, it is added, modified or deleted for all parties sharing that partition.
CAUTION:
Avoid adding the same sharable entity to both global and local
partitions. Global partition members are intended to be shared by all parties, while local
partition members are meant exclusively for your system. Adding an entity in both types of
partitions can lead to undesirable behavior.
Rules concerning local and global entities
- Partition membership is not inherited from parent entities. This means that a cardholder doesn’t become a global cardholder simply because its parent cardholder group is a member of a global partition.
- Local cardholders and cardholder groups cannot become members of global cardholder groups. The only exception to this rule is when this is done on the sharing host. In that scenario, the cardholder group is shared, while the local cardholder isn’t.
- Global cardholders and cardholder groups can be members of local cardholder groups.
- 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.
- Access rules are never shared. However, local access rules can apply to both local and global cardholders. This ensures that local administrators always have full control over the security of their local facilities.
Best Practice: It’s always recommended to apply access rules to cardholder groups
rather than individual cardholders. For this reason, it’s recommended to share the
cardholders along with their parent cardholder groups. If this isn’t 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 plan to implement GCM within your organization, we recommend
defining 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 aren’t federated on the sharing host.
- A sharing host that is also a Federation™ host should not share the entities it federates by adding them to a global partition because it doesn’t 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 federates a third system cannot share its federated entities with the sharing host because it isn’t 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’s 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 will lose the changes when the sharing host synchronizes with the Active Directory. The
only piece of information that can be modified in Security Center (either on the sharing
guest or the sharing host) is the cardholder picture.
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 isn’t designed to work on sharing guest systems.