Cli-microsoft365: Trouble spo login with an account with multi-factor authentication

[Laul0]

Hi,

I'm occurs an issue with login cmdlet :

root@37313dbb2dc5:/# o365 spo login $TENANT --authType password --userName $USER_LOGIN --password $USER_PWD
Error: AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000003-0000-0ff1-ce00-000000000000'.
Trace ID: 643f9309-c39a-45b5-a1f2-84eaff4e9300
Correlation ID: b158c728-d15b-4a8d-a334-db451e4850da
Timestamp: 2018-12-26 14:39:46Z

that's because my user account use MFA.... Fine, use App Password :

root@37313dbb2dc5:/# o365 spo login $TENANT --authType password --userName $USER_LOGIN --password $USER_APP_PWD
Error: AADSTS70002: Error validating credentials. AADSTS50126: Invalid username or password
Trace ID: e80a8192-f5a2-42f5-9300-46409173a100
Correlation ID: fe78277b-7ea0-410a-a5fa-5cd2333f4cce
Timestamp: 2018-12-26 14:40:19Z

Informations

$TENANT is URL : https://tenant-admin.sharepoint.com

Office365-cli version :

root@37313dbb2dc5:/# o365 version 
1.12.0-beta.8270091

But it doesn't work 😢

What's wrong in my script ?

[VelinGeorgiev]

I think that if you go with username and password, the only way is to use service account that does not require MFA (this applies to SPO and PnP PowerShell as well). More information here: https://techcommunity.microsoft.com/t5/Identity-Authentication/Authenticating-to-O365-using-Powershell-and-MFA/td-p/3954.

Other options is to use the device authentication, but you cannot automate a process or pipeline because you will be prompted to login every time.

Another option that the Office 365 CLI will soon support is app principle authentication. I think that should work no matter if MFA is enabled.

@waldekmastykarz, do you have more info on that?

[Laul0]

Hi @VelinGeorgiev ,

• Yes, but a Service Account with a password that never expire is not very secure, isn't it ? 😉
• As you said, a pipeline can not really works with a device authentication
• I have no other choice that waiting for the support of app principle authentication 😢

[VelinGeorgiev]

Hi @Laul0,

I am working with @waldekmastykarz to bring the app principle authentication as soon as possible since even I need it for our build and release pipelines.

Stay tuned, we may make it available sooner than you'd expect. Right Waldek? :)

[waldekmastykarz]

As @VelinGeorgiev mentioned, if you use MFA, you can't use credentials for authentication. This limitation is not specific to the CLI, but to any kind of daemon process that needs to connect to APIs secured with AAD.

Building up on work by @wictorwilen, I've just completed implementing certificate-based authentication (#389) which could address some of your issues, but which isn't without limitations itself, because it uses app-only context that isn't supported by all commands. This new option for logging should be available in the next or the following beta once I've finished implementing tests to verify that everything is working as expected.

[Laul0]

Hi @waldekmastykarz,

That you are saying is, PnP PowerShell, SPO Console Management and PSSession (for exchange) don't use APIs secured with AAD ?
If I don't say mistake, they work fine with an user account with App Password.

In this case, what they use to connect to SPO services ?

[waldekmastykarz]

If you have an account secured with MFA, when using PnP PowerShell you have to use the weblogin option which shows a popup to support MFA. It's an interactive process that you couldn't implement in a build pipeline. That's just the consequence of using MFA which always requires user interaction.

[Laul0]

Totally agree with you about MFA authentication when you are using you login and account password.

Currently, with my account secured MFA, to connect with PnP (Connect-PnPOnline) I'm using my login (ex: [email protected]) and an App Password.
Thank to App Password I can bypass the MFA (App Password is used for Outlook that doesn't support MFA too).

[waldekmastykarz]

So how is that exactly different from using an account without MFA enabled? 🙂

[waldekmastykarz]

I recall a conversation I had a while ago with people responsible for AAD and OAuth and they mentioned, that username + app password is considered legacy and is available only for legacy clients which don't support MFA (such as old versions of Outlook or some other mail clients). As such, username + app password are not supported in the credentials OAuth flow.

By default, PnP PowerShell doesn't use OAuth for authentication, but uses SharePoint APIs instead. This isn't a big issue with PnP PowerShell, because most cmdlets are communicating with SharePoint. If you however would try to execute any other cmdlet that communicates with the Microsoft Graph or any other API outside of SharePoint, then you would have to use OAuth flow for authentication and you couldn't use username + app password.

[Laul0]

I'm sure, you're right about OAuth and the support between Microsoft Graph and App Password. That why you can use App ID and App Secret, isn't it ?

They are a lot of differences / reasons to enable MFA (I'm writing a post on my blog about that, I think it's interesting 👨🏼‍💻, here a sample ) :

1. An user cannot use App Password to connect the Office Portal
2. App Password never expire (you can set never expire password for specific account but it is not obvious to manage this kind of accounts). The user can change his password and the App Password is keeping
3. You can generate several App Passwords (I don't know if this case is really interesting but you can 😉)
4. You can revoke all App Password in one shot
5. For security reason, all accounts with admin role(s) should have MFA activated (especially for Global Admin role)
6. If an enterprise wish to have a good score on Microsoft Secure Score, enable MFA is recommended (CSA CCM301, Control DSI-02, FedRAMP Moderate, Control IA-3, GDPR, etc.)

There are still other differences / reasons, but here are the ones I expose to my customers and also why I generally advise to activate the MFA.

[VelinGeorgiev]

MFA is a must have for any tenant admin role, this is my opinion.

I was trying to understand, if App Password is viable option and can be used for scripts. Now, looking at your comments @Laul0, App Password is not something I would use since looks like we are basically bypassing the MFA.

My approach would be cert authentication stored in a Azure Key Vault with the CLI tool when cert auth is available.

[Laul0]

It's not really a bypass... It's most an easy solution to keep a minimum of security and a easy way to manage this type of use case.
After that, if some resources have the skills that allow them to use an other method like your suggestion I can only approve it. Your solution seems to be more secure 😉

[waldekmastykarz]

What I meant with "what is the difference", is what @VelinGeorgiev brought up: if the username + app password leaks, it could do just as much damage as username + password. Using app password allows you to work around limitations of clients that don't support MFA but it doesn't work with OAuth which is the recommended (and in some cases even the only) way for applications to communicate with APIs secured with Azure AD.