Cli-microsoft365: Login issue with authType password

[kfrymus]

Hi,

I have an issue login in one tenant with authType password, the production one. On the other(QA or dev) do not have the issue. I'm able to login with deviceCode option only on the production tenant.
I have received confirmation that MFA is disabled for the account, but I do not have permissions to check this.

On QA or dev tenant I'm able to login using the command:
o365 login --authType password --userName [email protected] --password XXX

On Production tenant I'm getting 'D3242: The security token could not be authenticated or authorized'
o365 login --authType password --userName [email protected] --password XXX --verbose --debug

Logging out from Office 365...
DONE
Signing in to Office 365...
No token found for resource https://graph.microsoft.com
Retrieving new access token using credentials...
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - Authority: VERBOSE: Performing instance discovery
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - Authority: VERBOSE: Performing static instance discovery
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - Authority: VERBOSE: Authority validated via static instance discovery.
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - TokenRequest: INFO: Acquiring token with username password
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - CacheDriver: VERBOSE: finding using query
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - CacheDriver: VERBOSE: Looking for potential cache entries:
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - CacheDriver: VERBOSE: Found 0 potential entries.
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - TokenRequest: VERBOSE: No appropriate cached token found.
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - UserRealm: VERBOSE: UserRealm response:
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - UserRealm: VERBOSE: AccountType: federated
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - UserRealm: VERBOSE: FederationProtocol: wstrust
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - TokenRequest: VERBOSE: Acquiring token with username password for federated user
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - TokenRequest: VERBOSE: Attempting mex
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - MEX: VERBOSE: Mex created
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - MEX: VERBOSE: Retrieving mex
Wed, 13 Jan 2021 12:09:09 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - MEX: VERBOSE: Retrieving mex at: https://sts.mycompany.eu/adfs/services/trust/mex
Wed, 13 Jan 2021 12:09:10 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - MEX: VERBOSE: found matching policy id
Wed, 13 Jan 2021 12:09:10 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - MEX: VERBOSE: found matching policy id
Wed, 13 Jan 2021 12:09:10 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - MEX: VERBOSE: found binding matching Action and Transport: UserNameWSTrustBinding_IWSTrustFeb2005Async
Wed, 13 Jan 2021 12:09:10 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - MEX: VERBOSE: foud binding matching Action and Transport: UserNameWSTrustBinding_IWSTrust13Async
Wed, 13 Jan 2021 12:09:15 GMT:f30b5846-0bec-460d-9357-4ded68819be0 - TokenRequest: VERBOSE: getTokenFunc returned with err
Response:
undefined
Error: WS-Trust RST request returned http error: 500 and server response: http://www.w3.org/2005/08/addressing/soap/fault2021-01-13T12:09:15.736Z2021-01-13T12:14:15.736Zs:Sendera:FailedAuthenticationID3242: The security token could not be authenticated or authorized.
Error:
WS-Trust RST request returned http error: 500 and server response: http://www.w3.org/2005/08/addressing/soap/fault2021-01-13T12:09:15.736Z2021-01-13T12:14:15.736Zs:Sendera:FailedAuthenticationID3242: The security token could not be authenticated or authorized.
Error: WS-Trust RST request returned http error: 500 and server response: http://www.w3.org/2005/08/addressing/soap/fault2021-01-13T12:09:15.736Z2021-01-13T12:14:15.736Zs:Sendera:FailedAuthenticationID3242: The security token could not be authenticated or authorized.

Might you have any suggestion what could be the issue and what shall I check?

[waldekmastykarz]

Do you happen to have conditional access enabled for this account?

[kfrymus]

Do you happen to have conditional access enabled for this account?

Yes, we have the conditional access configured for the tenant where the issue is present for all users in this tenant(we do allow only access from Intranet).
Could it be related?

[waldekmastykarz]

Possibly. We have a similar issue with device code auth. I wouldn't be surprised if this was related. Do you have a way to test it with and without the conditional access policy to see if you can repro the issue? Meanwhile, we're working on a solution that will address this issue and which should be available in the coming weeks #1979

[kfrymus]

With device code auth(default one) I'm able to login to this tenant where I have issue with password authtype:
o365 login --userName [email protected]
Then I'm asked to go to the webpage and put the code and I'm logged in.

In my case I'm also using ADFS and onprem account synced into AzureAD as in the issue you have metnioned.

I will not be able to test this without conditional access policy in this tenant.

[waldekmastykarz]

Have you tried using domain\user instead? I've seen a number of articles about this error and often they relate to other systems like SharePoint or CRM Online in combination with ADFS, so it could be related. Do you have other apps on the same machine where you also authenticate using username and password so that we can verify that it's not a machine configuration issue but rather something on our end?

[plamber]

Hi @kfrymus,
the username and password authentication uses the Resource Owner Password Credentials flow.

Federated identities have issues with that approach. Note also the important points listed on the official Microsoft site:

