Why HMI local users fail when the domain controller is offline

Why do local logins fail when the domain controller is off?

With MpUserX set to "Local and central" on mapp Services 5.15.0, every login attempt waits on the LDAPS connection to port 636 first. With no timeout parameter defined, that wait has no bound you can set, so the login never reaches the local user list.

One field case shows the full pattern. With the controller on, both user sources work and roles map correctly from the AD groups. With the controller off, no login succeeds, and the condition survives a warm restart, so it is configuration behavior, not a stuck session. Switching Type to "Local" brought local logins back at once. That tells you the panel's own user database was intact; the central connection was the blocker.

• All logins fail only while the controller is off, and both sources work with it on: the blocked path is the central connection, not the user data.
• Users created at runtime through the HMI fail as well: the whole login is stuck, not one account.
• A warm restart changes nothing: the condition lives in configuration state, not session state.
• Setting Type to "Local" restores logins immediately: the local list is intact, the central wait is the blocker.

A panel frozen at its login screen while a server is unreachable is a common failure shape across HMI software; the article on WinCC Unified kiosk mode stuck on establishing connection covers the web-kiosk version of the same hang. The pattern is wider than one automation package. Any platform that authenticates against a central identity provider needs a fallback path, the problem walked through in user source fallback when the IdP is unreachable.

How do I get local users back in without upgrading?

Set the MpUserX Type from "Local and central" to "Local" and local logins return immediately, at any mapp Services version. The panel then authenticates against its own user list only and never opens the LDAPS connection.

This is the stopgap, and it works on 5.15.0 the same as on later versions. The change goes into the MpUserX configuration, and the field case shows local logins returning immediately after it. The tradeoff: while Type is "Local", accounts that live on the domain controller cannot sign in, and the AD group to role mapping is out of the picture. Switch Type back to "Local and central" once the controller is reachable and both sources return. Keep one strong local account on the panel regardless, because with the Timeout set it is the account that gets you in during the next outage.

Which mapp Services version introduced the Timeout?

mapp Services 5.20.0 introduced the MpUserX Timeout parameter together with a prioritization setting. mapp Services 5.24.2, dated February 14, 2024, lists the slow login of local users when the server is unavailable as solved.

Upgrade mapp Services and mapp View together; the field upgrade that exposed the Timeout field took both packages to 5.20.0. The revision history then carries the fix through 5.24.2, whose notes list the item "MpUserX: Slow login of local users if server is not available" as solved. Version 5.24.6 was the newest release of that line at the time. Take 5.24.2 as the floor, or the newest release your panel's automation runtime supports.

How do I set the Timeout to seconds instead of Automatic?

Upgrade, then open the MpUserX configuration in your project. The Timeout field that appears at mapp Services 5.20.0 and later offers "Automatic" or a number, and you type the seconds you want, for example 5, in place of "Automatic".

1. Upgrade mapp Services and mapp View to 5.24.2 or later, and confirm the panel's runtime supports them.
2. Open the MpUserX configuration in the project.
3. In the Timeout field, replace "Automatic" with a number of seconds; this article uses 5.
4. Leave Type at "Local and central" so both user sources stay active.
5. Transfer the project and test with the domain controller powered off.

A fixed value is measurable with a stopwatch, repeatable after every restart, and safe to write into a maintenance procedure.

How many seconds should the Timeout be?

Five seconds. A domain controller on the same plant network answers LDAPS on port 636 in well under a second, so 5 s covers a busy or briefly slow server. Any wait past 5 s during normal operation points at a network fault you want to know about.

An LDAPS login is a TCP handshake, a TLS handshake, and a bind: a handful of round trips, each a few milliseconds on a plant LAN. Five seconds tolerates a loaded server and a sluggish switch stack. Going lower is risky in the other direction. Once the timeout expires, the panel can only check its local list, so a real domain user gets rejected over a brief load spike. Twenty or thirty seconds also works, but every login during an outage then waits that long before the fallback, as the example below shows.

Example: how long does a login take with the Timeout at 5 seconds?

Worst case, a local user waits 5 s for the LDAPS attempt to time out plus about 1 s for the local check: 6 s from tap to desktop. With the controller back on, the same login finishes in under 1 s.

Take a packing line with one domain controller and 10 operators logging in across a 4-hour maintenance window while the controller is powered off. Each local login takes 5 s of timeout plus about 1 s of local check: 5 + 1 = 6 s. Ten logins add 10 x 6 s = 60 s of waiting across the whole window. Set the Timeout to 30 s instead and the same window takes 10 x 31 s = 310 s, more than five minutes of people standing at the panel. On mapp Services 5.15.0 with no timeout, the same ten logins never complete, and the line waits on the Type "Local" stopgap.

Do the Active Directory users still work with the controller off?

In the reported test after the upgrade, yes: users created on the domain controller logged into the panel with the controller powered off. No public document states a credential cache or a retention time, so verify it on your own panel before you rely on it.

The observation comes from the same panel after the move to 5.20.0: local users and DC-created users both logged in with the controller off and on. The release notes through 5.24.2 and the Timeout help text describe no cache. Plan for the useful behavior without building on it: give the accounts that must work during an outage a place in the local list. The test takes two minutes, and the field question was handed to the vendor's support line for a definitive answer on caching.

How do I check the fix before a real outage?

Test it during a maintenance window. With the Timeout set to 5 s, power the domain controller off, log in as a local user with a stopwatch, and expect roughly 6 s. Then warm-restart the panel with the controller still off and log in again.

• Controller on: a local user and a domain user both log in, and the AD group to role mapping still applies.
• Controller off: a local user logs in within about 6 s, the timeout you set plus the local check.
• After a warm restart with the controller still off: the same local login still works, because the Timeout is part of the configuration.
• Timed with a stopwatch: if the wait runs far past the seconds you set, the Timeout is still on "Automatic" or the mapp Services version is below 5.20.

Floor information that needs no login keeps running through the same outage. Running those screens from local storage, as in offline dashboard signage for screens without logins, takes the login server out of the picture for good.

Recommendation: Run mapp Services 5.24.2 or later and set the MpUserX Timeout to a fixed 5 s, with Type left at "Local and central". If an outage hits before the upgrade is done, switch Type to "Local" to bring local logins back immediately, then switch it back when the domain controller returns. Give every account that must survive an outage an entry in the local user list.

Questions