Cli-microsoft365: Bug report: Unable to use the certificateBase64Encoded for M365 login

[pmatthews05]

Description

Tying to pass the certificateBase64Encoded instead of a certificate file. Using PowerShell.
I have grabbed latest version of M365 cli V3.3.0

Looking through the code, the login.ts file shows --certificateBase64Encoded as an option.
https://github.com/pnp/cli-microsoft365/blob/0dbd08d45ca95fcb755de52ed572ebc87c19ff3d/src/m365/commands/login.ts#L154

However, when I view the help file
m365 login --help

There are no option for the certificateBase64Encoded.

It's as if I'm not loading the latest version of M365 cli even though it's states it's the latest.

m365 login -h

login

Log in to Microsoft 365

Usage

sh
m365 login [options]

Options

-h, --help
: output usage information

-t, --authType [authType]
: The type of authentication to use. Allowed values certificate,deviceCode,password,identity. Default deviceCode

-u, --userName [userName]
: Name of the user to authenticate. Required when authType is set to password

-p, --password [password]
: Password for the user. Required when authType is set to password

-c, --certificateFile [certificateFile]
: Path to the file with certificate private key. Required when authType is set to certificate

--thumbprint [thumbprint]
: Certificate thumbprint. Required when authType is set to certificate

--query [query]
: JMESPath query string. See http://jmespath.org/ for more information and examples

-o, --output [output]
: Output type. json,text. Default text

--verbose
: Runs command with verbose logging

--debug
: Runs command with debug logging

Remarks

Using the login command you can log in to Microsoft 365.

By default, the login command uses device code OAuth flow to log in to Microsoft 365. Alternatively, you can authenticate using a user name and password or certificate, which are convenient for CI/CD scenarios, but which come with their own limitations. See the CLI for Microsoft 365 manual for more information.

When logging in to Microsoft 365, the login command stores in memory the access token and the refresh token. Both tokens are cleared from memory after exiting the CLI or by calling the logout (logout.md) command.

When logging in to Microsoft 365 using the user name and password, next to the access and refresh token, the CLI for Microsoft 365 will store the user credentials so that it can automatically re-authenticate if necessary. Similarly to the tokens, the credentials are removed by re-authenticating using the device code or by calling the logout (logout.md) command.

When logging in to Microsoft 365 using a certificate, the CLI for Microsoft 365 will store the contents of the certificate so that it can automatically re-authenticate if necessary. The contents of
the certificate are removed by re-authenticating using the device code or by calling the logout (logout.md) command.

To log in to Microsoft 365 using a certificate, you will typically create a custom Azure AD application. To use this application with the CLI for Microsoft 365, you will set the CLIMICROSOFT365_AADAPPID environment variable to the application's ID and the CLIMICROSOFT365_TENANT environment variable to the ID of the Azure AD tenant, where you created the Azure AD application.

Managed identity in Azure Cloud Shell is the identity of the user. It is neither system- nor user-assigned and it can't be configured. To log in to Microsoft 365 using managed identity in Azure Cloud Shell, set authType to identity and don't specify the userName option.

Examples

Log in to Microsoft 365 using the device code

sh
m365 login

Log in to Microsoft 365 using the device code in debug mode including detailed debug information in the console output

sh
m365 login --debug

Log in to Microsoft 365 using a user name and password

sh
m365 login --authType password --userName [email protected] --password pass@word1

Log in to Microsoft 365 using a PEM certificate

sh
m365 login --authType certificate --certificateFile /Users/user/dev/localhost.pem --thumbprint 47C4885736C624E90491F32B98855AA8A7562AF1

Log in to Microsoft 365 using a personal information exchange (.pfx) file

sh
m365 login --authType certificate --certificateFile /Users/user/dev/localhost.pfx --thumbprint 47C4885736C624E90491F32B98855AA8A7562AF1 --password 'pass@word1'

Log in to Microsoft 365 using a system assigned managed identity. Applies to Azure resources with managed identity enabled,
such as Azure Virtual Machines, Azure App Service or Azure Functions

sh
m365 login --authType identity

Log in to Microsoft 365 using managed identity in Azure Cloud Shell. Uses the identity of the current user.

sh
m365 login --authType identity

Log in to Microsoft 365 using a user-assigned managed identity. Client id or principal id also known as object id value can be specified in the userName option. Applies to Azure resources with managed identity enabled, such as Azure Virtual Machines, Azure App Service or Azure Functions

sh
m365 login --authType identity --userName ac9fbed5-804c-4362-a369-21a4ec51109e

Steps to reproduce

View the help file of m365 Login doesn't give you the option.
m365 login --help

Also attempted of just calling the command.
m365 login --authType certificate --certificateBase64Encoded $certValue --thumbprint $certthumbprint

I have also uninstalled the npm package and reinstalled again. Still same problem.

Expected result

To be able to log in using CertificateBase64Encoded value, and should be able not use the thumbprint any more.

Actual result

Error: Invalid option: 'certificateBase64Encoded'

Environment

PowerShell/ Windows

[waldekmastykarz]

This option is available in the latest beta, which you can install with npm i -g @pnp/cli-microsoft365@next. It will released as v3.4.0 in the first week of January '21.

[pmatthews05]

Thank you for your quick answer, and yes I have now tested with the @next version without any problems.

I've just seen the "tag" on branches, I will make sure I'm looking at the right branch in future. I thought master was the latest released.

Slowly understanding and learning Node with your code. Awesome work.

[waldekmastykarz]

Great to hear you got it to work. Is there anything that we could clarify in our docs to make this more explicit?

[pmatthews05]

My experience when learning how to use M365 cli is to go directly to your documents to understand how the commands work. So today for example I went to https://pnp.github.io/cli-microsoft365/cmd/login/ to understand different ways you could log in. I would have thought that these instructions should show the currently released version, not the beta version.

I'm afraid I don't know enough of how https://pnp.github.io/cli-microsoft365/ ties to the github source code, but can it not point to the latest tagged version branch, and then repoint to the next tagged version branch on release? Or is it possible to have a version switcher like the Beta and 1.0 graph API does?
https://docs.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0

[garrytrinder]

Thanks for the feedback @pmatthews05 👍🏻

We can look at adding a version switch to our docs, we use MkDocs Material and that has this capability now, essentially this would version our docs creating a lockdown copy for every version we release.

https://squidfunk.github.io/mkdocs-material/setup/setting-up-versioning/

[pmatthews05]

Lockdown version docs would also be good for people that cannot always update to the latest version. But need to extend an existing piece of code and need to check documentation.

Thanks.

[garrytrinder]

Would you mind creating a new issue, so we can credit you with the feedback and discuss it further?

It's not quite a simple as upgrading MkDocs, we also have to think about our integration with MarkShell which we use to display the docs in the CLI --help command, certainly not impossible though.

[pmatthews05]

Sure, I will raise a new issue first thing in the morning.

[waldekmastykarz]

It's not quite a simple as upgrading MkDocs, we also have to think about our integration with MarkShell which we use to display the docs in the CLI --help command, certainly not impossible though.

I think this is the easy part. The docs shipped with the CLI package reflect exactly what's available to you in that particular version. It's the docs available on the web that are causing confusion because it's not clear that they reflect the @next version of the CLI.