Cannot get Token from LCS

[kblacquiere]

Hello, I'm trying to call Get-D365LcsApiToken with -ClientId XXXX -UserName uuuuu -Password pppp -LcsApiUri https://lcsapi.lcs.dynamics.com .

But we are receiving : "invalid_grant","error_description":"AADSTS50126: Error validating credentials due to invalid username or password.

I know that the username password are good because I am login into LCS Web Portal and it works ClientID is also Good because We are using Upload Package using LCS in DEVOPS and everything works ...

But we had to change or script few months ago to use MSAL for authentication.

So, I suspect that we have the problem trying to authenticate with d365fo.tools becaue of MSAL ...

Am I right ?

Do you have an idea how to fix this ?

Thanks in advance for you help !

[Splaxi]

As late as yesterday, I was working with the Get-D365LcsApiToken myself. My version is: 0.6.77

If you receive ANY error codes starting with "AADSTS" - I would trust the error message, as this comes directly from the Azure AD, that the cmdlet is trying to authenticate against. The authentication request goes towards: https://login.microsoftonline.com/common/oauth2/token

With that said, we have seen that 3. party identity tools like OKTA has been implemented, which would break the tools - or the expected authentication flow. The community has seen things like this: https://www.yammer.com/dynamicsaxfeedbackprograms/threads/1174941179609088

Extracted comment from the yammer thread:

Yes. I have made sure a number of times the user name and password are correct. These are the same details I am using to upload the package from ADO to LCS. Yes, we have full-blown Azure AD synced with Okta. When we log in manually, it redirects to the Okta authentication screen.

1. Are you sure that your project still runs in the original LCS region, and no one from your company has done a Geo-2-Geo migration?

I know that the username password are good because I am login into LCS Web Portal and it works ClientID is also Good because We are using Upload Package using LCS in DEVOPS and everything works ...

Regarding that statement, I'm guessing that you are running the official Microsoft task, that can be installed into the Azure DevOps organization - right?

We don't quiet know what requirements that the Microsoft task has in terms of specific settings for the Application Registration (ClientId), but personally I have seen different things that needed adjustments of the settings "inside" the Application Registration (manifest). This varies very much, based on what the Azure AD administrators in your organization has configured.

I know that I had to set this to true once, with a customer: oauth2AllowIdTokenImplicitFlow

Here is a valid manifest file from my own Azure AD, that you can compare to your own manifest file.

{
    "id": "{GUID1}",
    "acceptMappedClaims": null,
    "accessTokenAcceptedVersion": null,
    "addIns": [],
    "allowPublicClient": true,
    "appId": "{GUID2}",
    "appRoles": [],
    "oauth2AllowUrlPathMatching": false,
    "createdDateTime": "2021-12-02T10:11:11Z",
    "description": null,
    "certification": null,
    "disabledByMicrosoftStatus": null,
    "groupMembershipClaims": null,
    "identifierUris": [],
    "informationalUrls": {
        "termsOfService": null,
        "support": null,
        "privacy": null,
        "marketing": null
    },
    "keyCredentials": [],
    "knownClientApplications": [],
    "logoUrl": null,
    "logoutUrl": null,
    "name": "LCS-D365-Automation",
    "notes": null,
    "oauth2AllowIdTokenImplicitFlow": false,
    "oauth2AllowImplicitFlow": false,
    "oauth2Permissions": [],
    "oauth2RequirePostResponse": false,
    "optionalClaims": null,
    "orgRestrictions": [],
    "parentalControlSettings": {
        "countriesBlockedForMinors": [],
        "legalAgeGroupRule": "Allow"
    },
    "passwordCredentials": [],
    "preAuthorizedApplications": [],
    "publisherDomain": "{DomainName}",
    "replyUrlsWithType": [],
    "requiredResourceAccess": [
        {
            "resourceAppId": "00000003-0000-0000-c000-000000000000",
            "resourceAccess": [
                {
                    "id": "{GUID3}",
                    "type": "Scope"
                }
            ]
        },
        {
            "resourceAppId": "{GUID4}",
            "resourceAccess": [
                {
                    "id": "{GUID5}",
                    "type": "Scope"
                }
            ]
        }
    ],
    "samlMetadataUrl": null,
    "signInUrl": null,
    "signInAudience": "AzureADMyOrg",
    "tags": [],
    "tokenEncryptionKeyId": null
}

[FH-Inway]

@kblacquiere Did you get this working? Or do you have further questions or comments on this?

[Splaxi]

Will close in 7 days if no new information is provided

[kblacquiere]

Hello, It is not working but we think it's because we are using an AD account that is coming from our on premise infrastructure. There is syncronization between On premise AD and Azure AD . We will try with a pure Azure Ad account and see if it make a difference. We will keep you posted. Thanks

[FH-Inway]

@Splaxi Could you close the issue?

@kblacquiere Did you get it to work with a pure Azure AD account? Feel free to post further information, even if we close the issue. Others might benefit from your experiences.