Module 5: Cardholder databases and synchronization

Cardholder records and credential lifecycle, AD/Entra/ClearID/GCS sync, controller memory and troubleshooting.

⏱ ~60 minModule 5 of 6Quiz ↓Common mistakes ↓

🎯 Learning objectives

Manage cardholder and credential records over their lifecycle
Choose the right sync source (AD, Entra ID, ClearID, GCS, CSV)
Understand how controllers hold data offline
Troubleshoot sync problems

5.1 Anatomy of a cardholder record

Identity: First and last name, email, picture, description
Status: Active or inactive, with optional activation and expiration dates
Groups: Cardholder group memberships (where most access comes from)
Access rules: Inherited from groups, plus any assigned directly
Credentials: One or more cards, PINs, mobile or plate credentials
Custom fields: Employee ID, department, cost centre, badge type; can be mapped from AD
Partition: Which administrators can see and edit the record

Keep the cardholder and the credential separate in your mind. The person holds rights; the credential is just a token proving who they are.

5.2 Credential lifecycle

EnrollCreate the credential (present the card at an enrollment reader, type the FC and number, or import), choose the card format, print a badge.
AssignLink it to the cardholder; access comes from the cardholder's rules.
SuspendSet the credential inactive (or lost or stolen) for a forgotten or missing card; set the cardholder inactive for a leave of absence.
ReplaceIssue a new credential to the same cardholder; rules do not change.
RevokeOn termination, deactivate the cardholder immediately and recover or retire the credential. Do not reissue a lost card number.

5.3 Ways to get cardholders into Synergis

Method	Source	Direction	Best for
Manual entry	Security Desk Cardholder management	n/a	Small sites, exceptions
Import tool	CSV file	One-time or bulk update	Migrations and bulk changes
Active Directory role	On-prem AD security groups	AD to Security Center	Organizations with Windows AD
Synergis Card Synchronization plugin	Entra ID, databases, files	One-way into Security Center	Cloud identity or HR exports
ClearID	Entra ID via ClearID	ClearID to Synergis	Self-service and policy-driven access
Global Cardholder Synchronizer	Another Security Center (sharing host)	Two-way, host validates	Multi-site, central badging office

5.4 Active Directory role

Imports AD security groups as cardholder groups and/or user groups; members become cardholders, optionally with credentials.
Maps standard and custom AD attributes to cardholder fields and custom fields; most imported fields become read-only in Security Center.
A user added to a synced group becomes a cardholder after the next sync; an account disabled in AD disables the cardholder.
Sync runs on a scheduled task you create; without one, Config Tool warns that no scheduled task exists.
Connects over LDAP (389) or LDAPS (636), or the global catalog (3268 / 3269); use the FQDN.

5.5 Entra ID via the Card Synchronization plugin

For Entra ID, the Synergis Card Synchronization plugin connects with a tenant name, client ID and app key, and can import cardholders, cardholder groups, group memberships and credentials. Sync is one-way and runs manually or on an interval.

Two traps

Importing groups does not put people in them unless you also select group memberships, and any mapped field you edit in Security Center is overwritten at the next sync.

5.6 Global Cardholder Synchronizer

Global Cardholder Management shares cardholders across independent Security Center systems. A central sharing host owns global partitions; each sharing guest runs one GCS role that keeps local copies synchronized, on demand, on schedule or automatically, while guest-to-host changes are sent immediately for the host to validate.

Shared: cardholders, cardholder groups, credentials, badge templates in global partitions.
Not shared: access rules. Each site keeps control of its own doors and applies local rules to global cardholders.
Only one GCS role per system; supported up to 250,000 cardholders and 250,000 credentials.
Global and local custom fields must not share names, or sync fails.
Custom card formats must be defined on the guest to read global credentials that use them.

5.7 How controllers store the database

Controllers decide locally from synchronized data; events flow back to the Access Manager and are buffered while offline.

Situation	What happens	Status
Online	Units decide locally from synced data and report every event in real time. Security Center pushes changes to affected units automatically (Genetec documents every 15 seconds); HID units can also sync daily, weekly or on demand.	Normal
Unknown credential	The unit asks the Access Manager (host lookup) and updates its memory with the answer.	–
Offline	The unit keeps deciding from its last sync, logs events locally and uploads them on reconnect. It cannot receive new changes, so a revoked card may still work until it reconnects.	Degraded
Mercury host decision handoff	On SCL, decisions can be made by the SCL or handed to the Mercury board locally; keep all hardware of a door on the same Mercury board and SCL for reliable offline behaviour.	–

5.8 Troubleshooting sync issues

Symptom	Likely cause	Check
New hire badge denied	Directory sync has not run, or person not in synced group	AD scheduled task, Card Sync last run, group membership
Fired employee's badge still works	Unit offline, or AD disable not yet synced	Unit status (red = offline), force sync, deactivate manually
Field changes keep reverting	Field is mapped from AD, Entra or ClearID	Change it at the source
All cards unknown on one door	Card format mismatch or reader in wrong mode	Raw data in the event, card format settings
Alarms flood after server restart	Input states resync and count as changes	Expected after Access Manager restart
GCS errors on custom fields	Same name used for a global and local field	Rename local custom field
CSV import fails	Missing name field, bad column binding, wrong encoding	Import tool bindings and CSV header rules

ReproduceBadge the door and read the exact event (granted, denied with reason, unknown credential).
Check the recordCardholder active, credential active, dates, group membership, rules.
Check the doorRules on the door and its area, door side, schedule active now.
Check the unitOnline, last sync time, firmware; trigger a sync from the unit's Synchronization tab.
Check the sourceWhether AD, Entra, ClearID or the GCS host owns the field you are fixing.

Common mistakes

Editing synced fields locally and having them overwritten.
No scheduled task for the AD role, so sync never runs on its own.
Relying on directory sync for terminations instead of deactivating the cardholder immediately.
Deleting cardholders instead of deactivating, losing the audit history.
Mixing the same entity into global and local partitions.

Check your understanding

1.Why does Synergis grant access to the cardholder rather than the credential?

So a lost card can be replaced without changing rules or pushing rule changes to controllers.

2.What happens to access decisions when a controller loses its Access Manager connection?

The unit keeps deciding from its last synced data and buffers events, but receives no new changes until it reconnects.

3.Your Entra import created groups but nobody is in them. What did you miss?

The Cardholder group memberships option.

4.Are access rules shared by the Global Cardholder Synchronizer?

No. Each site applies its own local rules to global cardholders.

5.A field you edited in Security Center keeps reverting. Why?

The field is mapped to an external source (AD, Entra, ClearID) and is overwritten at each sync.

6.What is the safest action on a hostile termination?

Deactivate the cardholder in Security Center immediately, confirm the units are online and synced, then let the directory catch up.

Progress is saved in this browser only.