How to authenticate orchestrator api using windows credentials

@bajji245 @Ncr_Hines - 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).

1 Like

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

https://orchestrator.uipath.com/reference#api-references

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.

3 Likes

Hi,
I am having the same concern for v2018.4.1.

Hi twhitehead

Have you solved the problem , i tried creating an user , it did not help to solve the problem.
Please give some inputs on this

Hi @j11,

Yes, I did, my posts above indicate what I did at a high level. If you’re having troubles I’d suggest opening a new thread specific to your issue detailing a few things

  1. What you are trying to accomplish
  2. What issues are you running into (Symptoms, errors, etc.)
  3. Steps you have taken (detailed as possible)
  4. Any other troubleshooting you have already done

In this way, the thread remains subjective to the original post and doesn’t get hijacked/off-topic to the OP.
Feel free to PM your thread and I’d be happy to review / respond if I can assist.

Cheers,
Tim

1 Like

To summarize my findings above

There are two methods to authenticate a user whether that is via the Web Console or API.

  1. Local User (User is created locally in Orchestrator)
  2. Domain User (User record is created locally in Orchestrator with a reference to the domain)

Local User
When using a local user credential, the user can log in using the Orchestrator web console login form.

image

These same credentials can be used to access the API assuming the user has the right roles and permissions to request the specific endpoints. In order to do so, you must first authenticate your user and receive a Bearer Token in return which will be used on your subsequent API requests

  1. Authenticate against by POST to /api/Account/Authenticate
    Headers: Content-Type application/json, Accept: application/json
    The body at a minimum should have the following JSON payload

    {
     "usernameOrEmailAddress": "randomuser",
     "password": "randompassword"
    }
    

    The response will include a Bearer Token noted in the result key. It will be much longer

    {
      "result": "0c_L7-baK_afadsfasdfasdfadfuzjIWsTT1L1PoIkH..........PcNWqITasdfasdfadfasdfCg",
      "targetUrl": null,
      "success": true,
      "error": null,
      "unAuthorizedRequest": false,
      "__abp": true
    }
    
  2. Make another API request such as for the list of Machines /odata/Machines
    Headers: Content-Type: application/json, Accept: application/json, Authorization: Bearer 0c_L7-baK_afadsfasdfasdfadfuzjIWsTT1L1PoIkH..........PcNWqITasdfasdfadfasdfCg

    Note that the Authorization header’s value is prefixed with Bearer followed by the token provided in the authorization result

    Body sample

    { 
       "Name": "RANDOMCOMPUTERNAME"
     }
    

    Response

    {
        "@odata.context": "https://.../odata/$metadata#Machines/$entity",
        "LicenseKey": "5adsf-8232-456b-915f-345ab34785c9",
        "Name": "RANDOMCOMPUTERNAME",
        "Type": "Standard",
        "NonProductionSlots": 0,
        "UnattendedSlots": 0,
        "Id": 49,
        "RobotVersions": []
    }
    

Domain User
When authenticating as a domain user on the web console (If auto-login is not enabled) the user would click the Windows icon below the login form.

image

When authenticating with NTLM this is configured by default in IIS as one of the Authentication Providers for the UiPath Orchestrator site.

image

For authenticating with the API, you do not need to do Step 1 as indicated with the Local user. Instead, when querying an endpoint instead of providing a Bearer Token in your Authentication header you provide an NTLM token.

Authorization: NTLM wfiyauerfpoauyif;asdyfapw8yefpawf

This is why when accessing/testing the API through the Swagger UI, you do not need to authenticate yourself.

In addition, as I noted in one of my earlier posts, you can set a local password on a domain user, but keep in mind that these are two separate passwords (One local to Orchestrator and one for the Domain user) for the same user record in Orchestrator.


In summary, I do find it a bit misleading and the documentation could be clearer as well as it could be simplified by allowing domain users to enter their domain credential into the login form/authorization endpoint, as I would expect with many other services out there.

18 Likes

