Home

Azure Functions and Conditional Access Policies

%3CLINGO-SUB%20id%3D%22lingo-sub-169571%22%20slang%3D%22en-US%22%3EAzure%20Functions%20and%20Conditional%20Access%20Policies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-169571%22%20slang%3D%22en-US%22%3EA%20common%20pattern%20is%20emerging%20where%20an%20Azure%20Function%20will%20be%20written%20that%20calls%20back%20into%20an%20O365%20tentant%20to%20execute%20calls%20against%20various%20APIs%20on%20even%20via%20Powershell.%3CBR%20%2F%3E%3CBR%20%2F%3EI%20want%20to%20be%20able%20to%20add%20an%20Azure%20AD%20Conditional%20Access%20policy%20that%20limits%20%E2%80%9Cwhere%E2%80%9D%20these%20Azure%20Functions%20can%20connect%20from.%3CBR%20%2F%3E%3CBR%20%2F%3EFor%20example%20if%20I%20have%20tenant%20A%2C%20and%20I%20have%20an%20Azure%20function%20running%20on%20tenant%20B%20that%20uses%20Powershell%20to%20connect%20to%20tenant%20A%20-%20how%20do%20I%20configure%20a%20conditional%20access%20policy%20on%20tenant%20A%20that%20controls%20if%20tenant%20B%20can%20call%20tenant%20A%20(hope%20this%20makes%20sense).%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-169571%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAccess%20Management%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EAzure%20AD%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-171304%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20Functions%20and%20Conditional%20Access%20Policies%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-171304%22%20slang%3D%22en-US%22%3E%3CP%3EI'll%20answer%20this%20myself!%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20had%20an%20Azure%20Function%20running%20in%20a%20Consumption%20plan%20in%20Tenant%20B%2C%20with%20this%20plan%20I%20cannot%20really%20identify%20the%20source%20IP%20Address%20of%20the%20function%20when%20it%20is%20designed%20to%20call%20into%20Tenant%20A%20and%20so%20I%20cannot%20configure%20a%20Tenant%20A%20Conditional%20Access%20Policy%20to%20allow%20this%20function%20%22in%22%20(unless%20I%20allow%20ALL%20IP%20Addresses%20from%20the%20Azure%20Data%20Centre%20the%20function%20is%20running%20in).%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20then%20created%20an%20Azure%20Function%20running%20in%20an%20App%20Service%20Plan%2C%20with%20this%20plan%20I%20*can*%20identify%20the%20source%20IP%20Address%20of%20the%20function%2C%20and%20so%20I%20can%20register%20this%20source%20IP%20Address%20on%20the%20Tenant%20A%20Conditional%20Access%20Policy.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ESome%20other%20investigations%20that%20tripped%20me%20up%20as%20I%20was%20trying%20to%20understand%20all%20of%20this%20connectivity%20and%20access%20controls.%20The%20function%20I%20was%20testing%20was%20a%20simple%20PowerShell%20script%20that%20ran%20the%20PnP%20commands.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EConnect-PnPOnline%20-Credentials%20%24userCredential%20-Url%20%22https%3A%2F%2F%3CTENANTA%3E.sharepoint.com%22%26nbsp%3B%3C%2FTENANTA%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThis%20powershell%20ALWAYS%20succeeded%2C%20even%20under%20the%20Consumption%20plan%20and%20I%20couldn't%20understand%20why.%20The%20reason%20is%20that%20using%20the%20-Credentials%20parameter%20the%20commandlet%20uses%20the%20Legacy%20Authentication%20and%20not%20Modern%20Authentication%2C%20and%20so%20my%20Azure%20Conditional%20Access%20Policy%20never%20kicked%20in.%20I%20tweaked%20the%20Powershell%20to%20use%20the%20following%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%3EConnect-MicrosoftTeams%20-Credential%20%3C%2FSPAN%3E%3CSPAN%3E%24userCredential%3C%2FSPAN%3E%3C%2FP%3E%0A%3CDIV%3E%0A%3CDIV%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3C%2FDIV%3E%0A%3CDIV%3E%3CSPAN%3EThe%20Microsoft%20Teams%20commandlets%20DO%20use%20Modern%20Authentication%20and%20so%20the%20Conditional%20Access%20Policy%20does%20kick%20in%2C%26nbsp%3Band%20for%20the%20function%20on%20the%20Consumption%20Plan%20the%20script%20fails%20the%20correct%20error.%3C%2FSPAN%3E%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3E%5BError%5D%20Connect-MicrosoftTeams%20%3A%20One%20or%20more%20errors%20occurred.%3A%20AADSTS53003%3A%20Blocked%20by%20conditional%20access.%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3EWhen%20I%20ran%20this%20script%20in%20the%20function%20running%20under%20the%20App%20Service%20Plan%20it%20succeeded%2C%20as%20I%20configured%20the%20App%20Service%20Plan%20Outgoing%20IP%20Address%20as%20being%20allowed%20in%20the%20Conditional%20Access%20Policy.%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CDIV%3ESo%20if%20you%20want%20to%20control%20where%20functions%20can%20connect%20too%20your%20tenant%20you%20need%20to%20consider%20the%20plan%20the%20function%20runs%20under%2C%20and%20you%20also%20need%20to%20consider%20what%20commands%20your%20function%20will%20use%20to%20connect%20to%20your%20tenant.%3C%2FDIV%3E%0A%3CDIV%3E%26nbsp%3B%3C%2FDIV%3E%0A%3C%2FDIV%3E%3C%2FLINGO-BODY%3E
Colin Rippey
New Contributor
A common pattern is emerging where an Azure Function will be written that calls back into an O365 tentant to execute calls against various APIs on even via Powershell.