- The Microsoft identity platform endpoint only supports ROPC for Azure AD tenants, not personal accounts. This means that you must use a tenant-specific endpoint (https://login.microsoftonline.com/{TenantId_or_Name}) or the organizations endpoint.
- Personal accounts that are invited to an Azure AD tenant can't use ROPC.
- Accounts that don't have passwords can't sign in through ROPC. For this scenario, we recommend that you use a different flow for your app instead.
- If users need to use multi-factor authentication (MFA) to log in to the application, they will be blocked instead.
- ROPC is not supported in hybrid identity federation scenarios (for example, Azure AD and ADFS used to authenticate on-premises accounts). If users are full-page redirected to an on-premises identity providers, Azure AD is not able to test the username and password against that identity provider. Pass-through authentication is supported with ROPC, however.

We recommend to use a different authentication method. Alternatively, you could try it out with a cloud only identity.

Hope this helps,
Patrick

[kfrymus]

Hi Waldek,
I cannot use the domain\user, since the domain from the email address is used to determine the sts service against which to authenticate.
I'm able to authenticate from the same machine in other tenants.

o365 login --authType password --userName domain\user --password XXX --debug --verbose
Logging out from Office 365...
DONE
Signing in to Office 365...
No token found for resource https://graph.microsoft.com
Retrieving new access token using credentials...
Thu, 14 Jan 2021 15:08:01 GMT:e1e60df6-1ad4-4ca2-a095-02ff124cf8a8 - Authority: VERBOSE: Performing instance discovery
Thu, 14 Jan 2021 15:08:01 GMT:e1e60df6-1ad4-4ca2-a095-02ff124cf8a8 - Authority: VERBOSE: Performing static instance discovery
Thu, 14 Jan 2021 15:08:01 GMT:e1e60df6-1ad4-4ca2-a095-02ff124cf8a8 - Authority: VERBOSE: Authority validated via static instance discovery.
Thu, 14 Jan 2021 15:08:01 GMT:e1e60df6-1ad4-4ca2-a095-02ff124cf8a8 - TokenRequest: INFO: Acquiring token with username password
Thu, 14 Jan 2021 15:08:01 GMT:e1e60df6-1ad4-4ca2-a095-02ff124cf8a8 - CacheDriver: VERBOSE: finding using query
Thu, 14 Jan 2021 15:08:01 GMT:e1e60df6-1ad4-4ca2-a095-02ff124cf8a8 - CacheDriver: VERBOSE: Looking for potential cache entries:
Thu, 14 Jan 2021 15:08:01 GMT:e1e60df6-1ad4-4ca2-a095-02ff124cf8a8 - CacheDriver: VERBOSE: Found 0 potential entries.
Thu, 14 Jan 2021 15:08:01 GMT:e1e60df6-1ad4-4ca2-a095-02ff124cf8a8 - TokenRequest: VERBOSE: No appropriate cached token found.
Thu, 14 Jan 2021 15:08:02 GMT:e1e60df6-1ad4-4ca2-a095-02ff124cf8a8 - TokenRequest: VERBOSE: getTokenFunc returned with err
Response:
undefined
Error: User Realm Discovery request returned http error: 404
Error:
User Realm Discovery request returned http error: 404
Error: User Realm Discovery request returned http error: 404

[plamber]

Hi @kfrymus,
as far as I understood you are using an identity synchronized from the local AD. Our CLI uses the Resource Owner Password Credential flow that does not work with such identities. You can use cloud only identities. This is a limitation of Azure AD. You can find more information here

The device code flow works with synchronized identities.

If your process requires you to pass a username and password, then create a cloud only identity. Otherwise, other authentication approaches should be used.

br,
Patrick

[kfrymus]

Hi Patrick,

I need to check what could be possible in our case. This could be the issue:
ROPC is not supported in hybrid identity federation scenarios (for example, Azure AD and ADFS used to authenticate on-premises accounts). If users are full-page redirected to an on-premises identity providers, Azure AD is not able to test the username and password against that identity provider. Pass-through authentication is supported with ROPC, however.

BTW. I have done tests with the SharePointPnPPowerShell and I have similar issue, I can connect to the QA, but not production tenant.
In both cases I have users coming from local AD synced into AzureAD, configured conditional accesses.
The user in both environment has access to the tenant app catalog and can manually upload package to it.

Connect-PnpOnline -Url https://mytenant_qa.sharepoint.com/ -Credentials mytenant_qa -IgnoreSslErrors -verbose
VERBOSE: Using parameter set 'Main'
VERBOSE: PnP PowerShell Cmdlets (3.25.2009.1): Connected to https://mytenant_qa.sharepoint.com/
Disconnect-PnPOnline
Connect-PnpOnline -Url https://mytenant_prod.sharepoint.com/ -Credentials mytenant_prod -IgnoreSslErrors -verbose
VERBOSE: Using parameter set 'Main'
Connect-PnpOnline : Federated service at https://sts.mycompany.eu/adfs/services/trust/2005/usernamemixed returned error
: ID3242: The security token could not be authenticated or authorized.
At line:1 char:1
+ Connect-PnpOnline -Url https://unicredit.sharepoint.com/ -Credentials ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Connect-PnPOnline], MsalClientException
    + FullyQualifiedErrorId : Microsoft.Identity.Client.MsalClientException,PnP.PowerShell.Commands.Base.ConnectOnline

[waldekmastykarz]

So could this be that it's a limitation of identity setup and there is not much that we can do about it?

[kfrymus]

So could this be that it's a limitation of identity setup and there is not much that we can do about it?

Hi,
I suppose you are right Waldek.
I will ask MS to support us with those checks, since we have issue with Connect-PnpOnline either on one env and not the other to understand the differences.
Thank you.

[waldekmastykarz]

Sorry we don't have a better answer. If you find out something that could help us address this issue, please, don't hesitate to reach out.

[kfrymus]

Hi,
We have resolved the issue and it was issue in our prod env. We saw in logs in ADFS that there is an issue with recognizing the user and we noticed two users with the same email, so ADFS could not authenticate user. After the fix I'm able to login with authType password.
Thank you

[waldekmastykarz]

Awesome! Great to hear you're unblocked and thanks for sharing the root cause. There is always a chance someone else will come across a similar issue so it could help others 👏