I’ve just added two new scripts to my Office365 repository on GitHub. One connects PowerShell to SharePoint Online using PnP PowerShell. The other connects to Exchange Online. Both run on Linux, and both use certificate-based, app-only authentication. There’s no browser, no typed password and no MFA prompt at connection time.
Why bother building Linux versions? Mostly because of agents.
Built for machines that nobody is sitting at
More and more of my admin work now gets done by autonomous agents like Grok Bot, running on a Linux computer that no person is logged into. An agent like that can write and run PowerShell happily enough. Where it gets stuck is sign-in. A pop-up browser window, a device code that someone has to type in, or an MFA approval on a phone all stop it in its tracks. Automation that needs a human to tap “approve” isn’t really automation.
Certificate-based app-only authentication fixes that. You register an app in Entra, upload the public half of a certificate, keep the private key on the machine, and the script connects as the app. I’ve covered the Windows side before in Certificate-Based Authentication for SharePoint Online: The Bit Everyone Avoids and A Cleaner Way to Connect PowerShell to Exchange Online. These new scripts are the Linux counterparts, built so an agent’s computer can connect and get on with the job unattended.
What the scripts do
Both scripts work the same way and have two main modes:
- -GenerateLocalCertificate creates an RSA-2048/SHA256 certificate, a public .cer file and an encrypted .pfx using .NET, so you don’t need OpenSSL.
- -UseCertificateAuth connects with the encrypted PFX: PnP.PowerShell for SharePoint, ExchangeOnlineManagement for Exchange.
- -ProvisionEntraApp (optional) creates or reuses an Entra app, uploads the public certificate, grants the required permissions and saves a connection profile. This setup step uses a one-off device-code sign-in by an administrator.
For true headless runs, use -noprompt (alias -Headless). Supply the PFX password through a SecureString parameter, or name an environment variable with -CertificatePasswordEnvironmentVariable. The scripts never print or save that password. Saved profiles mean that, once set up, an agent can connect with little more than -UseCertificateAuth -ProfileName Contoso -Headless.
You’ll need Linux and PowerShell 7.4 or later (7.4.6+ for the PnP script), plus PnP.PowerShell 3.0.0+ or ExchangeOnlineManagement 3.5.0+. Missing modules install for the current user, with no sudo needed. Use -noupdate to skip update checks.
A word on security
Unattended access is powerful, so treat it with respect. The SharePoint provisioning grants Sites.FullControl.All, which means full control of every site. The Exchange provisioning grants Exchange.ManageAsApp and adds the app to Organization Management, which means full Exchange administration. The scripts keep certificates and profiles in dedicated folders locked to mode 700, with files at mode 600, and they refuse symbolic links there. Even so, that .pfx is effectively an admin key. Guard it, keep its password in a vault or a protected environment variable, and only put it on machines you trust. If your scenario needs less, trim the app’s permissions.
Get the scripts
- SharePoint (PnP): o365-connect-pnp-cert-linux.ps1, documentation
- Exchange Online: o365-connect-exo-cert-linux.ps1, documentation
To me, this is where Microsoft 365 administration is heading. More of the routine work will be done by agents on machines that nobody watches, and the bottleneck is getting them connected securely without a human in the loop. Take the scripts, try them in a test tenant, and let me know how you go.
