%3CLINGO-SUB%20id%3D%22lingo-sub-1497387%22%20slang%3D%22en-US%22%3EModern%20Auth%20and%20Unattended%20Scripts%20in%20Exchange%20Online%20PowerShell%20V2%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1497387%22%20slang%3D%22en-US%22%3E%3CP%3EToday%2C%20we%20are%20happy%20to%20announce%20the%20Public%20Preview%20of%20a%20Modern%20Auth%20unattended%20scripting%20option%20for%20use%20with%20-ERR%3AREF-NOT-FOUND-Exchange%20Online%20PowerShell%20V2.%20This%20feature%20provides%20customers%20the%20ability%20to%20run%20non-interactive%20scripts%20using%20Modern%20Authentication.%20This%20feature%20requires%20version%202.0.3-Preview%20or%20later%20of%20the%20EXO%20PowerShell%20V2%20module%2C%20available%20via%20%3CA%20href%3D%22https%3A%2F%2Fwww.powershellgallery.com%2Fpackages%2FExchangeOnlineManagement%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EPowerShellGallery%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3ECheck%20out%20the%20detailed%20guide%20on%20how%20to%20install%2Fupdate%20the%20new%20EXO%20PowerShell%20V2%20Module%20%3CA%20href%3D%22https%3A%2F%2Faka.ms%2Fexops-docs%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehere%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3EAs%20previously%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fexchange-team-blog%2Fbasic-authentication-and-exchange-online-april-2020-update%2Fba-p%2F1275508%22%20target%3D%22_blank%22%20rel%3D%22noopener%22%3Eannounced%3C%2FA%3E%2C%20Basic%20Authentication%20for%20Exchange%20Online%20Remote%20PowerShell%20will%20be%20retired%20in%20the%20second%20half%20of%202021.%20Customers%20who%20currently%20use%20Exchange%20Online%20PowerShell%20cmdlets%20in%20unattended%20scripts%20should%20switch%20to%20adopt%20this%20new%20feature.%20This%20new%20approach%20uses%20AzureAD%20applications%2C%20certificates%20and%20Modern%20Authentication.%20You%20can%20find%20detailed%20step-by-step%20instructions%20available%20%3CA%20href%3D%22https%3A%2F%2Faka.ms%2Fexops-apponly%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehere%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3EIt%E2%80%99s%20simple%20to%20create%20and%20use%20sessions%20using%20this%20new%20feature.%20For%20example%2C%20if%20you%20are%20currently%20using%20Basic%20Authentication%20for%20unattended%20scripting%2C%20you%20are%20probably%20using%20something%20like%20this%20in%20your%20scripts%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-applescript%22%3E%3CCODE%3ENew-PSSession%20-ConfigurationName%20Microsoft.Exchange%20-ConnectionUri%20https%3A%2F%2Foutlook.office365.com%2Fpowershell-liveid%2F%20-Credential%20%24UserCredential%20-Authentication%20Basic%20-AllowRedirection%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EOnce%20you%20have%20changed%20to%20Certificate%20Based%20Authentication%2C%20the%20above%20cmdlet%20pattern%20will%20need%20to%20be%20changed%20to%20use%20%3CEM%3EConnect-ExchangeOnline%3C%2FEM%3E%20along%20with%20other%20necessary%20parameters.%20For%20example%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-applescript%22%3E%3CCODE%3EConnect-ExchangeOnline%20-CertificateFilePath%20%22C%3A%5CUsers%5Cjohndoe%5CDesktop%5Cautomation-cert.pfx%22%20-AppID%20%22alpha-beta-gamma-123456%22%20-Organization%20%22contosoelectronics.onmicrosoft.com%22%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EPlease%20note%20the%20feature%20does%20not%20support%20delegation.%20Unattended%20scripting%20in%20delegation%20scenarios%20is%20supported%20with%20the%20Secure%20App%20Model%20which%20is%20documented%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fpowershell%2Fpartnercenter%2Fmulti-factor-auth%3Fview%3Dpartnercenterps-3.0%23exchange%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehere%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3EWe%20hope%20this%20new%20feature%20makes%20it%20possible%20for%20you%20to%20move%20away%20from%20using%20Basic%20Authentication%20for%20your%20unattended%20scripting%20needs%20and%20appreciate%20the%20increased%20security%20this%20new%20option%20provides.%20Please%20do%20give%20us%20feedback%2C%20we%20really%20do%20want%20to%20hear%20what%20you%20think.%3C%2FP%3E%0A%3CP%3E%3CFONT%20color%3D%22%23FF6600%22%3EThe%20Exchange%20Team%3C%2FFONT%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1497387%22%20slang%3D%22en-US%22%3E%3CP%3EToday%2C%20we%20are%20happy%20to%20announce%20the%20Public%20Preview%20of%20a%20Modern%20Auth%20unattended%20scripting%20option%20for%20use%20with%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fexchange-team-blog%2Fannouncing-general-availability-of-the-exchange-online%2Fba-p%2F1436623%22%20target%3D%22_blank%22%3EExchange%20Online%20PowerShell%20V2%3C%2FA%3E.%20This%20feature%20provides%20customers%20the%20ability%20to%20run%20non-interactive%20scripts%20using%20Modern%20Authentication.%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1497387%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAdministration%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3Eall%20posts%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EAnnouncements%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EExchange%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EExchange%20Online%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EScripting%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ESecurity%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1499553%22%20slang%3D%22en-US%22%3ERe%3A%20Modern%20Auth%20and%20Unattended%20Scripts%20in%20Exchange%20Online%20PowerShell%20V2%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1499553%22%20slang%3D%22en-US%22%3E%3CP%3EGreat%20News!%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWill%20this%20work%20with%20Exchange%20RBAC%20roles%20(custom%20roles)%20or%20only%20with%20Azure%20default%20service%20roles%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1500299%22%20slang%3D%22en-US%22%3ERe%3A%20Modern%20Auth%20and%20Unattended%20Scripts%20in%20Exchange%20Online%20PowerShell%20V2%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1500299%22%20slang%3D%22en-US%22%3E%3CP%3EGreat%20News.%20A%20Welcome%20Addition%20!%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBut%20I%20was%20reading%20the%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fpowershell%2Fexchange%2Fapp-only-auth-powershell-v2%3Fview%3Dexchange-ps%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fpowershell%2Fexchange%2Fapp-only-auth-powershell-v2%3Fview%3Dexchange-ps%3C%2FA%3E%26nbsp%3Barticle%20Friday%20which%20made%20no%20suggestion%20this%20is%20a%20public%20preview%20...%20maybe%20worth%20flagging%20on%20there%20in%20case%20folks%20come%20across%20that%20link%20without%20reading%20this%20blog%20post.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1500807%22%20slang%3D%22en-US%22%3ERe%3A%20Modern%20Auth%20and%20Unattended%20Scripts%20in%20Exchange%20Online%20PowerShell%20V2%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1500807%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20is%20great%20with%20one%20slight%20amendment%20on%20the%20command...%20The%20AppID%20needs%20to%20be%20the%20Registered%20Apps%20AppID%20GUID%20not%20its%20displayname...%20Otherwise%20it%20does%20not%20locate%20the%20registered%20app%20in%20the%20target%20tenant...%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1502389%22%20slang%3D%22en-US%22%3ERe%3A%20Modern%20Auth%20and%20Unattended%20Scripts%20in%20Exchange%20Online%20PowerShell%20V2%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1502389%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20installation%20path%20for%202.0.3-preview%20has%20been%20changed%20to%20%25UserProfile%25%5CDocuments%5CWindowsPowerShell%5CModules%5CExchangeOnlineManagement.%20Compared%20to%20the%20GA%20version%2C%20it%20is%20C%3A%5CProgram%20Files%5CWindowsPowerShell%5CModules%5CExchangeOnlineManagement.%3C%2FP%3E%3CP%3EIs%20this%20a%20permanent%20change%20or%20just%20for%20the%20preview%20version%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1501719%22%20slang%3D%22en-US%22%3ERe%3A%20Modern%20Auth%20and%20Unattended%20Scripts%20in%20Exchange%20Online%20PowerShell%20V2%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1501719%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F311758%22%20target%3D%22_blank%22%3E%40JamesIII%3C%2FA%3E%26nbsp%3B-%20We%20are%20only%20supporting%20Exchange%20Built-in%20roles%20which%20are%20available%20in%20AAD%20as%20those%20are%20the%20ones%20which%20can%20be%20assigned%20to%20an%20AAD%20App.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F55238%22%20target%3D%22_blank%22%3E%40Jamie%20BRANDWOOD%3C%2FA%3E%26nbsp%3B-%20Thanks%20for%20the%20note.%20This%20has%20been%20corrected%20and%20docs%20changes%20should%20reflect%20in%20few%20hours.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F35440%22%20target%3D%22_blank%22%3E%40Paul%20Westlake%3C%2FA%3E%26nbsp%3BYou%20are%20right%20and%20that's%20what%20we%20intend%20to%20tell%20with%20the%20parameter%20name.%20Name%20is%20generally%20not%20considered%20as%20unique%20and%20hence%20GUID%20will%20be%20the%20one%20to%20use.%20We%20will%20call%20it%20out%20explicitly%20in%20example.%3C%2FP%3E%3C%2FLINGO-BODY%3E