Mate, this is awesome!!! Thank you so much!!

1 Like

@codemonkee Thanks for the tip.

Using Postman, the authentication needs to be set to NTLM. Enter username, password and advanced options if necessary. Set the header ‘Accept’ to ‘application/json’

image

1 Like

@Baiduryakanti_Majumd,

This is not necessarily required if you can generate your NTLM Token in other ways, which is what that Authorization tab in Postman is doing after it’s been saved, you’ll see in your headers tab an Authorization header with a value prefixed with NTLM and the NTLM token.

1 Like

@codemonkee It looks like the developer doesn’t need to explicitly handle the auth process and NTLM token generation.We can use simple HTTP request, with Simple Authentication where the developer would be asked to give the username and password.

For a C# code implementation I think this link provides a good enough accepted answer :
https://stackoverflow.com/questions/1520703/sending-http-headers-with-http-web-request-for-ntlm-authentication

1 Like

I was looking into a semi-related issue (using the HTTP request activity) and authenticating against another REST service that does not accept Basic auth and the current user doesn’t have authorization.

When inspecting the traffic, I can see four requests with a single activity.

  1. Connect
  2. GET passing Authorization header with Basic, which is rejected in my case
  3. Connect
  4. GET passing Authorization head with Negotiate

In my use case, my domain user has authorization to the service in question, but for the unattended robot, the service account being used does not directly. Setting the Basic authentication with correct credentials was also not accepted by the remote service where it was expecting to receive Negotiate or NTLM authentication.

I ended up using GetRobotCredential to pull the credentials from an asset in orchestrator. I then added the credentials as a domain credential into the Windows Credential Manager using the Add credential activity setting the persistence to Session so it is destroyed after the current session is complete. With the domain credentials saved in WCM, you don’t need to provide any other authentication properties.

If the goal is to interact with the Orchestrator API from the automated process/robot, I might suggest using the Orchestrator HTTP Request activity which authenticates using the robot which the process is executed on, assuming the Robot role has the appropriate permissions in Orchestrator and it suits your needs.

There have also been a few times when I leveraged the RestSharp package to programmatically interact with a Restful service where I might find the HTTP Request activity to be limiting.

8 Likes

Great Post! We’re are facing the same issue and this is very helpful. Thank you for taking the time to write this out!!

1 Like

Hi, I am getting the same “loginModel is null” error. If you were able to resolve the issue, can you please share your solution?

Hi @atul.trikha,

Please take the time to read through the thread; It covers two authentication methods (Local Authentication with a Bearer Token and Domain Authentication via NTLM).

If any of the above is unclear, please indicate which part that is and I would be happy to assist, as I am sure others would be as well.

Depending on your circumstances, I might also suggest making a new topic (MCVE) specific to your issue detailing what it is you’re trying to do, What you have tried so far, and the outcome you are getting. Doing this will make it much easier for someone to assist you with your particular case.

Cheers,
Tim

Hi Tim,
I’m looking for code to get Domain Authentication NTLM token. Can you provide code?

3 Likes

Hi, could you please assist how did you create an NTLM token? Actually there is a requirement in my project which requires to authenticate Orchestrator by this way

@codemonkee…In our environment, So far Authentication of users are being done by orchestrator local user. How ever going forward it is being replaced with the active directory i.e. using windows creds , user would be authenticated using SSO.

We are leveraging the Rest API’s of orchestrator. Initially we were utilizing the local credential of orchestrator user to /api/account/authenticate but now since SSO is enabled , i need to understand how to get the NTLM token to pass it as a header to subsequent requests.

If you have SSO enabled and automatic-login is enabled on the orchestrator you can simply skip the authentication.

Hi
Example of code:

Invoke-WebRequest `
-Uri 'https://onprem-uipath-hostname/odata/Folders' `
-Method GET `
-ContentType "application/json" `
-UseDefaultCredentials

2 posts were split to a new topic: How to authenticate Orchestrator API using ReactJS & NTLM