By default an HMI panel signs you in against the user list saved in its project, and no domain controller is involved. A few HMI runtimes document LDAP or domain authentication, with limits like a single domain. If your requirement is rejecting disabled or expired accounts on every panel the day they change, pick a panel whose vendor documents it, run the visualization on a domain-joined panel PC, or plan local accounts with a fixed deprovisioning routine.
Can an HMI panel sign an operator in against the plant's domain controller or LDAP directory before the protected screens open? As shipped, most cannot. The login you type is checked against the user list stored in the panel's project, and no server is contacted. A handful of HMI runtimes document directory authentication as an option, with limits to read before you specify it. This page explains what LDAP authentication demands of a panel, what the login on your panel checks today, and which design satisfies a site-wide credential requirement.
What LDAP authentication asks of a panel
LDAP, specified in RFC 4511, is the protocol a client uses to talk to a directory service. Authentication is one operation inside it, the bind. The client sends an account name and a password; the directory checks that the account exists, is enabled, is not expired, is not locked out, and that the password matches, then it either opens a session or returns an error. Everything your IT team values in directory logins lives in that check: disable an account once, and every bind for it fails.
A directory service listens on TCP port 389; the TLS-wrapped form, LDAPS, uses 636. A Windows domain also answers Kerberos on port 88, which is what a domain-joined computer speaks at logon. For a panel to take part, its firmware must contain an LDAP client: a bind function, a way to trust the server's certificate, a network path, and usually a service account the directory team approves. Wiring the panel to the same switch as a domain controller supplies none of that. The client is a firmware feature, so it is bought with the panel, never configured into existence.
What the login on the panel checks today
An HMI project's user administration keeps its own list: account names, passwords, and a security level for each user. Screens and buttons are gated by those levels, so a level 2 operator opens the run screens and a level 5 engineer opens the recipe editor. The whole check runs inside the panel, and a walkthrough of configuring user accounts and access levels on an HMI panel shows the mechanics step by step.
A two-minute test tells you which check you have. Create a test account, pull the panel's network cable, and log in. If the login succeeds with the panel off the network, the credentials were checked against the project's list. Three usable consequences follow: the PLC can read the logged-in user and manage login state, the permission map is project data you can audit through screen access control for a protected operator view, and where the platform supports it, the roster of login numbers can live in the PLC, as in verifying employee login numbers against a PLC roster.
Typing DOMAIN\username at the panel login changes none of this. The string is just an account name, and a match against the local list fails on a name carrying a backslash. On newer platforms the accounts themselves are moving to the PLC side of the link, set up through the engineering software's security configuration, so ask where the accounts live before you plan who audits them.
When a panel can check the directory
Some vendors added the client. One widely deployed HMI runtime documents domain authentication from a named software version onward; the documented limits are a single domain per panel, and a reboot of the terminal before the LDAP settings take effect. Those two details sketch the whole question: capability arrives with a software version, and it carries limits you plan around.
Put a specific question to the panel vendor: for this model on this firmware, does the documentation name LDAP or domain authentication, on which protocol and port, and with which limits. Ask for a documented feature. If the answer is no, then no DNS entry, server address or username format adds the client. The check you have stays the local one described above, and the two designs below are the honest ways to meet a directory requirement.
The panel PC route when the panel cannot check
If the requirement stands and the panel has no documented directory client, move the login to hardware that has one. A panel PC running Windows and joined to the domain performs the Kerberos and LDAP work at logon; the visualization runs on top and can gate screens by the logged-in user's groups. The cost is a Windows licence and a patching schedule at the machine, and boot behaviour after a scheduled restart needs planning, which Windows kiosk auto logon with a domain user after a scheduled reboot covers. This is the standard route when a credential change has to follow the HR leaver process on the same day.
Example: one leaver, 12 panels
Scenario: a packaging area has 12 HMI panels, each project holding the same nine operator accounts. An operator leaves on Friday and the account must be dead the same day.
Local-account design: edit the user list and download the project to every panel. Budget 10 to 15 minutes per panel for the edit, the download and a login test. Twelve panels at 15 minutes is 180 minutes, 3 hours of work, and each download blacks the screen, so each panel also needs a window when its machine can run without its visualization; the article on why an HMI project upload blacks the screen tells you to plan each one as an outage. Total per leaver: 3 hours of work and 12 planned outage windows.
Directory-backed design: disable the account once in the directory. Panel visits: 0. The next login attempt on each of the 12 panels fails, because a bind for a disabled account is refused. The 15-minute figure is a planning budget; a long project over a slow link stretches the local design further behind.
Decide what happens when the directory is down
A directory-backed login inherits the domain's outages, so write the failure rule before the first panel is configured. Fail closed: the panel rejects every login while the directory or the link between them is down, and a machine that needs a login waits on IT. Fail open: one documented local account, held by controls and changed on a schedule, opens the machine screens during the outage. Put the rule in the project documentation and rehearse it during commissioning by cutting the directory link on purpose once. The failure modes of a domain-connected panel are the subject of why HMI local users fail when the domain controller is offline.
One security line: keep domain passwords out of PLC tags, recipe fields and ordinary logs. Those are readable project data, and a comparison inside the PLC validates nothing with the directory; it only places the secret in a second location.
The decision for each case
- Keep operators off engineering and recipe screens: local users and security levels in the panel project, administered by the project owner. No servers, and the check works with the panel off the network.
- Reject disabled and expired accounts on every panel the day they change: buy panels whose vendor documents directory authentication for your exact model and firmware, or run the visualization on a domain-joined panel PC, or, where the panel's documented client accepts a configurable server address, put an on-premises authentication proxy service agreed with IT in the path. Settle the unreachable-directory rule before any panel is configured.
- The panel supports neither and a PC is out: local accounts plus a written deprovisioning routine, one named owner, executed as planned downloads.
Recommendation: keep operator screen access on the panel's documented local users and security levels unless the site requirement is to reject disabled or expired domain accounts everywhere on the day they change. Only that requirement justifies a directory-backed path. If you build one, choose hardware that documents the feature, set the fail-closed or fail-open rule with IT and controls together, and rehearse the directory-down case during commissioning, before the panels go into service.
Questions
Does typing DOMAIN\\user into an HMI login screen make it a domain login?
No. The string is just an account name; the panel matches it against its local user list, and a name carrying a backslash usually fails that match. A real domain check needs an LDAP or Kerberos client in the panel firmware and a project configured to use it. Get the feature named in the release notes for your exact model and firmware build, then test with a genuinely disabled account before go-live.
How long does a directory outage block a panel login?
For the duration of the outage. The panel sends a fresh bind at each login attempt, so the moment the directory answers again, or the link is restored, logins work with no change at the panel. Anything that keeps working during the outage is local by design, such as a break-glass account held by controls. Give the restore the same priority you would give any single server the line depends on.
Can the PLC check the password for the HMI?
A PLC can compare an employee number against a roster, and that is a reasonable identification check. A password comparison in the PLC only tests a string you wrote into a tag: anyone with project or tag access can read it, the directory stays out of the loop, and each panel carries its own copy to maintain. Use PLC comparisons for ID numbers, never for credentials.
Does LDAP authentication also control what a user can open on the panel?
No. The directory answers one question: are these credentials valid, with the account enabled and unexpired. What the user may touch afterwards is authorization, and the HMI runtime handles that by mapping the user's security level or groups to screens and buttons. Plan both halves: the bind check in the directory, and the permission map in the project, tested for one permitted and one denied screen.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.