Introducing Certificate-Based Authentication for Exchange Online Remote PowerShell – Webinar Q&A
Were you at our ‘Introducing Certificate-Based Authentication for Exchange Online Remote PowerShell’ session last week? You can download the on-demand webinar session here.
We were jam-packed with content and didn’t get round to answering all of your burning questions. So in no particular order, I’ll answer them now.
Certificate-Based Authentications for ExO Remote PowerShell Questions
Several people asked whether this new method will work for Azure Automation, Azure runbooks, Azure Cloud Shell, PowerShell Core, and similar. The answer is that the current version of the module requires some .NET methods for handling the certificate, therefore it only runs on Windows PowerShell, and systems that utilize it for automation.
Here’s a short guide by Justin Grote on how you can enable this in Azure Automation. For environments where you cannot run the module, you can follow the “manual” steps we demoed (more on this later).
Our next question is: “Is it possible to connect with application id and app password instead of certpath as I have had issues getting it working using cert with the error being current user does not have access to cert even though it is in the users profile directory?”
The answer here is, it depends. The module only supports certificate-based authentication currently, there is no parameter you can use to provide a client secret, and you cannot pass a token you’ve obtained programmatically. Outside of the module though, the answer is yes – as we demoed you can use any authentication method configured for the Azure AD application. Here’s an updated example that “talks” to the auth endpoint directly to obtain a token (instead of using the ADAL methods as showcased in our demo), then establishes a new PS session:
With regards to the error message mentioned above, the certificate must also be present in the “My” store for the current user, along with its private key.
When it comes to configuring the certificates, several questions were repeatedly asked, so let us re-answer them here:
- Do I need a public issued cert for this or can I use self-signed cert? Can you use a certificate from an internal CA? You can use any type of certificate, as long as you have the private key for it. Now, as we mentioned in the webinar, CNG API-authored certificates are currently not supported. In addition, some people will strongly object that self-signed certificates should only be used for testing purposes.
- Few people asked how to create a self-signed certificate for use with the module, so here’s the example cmdlet we used for the demos:
New-SelfSignedCertificate -Subject “ExOPS” -CertStoreLocation “cert:\CurrentUser\My” -KeySpec KeyExchange
Once created, you can export it via the MMC console, or you can do the whole thing via PowerShell. As mentioned on the webinar, Microsoft’s Dave Goldman has prepared a PowerShell module that automates almost all the steps you need to setup CBA for ExO PS, including the creation of a self-signed certificate.
Here’s probably a good place to remind you that only the “My” store for the current user is supported in the preview version of the module, but Microsoft is working on providing support for the “LocalMachine\My” store as well as generic certificate objects.
- What happens if the certificate or client secret expires? When this happens, you can simply renew the certificate and replace it, or create a new one. Multiple certificates or client secrets can be configured on the same Azure AD app simultaneously and each of those can be used to connect.
A question of accountability/audit trail was also asked: if there are multiple administrators, should there be an APP registration for each, or should only the certificate be added? What’s the recommendation?
There are few gotchas here, as Azure AD has some limitations with regards to capturing application logins, or restricting access. Everyone that has access to the certificate private key or knows the client secret can potentially use the application. If you want to enforce some control, the recommendation would be to use separate applications, with different certificates for each, and optionally limit use to specific computers only by preventing the export of the certificate private key. When it comes to auditing, on Exchange’s side of things the standard admin audit log controls apply, so any cmdlet you execute will result in an audit item created with the corresponding application listed (excluding Get-* cmdlets).
And since we mentioned “control” above, let’s address a few questions we received with regards to RBAC. As mentioned on the webinar, currently only the handful of Azure AD admin roles that are being “synchronized” with a corresponding role group in Exchange Online can be used for assigning permissions (see screenshot below). As the RBAC cmdlets currently do not recognize service principal objects, you cannot create custom controls, but Microsoft is working on providing support for at least some of the other built-in Role Groups. Keep an eye on this in the upcoming versions of the module.
Speaking of upcoming updates, a question was asked as to whether the Security and Compliance Center PowerShell cmdlets support CBA. Currently, only the Connect-ExchangeOnline cmdlet has the CBA-related parameters added, so connecting to the SCC endpoint is not supported. Keep in mind that much of the work that Microsoft has done to enable this is on the backend, so there’s a lot more involved than adding few parameters to a cmdlet. That said, this will be possible in the future, so keep an eye on updates for the module.
Next, we address a question about session lifetimes – “With the username and password the shell connection times out after a while and you have to re-authenticate. When you connect via a cert does it still time out after a period of time?”
The answer here is that nothing has changed in this regard, the CBA feature only relates to the way you authenticate. Once you do authenticate, the experience is pretty much the same – you get an access token valid for one hour, which needs to be renewed for longer running sessions. That said, Microsoft has introduced a bunch of improvements with regards to session handling in the V2 module, and regardless of the type of authentication used the access token will be renewed and sessions will reconnect automatically. So, overall, you should be seeing an improvement.
Similar to the above, we received a question about adapting old scripts to use CBA: “If I have Scripts that are running on the Version 1 of the Online Connector can I use them as well if do just change the connection with the certificate on the new version or do I need to adapt them are there any cmdlets no longer available?”
The answer here is that the newly introduced functionality only relates to authentication, once you establish the session everything should work as before. However, we would still advise some caution on that front, as there have been numerous changes made on the backend in order to adapt the new “run in application context” model. During the private preview, multiple issues with existing cmdlets were identified and fixed, but keep in mind that the new bits are still in preview, so the occasional bug might pop up.
CBA for Office 365/Azure AD
A couple of questions revolved around the use of Certificate-Based Authentication for Office 365/Azure AD, generally not related to Exchange Online Remote PowerShell. While Azure AD doesn’t natively support CBA for user logins, it has always been possible to leverage CBA by means of redirecting the authentication process to an on-premises AD FS farm. Over the years, some workarounds have been introduced to handle scenarios such as ActiveSync. The advent of Modern authentication expanded CBA to additional clients or workloads. The same goes for using certificates as a secondary authentication, using other methods of primary authentication, and so on. You can refer to the official documentation if you are interested in such scenarios.
Another participant asked whether resource mailboxes, such as room and equipment mailboxes, should be configured to leverage cert-based authentication?
The answer to the previous question applies here as well. Just to reiterate, the new features shown on the webinar were specific to Exchange Online Remote PowerShell, and specifically for running it in the context of an application/service principal. As for resource mailboxes, you shouldn’t be logging in directly to them. And in case the question in the context of Room systems and such, it’s up to the corresponding vendors to support such capabilities.
Thank you again for attending the webinar. If you missed it, you can watch it on-demand.