Today, we are happy to announce the Public Preview of a Modern Auth unattended scripting option for use with Exchange Online PowerShell V2. This feature provides customers the ability to run non-interactive scripts using Modern Authentication. This feature requires version 2.0.3-Preview or later of the EXO PowerShell V2 module, available via PowerShellGallery.

Check out the detailed guide on how to install/update the new EXO PowerShell V2 Module here.

As previously announced, Basic Authentication for Exchange Online Remote PowerShell will be retired in the second half of 2021. Customers who currently use Exchange Online PowerShell cmdlets in unattended scripts should switch to adopt this new feature. This new approach uses AzureAD applications, certificates and Modern Authentication. You can find detailed step-by-step instructions available here.

It’s simple to create and use sessions using this new feature. For example, if you are currently using Basic Authentication for unattended scripting, you are probably using something like this in your scripts;

 

New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

 

Once you have changed to Certificate Based Authentication, the above cmdlet pattern will need to be changed to use Connect-ExchangeOnline along with other necessary parameters. For example:

 

Connect-ExchangeOnline -CertificateFilePath "C:\Users\johndoe\Desktop\automation-cert.pfx" -AppID "alpha-beta-gamma-123456" -Organization "contosoelectronics.onmicrosoft.com"

 

Please note the feature does not support delegation. Unattended scripting in delegation scenarios is supported with the Secure App Model which is documented here.

