Hero Banner

Multi-Factor Authentication (MFA)

Learn and ask questions on how to implement MFA

Reply
Level 2 Contributor

Automation now MFA is enabled

Hi

I had developed an onboarding process using a combination of Flow and Azure Automation in order to create the necessary accounts.

An on-premise service account was saved using the credentials function in azure automation to perform the vairous on premise tasks using the hybrid worker. This part works fine.

The issues now arise with accesing azure/office 365 resources. Where as the stored credentials could be stored in azure automation and called using connect-msolservice and connect-azuread, with MFA in place these now require interaction. I see from various posts/blogs etc. that the Azure AD supports the use of service principals for connecting, however I'm seeing nothing regarding the use of the MSOnline cmdlets and service principals. Considering these cmdlets are responsible for configuring user licenses not being able to use them whould present a significant step backwards.

Any thoughts on how we can get around this limitation?

13 REPLIES 13
Microsoft

Here is an example on using MSOnline cmdlets in Secure app Model: https://docs.microsoft.com/en-us/powershell/partnercenter/secure-app-model?view=partnercenterps-1.5#msonline 

 

Is this what you are looking for?

Kind regards,
Janosch
Level 2 Contributor

Not exactly. I'm more referring to the limitations these changes have when managing your own environments, let alone anyone elses when you are forced to use MFA.

You're unable to programatically use the MSOnline Cmdlets with the built in Azure Automation run as account which get's created (a secure method of authenticating and one which allows it to be completed programatically), although after some further reading around I've managed to replicate 90% of the previous runbook using the Azure AD cmdlets. This has now presented further issues with managing distribution groups.

Add-azureadgroupmember is unable to update distribution groups due to the following error "Unable to update the specified properties for objects that have originated within an external service" which appears to be a limitation of the backend graph API it calls. Does this mean that in order to perform exchange management in an automated fashion we need to employ the exchange online cmdlets workaround mentioned previously?

Level 2 Contributor


@am549 wrote:

Not exactly. I'm more referring to the limitations these changes have when managing your own environments, let alone anyone elses when you are forced to use MFA.

You're unable to programatically use the MSOnline Cmdlets with the built in Azure Automation run as account which get's created (a secure method of authenticating and one which allows it to be completed programatically), although after some further reading around I've managed to replicate 90% of the previous runbook using the Azure AD cmdlets. This has now presented further issues with managing distribution groups.

Add-azureadgroupmember is unable to update distribution groups due to the following error "Unable to update the specified properties for objects that have originated within an external service" which appears to be a limitation of the backend graph API it calls. Does this mean that in order to perform exchange management in an automated fashion we need to employ the exchange online cmdlets workaround mentioned previously?


As a further insult to injury, the provided powershell for creating the exchange online work around account fails with "Property mailNickname value is required but is empty or missing".

Does anyone actually verify these before posting?

It also looks like this doesn't work either. Created an account as per the provided powershell (added in the missing element) and assigned the account as an exchange admin. Try and connect to powershell and just get access denied.

Microsoft

You mean this guidance for Exo Powershell workaround https://docs.microsoft.com/en-us/partner-center/partner-security-requirements#exchange-online-powershell

 

@idwilliams- can you comment on these concerns?

Kind regards,
Janosch
Level 1 Contributor

So I've gotten the MSOnline connection working, and everything operates just fine. But whenever I try to use the method given on cyberdrain to connect to AzureAD it says that I don't have permission for some reason. Is there some reason that they are different, or am I doing something wrong? 

 

Thanks, 

John  

Microsoft

Generally all the powershell cmdlets may show a different behavior, some of this is also discussed in the comments-section in Kelvins article. 

 

If you post your complete approach and the exact error message maybe we can find ot whats going wrong, you can also raise a ticket in the Technical PreSales and Deployment Services team via https://aka.ms/tpdmsform to get a Partner Consultant helping you (in the ticket, do not describe that you are facing an error, mention that you need guidance on how to implement Secure App Model for automating with AzureAD powershell module).

 

 

Kind regards,
Janosch
Level 1 Contributor

I figured out that I was not granting the required permissions to the Azure application that I made, and everything is working now. 

 

Thank you so much for the help : ) 

Level 2 Contributor

Correct. A parameter is missing from the script and it also doesn't work. Setting the account as a global admin presents an access denied message when attempting to connect to exchange online PowerShell when the default conditional access policies are enabled.

Whilst I fully appreciate the security concerns for managing customer environments without suitable workarounds this also impacts our own production environments, which is our main issue as a result of having to enforce these requirements.

As a partner our own environment should set an example to potential and existing customers of what's possible with the Microsoft suites, by enforcing MFA means we're unable to manage or use our own environment effectively.

Microsoft

Will need to find some time to test this again - the last Partner I worked with on this could  successfully connect to ExO following this approach, so it does generally work.

 

So, you are not using ExO powershell to connect to end customer tenants with delegated admin, but only to your own tenant?

 

 

Kind regards,
Janosch
Level 2 Contributor

Correct. I had a number of azure runbooks which accessed our exchange online to perform various functions and adding the user account to any of the typical admin roles (user administration for example) results in an MFA prompt.

I have found a way around this which involves permissions set in the ECP (therefore bypassing all of the roles looked at by the MFA conditions) however accessing ExO PowerShell this way uses basic authentication. With this being disabled in the next 12 months or so it's crucial that we can use service principals to authenticate against exchange online, much like the rest of the 365 PowerShell modules allow.

Level 1 Contributor

I know It's been like almost a year, but if you ever see this would you mind explaining the workaround you found? I am stuck on this issue and can't seem to get around it. 

Microsoft

@John1 : Can you elaborate on the specific scenario you are in and problems you are facing specifically?

 

Also wanted to post this great summary on how to connect with Secure App Model to various services, maybe something you can build on: https://www.cyberdrain.com/connect-to-exchange-online-automated-when-mfa-is-enabled-using-the-secureapp-model/

Kind regards,
Janosch
Level 1 Contributor

Thank you, that post actually helps me out a ton! 

what I’m trying to do is run a script once a day that goes through each of my tenants in order to update the members of a specific group as they get more users. And my plan was to do this through azure automation. This post solves the area where I was having trouble and it looks like it will work, I just need to implement it when I get back to work. 

Thanks again