Superfast using Web App and Managed Identity to invoke Function App triggers
TOC Introduction Setup References 1. Introduction Many enterprises prefer not to use App Keys to invoke Function App triggers, as they are concerned that these fixed strings might be exposed. This method allows you to invoke Function App triggers using Managed Identity for enhanced security. I will provide examples in both Bash and Node.js. 2. Setup 1. Create a Linux Python 3.11 Function App 1.1. Configure Authentication to block unauthenticated callers while allowing the Web App’s Managed Identity to authenticate. Identity Provider Microsoft Choose a tenant for your application and it's users Workforce Configuration App registration type Create Name [automatically generated] Client Secret expiration [fit-in your business purpose] Supported Account Type Any Microsoft Entra Directory - Multi-Tenant Client application requirement Allow requests from any application Identity requirement Allow requests from any identity Tenant requirement Use default restrictions based on issuer Token store [checked] 1.2. Create an anonymous trigger. Since your app is already protected by App Registration, additional Function App-level protection is unnecessary; otherwise, you will need a Function Key to trigger it. 1.3. Once the Function App is configured, try accessing the endpoint directly—you should receive a 401 Unauthorized error, confirming that triggers cannot be accessed without proper Managed Identity authorization. 1.4. After making these changes, wait 10 minutes for the settings to take effect. 2. Create a Linux Node.js 20 Web App and Obtain an Access Token and Invoke the Function App Trigger Using Web App (Bash Example) 2.1. Enable System Assigned Managed Identity in the Web App settings. 2.2. Open Kudu SSH Console for the Web App. 2.3. Run the following commands, making the necessary modifications: subscriptionsID → Replace with your Subscription ID. resourceGroupsID → Replace with your Resource Group ID. application_id_uri → Replace with the Application ID URI from your Function App’s App Registration. https://az-9640-faapp.azurewebsites.net/api/test_trigger → Replace with the corresponding Function App trigger URL. # Please setup the target resource to yours subscriptionsID="01d39075-XXXX-XXXX-XXXX-XXXXXXXXXXXX" resourceGroupsID="XXXX" # Variable Setting (No need to change) identityEndpoint="$IDENTITY_ENDPOINT" identityHeader="$IDENTITY_HEADER" application_id_uri="api://9c0012ad-XXXX-XXXX-XXXX-XXXXXXXXXXXX" # Install necessary tool apt install -y jq # Get Access Token tokenUri="${identityEndpoint}?resource=${application_id_uri}&api-version=2019-08-01" accessToken=$(curl -s -H "Metadata: true" -H "X-IDENTITY-HEADER: $identityHeader" "$tokenUri" | jq -r '.access_token') echo "Access Token: $accessToken" # Run Trigger response=$(curl -s -o response.json -w "%{http_code}" -X GET "https://az-9640-myfa.azurewebsites.net/api/my_test_trigger" -H "Authorization: Bearer $accessToken") echo "HTTP Status Code: $response" echo "Response Body:" cat response.json 2.4. If everything is set up correctly, you should see a successful invocation result. 3. Invoke the Function App Trigger Using Web App (nodejs Example) I have also provide my example, which you can modify accordingly and save it to /home/site/wwwroot/callFunctionApp.js and run it cd /home/site/wwwroot/ vi callFunctionApp.js npm init -y npm install azure/identity axios node callFunctionApp.js // callFunctionApp.js const { DefaultAzureCredential } = require("@azure/identity"); const axios = require("axios"); async function callFunctionApp() { try { const applicationIdUri = "api://9c0012ad-XXXX-XXXX-XXXX-XXXXXXXXXXXX"; // Change here const credential = new DefaultAzureCredential(); console.log("Requesting token..."); const tokenResponse = await credential.getToken(applicationIdUri); if (!tokenResponse || !tokenResponse.token) { throw new Error("Failed to acquire access token"); } const accessToken = tokenResponse.token; console.log("Token acquired:", accessToken); const apiUrl = "https://az-9640-myfa.azurewebsites.net/api/my_test_trigger"; // Change here console.log("Calling the API now..."); const response = await axios.get(apiUrl, { headers: { Authorization: `Bearer ${accessToken}`, }, }); console.log("HTTP Status Code:", response.status); console.log("Response Body:", response.data); } catch (error) { console.error("Failed to call the function", error.response ? error.response.data : error.message); } } callFunctionApp(); Below is my execution result: 3. References Tutorial: Managed Identity to Invoke Azure Functions | Microsoft Learn How to Invoke Azure Function App with Managed Identity | by Krizzia 🤖 | Medium Configure Microsoft Entra authentication - Azure App Service | Microsoft Learn
Global Administrator MFA recovery not possible
Since Microsoft automatically enforced MFA on administrator role in Azure you can end up in the situation where it is no longer possible to recover your tenant. If your only account on that tenant is with Global Administrator role and you accidentally loose your MFA, the only way is to call Microsoft support. Support on the phone is automated where any question regarding Azure is redirected to visit Azure portal. If your only user cannot login then Azure portal is not accessible.MTO and access to on premises file system
Let me preface this by saying I'm still fairly new to 365 Admin (it's been a steep learning curve) and haven't even got my feet wet with on premises stuff as yet. Also, I think some of the admin decisions made previously by others may have been based on just repeating what was found to work the first time rather than necessarily a deep understanding of the best solution. The situation when I arrived on the scene was this (actually it was a bit more complex and messy than this, but this simplified description covers the salient points at this stage) One tenant, with two domains, call them old-domain and new-domain. Two types of user, who I will refer to operations and corporate. An on premises Active Directory system running a file server. Well to be more precise on three premises with mirroring of data and a DFS, but from the user perspective when you're one of the office locations and connect to the network the same folders are available to you. Everyone was using Azure Joined Company Laptops to do this, so their laptop logins were also their network logins. Outside of the offices people connected to the DFS using a VPN (with three gateways in different countries). Operations Users had one account, @old-domain, this was licensed for 365 and had a mailbox associated with it. It was also synched to their on premises AD account Corporate Users had two accounts, one @old-domain with no license, synched to an on premises AD account. The second was new-domain with a 365 license and mailbox. If you're scratching your head wondering why two accounts rather than assigning the new-domain email address to the same account, I can't give you a definitive answer as I've never been given one, but for whatever reason when new domains were brought into play on corporate name changes the admins gave them new mailboxes rather than simply aliasing email addresses to the same mailbox (some people had three accounts as a result). What I did note was that when a new Corporate user was added the admins gave them both of the above accounts, I was told that the unlicensed old-domain one was required for the access to the DFS. Now for reasons not worth getting into here, a decision was made to move the Corporate users to a new tenant, along with new-domain and then to link the two tenants in a multi-tenant organization. It was also decided to leverage BYOD for Corporate users, so their devices will only be Azure registered. This has been done, there was some pain thanks to the reluctance of Microsoft applications to switch to the new account locations rather than redirecting back to the old tenant, but that's been sorted. So right now Corporate users still have two accounts, but on two tenants. On the Old Tenant they have their @old-domain account, no license, no mailbox, synched to the on premises AD (as before) On the New Tenant they have their new-domain account. This is where they actually do their work, and is the only account anyone should be communicating with internally or externally. Access to the DFS is being done using the VPN with the on premises credentials associated with the old-domain account. In terms of functionality, this works perfectly well, people across the two tenants appear in each other's address lists, they can chat and share information etc. Everybody also has access to the folders they should have access to on the DFS. However there are two issues. The first, and most detrimental in terms of just getting work done is that users in one of the overseas offices have found their access to the DFS has slowed considerably, despite being in physically the same location as the data. I believe the problem is that although the data is on-premises, the VPN gateway is not, therefore data does a round trip from the server, through that gateway IP address at the ISP and back to the user. Since they are in a remote location with poor internet this slows things considerably. So the first question is, how do we take that loop out of the equation so that when they are in the office they connect more directly to the servers on site? Ideally without having to revert to needing an Azure AD joined device. The second issue is that those remaining old-domain accounts (the ones for the Corporate users who are now working on the new tenant) on the old tenant are messy, in two ways 1) From an admin perspective, because every one of those corporate users still has two accounts, their local one that is synched to On Premises AD, and the the external account shared from the new tenant as part of the MTO 2) From a user's perspective. For reasons that I cannot fathom (but this is coming direct from Microsoft after many attempts on my part to find a way) it seems that while you can control which licensed accounts appear on Teams search by controlling whether they are in the GAL and setting the appropriate switch in Teams Admin, all the unlicensed users appear whether you like it or not. The net result is that when someone on the old tenant starts typing in a name of someone in Corporate, they get two suggestions coming up. So the second question is, are those accounts actually necessary?
A little help please with Get-AzADObject
I am trying to write a PowerShell script that will list the users who hold specified Azure roles into a .csv file for security reviews. I'm new to PowerShell and I'm struggling with this for far too long on my own. Here's what I've got: I keep getting the error: Get-AzADObject: The term 'Get-AzADObject' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. I've already used: Get-Module AzureAD Install-Module AzureAD Import-Module AzureAD With no errors on any of those. What am I missing, please?
Ad-Hoc Entra MFA using SMS
Error : Get MFA Client Access TokenDone. Send MFA challenge to the user Done. OTP sent to your phone. Please enter the OTP: Enter the OTP sent via SMS: 696632 Invoke-RestMethod: C:\Git_Repo\MFA_Test\MFATestWIthKyle\sms.ps1:54:28 Line | 54 | … ionResult = Invoke-RestMethod -Uri 'https://strongauthenticationservi … | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Service BODY { color: #000000; background-color: white; font-family: Verdana; margin-left: 0px; margin-top: 0px; | } #content { margin-left: 30px; font-size: .70em; padding-bottom: 2em; } A:link { color: #336699; font-weight: bold; | text-decoration: underline; } A:visited { color: #6699cc; font-weight: bold; text-decoration: underline; } A:active { color: | #336699; font-weight: bold; text-decoration: underline; } .heading1 { background-color: #003366; border-bottom: #336699 6px | solid; color: #ffffff; font-family: Tahoma; font-size: 26px; font-weight: normal;margin: 0em 0em 10px -20px; padding-bottom: | 8px; padding-left: 30px;padding-top: 16px;} pre { font-size:small; background-color: #e5e5cc; padding: 5px; font-family: | Courier New; margin-top: 0px; border: 1px #f0f0e0 solid; white-space: pre-wrap; white-space: -pre-wrap; word-wrap: break-word; | } table { border-collapse: collapse; border-spacing: 0px; font-family: Verdana;} table th { border-right: 2px white solid; | border-bottom: 2px white solid; font-weight: bold; background-color: #cecf9c;} table td { border-right: 2px white solid; | border-bottom: 2px white solid; background-color: #e5e5cc;} Service Endpoint not found. WARNING: Invalid OTP or validation failed. Below line causing the error $mfaValidationResult = Invoke-RestMethod -Uri 'https://strongauthenticationservice.auth.microsoft.com/StrongAuthenticationService.svc/Connector//ValidatePin' -Method POST -Headers $Headers -Body $XML -ContentType 'application/xml'Principle 'XYZ' could not be found or this principal type is not supported - Azure SQL DB and MI
In this blog article, we will be discussing the possible scenarios to get the error "Principle 'XYZ' could not be found or this principal type is not supported" while adding an AAD user or group to your Azure SQL database or Azure SQL managed instance.
O365 SSPR require users to register when signing in
Hi Everyone Can someone please shed some light on this. In Azure SSPR under password reset>registration> require users to register when signing in Yes or No. Below is MS website explanation. Does that mean if I set it to Yes, if users go to office.com they are prompted to register in SSPR? What are the down side of choosing no, You can enable the option to require a user to complete the SSPR registration if they use modern authentication or web browser to sign in to any applications using Microsoft Entra ID. This workflow includes the following applications: Microsoft 365 Microsoft Entra admin center Access Panel Federated applications Custom applications using Microsoft Entra ID When you don't require registration, users aren't prompted during sign-in, but they can manually register
