Received the following error in the DBSS SQL Server error log as follows:
"Failed to get connection for Usability OS processor. For security reasons, the user account "" is locked by the agent due to invalid login credentials. Please use the support module to unlock it."
The agent for security reasons will lock the user within the agent after failed attempts to avoid locking the user account on the actual server/database.
There are two types of connections: to the OS and to the Database.
In most, if not in all, organizations, the user account will be locked after a certain amount of incorrect connection tries. For example bad password.
When the agent tries to connect it approaches the OS or Db in the same manner a user attempts to login to the OS or Db, and the same restrictions apply. Meaning that the account will be locked upon incorrect login.
Note:the lock is per account and not per Agent.
In order to avoid locking the domain accounts or Db accounts, the Agent ASP has default for Number of failed connection attempts before locking account, for both OS account and Database account.
Setting the figure to 0 (zero) mean that the attempts to connect will not be limited and the risk to lock the domain/db account is very high.
And it works on the other way as well: if you set the attempts to, let's say, 50, it is most likely that the domain/db account will be locked (depends on how many attempts the OS/Db allows).
When the Agent attempts to connect are exceeded, there will be an internal account lock on the agent side. Meaning it will not try to connect again.
This way the Agent will avoid locking the real domain/Db account.
Agents are locked when a temporary disconnection takes place between the FglAM machine and the Database servers.
The agents logs reflect if the account is locked. Unlock the agent by carrying out the following procedure:
Pertains to DBO Oracle Agents as well.
OS account and/or Database account internal locks depend on the Number of failed connection attempts before locking account configuration.
In many cases, customers that monitor SQL Server instances are using the same account for the instances. If, for some reason, one agent is locked out all other agents that use the same account credentials will be locked as well, as the lock is per account. In this case, unlocking one agent (from Database Technical Support > unlock Agents), will unlock all other agents using the same account.
In some scenarios, skipping the connection checkup on the agent side comes handy. For example, when the customer knows or identifies that there is a temporary disconnection from the FglAM host to the Database machines. If a temporary disconnection is the case, then it is better switching off the Number of failed connection attempts before locking account checkup. This way the agent won't be locked, and when the network connection is back, the Agents will keep on working without the need to unlock the account. In order to skip the Number of failed connection attempts before locking account checkup, edit each and every Agent properties (from Agent Status) and modify the number for Number of failed connection attempts before locking account to 0 (zero), for the Database account and if required to the OS account as well.
