Deploying Active Directory for Genetec Security Center Environments

If you are running a multi-server Genetec Security Center deployment without Active Directory, you are making everything harder than it needs to be. I see this regularly. Environments with a dozen servers, multiple client workstations, hundreds of cameras, and all of it managed through local accounts. Passwords shared across systems. No centralized policy enforcement. No reliable audit trail that ties actions to specific users. No time synchronization that you can trust.

Local accounts scale poorly. They are maintained inconsistently. When an operator leaves, their access has to be revoked on every system individually. When a password needs to change, it changes on some systems and gets forgotten on others. When something goes wrong and you need to reconstruct who did what, the answer is “someone logged into the shared admin account.”

Active Directory solves all of that. It also introduces dependencies and configuration requirements that, if missed, cause authentication failures that are difficult to diagnose. This post covers the AD integration for Genetec Security Center environments: what it requires, how to set it up, and what to watch for.

Prerequisites

Before integrating Genetec with Active Directory, the following must be in place:

Domain membership. The Genetec servers must be domain-joined. This is a prerequisite for Kerberos authentication, which is the preferred authentication method for AD-integrated Genetec environments. Attempting to configure AD authentication without domain-joining the servers will result in fallback to NTLM, which has known weaknesses and should not be relied on in environments where Kerberos is available.

Time synchronization. Kerberos authentication requires that the time difference between the Genetec servers and the domain controller is under 5 minutes. In practice, keep it under 2 minutes. A time skew that exceeds the Kerberos tolerance causes authentication failures that are cryptic to diagnose if you do not know to look for them. Configure all Genetec servers to synchronize time from the domain hierarchy. In environments with multiple sites, verify that the time synchronization path goes through the domain hierarchy and not through an independent NTP source that may drift relative to the domain.

DNS resolution. The Genetec servers must be able to resolve the fully qualified domain name of the domain controllers. Use the domain’s own DNS servers as the primary DNS for Genetec servers. Using external DNS (8.8.8.8, 1.1.1.1) as the primary DNS for domain-joined servers creates intermittent authentication problems when those servers cannot resolve domain resources.

Active Directory Users and Computers access. You will need permission to create Organizational Units, security groups, and service accounts in AD. Coordinate with the domain administrator before starting the configuration.

Organizational Unit Structure

Create a dedicated OU for Genetec-related AD objects. This keeps Genetec objects organized, makes Group Policy application easier to scope, and makes it straightforward to identify everything related to the Genetec deployment in a single location.

Suggested structure:

OU=Physical Security
  OU=Servers
    [Genetec server computer accounts]
  OU=Workstations
    [Genetec client workstation accounts]
  OU=Service Accounts
    [Genetec service accounts]
  OU=Security Groups
    [Genetec role groups]

Apply Group Policy to the Physical Security OU for settings specific to Genetec servers and workstations. This includes Windows Firewall rules for Genetec ports, exclusion paths for Genetec processes in Windows Defender, and any performance-related OS settings. Keeping these in a dedicated OU means they do not affect general-purpose servers and can be modified without touching broader domain policy.

Service Accounts

Genetec roles communicate with each other and with the directory using service accounts. Create dedicated service accounts for the Genetec environment rather than using the built-in local system account or a shared general-purpose account.

Create a service account for each Genetec role that requires one:

• GSC-SVC-DIRECTORY: Account used by the Directory role
• GSC-SVC-ARCHIVER: Account used by Archiver roles
• GSC-SVC-ACCESSMGR: Account used by the Access Manager role
• GSC-SVC-SQL: Account used by SQL Server for the Genetec database

Configure these accounts with passwords that do not expire (service accounts do not interactively log in, so password expiration causes service failures rather than prompting for a change). Use strong, randomly generated passwords and store them securely. Restrict these accounts to log on only as a service – they should not be usable for interactive login.

If your environment’s security policy requires password rotation on service accounts, use Group Managed Service Accounts (gMSA). gMSAs are AD accounts where the password is managed automatically by the domain, removing the operational overhead of manual password rotation. Genetec supports gMSAs on current versions.

