I want to connect to Exchange Online using PowerShell and modern authentication without depending on any modules or dll's.
There's a module available for modern authentication to Exchange Online that depends on the CreateEXOPSSession.ps1 and Microsoft.Exchange.Management.ExoPowerShellModule.dll, I have decompiled the latter and found that it generates an access token as such:
TokenInformation accessToken = TokenProviderFactory.Instance.CreateTokenProvider(new TokenProviderContext(authType, "a0c73c16-a7e3-4564-9a95-2bdf47383716", this.AzureADAuthorizationEndpointUri, acquireTokenEndpoint, this.UserPrincipalName, this.Credential, clientAppRedirectUri, (Action<string>) (s => this.WriteWarning(s)))).GetAccessToken();
I want to request the access token is the same way in PowerShell but I can't seem to get the right authentication context and method of retrieving the access token.
Any ideas?
You have to have an MSOL connection and create a remote session to EXO to use EXO cmdlets. There is no workaround for this.
The dependencies are there for a reason. The backend plumbing of MSOL / Azure / O365 expects what it expects, and skirting it will just lead you down a very frustrating/hair-pulling activity.
That token is an Azure AD as MA/ADAL requires that you have an Azure AD Premium license.
MA requires use of the ADAL API/DLL. This is like asking to programmatically connect to and use Exchange on-prem EAS/EWS services without using the API/DLL, that's not a thing either.
So, no matter how you look at this, there will be dependencies, as noted below. So, if you are serious about this effort, you need to really dig into what MA really is and how it's plumbing really works. Also, MFA must be already enabled for you and users, either in O365 and or the ADAL MFA settings in Azure.
Modern Authentication – What is it?
Modern Authentication brings Active Directory Authentication Library (ADAL)-based sign-in to Office client apps across platforms.
Microsoft identity platform authentication libraries
There is also an ADAL module on the MS PowerShellGallery.com.
Microsoft.ADAL.PowerShell 1.12
ADAL module for PowerShell
https://www.powershellgallery.com/packages/Microsoft.ADAL.PowerShell/1.12
Functions
Get-ADALAccessToken Clear-ADALAccessTokenCache
Examples are here:
Microsoft.ADAL.Powershell ```
####Example 1 This example acquire accesstoken by using RedirectUri from contoso.onmicrosoft.com Azure Active Directory for PowerBI
service. It will only prompt you to sign in for the first time, or
when cache is expired.
Get-ADALAccessToken -AuthorityName contoso.onmicrosoft.com `
-ClientId 8f710b23-d3ea-4dd3-8a0e-c5958a6bc16d `
-ResourceId https://analysis.windows.net/powerbi/api `
-RedirectUri "http://yourredirecturi.local"
See also:
Azure-AD-Authentication-with-PowerShell-and-ADAL
This is a set of really simple PowerShell scripts which allow you to get access tokens with Azure Active Directory using ADAL.
and this...
ADAL and PowerShell
Related
I'm connecting to AWS using a SAML login with AzureAD as my IdP. This is all working great and I can use SAML response in the browser to generate a temporary session token that gives me an hour to work in AWS CLI. However, according to this blog, I should be able to use AWS Tools for Windows PowerShell to capture the SAML Response but all I ever get is an error Unable to set credentials: Root element is missing. All my googling is leading to possible transient issues with certificates being near expiration or using older versions of the Powershell Module (I'm using the latest as of this writing: v4.1.13.0) or Powershell itself (I'm using 7.1.3).
Anybody successfully got the AWS Tools for Windows PowerShell to work with AzureAD as an IdP?
I found this somewhat more recent post, which has a ton more information about this kind of setup, some detail about how to configure it, and a note about why it may not be working (as of Jan2020)
Try using the AWSPowerShell command Use-STSRoleWithSAML(AWS docs) to generate some temporary credentials. The doc page goes into a lot of detail on what is required too for your Idp and in IAM, including links to relevant IAM guides. For example:
# Returns a set of temporary security credentials
Use-STSRoleWithSAML `
-RoleArn 'arn:aws:iam::ACCOUNTNUMBER:role/IAMROLE' `
-PrincipalArn 'arn:aws:iam::ACCOUNTNUMBER:saml-provider/SAMLPROVIDER' `
-SAMLAssertion 'BASE64ENCODEDRESPONSE' `
-DurationInSeconds 3600
So I can successfully run commands to manage our Microsoft 365/AzureAd/Exchange Online - this involves assigning and removing license, converting user to a shared mailbox, delegating access to a mailbox, etc. I followed the guide here for authentication. But that's me actually logging in with my credentials + MFA (Multi-factor authentication) for authentication.
I want to have a script that does these type of actions triggered by a schedule. I believe I can include the credentials but how to do MFA? Tried to follow this but getting error clientid is not a guid I have registered an app in https://portal.azure.com/ and able to do Graph API calls using that. No luck in PowerShell authentication though. Any thoughts? Thanks!
Maybe try this? It should allow you to connect to all Microsoft online services and includes support for MFA. If it does not work, the website has many other scripts you can try
This is not possible. A potential solution is to set some rules where in specific case, MFA will not be required.
I am working with PowerShell. So we can connect MFA enabled O365 through connect-exopssession but we need to manully enter password and Code sent to mobile. But I want to schedule a solution which has to connect to O365 automtically without any manual intervention in MFA enabled O365. Is there any solution which can bypass MFA without disabling MFA in O365.
The only way to do this is to setup an account that is dedicated for these types of tasks and remove MFA for it, or use Conditional Access to bypass MFA when connecting from your Public IP etc. Just make sure that you secure this account as much as possible.
To create non-interactive scripts, you need EXO V2 PowerShell module version 2.0.3 preview or later version. This unattended script authentication uses Azure AD applications, certificates, and Modern authentication.
Connect to Exchange Online PowerShell with existing service principal and client-secret:
To connect Exchange online with existing service principal and client-secret, you need to follow the steps below.
Step1: Get an OAuth access token using Active Directory Authentication Library (ADAL) PowerShell.
Step 2: Create PSCredential object
$AppCredential= New-Object System.Management.Automation.PSCredential(<UPN>,<Token>)
Step 3: Pass the PSCredential to the EXO V2 module.
Connect-ExchangeOnline -Credential $AppCredential
For more information please read https://learn.microsoft.com/en-us/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps#setup-app-only-authentication
Use App passwords. App passwords do not need MFA.
From docs:
An app password is a code that gives an app or device permission to access your Office 365 account. If your admin has turned on multi-factor authentication for your organization, and you're using apps that connect to your Office 365 account, you'll need to generate an app password, so the app can connect to Office 365.
Read more and how to in MS Docs here:
Is it possible to connect to exchange powershell online using registered Azure application ID/secret which allows GraphAPI/EWS access?
FYI, I know how to do it with basic auth (username/password) as guided in MSFT website: https://learn.microsoft.com/en-us/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/connect-to-exchange-online-powershell?view=exchange-ps
it is currently possible to use the Microsoft Graph API to make calls to the exchange endpoint. However it's not the same thing as Exchange Powershell Online, please refer to the docs on the exchange graph api here : https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/office-365-rest-apis-for-mail-calendars-and-contacts
For more information on how to make calls via powershell, please look here : https://blogs.technet.microsoft.com/cloudlojik/2018/06/29/connecting-to-microsoft-graph-with-a-native-app-using-powershell/
You will also need to login with a user that has access to said exchange resources. If you login with an application/user that does not have permissions to access the exchange resources you will get a access denied error.
I'd suggest try EXO V2 preview module to connect Exchange Online PowerShell using registered Azure application.
Step1: Get an OAuth access token using Active Directory Authentication Library (ADAL) PowerShell.
Step2: Create PSCredential object
$AppCredential= New-Object System.Management.Automation.PSCredential(<UPN>,<Token>)
Step3: Pass the PSCredential to the EXO V2 module.
Connect-ExchangeOnline -Credential $AppCredential
To authenticate to Azure and use the Azure Resource Manager cmdlets, I currently use the methods outlined here, namely using an Azure Active Directory account, encrypting the password, storing the encrypted string in a text file, and reading that into a credential object when using it in the script.
But I get the sense that maybe I should be using management certificates instead.
There is a documented method to use a publish settings file, but apparently that doesn't work for AzureRm cmdlets, only older cmdlets.
I have seen examples for using Powershell to create an application_id and service principal, and for authenticating a C# app, for instance, but I can't seem to find anything showing how to use management certificates for authentication in a powershell script, to use AzureRm cmdlets.
Maybe the secure string password storage method is the right one. But I don't have a good sense for that.
What do you use?
The best way to do it? It depends what is important to you. Ease of use, security, scripting?
Microsoft Azure Tooling (Visual Studio, Azure Powershell and CLI) lately moved to a more fine-granular, role-based access control approach based on Azure AD. This is currently a pretty good way to do it, since Management certificates allow owners to manage at subscription level and have proven to be rather difficult in environments like Azure Automation.
Refs
https://azure.microsoft.com/de-de/blog/azure-automation-authenticating-to-azure-using-azure-active-directory/
https://azure.microsoft.com/en-us/documentation/articles/cloud-services-certs-create/#what-are-management-certificates
http://blogs.msdn.com/b/cloud_solution_architect/archive/2015/03/17/rbac-and-the-azure-resource-manager.aspx
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/
https://azure.microsoft.com/en-us/documentation/articles/resource-group-rbac/#concepts
You should have a look to Service Principal
https://azure.microsoft.com/en-us/documentation/articles/resource-group-create-service-principal-portal/
https://azure.microsoft.com/en-us/documentation/articles/resource-group-authenticate-service-principal/