We hope this new feature makes it possible for you to move away from using Basic Authentication for your unattended scripting needs and appreciate the increased security this new option provides. Please do give us feedback, we really do want to hear what you think.

The Exchange Team

21 Comments
Frequent Visitor

Great News!

 

Will this work with Exchange RBAC roles (custom roles) or only with Azure default service roles?

Occasional Contributor

Great News. A Welcome Addition !

 

But I was reading the https://docs.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps article Friday which made no suggestion this is a public preview ... maybe worth flagging on there in case folks come across that link without reading this blog post.

Occasional Contributor

This is great with one slight amendment on the command... The AppID needs to be the Registered Apps AppID GUID not its displayname... Otherwise it does not locate the registered app in the target tenant... 

Microsoft

@JamesIII - We are only supporting Exchange Built-in roles which are available in AAD as those are the ones which can be assigned to an AAD App.

 

@Jamie BRANDWOOD - Thanks for the note. This has been corrected and docs changes should reflect in few hours.

 

@Paul Westlake You are right and that's what we intend to tell with the parameter name. Name is generally not considered as unique and hence GUID will be the one to use. We will call it out explicitly in example.

Senior Member

The installation path for 2.0.3-preview has been changed to %UserProfile%\Documents\WindowsPowerShell\Modules\ExchangeOnlineManagement. Compared to the GA version, it is C:\Program Files\WindowsPowerShell\Modules\ExchangeOnlineManagement.

