Hi Dojo Community,
is there any logfile I could use to find out, why authentication on the WebService API randomly fails? (Credentials are "hardcoded" in the script that connects via WebService API). I already checked the "Client" log on the DMA, but could not see additional information.
We can see many "Authentication Failure" Information Events with the Value "Connection did not authenticate. Computer: {hostname} Application: XYZ". In between these information events we see successful logins from the same device.
Is there a limit on the number of simultaneous connections on the WebService with different/same credentials? We have around 20 connections as per the client logfile on the agent.
Thanks and best regards
We spent some more time to investigate what is going on.
The external system accesses the WebService for some GetParameterValue requests on a regular basis (e.g. each 30 minutes). As there is no need to keep the connection open in between the connection is typically disconnected 5:xx minutes after the login (requests + 5 min grace period).
Here and then the authentication fails with the information event
"Authentication Failure" with value "Connection did not authenticate. Computer: {hostname} Application: XYZ". Today it happened twice after two days of normal operation without authentication failure. With the next connection attempt all is fine again. There are also other systems using the WebService without issues during the time the authentication failure appears. So we can exclude a general authentication issue around that time.
To exclude other system processes impacting this process I also checked the Windows Event Viewer, to check if there is any issue around the same time, but again I spotted nothing.
As it is happening only here and then it's hard to capture the traffic for a in-depth analysis of the communication.
I would be thankful for any additional idea how we might investigate the root cause of this issue.
Might be best to create a Log Collector package and open a new support ticket (if none exist yet for this issue) to get this further investigated.