Orchestrator API Error " You are not authenticated!" thrown in clustered environment.
Issue Overview: When trying to authenticate against the Orchestrator API, the following error is returned: “You are not authenticated!”.
Root Cause: This can happen when Orchestrator does not think the user is authenticated. It means that authentication was not done correctly or that Orchestrator has a configuration issue.
Usually the issue is in how the API request is made, as configuration issues on Orchestrator that break authentication would also break normal user login.
Troubleshooting Steps:
- For all the below steps, make sure that the tests are performed on the client where the commands are failing.
- Try performing authentication via swagger,
- Go to \Swagger
- Under the field “Account”, select the API /api/Account/Authenticate
- Try authenticating. This method will just use Basic Authentication, but that is OK because if authentication is broken, it should not work for basic or windows authentication.
- If Swagger authentication works, that means that Authentication works. Most likely the issue is with how the request is being made. See below
- See our documentation: About OData And References
- If using Postman, make sure to clear any cookies
- If using the Github scripts located at: Orchestrator Powershell, make sure to check out the examples that are given.
- If authentication works, but subsequent commands fail, go to the section Intermittent Failure.
- If the above step did not help, open a ticket with UiPath Support. Send the UiPath.Orchestrator.dll.config and web.config for Orchestrator. (If in a multi-node environment, send the files of each node.)
Intermittent Failure: If it is possible to authenticate against the API, but subsequent messages return “You are not authenticated!” it usually means that something is configured incorrectly on Orchestrator.
- Common scenario is in a multinode Orchestrator instance. In this case, that would mean Redis is not synced correctly.
- Try flushing Redis – From a the redis machine, execute $redis-cli FLUSHALL
- If the Orchestratator instance is multi-node and hosted as an Azure web app, make sure that the ARRAffinity header is not being used in requests
- Read Disabling Arrs Instance Affinity In Windows Azure Web Sites/
- If this setting is enabled, try disabling it. If that is not possible then the API can still be used, but the ARRAffinity header will need to be included in any API requests.
- Try tracing the HTTP requests in the IIS logs. Try to see if the node where authentication is occurring is also the node where the subsequent commands are sent.
- Hint: In the IIS logs just search for the API calls being made.
- In the web.config file check the value of: Auth.Cookie.Expire
- The default is 30 minutes
- If could be that the authentication token used in the API request is expiring.
- If none of the above helps, open a ticket with UiPath Support.
Debugging HTTP Requests
- To gain clarity on the request that is being made, try using cURL to execute the HTTP request from the command line
- In windows “-v” outputs both the HTTP request and Response. On Unix like systems the option is -k
- Executing the command with cURL is an excellent way to see the HTTP request that is being made
- Swagger gives examples of the cURL command that can be used after executing successfully
- If powershell is preferred use Invoke-WebRequest (this is actually just an alias for cURL)
- Try using Fiddler to capture the requests from where the API request are being made. Read Capturing-traffic-with-fiddler
- Swagger requests can be captured using a web debugger
- Comparing working and non-working requests typically provides insight into why a request is failing.