cli-microsoft365 icon indicating copy to clipboard operation
cli-microsoft365 copied to clipboard

Bug report: Missing documentation about necessary consent with password login

Open martinlingstuyl opened this issue 1 year ago • 7 comments

Description

In the ticket #3612 I've been talking with the user about the following error:

Error: network_error: Network request failed. Please check network trace to determine root cause. | Fetch client threw: Error: HTTP status code 400 | Attempted to reach: https://login.microsoftonline.com/organizations/oauth2/v2.0/token

when running m365 login --authType password --userName "myupn" --password "somepassword"

He kept getting the error, and in the end we discovered that he hadn't consented to the PnP application registration.

I looked in the docs, and I couldn't find any reference to this consent being necessary for the password login flow. It may be logical to us that you need to consent to that in all scenario's. but there's a lot of other tools that use basic auth, and this seems to be basic auth.

So I think we should add a few notes that this is necessary for the password login. I'd say in the following pages:

https://pnp.github.io/cli-microsoft365/cmd/login/ https://pnp.github.io/cli-microsoft365/user-guide/connecting-office-365/

Also, maybe it would be good to have a section about this error. It's thrown for a variety of reasons:

  1. You may have misspelled your password or username
  2. You may have forgotten to consent
  3. You may have forgotten you have MFA enabled
  4. You may be signing in with an account from a hybrid federation scenario (aka: Microsoft would normally redirect you ADFS sign on pages)

Requirements

Ok, what needs to be done for this issue to be closed is:

  1. Login command page - Add a remark or important note about the password login needing the AAD Consent
  2. User guide page - Add an important remark in the username/password section about needing the consent.
  3. User guide page - Add an extra section explaining the use of the PnP Management Shell App Registration and needing to consent to it using m365 login to get started.
  4. User guide page - Add an extra section in the username/password section explaining the Network request failed error and the possible reasons for it.

Aside from the documentation, it would be helpful if a hint is shown below the error, with the possible reasons for it.

  1. Show a hint in the CLI when the sign in fails with this error

martinlingstuyl avatar Sep 07 '22 06:09 martinlingstuyl

For me the cmd/login place would be a general remark that consent is required (for any way we login), while the user guide should go a bit more in depth as to what is needed to consent (and perhaps even reconsent as we might have added new permissions).

appieschot avatar Sep 07 '22 08:09 appieschot

That is a nice catch Martin. I will second Appie's suggestion,

For me the cmd/login place would be a general remark that consent is required (for any way we login)

Along with that, like you already covered in your suggestion, we can also give as an Important Note in the Login User Guide as well (https://pnp.github.io/cli-microsoft365/user-guide/connecting-office-365/#log-in-to-microsoft-365_1) which explains about setting up AAD for first time

arjunumenon avatar Sep 07 '22 11:09 arjunumenon

ok, thanks for the feedback: I added a requirements section and opened this up for help.

martinlingstuyl avatar Sep 07 '22 12:09 martinlingstuyl

Hi @martinlingstuyl,

I am currently having the stated problem you mentioned. Is AAD Consent page completely command line friendly -Noniterative?

Edited:

I just got mine to work by disabling 2FA using https://techcommunity.microsoft.com/t5/identity-authentication/mfa-shows-disabled-but-being-used/m-p/1317212

  1. Go to https://portal.azure.com/
  2. Use the search bar on the upper middle part of the page and search of "Azure Active Directory".
  3. Under Azure Active Directory, search for Properties on the left-hand panel. It is in-between of User Settings and Security.
  4. Under the Properties, click on Manage Security defaults.
  5. Under the Enable Security defaults, toggle it to NO.
  6. Wait for few minutes for propagation then try to sign-in using InPrivate or Incognito.

aaden001 avatar Sep 20 '22 18:09 aaden001

Hi @aaden001, Glad you got it working!

In this case I think you or someone in your org already consented for you! Initial consent cannot be worked around.

martinlingstuyl avatar Sep 20 '22 21:09 martinlingstuyl

We should consider showing the 3 suggestions you mentioned directly in the terminal, with a link to the specific page in our docs for more info. Since you're in the terminal at the time of error, that's the most probable place for us to help folks fix the error so we should definitely consider making use of it.

waldekmastykarz avatar Sep 21 '22 17:09 waldekmastykarz

That's a very good idea. I'll add it to the specs!

martinlingstuyl avatar Sep 21 '22 21:09 martinlingstuyl