Security Groups and Role Mapping

Genetec uses AD security groups to determine role assignment. When an AD user logs into Security Center, their group memberships are read and mapped to Security Center roles that have been linked to those AD groups.

Create security groups that correspond to Genetec access levels:

In the Security Center Configuration Tool, link each security group to the corresponding Security Center role. When an AD user is added to GSC-Operators, they automatically get Operator-level access to Security Center on their next login. When they leave the organization and their AD account is disabled, their Security Center access is immediately revoked as well.

Group Policy for Genetec Environments

Create a Group Policy Object linked to the Physical Security OU with settings specific to Genetec servers and workstations.

Windows Defender exclusions. Add exclusions for Genetec processes, the installation directory, the media storage directories, and the database files. Incorrect exclusions are one of the most common causes of Genetec performance problems. Genetec publishes the specific exclusion paths in their best practices documentation – apply them precisely. Do not exclude entire drives or root directories.

Windows Firewall rules. Configure inbound rules for the Genetec role ports. The specific ports depend on the roles running on the server and the Genetec version. At minimum: TCP 5500 and 5501 for the Directory, TCP 554 for RTSP streams, and the port ranges for any other roles deployed. Create the firewall rules through Group Policy rather than manually configuring them on each server – this ensures consistency and survives server rebuilds.

Power plan. Set the power plan to High Performance for Genetec servers and workstations. The Balanced power plan throttles CPU and GPU performance in ways that degrade both recording and video display. Configure this through Group Policy to ensure it is applied consistently and not overridden by default settings after a Windows update or restart.

NTP client configuration. Ensure all servers in the Physical Security OU synchronize time from the domain hierarchy. A GPO preference setting that configures the Windows Time service as a domain client is more reliable than manual configuration and ensures consistency.

Kerberos Configuration

Genetec Security Center supports both Kerberos and LDAP authentication for AD integration. Kerberos is strongly preferred. It is more secure, does not require the Security Center service to bind to the domain controller with a service account, and provides better performance in larger environments.

For Kerberos authentication to work correctly with Genetec, the Security Principal Name (SPN) for the Genetec service must be registered in Active Directory. Genetec handles this automatically when the server is properly domain-joined and the service account has the necessary permissions. If authentication is failing in ways that suggest Kerberos ticket issues, verify the SPNs are registered using setspn -L [account-name].

If LDAP is required (for environments where Kerberos cannot be used), configure LDAP over SSL (LDAPS) rather than unencrypted LDAP. Unencrypted LDAP sends credentials in cleartext. LDAPS requires a certificate installed on the domain controller, but it is the only acceptable option for production environments.

Common Pitfalls

Time synchronization drift. This is the most common cause of intermittent AD authentication failures in Genetec environments. The failure mode is that login works most of the time but fails periodically or for specific users. Check the time difference between the Genetec servers and the domain controller immediately whenever AD authentication starts failing intermittently.

DNS pointing to external resolver. A Genetec server configured with 8.8.8.8 as its primary DNS cannot reliably resolve domain resources. Kerberos ticket requests go to the domain controller by hostname. If the hostname cannot be resolved, authentication fails. This is especially common in environments where the Genetec servers were set up before the network was finalized and the DNS configuration was not updated.

Service account password expiration. If Genetec service accounts have passwords set to expire, the services will fail when the password expires and nobody notices until something stops working. Either set service account passwords to never expire, or use gMSAs, or build a process to rotate them before expiration. Whichever approach you take, document it so the next person who inherits the system knows what to expect.

Missing SPNs after server migration. When Genetec servers are migrated to new hardware or new IP addresses, SPNs may need to be re-registered. If AD authentication stops working after a server migration and everything else looks correct, SPN registration is the next thing to check.

Insufficient SPN registration rights. The service account needs specific permissions to register SPNs in AD. If the service account does not have those permissions, SPNs are silently not registered and Kerberos authentication fails. Verify with the domain administrator that the service account has the ability to register SPNs for the hostnames and IP addresses of the Genetec servers.