Connect to Exchange Online PowerShell with Connect-ExchangeOnline cmdlet and a service principal with client secret

Connecting to Azure with a service principal with client secret is quite simple - you can get the credentials and pass them to the Connect-AzAccount cmdlet and specify the -ServicePrincipal parameter.  

$credential = Get-Credential
Connect-AzAccount -Credential $credential -TenantId "your-tenant-identifier" -ServicePrincipal 


Connecting to Exchange Online however is somewhat more problematic - there is no "ServicePrincipal" parameter and using the cmdlet with just a credential and organization shows the following error.

The user is not recognized as a managed user, or a federated user.Azure AD was not able to identify the IdP that needs to process the user U/P: Wrong username

It looks like Microsoft haven't implemented the ability to use client secrets as they're not as secure as certificates (and the Connect-ExchangeOnline cmdlet has good support for certficiates).

Microsoft doesn't appear to have implemented any of their online services with any kind of consistency.

The cmdlets are all using the Microsoft Authentication Library (MSAL) under the hood which in turn creates and posts a message to the login.microsoftonline.com to generate a JWT (JSON Web Token) also seen as a bearer token so you can do this directly yourself bypassing the cmdlets and MSAL.


$clientId = "your-service-principal-app-identifier"
$clientSecret = "your-client-secret" 
$tenantId = "your-tenant-id" 

$tokenBody = @{ 

    Grant_Type    = "client_credentials" 

    Scope         = "https://outlook.office365.com/.default"

    Client_Id     = $clientId 

    Client_Secret = $clientSecret 

}  

 

$tokenResponse = Invoke-RestMethod -Uri https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token -Method POST -Body $tokenBody 

You can then pass this bearer (JWT) token to the Connect-ExchangeOnline cmdlet using the AccessToken parameter

Connect-ExchangeOnline -AccessToken $tokenResponse.access_token -Organization "your-organization-name.onmicrosoft.com"; 


You still need to use the Exchange PowerShell cmdlets rather than access the REST API directly because 

  • The REST API isn't public 

  • The REST API is in BETA (and presumable the PowerShell cmdlets will switch to production when a production API is available)

  • The REST API is not a proper REST API - if you look at the endpoint the say the Get-AddressList cmdlet is called you'd expect something like GET /AddressLists - however all the cmdlets that don't start with Get-EXO* actually sent a command to this one /InvokeCommand address

    https://outlook.office365.com/adminapi/beta/identifier/InvokeCommand

    The inside of the message posted to this address is some JSON that includes the cmdlet being run. This is pretty poor.

    {"CmdletInput":{"CmdletName":"Get-AddressList","Parameters":{}}}





Comments

Post a Comment

Popular posts from this blog

Windows Server 2016, 2019, 2022, Windows 10 and Windows 11: Date and time "Some settings are managed by your organization".

Image
When you're using the new "Modern" date and time settings in Windows Server 2016, 2019, 2022, Windows 10 and Windows 11 you may find that you can't set the correct date and time and the value "Some settings are managed by your organization". - While you're here - Why not check out our Windows Server Documentation and Audit Tool? The simplest way around this is to go back to the proper control panel using Start, Run, "Control.exe" and searching for "Set the date".  Within here you can set the date and time manually as required If you try and click the Change time zone button you may again get access denied... To resolve this open an elevated command prompt by right clicking the command prompt and selecting Run as Administrator  From there run the command rundll32.exe shell32.dll,Control_RunDLL timedate.cpl This will open the Data and Time control panel app elevated as an Administrator.
Read more

TFTPD32 or TFTPD64 reports Bind error 10013 An attempt was made to access a socket in a way forbidden by its access permissions.

Image
When you start the trivial FTP (TFTP) server application TFTPD32 or TDTPD64 you may see the following error Bind error 10013 An attempt was made to access a socket in a way forbidden by its access permissions. This can be because another application is using this port. The easiest way to check if (and which) application is using the port is as administrator run an elevated command prompt and enter netstat -anb > ports.txt Then open ports.txt in Notepad and search for :69, you'll quickly be able to see the process using the required port - While you're here - Why not check out our Windows Server Documentation and Audit Tool?
Read more

Enable function lock for F1-F12 on HP ZBook mobile workstations

Image
When you press the function keys on a HP ZBook mobile workstation you may find that they don't operate as expected. This is because of function lock, if you hold the fn key the function keys work as expected. You can lock the function keys on as described in this document. https://support.hp.com/gb-en/document/c02035108 However there are two things to note Firstly following a BIOS upgrade (which occurs automatically if you have the preinstalled HP software still installed) you may lose your locked function keys and have to reapply.   Secondly the HP documentation states you press the fn lock and fn keys at the same time as per the image below from the page.  While you're here - Why not check out our Windows Server Documentation and Audit Tool? This is not the case, you need to press and hold the fn key, and then tap the fn lock key to toggle function lock, not an obvious thing when you start work first thing in the morning and are hammering the function keys try
Read more