Enabling REST API access on new 2018 Orchestrator installation

I have just installed the 2018.1 Orchestrator Server on a VM in our on-premises environment using the UiPathPlaform.msi and I am having problems connecting to the /api/account/authenticate REST API.

Are there additional steps to perform after the installation to enable this?



1 Like

Ok so the problem seems to be when I try to use an Active Directory account to authenticate against the REST API I get the error

Invoke-RestMethod : {“message”:“An error has occurred.”,“errorCode”:0,“resourceIds”:null}

If I use an orchestrator account all works fine.

Do I need to specify the AD account in a certain format in the username field or are only orchestrator accounts supported?



I’ve just been working through this myself and here is what I’ve observed.

*I’m using Orchestrator 2018.3.1

  1. WindowsAuth is enabled
  2. Visiting HTTP site with AutoLogin enabled using an imported domain user will auto-negotiate or prompt for basic auth.
  3. Visiting HTTP site with AutoLogin disabled (or after manually logging out) will not accept domain credentials
  4. Authenticating with the API will not accept domain credentials
  5. Authenticating with the API will accept a local orchestrator user credentials

Attempting to authenticate with domain credentials by POST to /api/Account/Authenticate will result in an HTTP 400 Bad Request response.

    "message": "Invalid username/email address or password.",
    "errorCode": 1000,
    "resourceIds": null

Setting a local password on your Orchestrator’s domain user’s record will allow you to authenticate with the domain user’s username. I don’t know if this is by design or a bug in the implementation, but I would consider it to not function as expected as it almost defeats the purpose of authenticating against AD as now there are two sets of credentials for the same user that need to manually be kept in sync which adds complexity to management of the users and security.

I’ve submitted a support ticket to see if this is by design, a flaw or on the roadmap to enhance functionality (assuming it hasn’t been changed in already released later versions).


Looking at this further and reviewing the documentation (which isn’t exactly clear).


With that in mind, I created an NTLM Token passing it into my Authorization header and calling an endpoint such as /odata/Jobs(123) and was able to successfully get a response using a domain user without having to call the /api/Account/Authenticate endpoint to get a Bearer token.

I still believe that the HTML Login form and API should be able accept the domain credentials along with local accounts, at the very least the documentation should be improved to reflect this.