In this post, I focus on Exchange Online PowerShell as the client used for administration. In the past, it was used with Basic authentication as that was the only available authentication option. But that has changed, and the article Understanding the Different Versions of Exchange Online PowerShell Modules and Basic Auth tells you the whole story. What I would like to highlight is that the latest v3 module has been available for some months now and it replaces older Exchange Online PowerShell modules you might be using. v3 can be installed side-by-side with older versions to allow you to quickly fallback if something goes wrong. One nice feature of the v3 module is that it eliminates the "client machine WinRM Basic Authentication" dependency that is considered a security risk by some. Prior to the introduction of the v3 module, disabling Basic authentication for WinRM (About the Exchange Online PowerShell V2 module and V3 module) would break Exchange Online PowerShell functionality.
Using Modern authentication for interactive logons is easy; just install the Exchange Online PowerShell v3 Module and start your connection login through the Modern authentication dialog and you are done. So, the Azure AD sign-in logs won’t include interactive admin user authentication anymore.
If you still see those logins listed, the cause might be that in addition to the interactive logon, Exchange Online PowerShell is often used in automation scripts with service accounts. These service accounts might still be using Basic authentication to connect to Exchange Online as interactive logon doesn't work in that scenario.
There is a small caveat here; using an Azure AD app-only configuration is tied to Exchange Online and Azure roles as shown below. This is great for most of the requirements you might have. For example, it allows the Exchange Administrator role assignment for a complete management access, or Exchange Recipient Administrator with the scope of Mail User Administrator and even Global Reader, which allows read-only access through the configured app.
In the past, customers using the concept of least privilege access often created customized Exchange Online admin roles, and haven´t been able to use the listed roles which would have extended today’s permissions for administrator or service accounts.
In most cases service accounts are used for non interactive logon scenarios. Moving this daemon use cases from today’s basic authentication to modern authentication implies the usage of Exchange Online certificate-based authentication. If the RBAC role permissions were needed, these service accounts couldn't be moved away from Basic authentication.
First, I create a custom RBAC role in Exchange Online as I’ve done in the past. In my example, it is a view-only role that can run only Get-Mailbox and no other cmdlets. I connect to Exchange Online PowerShell as an Organization Admin and create a new role based on the given default role View-Only Recipients and assign this new role to a role group to allow easy role assignment to a user or an Azure AD app.
Next, I connect the dots and assign the new role to the Azure AD application and then verify the admin permissions and available cmdlets. This is where a new cmdlet, New-ServicePrincipal can be used.
For further configuration, I need some details from the registered Azure AD App, so I am using Get-AzureADServicePrincipal in the AzureAD PowerShell module to get the needed information for using the New-ServicePrincipal with the right values. Dealing with Azure AD applications and service principals means dealing with a lot of different GUIDs, so make sure to use the right ones.
The new service principal is used in Exchange Online to grant permission to access mailboxes (using the Identity/ServiceId of the service principal and not the AppId).
After I’ve created the anchor object for the Azure AD application in Exchange Online, I assign a custom RBAC role to the service principal:
Add-RoleGroupMember -Identity "ViewOnlyRecipients4CBA-Stripped" -Member Identity/ServiceId of the Service principal.
Next, I connect using Exchange Online PowerShell with the configured certificate to verify that the session enables only the Get-Mailbox cmdlet. In the past, I would have used Get-PSSession to check for available cmdlets. In the v3, module Get-ConnectionInformation is used and produces output like this:
Thanks to Namrata Gupta, Pallavi Prashanth, Nino Bilic and Greg Taylor for quickly helping me with early feedback and testing options.