How to Set Up LDAP and Active Directory Integration in a Niagara 4 Station

Niagara 4 can authenticate users against Active Directory or LDAP. Add an LDAP authentication scheme, map directory groups to user prototypes, and use LDAPS.

On a corporate site, IT departments want every system to use the organisation's own user accounts, so people log in with their normal credentials and leavers lose access automatically. Niagara 4 supports this through LDAP and Active Directory (AD) authentication. This guide explains how it works, how roles are assigned through user prototypes, the setup steps, and the issues that most often stop it working.

Why integrate Niagara with LDAP or Active Directory?

• One login: users sign in to the BMS with their normal domain username and password.
• Central control: IT adds, disables and removes users with their standard tools; nobody has to remember to delete BMS accounts.
• Role by group: membership of an AD group (for example "BMS-Operators") decides what a user can do in Niagara.
• Password policy: complexity, expiry and lockout follow corporate policy.
• Audit: logins are tied to real, individual identities.

LDAP gives a single login (the same credentials everywhere). For true single sign-on, Niagara also supports Kerberos with AD and SAML 2.0 with identity providers.

How LDAP authentication works in Niagara 4

1. A user logs in to the station through Workbench (FoxS) or a browser (HTTPS).
2. The station's LDAP authentication scheme checks the username and password against the directory server, ideally over LDAPS or LDAP with TLS.
3. On a successful login, the station creates a Niagara user account for that person based on information from the directory.
4. Niagara-specific properties, such as roles, web profile and NAV file, are applied from a user prototype.
5. Which prototype applies is decided by the scheme's attrPrototype property: it names the directory attribute (commonly group membership, or a department attribute) whose value is matched to a prototype name in the station.
6. If no prototype matches, the Alternate Default Prototype is used, which should normally grant minimal or no access.

Niagara's LDAP scheme supports Active Directory, LDAP V2 and LDAP V3. LDAP V2 and V3 servers may require a service account (bind username and password) for the station to search the directory.

What you need from IT

Before configuring anything, ask the IT or identity team for:

Step-by-step setup

Step 1: Back up the station and keep a local admin

Take a backup. Keep at least one local Niagara administrator account (not LDAP) with a strong password, so a directory outage or misconfiguration can never lock everyone out.

Step 2: Trust the directory's certificate

For LDAPS, the station host must trust the certificate presented by the domain controllers. Import the issuing CA certificate into the host's trust store using Workbench certificate management (the platform's or station's trust store as appropriate). Without this, TLS connections to the directory fail.

Step 3: Create user prototypes

1. In Config > Services > UserService, open the user prototypes area.
2. From the baja or ldap palette, add a UserPrototype for each functional role: for example BMS-Admins, BMS-Engineers, BMS-Operators, BMS-ReadOnly.
3. Name each prototype exactly as the attribute value it will match. If matching on AD group names, the prototype names must match the group names exactly.
4. On each prototype, set the roles, web profile, NAV file and other defaults users in that group should get.
5. Configure the Alternate Default Prototype to a minimal, read-only or no-access prototype.

Step 4: Add the LDAP authentication scheme

1. Open the ldap palette.
2. Drag the LDAP authentication scheme into Config > Services > AuthenticationService > Authentication Schemes.
3. Configure:
   • directory type: Active Directory, LDAP V2 or LDAP V3
   • server host(s) and port, with TLS/LDAPS enabled
   • domain or base DN for user searches
   • service account credentials if the directory requires them
   • attrPrototype: the directory attribute used to choose the prototype (for example the group membership attribute)
4. Save the station.

Step 5: Allow users to log in with the LDAP scheme

Users created by LDAP login are associated with the LDAP scheme automatically. Make sure the login screen and client (browser or Workbench) offer the scheme, and that local accounts that must remain local keep their own scheme.

Step 6: Test with one user in each group

• Log in as a test user in each AD group.
• Check the created Niagara user has the expected roles and NAV file.
• Log in as a user in no BMS group and confirm they get only the alternate default prototype's access (ideally none).
• Disable the test user in AD and confirm they can no longer log in.

Designing roles and groups

Keep it simple and aligned with real job functions:

Use Niagara categories to limit areas (for example, tenants see only their own floors), and assign category permissions in the roles.

Supervisors and multiple stations

On a Web Supervisor with many JACEs, it is common to use LDAP at the supervisor for operators and engineers, while JACEs use local accounts for machine-to-machine connections and break-glass access. Decide deliberately which stations authenticate against the directory, and make sure every station that does can reach the domain controllers.

Testing the directory before configuring Niagara

When LDAP logins fail, it helps to know whether the problem is Niagara or the directory connection. Before or during setup, IT can test from the station host itself:

