I’m encountering an issue and wanted to see whether this is “normal” behavior for the console. In my environment we’re using PIV Smart Cards for the Windows logon. Our BES Server has two Active Directory domains that are tied to console user LDAP accounts, one of them the domain supporting Smart Cards. Server is at 9.5.4 on Windows.
When a PIV-enabled user logs in to the console with the “Use Windows Credentials” option, the authentication is successful and they log on as expected. However, if they lock their workstation with the BES console open and leave it for a day or more, the server starts getting hammered with failed authentication requests for that console user. I believe this is occurs when the users’s Kerberos ticket expires or their NTLM password changes (which I think is every 24 hours for Smart Card-only accounts). The server_audit.log then begins to resemble
Fri, 30 Jun 2017 05:26:21 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:26:36 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:26:51 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:27:06 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:27:21 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:27:36 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:27:51 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:28:06 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:28:21 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:28:36 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:28:51 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:29:06 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:29:21 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:29:36 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:29:51 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:30:06 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:30:21 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:30:36 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:30:51 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:31:06 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:31:21 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:31:36 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:31:51 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Fri, 30 Jun 2017 05:32:06 -0500 -- domain\username: Too many log in attempts. (Data Connection)
Since the server is getting hammered with their failed logons from one console client, if the user moves to another console they cannot log on to the console from there. We’d need to find their original open console and close it, then wait for the lockout time to expire (and the log doesn’t show the IP address of the failed logons).
Is this expected behavior? My understanding is that we cannot switch to the built-in / SAML smartcard authentication, because that would force all LDAP logons to go through the smartcard interface and our second domain doesn’t support smartcard authentication.