The are some rules and restrictions that apply when using Global cardholder
management.
Before you start globally managing your cardholders, read the following rules and
restrictions.
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 even when they use the same name. They
are differentiated by their owner, which is the system that defines them.
- 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.
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 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.