Is this a permanent change or just for the preview version?

Contributor

@victorguo If you install the module with -Scope CurrentUser, it will go into %UserProfile%, while if you don't do it that way, it will install system-wide into Program Files.  It's a PowerShell / modules thing, but not anything exclusive to this module.

 

So happy to see this preview go live.

Regular Visitor

This is great Addition and will help to run auto script scheduler... hope it works with Azure Automation...

Senior Member

YOU MUST NOT USE CNG CERTIFICATES, for some bizarre reason there's no support for it in this module, and that is the default type of certificate created/imported by Windows 10

 

When generating your cert use New-SelfSignedCertificate -KeySpec KeyExchange to force a csp provider.


if you see

New-EXOPSSession : Invalid Provider Type Specified

as an error, this is your problem. I wasted several hours, would have been nice to know...

 

Also, it doesn't work in Azure Automation, which is where a lot of Exchange Tests run, throws a network dll error, you would think it would have been tested...

 

 

Contributor

@JGrote I see "New-EXOPSSession".  Could it be that you mean to be using Connect-ExchangeOnline instead?  I was doing some digging to see if I could find an answer about OAuth or JWT's requiring the KeySpec to be Signature, because most examples I see from docs.microsoft.com show the New-SelfSignedCertificate command having "-KeySpec Signature", so that's what I've always used.  But now I've done a test, and can confirm I'm able to connect using both a KeySpec = KeyExchange cert and KeySpec = Signature cert.

 

I create my self-signed certificate from Windows 10 and have pure success for both ways.  I just updated my New-SelfSignedAzureADAppRegistrationCertificate function (link to containing module), giving it a new parameter -KeySpec [Signature|KeyExchange] so I could test.   Both work fine for me from Windows 10 / Windows PowerShell 5.1, and in Azure Automation.

 

Maybe you're provider has a typo?

 

Last thing, I checked the script file Create-SelfSignedCertificate.ps1 and see that it actually uses KeyExchange for the key spec (1 = KeyExchange, 2 = Signature):

 

$key = new-object -com "X509Enrollment.CX509PrivateKey.1"
    $key.ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
    $key.KeySpec = 1
    $key.Length = 2048 
    $key.SecurityDescriptor = "D:PAI(A;;0xd01f01ff;;;SY)(A;;0xd01f01ff;;;BA)(A;;0x80120089;;;NS)"
    $key.MachineContext = 1
    $key.ExportPolicy = 1 # This is required to allow the private key to be exported
    $key.Create()

So with all of this, I don't think the module has an issue with KeySpec = KeyExchange for the self-signed certificate being used.

 

UPDATE:  And ahhh, just like that, I am now seeing what you mean.  It's that if you DON'T specify -KeySpec Signature OR KeyExchange with the New-SelfSignedCertificate cmdlet, it will default to None and yada yada ==> CNG.  Figured that out here - https://docs.microsoft.com/en-us/powershell/module/pkiclient/new-selfsignedcertificate?view=win10-ps

 

So now I get your point.  Windows 10's New-SelfSignedCertificate by default will create a non-working cert for us if we don't know better to take charge with the -KeySpec parameter.

 

Senior Member

@Jeremy Bradshaw try it with Keyexchange none. Both the keyexchanges you specified force a CSP certificate, not a CNG certificate.

Contributor

@JGrote I tried to update my post to show that I get what you mean now.  Just realized I put the update in the middle of my original message.  Will fix that, then delete this one.

 

It's a valid point you raised.  I think the step by step guide on docs could stand to be updated to clarify this issue to lookout for, but in their defense, they show using the downloadable script to create the self-signed cert, and it sets KeySpec to KeyExchange, so if people follow their guide, they should be good to go.

