Error on ApplicationIdAndSecret Authentication with O365

Help Activities
, ,
1

When using the MS Office 365 Scope activity, and choosing the method “ApplicationIdAndSecret” from the Authentication Type dropdown, I am getting a “generalException,” whose topmost inner exception is "RemoteException wrapping Microsoft.Identity.Client.MsalClientException: Error: ClientId is not a GUID. "

I copied this application ID directly from the registration. I’ve also seen another post that complained that the dashes were the wrong character, even though they looked like dashes, and replaced those.

This seems like a bug to me. Has anyone else experienced this?

2

I am using Office365, and have had some issues. Make sure your setup is using “Delegated” not just “Approved” in the Azure setup (this may not be the cause of your issue, just something to check). Did you fill in the Application Id and Secret values (the Secret needs to be an SecureString)? The Application Id and Tenant that I have used has dashes so that is probably not the issue.

1 Like
3

Hi Jeremy - thanks for the input. I’m having the creator of the application ID check on the Delegated vs Approved in Azure.

The only secure string variable that I see is the O365 password. When I use CTRL + K to create a variable for the application secret, it creates a string variable (as opposed to secure string).

Best Wishes,

Brad

4

I’ve just noticed that there is a field for both AppicationSecret, and for SecureApplicationSecret - I just assumed that this was like Password and SecurePassword, where you could choose one or the other. Can you confirm that this is true? Or…is this asking for two differing pieces of information?

5

The ApplicationSecret and SecureApplicationSecret are different values. The Admin of the Azure Instance should be able to provide both to you. I would store those as Assets on the Orchestrator or on the Config file. The SecureString is available if you search via the Type, which is the proper variable type for the SecureApplicationSecret.

6

The solution to this was to add the app permissions (shared read/write, etc) in azure. Once this was done, and the app was given admin approval, I was able to use the app ID, tenant Id, o365 user name and password, with the InteractiveToken selected from the AuthenticationType dropdown.

7

Great news. Glad you found a solution.

8

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.