I want to be able to add an Azure AD Conditional Access policy that limits “where” these Azure Functions can connect from.

For example if I have tenant A, and I have an Azure function running on tenant B that uses Powershell to connect to tenant A - how do I configure a conditional access policy on tenant A that controls if tenant B can call tenant A (hope this makes sense).
1 Reply

I'll answer this myself!

 

I had an Azure Function running in a Consumption plan in Tenant B, with this plan I cannot really identify the source IP Address of the function when it is designed to call into Tenant A and so I cannot configure a Tenant A Conditional Access Policy to allow this function "in" (unless I allow ALL IP Addresses from the Azure Data Centre the function is running in).

 

I then created an Azure Function running in an App Service Plan, with this plan I *can* identify the source IP Address of the function, and so I can register this source IP Address on the Tenant A Conditional Access Policy.

 

Some other investigations that tripped me up as I was trying to understand all of this connectivity and access controls. The function I was testing was a simple PowerShell script that ran the PnP commands. 

 

Connect-PnPOnline -Credentials $userCredential -Url "https://<tenantA>.sharepoint.com" 

 

This powershell ALWAYS succeeded, even under the Consumption plan and I couldn't understand why. The reason is that using the -Credentials parameter the commandlet uses the Legacy Authentication and not Modern Authentication, and so my Azure Conditional Access Policy never kicked in. I tweaked the Powershell to use the following:

 

Connect-MicrosoftTeams -Credential $userCredential

 
The Microsoft Teams commandlets DO use Modern Authentication and so the Conditional Access Policy does kick in, and for the function on the Consumption Plan the script fails the correct error.
 
[Error] Connect-MicrosoftTeams : One or more errors occurred.: AADSTS53003: Blocked by conditional access.
 
When I ran this script in the function running under the App Service Plan it succeeded, as I configured the App Service Plan Outgoing IP Address as being allowed in the Conditional Access Policy.
 
So if you want to control where functions can connect too your tenant you need to consider the plan the function runs under, and you also need to consider what commands your function will use to connect to your tenant.
 
Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
38 Replies
Extentions Synchronization
Deleted in Discussions on
3 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
How to Prevent Teams from Auto-Launch
chenrylee in Microsoft Teams on
29 Replies
Security Community Webinars
Valon_Kolica in Security, Privacy & Compliance on
13 Replies