Skip to main content

Account Sync

The Account Sync page manages multi-site account synchronization: users, roles, and passwords created on the tenant's primary site (the account source) are pushed automatically to every other GEM server in the tenant, so one set of credentials works everywhere.

Open Account Sync

Roles​

Every server is in exactly one of three states, and the page adapts:

  • Account source (the primary / auth server) — full control: choose what gets synced, watch per-peer push status, and push a manual full sync.
  • Managed peer — read-only status view showing how the server was provisioned, the current key generation, and when the last sync was applied (remembered across restarts). Accounts on this server are pushed from the primary; local account editing is disabled (the Users page shows a banner and drops its Add/Edit actions), and password changes and resets are blocked — a password changed locally would be silently reverted by the next push, so change it on the primary or through the cloud portal. Sites, roles, and notification profiles are likewise locked on a managed peer; access groups and holiday calendars lock only while the primary is actually pushing them (its Door access toggle is on) — otherwise they stay editable site-local. Visitors are the exception: they're site-local by design, so a managed peer can issue and revoke visitor PINs at any time. Make all other changes on the primary — they arrive automatically.
  • Not configured — sync is off; the page explains how to enable it.

Provisioning​

GEM Cloud tenant (automatic)​

When multiple GEM servers belong to one GEM Cloud tenant, enable account sync for the tenant in the cloud admin. Every member server is then provisioned automatically from its signed tunnel binding — the tenant sync key, the server's role (source or managed), and the current peer list arrive on the next update check. There are no keys to copy between sites.

Pushes travel through the cloud relay and are sealed end-to-end with AES-256-GCM under the tenant key — the relay only carries opaque bytes and can neither read nor forge account data. Sealed payloads carry a timestamp and sequence number, so replays and stale pushes are rejected, and a server provisioned this way refuses plaintext pushes outright. When the tenant key rotates, the previous key generation stays acceptable for a 30-minute grace window so peers that haven't polled for the new key yet aren't cut off mid-rotation.

gem.json (direct / VPN deployments)​

Sites that reach each other directly can instead configure peer_sync in gem.json: a shared sync_key, enabled: true on the source, managed: true on each peer. Pushes go straight to each peer site's URL (from Sites) authenticated by the shared key. Cloud-tenant provisioning takes precedence when both are configured.

What gets synced​

A push carries users (username, name, email/SMS, enabled state, roles, sites, session timeout, 2FA flag, notification profile, and the password hash), roles, sites, and notification profiles. Changes push immediately as they happen; a full sync runs at startup, whenever a new peer joins the tenant, and on demand.

Records cross the wire keyed by name, never by numeric id — ids differ between databases. A user's notification profile travels as the profile's name and is re-linked to the matching local profile on the receiving side.

The site registry converges automatically on a cloud tenant. When sync activates, the primary creates a site row for any tenant peer that doesn't have one — named by the installation's canonical name from the updater — so users scoped to that site can log in, then pushes the full list. A receiving peer recognizes its own row by that canonical name and applies it onto its local This Server entry, renaming it if needed (user site memberships follow the rename), rather than creating a duplicate; a push never deletes a peer's own site row or sets a URL on it.

Two toggles on the source control the optional payloads:

  • Door access (PINs, RFID, duress PINs, access groups, holiday calendars) — on by default. When off, only accounts, roles, passwords, and notification profiles sync — each site keeps its own local door credentials, access groups, and holiday calendars. Credentials are decrypted only for transport inside the sealed payload and re-encrypted with each receiving site's own local key. Access group membership travels as usernames; members the receiving site doesn't have (e.g. unsynced visitors) are dropped from the group there, with a warning in the server log.
  • Visitor accounts — off by default: a visitor PIN issued at one site usually shouldn't open doors at another. Local visitors on peers are never disabled by a sync either way.
Local accounts on managed peers

A full sync disables any enabled non-visitor account on a managed peer that doesn't exist on the primary. Create accounts on the primary — an account created locally on a managed peer is disabled on the next full sync.

Peers table​

On the source, each peer shows its last push, last successful push, and status — OK, no push yet, or the last error (hover for the full message). The page refreshes every 10 seconds.

Sync now​

Sync now pushes a full account sync (all users, roles, sites, notification profiles, and — when the Door access toggle is on — access groups and holiday calendars) to every peer immediately — useful after enabling sync, changing the toggles, or when a peer that was offline comes back.