Occasional Visitor

Trying to get this working, Unfortunately, I end up with New-ExoPSSession : No certificate found for the given CertificateThumbprint
I am assuming that the cause is that the certificate is in the personal folder for the local machine (because the account using the script will be a service account) any ideas how I can redirect the module to search the local machine compartment? 

Occasional Visitor

Is there plans to support authenticating directly with access/refresh tokens like most of the new Azure/O365 cmdlets support?

Senior Member

I made a GistBlog about how to add this to your Azure Automation RunAs account
https://gist.github.com/JustinGrote/832cc64cb22f062f4ee2663bd7427515/

Occasional Visitor

A  was If i try it after putting the very into a personal store it doesn’t return an error burn it still opens the sign-in dialog IE requiring interaction, Which is useless given the point is automation. Anyone else run into this?

 

UPDATE: it’s working now I had a blank thumbprint

Contributor

I've something to split hairs over.  It is the "-AppId" and "-Organization" parameters.  I feel like it would be better to make them "-ApplicationId", and "-TenantId".  Between Connect-AzureAD, Connect-AzAccount, Connect-PartnerCenter, the list goes on, they all have "-ApplicationId" and they have "-TenantId" (at least as an alias to "-Tenant" if not the primary parameter name).

 

So this module is suddenly different from those other modules with "-AppId" and "-Organization".  This difference is unnecessary and bad practice (in my opinion).  It should all be nice and consistent, considering it's all for authentication to the same place, via the same method.

Microsoft

@Jeremy Bradshaw  In the Organization parameter, we expect the tenant name to be passed and not the GUID as we have mentioned in the documentation. To avoid confusion, we explicitly chose Organization parameter instead of TenantId. Tenant ID generally is used for the GUID of the tenant which doesn't work in this case as request routing doesn't happen consistently to the right backend machine.

 

@MicahRowland - Support for AccessToken is in our backlog. We don't have a committed timeline to support it yet.

Senior Member

@navgupta is there any way to resolve the tenant name from the organization GUID *without* being authenticated?

I am using this in Azure Automation and I can get the tenant ID of the principal from the get-automationconnection, and I can use that with every app except Exchange, however to authenticate to azure just to resolve the tenant ID to then log into exchange adds a lot of time to the login. Is there any public API to do the resolution unauthenticated?

Occasional Visitor

@navgupta I looked at the module code in Reflector and it looks like you're connecting the same way we are (connectionUri 

"https://outlook.office365.com/PowerShell-LiveID?BasicAuthToOAuthConversion=true" and U/P with the authorization header contents as the password), there's just no way to bypass the token acquisition process. I originally tried passing the same formatted creds, but it looks like you're using the OAuth Resource Owner Password Credentials grant, so when it tried to pass the auth header as the password, it returned a 'your password is too long' error

 

We're an MSP and the "control panel" product I work on is not intended to have standing access to a single exchange environment. While we could use the -Credentials route, it would require us to collect customer user/passwords, which is a no-no, so having the ability to authenticate with access tokens is critical because we can't surface an authorization code flow popup to the end user during scheduled automations. Passing a refresh token would be fine as well, which you could use to retrieve the access token you need to connect and maintain access in the tokencache

Microsoft

Hey everyone! I created the PSServicePrincipal PowerShell module that is a helper module that will reduce the onboarding steps for Certificate Based Authentication to just to a few steps and you can do that from PowerShell command line itself. To fully automate this you must have sufficient permissions to register an application with your Azure AD tenant. The module will handle the creation of the service principal / application, certificate (local and Azure) and set the correct Exchange unattended application permissions. All you need to do is verify a RBAC role for security and accept the settings. You can download the module from the PowerShell Gallery here. The full help file can be found here.

Senior Member

@Dave Goldman  nice work! I'll add it to my article, I was going to write something similar but you saved me the trouble :)