Authentication failure handling

If a PLCnext device denies access because of invalid credentials for a specific user name, it usually is no big deal - just try again with the valid credentials. But a failing user authenticationalways starts a cascade of events.

Access to a PLCnext device is handled by the User Manager for all types of connections. When the user authentication fails, the username is entered into a penalty list which keeps also track of the current number of failed login attempts.

Retrying with invalid credentials will cause that this user is blocked for a specific penalty delay (for security reasons, we do not publish any details on the specifics here). Every unsuccessful retry will extend that delay so brute-force attacks cannot cause a security issue.

Of course, that's what is expected from a secure system. With extensive use of interfaces and services logging in to the PLCnext device, this authentication failure handling can cause unexpected side effects:

Even valid credentials do not grant access:
During the penalty delay, the affected user is not allowed to log in again even with the valid credentials until the delay has expired. In this case, logging in via WBM or any other service or interface is denied, too, even if valid credentials are presented.
Not all types of connections seem to be affected:
The blocking concerns only another login attempt, so if e.g. the OPC UA® client has already logged in successfully before a WBM login fails, the running OPC UA® session remains unaffected.
Service clients in auto-retry mode are increasing the delay:
If invalid credentials are set in the login routine of e.g. a OPC UA® client that is set to retry the login frequently until succeeding, it can deadlock that user in a never-ending penalty delay.
Maximum PLCnext session count:
Activation is rejected in case the maximum PLCnext session count is reached. For firmware up to 2021.9 the maximum session count is set to 32.
From firmware 2022.0 LTS, the maximum count can be set by admin users so it might be exceeded earlier or later.

Remedy

The service logs are reporting why the access is denied and are showing the penalty delay in milliseconds. The admin user could access the PLC and search the diagnostic log files for the cause and the duration of the delay.

If the penalty delay is still reasonable (e.g. 5 min) then just wait until it expires and try again with valid credentials.
If the penalty delay is far beyond reasonable then restart the PLC. The penalty list is erased and the user is back in good standing.

Preventive measures

It is highly recommended to make sophisticated use of the different user roles for access in different use cases, such as accessing the PLCnext device for programming, OPC UA® access, PLCnext Engineer HMI,... That's what the fine-tuned user roles are for.
In general, avoid accessing devices with the admin user as much as possible. Having the above described cascade in mind, it's an especially bad idea to access a device as the admin user via a client or interface in auto-retry mode: You're prone to locking yourself out of the device for good by making a simple typo in the credentials.