• confirm the host resolves the domain controllers' names and reaches them on port 636 (for example with PowerShell Test-NetConnection dc01.corp.example.com -Port 636)
• test an LDAPS bind with the service account using a directory tool such as Windows' ldp.exe or ldapsearch on Linux
• confirm the user's group memberships and the attribute you plan to use for attrPrototype
• check the certificate chain presented by the domain controllers and that the issuing CA is the one you imported

If these tests succeed but Niagara logins fail, the issue is in the scheme configuration or prototypes; if they fail, fix the network or directory side first.

Troubleshooting

Enable debugging on the scheme or check the station's application director output while testing to see the exact LDAP errors.

Worked example: a university estate

A university wants its estates staff to log in to the Niagara supervisor with their normal campus accounts.

• IT creates four AD groups: BMS-Admins (2 controls engineers), BMS-Engineers (6 engineers and the BMS contractor's named staff), BMS-Operators (20 estates helpdesk and maintenance staff) and BMS-ReadOnly (energy and sustainability team).
• On the supervisor, four user prototypes with the same names carry the matching roles, NAV files and web profiles. Operators see only the buildings in their area through categories.
• The LDAP scheme uses LDAPS to two domain controllers, with the university's CA certificate imported into the supervisor host's trust store, and attrPrototype set to group membership.
• Two local break-glass administrator accounts remain, with credentials in the estates team's vault.
• When a member of staff leaves, IT disables their campus account and BMS access ends automatically.

Result: no more shared logins, auditable access, and no BMS-specific accounts for IT to forget about.

Kerberos and SAML for single sign-on

LDAP gives users one set of credentials, but they still type them at the Niagara login. For a smoother experience:

• Kerberos with Active Directory can let domain-joined PCs sign in to Niagara without re-entering credentials.
• SAML 2.0 (supported since Niagara 4.4) delegates login to an identity provider such as an on-premises or cloud service, giving single sign-on and the provider's multi-factor policies. SAML user accounts also use user prototypes, with attribute mapping from the identity provider's claims.

Both need closer coordination with IT and careful certificate management, but are worth considering on large corporate estates.

Security good practice

• Always use LDAPS or LDAP with TLS; never plain LDAP across a network.
• Use a read-only, least-privilege service account with a long password, if one is needed.
• Keep break-glass local admins with strong passwords, stored securely.
• Make the alternate default prototype grant no meaningful access.
• Combine with two-factor authentication for local accounts, or use SAML with your identity provider's multi-factor policy for corporate users.
• Review group memberships with IT periodically.

LDAP vs SAML vs local accounts

Frequently asked questions

Does Niagara 4 support Active Directory?

Yes. Niagara 4's LDAP authentication scheme supports Active Directory, LDAP V2 and LDAP V3, and Kerberos can provide single sign-on with AD.

How are Niagara roles assigned to LDAP users?

Through user prototypes. The scheme's attrPrototype property names the directory attribute, such as group membership, whose value is matched to a prototype name, and the prototype's roles and settings are applied.

What happens if an LDAP user isn't in any BMS group?

The Alternate Default Prototype is applied. Configure it to give minimal or no access.

Should I use LDAPS?

Yes. Use LDAPS (or LDAP with TLS) so credentials are encrypted, and import the directory's CA certificate into the station host's trust store.

Can I still log in if the domain controller is down?

Only with local Niagara accounts. Keep at least one local administrator for this situation.

Does each Niagara station need its own LDAP configuration?

Yes. Each station that authenticates users against the directory needs its own LDAP scheme, prototypes and trust in the directory's certificate. Many estates enable LDAP only on the supervisor.

What port does LDAPS use?

636 by default. LDAP with StartTLS uses 389.

What is the difference between LDAP and SAML in Niagara?

LDAP checks credentials directly against a directory server. SAML delegates login to an identity provider and supports single sign-on and the provider's multi-factor policies.

What happens when a user's AD group changes?

The prototype is resolved from the directory at login, so a user moved to a different group receives the matching prototype's roles the next time they log in. Removing them from all BMS groups leaves them with only the alternate default prototype's access.

Do LDAP users need to be created in Niagara first?

No. The station creates the Niagara user account automatically at the user's first successful LDAP login, applying the matching prototype.

Need help from a Niagara engineer?

If this guide has not solved the problem, contact the Tyrrell Products technical team on 01942 732819 or [email protected]. Tell us the controller or host type, its Niagara version and what you have already tried, and we will help you get the system running.

Related guides

• Two-factor authentication in Niagara 4
• Code signing and certificates
• JACE default credentials and security
• What is Tridium Niagara 4?