Unlocking Snowflake Data Integration in Power Platform: Using Custom Connector with Snowflake REST API – Part 1

In today’s data-driven world, businesses rely on integration between their data sources and analysis platforms to derive insights and make informed decisions. One such powerful combination is leveraging Snowflake, a leading cloud-based data warehousing platform, alongside Microsoft Power Platform. In this blog series, we’ll delve into the options of integrating Snowflake data sources into Power Platform, exploring both custom and out-of-the-box connector options. In Part 1, our focus will be on setting up and configuring Snowflake, followed by creating a custom connector that leverages Snowflake’s SQL REST API. This connector facilitates the connection between Snowflake and the Power Platform services such Power Apps and Power Automate.

Pre-requisites:

  • Snowflake account with Account Admin access: Snowflake offers a 30-day trial, granting full access to explore its capabilities. You can select either Azure/AWS/GCP
  • Entra ID access (Global Admin or Privileged Administrator Role) to create App registration and grant Admin consent: Ensure you have Entra ID access to enable the creation of App registrations and to grant Admin consent for necessary permissions.
  • Power Platform Administrator Role: To make adjustments to allow custom connector endpoints for Snowflake identifier URL, especially in cases where endpoints are blocked by the tenant scoped DLP policy.
  • Maker or System Administrator access in a Power Platform Environment: Access privileges should include Maker or System Administrator rights within your Power Platform environment to register custom connector.
  • Power Apps premium license: A Power Apps premium license is required to use a custom connectors in a Power Apps or a Cloud flow.

This blog post is divided into the following sections:

  • Creation of Entra ID Apps.
  • Setup Snowflake Environment.
  • Creation of a custom connector & DLP Policy Update.

Creation of Entra ID Apps:

There are two app registrations required to facilitate the API access through Microsoft Entra ID, where one would represent the Snowflake OAuth resource and the other would represent the OAuth client application which would be in this case the custom connector

Section 1 – Registering an Application in Microsoft Entra ID for Snowflake OAuth resource:

In the Entra ID portal, navigate to App registrations and click + New registration. Enter a name, such as Snowflake OAuth resource, and proceed by clicking the Register button, leaving all settings as default.

Under the Manage section in the side menu, select Expose an API. Set the Application ID URI with the default value and remember to copy this value for future use. This will be known as external_oauth_audience_list in the section Setup and configuration in Snowflake

Click on the Add a scope button to access the panel. The Snowflake Role Public is added as an OAuth scope for OAuth flows where the Snowflake OAuth client acts on behalf of a user from the custom connector. If there is a custom Snowflake role, it should be added as a scope instead of ‘Public’:

  1. Enter a new Scope name as session:scope:PUBLIC
  2. Set Admin consent display name to Account Admin
  3. Provide Admin consent description as “Can Administer the Snowflake account”
  4. Ensure the Enabled scope state is selected.

Complete the process by selecting the Add scope button to create the scope.

Section 2 – Registering an Application in Microsoft Entra ID for Snowflake OAuth client:

In the Entra ID portal, navigate to App registrations and click + New registration. Enter a name, such as Snowflake OAuth client, and proceed by clicking the Register button, leaving all settings as default.

Retrieve the Client ID, Tenant Id from the Overview section of the Entra ID app and generate a secret through the Certificates & secrets under the Manage blade. Once the secret is successfully created, copy its value for use in configuring the custom connector OAuth Authentication.

In the API permissions section under the Manage blade, click + Add a permission and search for Snowflake OAuth resource, the application created previously.

Select the Delegated permission session:scope:PUBLIC defined in the previous section as shown below, and grant Admin consent.

Everything is configured in Entra ID. Now, let’s move on to Snowflake to set up the necessary components for this integration to function.

Reference: https://docs.snowflake.com/en/user-guide/oauth-azure

Setup Snowflake Environment:

Let’s head in to the Snowflake instance as an Account Admin. Here, you’ll create a

  • Create Database with sample data & grant roles
  • Set up security integration
  • Create a user in Snowflake synchronized with the Entra ID user

Log in to the Snowflake instance to copy the Identifier URL as shown below. This URL will be used in the custom connector to access the Snowflake REST API.

Snowflake Identifier URL: https://texxxx.eu-north-1.aws.snowflakecomputing.com

Create Database with sample data & grant role:

Create a SQL Worksheet as shown below and execute the following script to set up the Snowflake environment by creating a warehouse, database, and table named ‘rockers_table’. Sample data is inserted into the table, and permissions are granted to the ‘public’ role for accessing and updating the table:

-- Switch to the 'accountadmin' role
use role accountadmin;
-- Create the HOL_WH warehouse with size 'X-SMALL'
CREATE OR REPLACE WAREHOUSE HOL_WH WITH WAREHOUSE_SIZE='X-SMALL';
-- Create the HOL_DB database
CREATE OR REPLACE DATABASE HOL_DB;
-- Grant usage on the warehouse HOL_WH to the role 'public'
GRANT USAGE ON WAREHOUSE hol_wh TO ROLE public;
-- Grant usage on the database HOL_DB to the role 'public'
grant usage on database hol_db to role public;
-- Grant usage on the schema HOL_DB.PUBLIC to the role 'public'
grant usage on schema hol_db.public to role public;
use role accountadmin;
-- Switch to the HOL_DB database
use database HOL_DB;
use warehouse HOL_WH;
-- Create the 'rockers_table' table
CREATE TABLE rockers_table (
  id INT,
  name VARCHAR(50),
  age INT
);
-- Insert data into the 'rockers_table' table
INSERT INTO rockers_table (id, name, age)
VALUES (1, 'Jimi Hendrix', 27),
       (2, 'Janis Joplin', 27),
       (3, 'Elvis Presley', 42),
       (4, 'Freddie Mercury', 45),
       (5, 'Whitney Houston', 48),
       (6, 'Michael Jackson', 50),
       (10, 'John Lennon', 40);
-- Grant select and update permissions on the 'rockers_table' table to the role 'public'
grant select, update on table hol_db.public.rockers_table to role public;

Set up security integration:

Let’s proceed to create the Security integration, which is a Snowflake object that establishes an interface between Snowflake and Entra ID. This integration is a prerequisite for enabling Entra OAuth authentication in the custom connector. Execute the following script:

create security integration connector
       type = external_oauth
       enabled = true
       external_oauth_type = azure
       external_oauth_issuer = 'https://sts.windows.net/tenantId/'     
       external_oauth_jws_keys_url = 'https://login.microsoftonline.com/tenantId /discovery/v2.0/keys'
       external_oauth_audience_list = ('applicationIDURI')
       external_oauth_token_user_mapping_claim = 'upn'
       external_oauth_snowflake_user_mapping_attribute = 'login_name'
       external_oauth_any_role_mode = 'ENABLE';

Replace the tenantid in ‘external_oauth_issuer’ and ‘external_oauth_jws_keys_url’, and the Application ID URI in ‘external_oauth_audience_list’. These values should be copied from sections 1 and 2 of the Entra ID app creation process written above.

Reference:

https://quickstarts.snowflake.com/guide/power_apps_snowflake/#0

Create a user in Snowflake synchronized with the Entra ID user:

We’ll create a user in Snowflake that mirrors the Entra ID user upn as created in the security integration. In the User & Roles section under Admin, click + User. The login name should be the UPN (User Principal Name) from Entra ID/AD. Once the required details are entered, proceed to click on Create User.

Creation of a custom connector & DLP Policy Update:

The custom connector serves as a wrapper around the Snowflake REST API, facilitating communication between Power Apps or Power Automate and the API. To create this connector, navigate to Custom connectors in the Power Apps/Power Automate maker portal, then click on + New custom connector and select Create from blank. Enter the connector name, and on the subsequent screen, enter the Snowflake Identifier URL in the Host field and some description about the connector.

Now click Security on the right bottom corner or from the Tab to enter the Entra ID application information copied from the App registration Snowflake OAuth Client for the OAuth 2.0 authentication type. Under the section OAuth 2.0

  1. Change the Identity provider to Azure Active Directory
  2. Enter the Client id & Client secret copied from the Section 2 of the Entra ID app registration Snowflake OAuth Client
  3. Enter the Resource URL as api://applicationIDURI copied from the Section 1 of the Entra ID app registration Snowflake OAuth Resource
  4. Enter the Scope as session:scope:PUBLIC based on the permissions you have added. Leave a space between each permission if there are multiple permissions

After the above information is filled in, click Create connector which will autogenerate the Redirect URL https://global.consent.azure-apim.net/redirect/cc-2dsnowflake-xxxxxx-5f92d3264404092da9. Now go to the Entra ID App registration Snowflake OAuth Client created in Section 2 of the Entra ID apps and add the above Redirect Web URI.

The connector is now prepared to add actions based on the Snowflake REST API endpoints. Snowflake’s REST API offers functionalities such as submitting SQL statements, checking execution statuses, cancelling executions, and fetching query results concurrently. This blog post will primarily concentrate on integrating with the API to submit SQL statements. For more guidelines, it’s recommended to look at the Snowflake REST API documentation for best practices.

Let’s proceed to add an action for submitting a SQL statement. Navigate to Definitions and select + New action. Once you’ve filled in the Summary, Description, and Operation ID (e.g., GETSFData), click on + Import from sample under the Request section, and input the following details:

Verb: POST

URL: https://snowflakeidentifierURL/api/v2/statements

Replace the Snowflake Identifier URL

Headers:

Content-Type application/json

Accept application/json

Body:

{
"statement": "select name, age from rockers_table;",
"timeout": 60,
"database": "HOL_DB",
"schema": "PUBLIC",
"warehouse": "HOL_WH",
"role": "PUBLIC"
}

Click Import & Update connector then proceed to click the Test tab and create a New connection. In the event of encountering DLP error message indicating that connection creation has been blocked by Data Loss Prevention (DLP) policy. Add the Snowflake Identifier URL as a connector pattern allowed in the Business/Non Business category of the DLP policy.

VOILA, everything is set up. You can now test the action to execute a SQL statement to retrieve data from the rockers_table as shown below:

The request body for updating an existing item is

{
"statement": "UPDATE rockers_table SET Name = 'Mohamed Ashiq' WHERE ID = '1';",
"timeout": 60,
"database": "HOL_DB",
"schema": "PUBLIC",
"warehouse": "HOL_WH",
"role": "PUBLIC"
}

Summary:

In the next part of the blog series, we’ll explore how to manipulate the response from the connector action. This involves adding C# code in the custom connector to facilitate the display in Power Apps gallery control without using a Power Automate flow. Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.

Do you like this article?

Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.

Streamlining Integration: Using Azure Managed identities in Power Apps and Power Automate to access Microsoft Graph API – Part 3

In both Part 1  and Part 2 of the blog series, I’ve covered the utilization of Managed Identities in Power Apps and Power Automate for secure access to Microsoft Graph API. This included a deep dive into setting up and configuring the Azure API Management service with the Microsoft Graph permissions for the managed identity. In Part 2, I’ve explored the process of exporting the API as a connector in Power Platform, securing it with API key authentication.

The Part 3 aims to enhance the security of the connector by implementing Entra ID OAuth authentication.

Entra ID Apps:

To enhance the security of the custom connector published from Azure API Management for Microsoft Graph APIs using Entra ID OAuth authentication instead of Subscription key, it is essential to create two Entra ID applications. One application should represent the API from API Management, while the other should represent the client application to be utilized in the Entra ID OAuth authentication for the custom connector.

Registering an Application in Microsoft Entra ID for API Representation:

In the Entra ID portal, navigate to App registrations and click + New registration. Enter a name, such as APIM PP Resource, and proceed by clicking the Register button, leaving all settings as default. This app represents the APIs added in the Azure API management instance.

  • Under the Manage section in the side menu, select Expose an API. Set the Application ID URI with the default value and remember to copy this value for future use.
  • Click on the Add a scope button to access the Add a scope panel:
    1. Enter a new Scope name as APIM.MSGraphAPI
    2. Set Admin consent display name to APIM MSGraph API
    3. Provide Admin consent description as “Grants access to the API in APIM.”
    4. Ensure the Enabled scope state is selected.
    5. Complete the process by selecting the Add scope button to create the scope.

Registering an Application in Microsoft Entra ID for Client Representation:

Create another Entra ID app to be used in the custom connector for securing with Entra ID OAuth Authentication. In the Entra ID portal, navigate to App registrations and click + New registration. Enter a name, such as APIM PP Client, and proceed by clicking the Register button, leaving all settings as default.

  1. Retrieve the Client ID, Tenant Id from the Overview section of the Entra ID app and generate a secret through the Certificates & secrets under the Manage blade. Once the secret is successfully created, copy its value for use in configuring the custom connector OAuth Authentication.
  2. Go to the Entra ID app APIM PP Resource created earlier. In the Manage section, click on Expose an API and then Add a client application by selecting + Add a client application in the popout panel. Enter the Client ID of the APIM PP Client app registered now. Select the authorized scope created in the previous section, then proceed by clicking Add Application. This ensures the application APIM PP Resource trusts the client application APIM PP Client and users should not be asked to consent when the client calls the APIs published API Management instance.

Note: If you prefer users/admins to provide consent for the permission while creating a connection for the custom connector, add the APIM.MSGraphAPI Scope to the APIM PP Client app, as shown below. In this scenario, the step mentioned in bullet no 2 becomes unnecessary.

Configuring Custom Connector Authentication to Entra ID OAuth:

Following the export of the API from the Azure API Management as a custom connector in Power Platform in Part 2 of this blog series, proceed to the Power Apps or Power Automate maker portal to edit the connector.

  1. Access the custom connectors, locate the exported connector in the Power Platform Environment where the connector was exported from API Management
  2. Within the Authentication type settings, originally set to API Key, click Edit, and modify it to OAuth 2.0.
  3. Choose the Identity provider as Azure Active Directory. Enter the Client ID and Client secret obtained from the APIM PP Client app copied earlier. Set the resource URL to the Application ID URI generated from the APIM PP Resource app.
  4. Click Update connector to generate a Redirect URL on the same screen—ensure to copy this URL.
  1. Navigate to the APIM PP Client app in the Entra ID portal and add a Web Redirect URI, paste the copied Redirect URL.

Azure API Management: Configure JWT validation policy to Authorize requests from Custom connector:

The JWT validation policy pre-authorizes requests from the Power Platform Custom connector as it adds the layer of security to ensure that incoming access tokens are valid and meet specific criteria before the APIM starts processing requests to the added MS Graph API endpoints. The policy checks the value of the audience claim in an access token obtained from Microsoft Entra ID with in the custom connector. The audience claim typically specifies the intended recipient of the token, ensuring that the token is meant for the intended API.

By configuring the following JWT validation policy in the <inbound> policy section below the node <base />, you enforce the validation of the access token, and if the token is invalid, an error message is returned.  Don’t forget to replace the TenantId and the required claims value to the client id of the app APIM PP Resource.

<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">

<openid-config url="https://login.microsoftonline.com/replaceherewithTenantId/v2.0/.well-known/openid-configuration" />
<issuers> <issuer>https://sts.windows.net/replaceherewithTenantId/</issuer>
</issuers>
<required-claims>
<claim name="aud">
<value>api://replaceherewiththeClientIDoftheApp-APIM PP Resource</value>
</claim>
</required-claims>
</validate-jwt>

Note:  If you attempt to establish the connection from the Test Tab and subsequently execute the action, you will encounter the following error “Access denied due to missing subscription key. Make sure to include subscription key when making requests to an API.

Creating a Product:

To enable the custom connector to generate tokens for API access from API Management, it’s necessary to associate the APIs with a Product that doesn’t require a subscription key. Follow these steps:

  • In the left navigation pane, go to Products and click on + Add.
  • Provide the Product Name, Description, uncheck the box Require subscription option, select the relevant API, and proceed to create the Product.

Testing the Custom connector:

Navigate to the Power Platform Maker portal and access the custom connector interface. Edit the connector to initiate the creation of a connection within the Test tab. Click on + New connection and click Create. Notably, you’ll observe that it doesn’t prompt for the API Subscription key, as discussed in the Part 2 of the article.

Once the connection is created, return to the edit mode of the custom connector to initiate testing of the actions. Navigate to the Test tab, where you can select the specific connection and choose the operation you wish to test. Test the operation and validate the results of the custom connector action.

Summary:

This concludes the blog series, where we delved into the secure access of Microsoft Graph APIs in Power Platform with the help of Azure API management, employing both Subscription keys and Entra ID OAuth authentication. Demonstrated the usage of managed identities in Power Platform, the methods explored here, particularly for securing Microsoft Graph API with application permissions, are adaptable for various services. Addressing the significant security risk of Broken Access Control, I have highlighted the importance of correctly implementing authentication mechanisms to prevent potential exploitation by attackers.

For those with existing Entra ID app registrations seeking to enhance security with API Management, the credential manager feature offers a solution. Utilizing the Grant Type Authorization code for Delegated Permission and Client Credentials for Application Permission ensures a comprehensive approach to safeguarding your applications and APIs. Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.

Do you like this article?

Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.

Streamlining Integration: Using Azure Managed identities in Power Apps and Power Automate to access Microsoft Graph API – Part 2

In Part 1 of the blog series on using Managed identities in Power Apps and Power Automate to access Microsoft Graph API securely, I have delved into the setup and configuration of the Azure API management service with the necessary Microsoft Graph permissions for the managed identity. Building upon that foundation, Part 2 aims to take it further your integration journey in making the API’s available as a connector in Power Apps and Power Automate secured with API key Authentication.

Azure API Management Instance: Managing API Subscription Keys

APIs published through the Azure API Management instance are by default secured by Subscription keys. These keys play a crucial role in establishing connections in Power Apps or Power Automate after exporting APIs as custom connectors.

To manage these keys, navigate to the left navigation menu under the “Subscriptions” blade in the Azure portal within your API Management (APIM) instance. Here, you have the option to generate a new key or utilize an existing one. Copy the key from the portal to create the connection in the later section.

You can test the API by using the Subscription key from Postman as shown below:            

Exporting API as a Connector in Power Platform:

To harness the capabilities of the APIs within your API Management instance secured with the Managed identities, exporting them as connectors in Power Platform is a major step in order to be used in Power Apps and Power Automate. Follow these simple steps for a seamless integration:

In the left navigation menu, navigate to Power Platform under the APIs blade.

  • Click on Create a connector to initiate the connector creation process.
  • Choose the specific API (e.g., msgraph) that you wish to export as a connector.
  • Select the Power Platform environment where you have Maker/Admin role access.
  • Under API Display Name, enter a name for the connector. This will be the identifier for your connector within Power Platform.
  • Click on the “Create” button to complete the process.

Once the connector is created, navigate to your Power Apps or Power Automate portal. You’ll see the API listed under Custom Connectors on the left navigation bar in Environment where the connector has been created from the API Management instance.

  • Click on the Edit icon to initiate the analysis and testing of connector actions.
  • Explore the Definition tab to view the view the API operations within the APIM instance now listed as Actions.
  • Verify the Authentication type of the connector by navigating to the Security tab, where the setting is configured to API key for streamlined validation.
  • Begin by creating a connection in the Test tab. Click on + New connection to start testing.
  • Enter the Subscription key, which you previously copied from the Azure portal for the API Management (APIM) instance. This key establishes the secure link between your connector and the APIM services. If there is no error, the connection will be created.

In the event of encountering below error message indicating that connection creation has been blocked by Data Loss Prevention (DLP) policy

Add the Gateway URL copied from the API management instance under the Overview section on the portal as a connector pattern allowed in the Business/Non Business category of the DLP policy.

Note: Please be aware that in the API Management instance, within the APIs Policies section, if you haven’t included the wildcard (*) as I did for CORS, and have instead specified particular URLs like https://make.powerapps.com, an additional policy in the Custom connector is required to be added under the Definitions tab. Specifically, you need to add a policy to set the request Origin header.

Testing the Custom Connector:

Once the connection is created, return to the edit mode of the custom connector to initiate testing of the actions. Navigate to the Test tab, where you can select the specific connection and choose the operation you wish to test. Test the operation and validate the results of the custom connector action.

Summary:

This completes the Part 2 of the blog series where we have explored the process of accessing Microsoft Graph APIs securely within the API management with Subscription key authentication using managed identities (System and User) as a connector in Power Platform. In our next article, we will delve into the enhancing security further by implementing OAuth authentication within the custom connector for API management APIs. Stay tuned. Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.

Do you like this article?

Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.

Streamlining Integration: Using Azure Managed identities in Power Apps and Power Automate to access Microsoft Graph API – Part 1

Using Microsoft Graph in Power Apps and Power Automate offers several advantages for streamlining integration with various Microsoft 365 services and applications. Additionally, securing these integrations with Azure Managed Identities significantly enhances the overall security of the solution. Azure Managed Identities enable applications and services to authenticate with Azure services seamlessly and securely. When it comes to using Microsoft Graph API, you don’t need a client secret anymore. This makes it simpler to manage and keeps everything more secure. This blog series, divided into multiple articles, is dedicated to utilizing managed identities either System Assigned or User Assigned in Power Platform to access MS Graph API endpoints. It leverages Azure API Management service with the support of a custom connector. The focus of this particular article is on configuring the Azure API management service with the necessary Microsoft Graph permissions for the managed identity.

Pre-requisites & permissions:

Here are the resources and permissions required to follow along this blogpost:

Azure Subscription/Entra ID:

You need an Azure subscription to create and manage Azure API Management instances.

  • Azure Managed Identity – User or System Assigned:
    • Create or use an existing Azure Managed Identity. This can be either a user-assigned identity or a system-assigned identity of the APIM resource, depending on your requirements.
  • Global Admin or Privileged Administrator Role:
    • The user should have Global Administrator or Privileged Administrator role in the Microsoft Entra ID to grant Admin consent for the MS graph permissions on the Managed Identity using Microsoft Graph PowerShell SDK.

Power Platform Environment:

Set up a Power Platform Environment where you plan to create and use custom connectors.

  • Role:
    • Ensure that the user/maker has the System Administrator/Customizer/Maker role on the Power Platform Environment. This role is required to create custom connectors.
  • DLP Policy:
    • Make adjustments to allow custom connector endpoints, especially in cases where endpoints are blocked by the tenant scoped DLP policy.
  • License:
    • A Power Apps or Power Automate Premium license is necessary for creating and using custom connectors. Ensure that the user has the required premium license assigned.

Azure API Management Setup with Microsoft Graph Permissions:

Create a Azure API Management resource and turn on System assigned managed identity and if available, add a User Assigned Managed Identity in the Security section of the API Management instance. Execute the following PowerShell script which user Microsoft Graph SDK to add the permission User.Read.All to either the System or User assigned managed identity. Adjust the permissions as needed for your specific requirements. Before executing the script, replace the permission and the display name of the Managed identity depending on the managed identity you have used. If you have used a System Assigned managed identity, ensure that it corresponds to the display name of the API Management instance.

# Install Microsoft Graph PowerShell module if not already installed

$PermissionName = "User.Read.All"
$DisplayNameOfMSI = "replaceherewithactualnameofManagedIdentity"
$GraphAppId = "00000003-0000-0000-c000-000000000000"

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Directory.ReadWrite.All","AppRoleAssignment.ReadWrite.All"

# Get Managed Identity Service Principal

$MSI = (Get-MgServicePrincipal -Filter "displayName eq '$DisplayNameOfMSI'")
# Sleep for a while to allow time for service principal creation if needed

Start-Sleep -Seconds 10
# Get Microsoft Graph Service Principal
$GraphServicePrincipal = Get-MgServicePrincipal -Filter "AppId eq '$GraphAppId'"

# Retrieve the App Role from the Microsoft Graph Service Principal based on the specified Permission Name
$Role = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName}

# Create an App Role Assignment HashTable for assigning the role to the Managed Identity
$AppRoleAssignment = @{

principalId = $MSI.Id

resourceId = $GraphServicePrincipal.Id

appRoleId = $Role.Id }

# Assign the Graph permission
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MSI.Id -BodyParameter $AppRoleAssignment

You can download the above script from this link. If you prefer using the Azure AD PowerShell module, keep in mind that it is planned for deprecation. In such a case, you can get the script from this link.

Note: You’ll discover equivalent commands for Microsoft Graph PowerShell as opposed to the Azure AD PowerShell cmdlets on the following link

https://learn.microsoft.com/en-us/powershell/microsoftgraph/azuread-msoline-cmdlet-map?view=graph-powershell-1.0

Upon successful execution of the script, the following message will be displayed

The permission granted to the Managed identity can be validated from the Entra ID portal as shown below

Configure the Microsoft Graph API endpoint in API Management and configure policy:

SettingValue
Display namemsgraph
Web service URLhttps://graph.microsoft.com/v1.0
API URL suffixmsgraph

In the API Management instance, on the left menu select APIs > + Add API. Select HTTP and enter the following settings. Then select Create.

System Assigned Managed Identity:

Navigate to the newly created API and select Add Operation. Enter the following settings for accessing the API through System Assigned Managed Identity (SAMI) and select Save.

SettingValue
Display namegetUsrProfileSAMI
URL for GET/users/{User (UPN)}

Select the Operation getUserProfile. In the Inbound processing section, select the (</>) (code editor) icon to use the authentication-managed-identity policy to authenticate with the Microsoft Graph API endpoint using the Managed Identity. This policy uses the managed identity to obtain an access token from Microsoft Entra ID for accessing the specified graph resource.

Replace with the following code in the inbound node:

<inbound>
<base />
<authentication-managed-identity resource="https://graph.microsoft.com" />
</inbound>

User Assigned Managed Identity:

If you prefer to utilize a user-assigned managed identity, click on Add Operation, input the specified settings for accessing the API via User Assigned Managed Identity (SAMI), and then click Save

SettingValue
Display namegetUsrManagerUAMI
URL for GET/users/{User (UPN)}/manager

The Inbound processing section should have the following code

<inbound>

<base />
<authentication-managed-identity resource="https://graph.microsoft.com" client-id="ReplaceitwiththeAppcationIdoftheUAMI" />
</inbound>

You would now be able to test the Graph API endpoint for both the identities from the Test tab.

Add CORS Policy to API in API Management:

CORS settings allow or restrict web applications or services hosted on different domains from making requests to your API. If you want to enable cross-origin requests to the configured Graph API’s from Power Platform Custom connector, you need to configure CORS settings in the API Management service. In the left menu, select APIs and select the API that you will export as a custom connector. If you want to, select only an API operation to apply the policy to.

In the Policies section, in the Inbound processing section, select + Add policy. Select Allow cross-origin resource sharing (CORS).

Add the following Allowed origin: *

Select Save.

I have added * which allows all URL’s but you can be specific by adding the only the relevant URL’s such as https://make.powerapps.com, https://make.powerautomate.com etc

Reference: https://learn.microsoft.com/en-us/azure/api-management/enable-cors-power-platform#add-cors-policy-to-api-in-api-management

Summary:

Up to this point, we have set up the API Management instance with Graph API endpoints for both System Assigned and User Assigned identities. In the upcoming article, we will delve into exporting the API to the Power Platform as a custom connector, implementing security through API key authentication. Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.

Do you like this article?

Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.

How to invite external users to a SharePoint site or Microsoft Team using Power Automate and Graph API

SharePoint and Microsoft teams services in Microsoft 365 makes it easier to share content or collaborate with external users who is outside your organization. A guest or external user is someone who do not have a school or work account with your organization, they can be your partner, vendor, customer etc. In this article let us see how to build a self-registration experience for external users with the help of Microsoft Forms & Power Automate to onboard them to a

  • SharePoint online site
  • Microsoft Team

Microsoft Form to collect details from External User:

To start building this experience, create a Microsoft form with the setting Anyone can respond and with fields (Name, Email address etc) to collect information from the external user to send invitation.

Azure Active Directory Application registration:

The next step after creating the form is to register an application in Azure AD with Microsoft graph API permission to send invitation to external user. After the app is registered obtain the client id, client secret & tenant id to be used in the Power Automate flow further down this article to generate the JSON webtoken to access Microsoft Graph API for sending invitation. Find below screenshot with the permission User.Invite.All added to the app. Keep in mind the permission requires Admin consent.

There is also delegated permission available for User.Invite.All.

Onboard External users to a SharePoint online site:

Once the Microsoft form is ready, we can start building the Power Automate flow which can send the email invitation to the external user and for granting access to the SharePoint site. The external sharing features of SharePoint Online enables users in your organization share content with people outside the organization. There is no limit to the number of guests you can invite to SharePoint sites as per this SharePoint online limits documentation. Find below steps to create the Power Automate flow with a custom approval on a Microsoft Team

Power Automate Flow:

Create an Automated flow with the trigger When a new response is submitted with the above form name selected on the dropdown and then add the action Get response details with the Response Id selected from the dynamic content for the trigger to get the form details submitted in the Microsoft form by the external user. Find screenshot below

Adaptive card for Teams Approval:

For the Approval in Microsoft Teams, I have used a custom card created from the Adaptive card designer with elements ColumnSet, TextBlock to display information submitted in the form & action button Approve and Reject to take further action by a Microsoft teams user to proceed with Invitation for the Guest account creation. Find screenshot below from the adaptive card designer

  1. After the card is designed, copy the card payload from the designer and go to the flow and then add the action Post adaptive card and wait for a response and make appropriate selection on the available fields as shown below
    • Post as: Flow bot
    • Post in: Channel
    • Message: Payload copied from designer. Replace the fields for usrName & userEmail selected from the dynamic content from the outputs of the action Get response details. The created on textBlock element has the flow expression formatDateTime(utcNow(),’g’) to display the current datetime information on the card.
  • Update Message: Custom message which appear after an action taken in Microsoft Teams
  • Team: Select the Team where you would like to post the card
  • Channel: Select the channel from the Microsoft Team where you would like to have the approval adaptive card posted

Card payload:

{
    "type": "AdaptiveCard",
    "body": [
        {
            "type": "TextBlock",
            "weight": "Bolder",
            "text": "Approval for adding the External User",
            "wrap": true
        },
        {
            "type": "TextBlock",
            "spacing": "None",
            "text": "Created Add flow expression to get current date",
            "isSubtle": true,
            "wrap": true
        },
        {
            "type": "ColumnSet",
            "columns": [
                {
                    "type": "Column",
                    "items": [
                        {
                            "type": "TextBlock",
                            "text": "Name:",
                            "wrap": true,
                            "size": "Medium",
                            "weight": "Bolder"
                        },
                        {
                            "type": "TextBlock",
                            "text": "Email:",
                            "wrap": true,
                            "weight": "Bolder",
                            "size": "Medium"
                        }
                    ],
                    "width": "stretch"
                },
                {
                    "type": "Column",
                    "width": "stretch",
                    "items": [
                        {
                            "type": "TextBlock",
                            "text": "usrName-Replace it from Microsoft Form",
                            "wrap": true
                        },
                        {
                            "type": "TextBlock",
                            "text": "userEmail-Replace it from Microsoft Form ",
                            "wrap": true
                        }
                    ]
                }
            ]
        }
    ],
    "actions": [
        {
            "type": "Action.Submit",
            "title": "Approve",
            "id": "btnApprove"
        },
        {
            "type": "Action.Submit",
            "title": "Reject",
            "id": "btnReject"
        }
    ],
    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
    "version": "1.0"
}
  1. The above adaptive card is used to get approval from the Organization teams user based on the information submitted by the external user in the Microsoft form to proceed with the next steps for sending the guest account invite. Now we will have to identify if the user has clicked the button Approve or Reject. This information can be easily obtained from the Outputs of the action.

Note: Adaptive card can also be sent using a Microsoft Graph API with the card payload in Attachments field

Adaptive card for Teams – Dynamic content Missing:

As of the time I am writing this article there is an issue in getting the output as dynamic content for the Post adaptive card and wait for a response action if there is dynamic content added on the JSON Payload (Name, Email from Forms). The fix is to run the flow till the post adaptive card action and take an action on Microsoft teams by clicking either Approve or Reject and then go to the Flow run from the history as shown below

From the above screenshot, we can see if the user has clicked the Approve or Reject button from the field submitActionId. To get this value in Flow, use the expression

outputs('Post_adaptive_card_and_wait_for_a_response').body.submitActionId

or

@outputs('Post_adaptive_card_and_wait_for_a_response')?['body/submitActionId']

Spaces in the name of the action is replaced with underscore.

To get the userPrincipalName, the expression is

outputs('Post_adaptive_card_and_wait_for_a_response').body.responder.userPrincipalName

or

@outputs('Post_adaptive_card_and_wait_for_a_response')?['body/responder/userPrincipalName']

To get the submitActionId, enter the expression outputs(‘Post_adaptive_card_and_wait_for_a_response’).body.submitActionId in the compose action, then add a condition control to decide action based on users approval

I have observed this issue occurs in other team’s adaptive card actions as well, the above fix should work. Now we can implement the logic to send the Guest Invitation using Microsoft Graph API. To send the invite, we will use the Azure AD application registered above.

Generate JSON Web token to Access Graph API:

Be ready with the ClientId, Client Secret and Tenant Id collected from the AD app registration you have done initially. The only authentication flow to generate a access token for application permissions is Client credentials.

To generate a token

  1. Store the Client Secret on a String variable or a compose action
  2. Make a HTTP request using the HTTP connector with the following details. Make sure to replace the string for tenantId, azureAdAppclientId and azureAdAppclientSecret

Add a HTTP connector action to the flow for making a POST request per the following information

HTTP Method: POST

URI: https://login.microsoftonline.com/yourtenantId/oauth2/v2.0/token

Headers: Content-Type: application/x-www-form-urlencoded

Body:

tenant=yourtenantId&client_id=azureAdAppclientId&client_secret=@{decodeUriComponent(variables('azureAdAppclientSecret'))}&grant_type=client_credentials&scope=https://graph.microsoft.com/.default

For the client secret make sure to URL encode using the expression encodeUriComponent(variables(‘clientSecret’)) else the request may fail due to the presence of special characters.

In the above screen, I have added a compose action to store the SharePoint site address to be used for granting the external user access to. To extract the token from the above request, add the parse JSON action with Content from the HTTP request body and the following schema

{
    "type": "object",
    "properties": {
        "token_type": {
            "type": "string"
        },
        "scope": {
            "type": "string"
        },
        "expires_in": {
            "type": "integer"
        },
        "ext_expires_in": {
            "type": "integer"
        },
        "access_token": {
            "type": "string"
        },
        "refresh_token": {
            "type": "string"
        }
    }
}

Include the access token when calling the Microsoft Graph API in the Headers section or raw as shown in the next section.

Send Invitation using Microsoft Graph API:

Before sending the invitation, validate if the user already exists in your organization AD tenant by using the email address of the external user with the help of the action Search for users as shown below

If there is null response for the action Search for users, then the user does not exist. This can be calculated using the expression length and by passing the value as a parameter, if it is equals zero then the external user does not exist. If the user already exists, we can directly proceed to granting the external user access to SharePoint.

Graph API to check if a guest user already exists:

https://graph.microsoft.com/v1.0/users?$filter=UserType eq ‘Guest’&$filter=mail eq exteruseremailaddress@domain.com’

or

https://graph.microsoft.com/v1.0/users?$filter=startswith(mail,’exteruseremailaddress@domain.com’)

Find below the Graph API endpoint http request details to invite the external user

Method: POST

URL: https://graph.microsoft.com/v1.0/invitations

Request Body:

{
  "invitedUserDisplayName": "External User Name",
  "invitedUserEmailAddress": "External User Email Address",
  "sendInvitationMessage": true,
  "inviteRedirectUrl": "SharePoint site URL or any URL",
  "invitedUserMessageInfo": {
    "messageLanguage": "en-US",
    "customizedMessageBody": "Welcome to the M365PAL SharePoint site! Click the link below and sign in."
  }
}

In HTTP request body, use the dynamic content of the form to populate the fields invitedUserDisplayName & Emailaddress. The invite redirectUri is the output of the compose action which has the SharePoint site url. I have added a delay of one minute before granting access to SharePoint site for the external user, this step is to make sure there is an entry in Azure AD for the external user/guest account.

Custom connector can be used for calling the Graph API for sending invitations instead of using HTTP connector, you can refer to the post Call Microsoft Graph API in Power Apps and Power Automate using a Custom connector for detailed instructions.

Grant Access to SharePoint site for the external user:

As soon as the guest account invite is sent from the above Microsoft graph API request HTTP action, it is time to grant access to the SharePoint site for the external user. There is a SharePoint REST API endpoint to add a user to a SharePoint group (Owners, Member, Visitors), find below the request details

Request URL: https://tenantname.sharepoint.com/sites/siteName/ _api/web/sitegroups/GetById(groupId)/users

For the groupId to the corresponding SharePoint group, refer to the following table

SharePoint GroupGroupId
Owners3
Members5
Visitors4

Headers:

Key: accept value: application/json;odata.metadata=none

Key: content-type value: application/json

Body:

{'LoginName':'i:0#.f|membership|userPrinipalNameorEmailaddressofExternalUser'}

For the external user, the email address used to send the invite works.

Go back to the flow and add the action Send an HTTP request to SharePoint to call the above REST api. Find below the screenshot of the action

The above action uses delegated permission, the user of the connection should have access to the SharePoint site. As of now, there is no Graph API for adding the user to a SharePoint group but you can register an app in Active directory and add permission for SharePoint to call the above REST API. Refer to the documentation Granting access via Azure AD App-Only for calling the REST API using the registered AD app.

Testing the flow:

The whole flow can now be tested by submitting the form which sends the adaptive card on Teams first as shown below

After the card is approved, the invite is sent to the external user. After the external user accepts the invite, the user should be automatically redirected to the SharePoint site with the appropriate access. The access to the SharePoint site for the external user can be validated by the checking the membership of the SharePoint group in the site even before the user accepts the invitation. The site members can also be validated by accessing the URL for All users list:

https://tenantName.sharepoint.com/sites/siteName/_layouts/15/people.aspx?MembershipGroupId=0

This approach of granting access to SharePoint site for external user can be applied to internal users by turning off the access requests.

Limit External Sharing by domain:

The external sharing on SharePoint can be restricted based on domain of the external user. To enable the setting login into the SharePoint admin center > Policies > Sharing > Enable the checkbox Limit external sharing by domain > Add domain

Onboard External users to a Microsoft Team:

To onboard the external user to a Microsoft Team, the only change to the above flow is, instead of adding the user to the SharePoint group the user must be added as a Member to the Microsoft 365 group connected to the Microsoft Teams. The graph API to add a member to a Microsoft Team is

Request Type: POST

Request URL: https://graph.microsoft.com/v1.0/teams/{team-id}/members

The team-id is the Microsoft 365 group object Id, as there is always a Microsoft 365 group connected to a Microsoft Team.

Body:

{
    "@odata.type": "#microsoft.graph.aadUserConversationMember",
    "roles": ["owner"],
    "user@odata.bind": "https://graph.microsoft.com/v1.0/users(userObjectIdofGuest')"
}

The expression to get the user object Id of the external user as per the below screenshot is

outputs(‘HTTP-SendGuestInvitation’).body.invitedUser.Id The expression can be used in a compose action to get the Object Id of the external user which can be used in the Graph API request to add the member to a Team. HTTP-SendGuestInvitation is the name of the HTTP Action.

Permission for the Azure AD App to add a member to a Microsoft Team:

The application permission Group.ReadWrite.All has to be added on the Azure AD app, if you are going to be using the same JSON webtoken generated above. There is delegated permission as well for adding members.

https://graph.microsoft.com/Group.ReadWrite.All

I recommend you read the following documentation from Microsoft for External sharing

https://docs.microsoft.com/en-us/microsoftteams/manage-external-access

https://docs.microsoft.com/en-us/microsoftteams/guest-access

https://docs.microsoft.com/en-us/microsoftteams/communicate-with-users-from-other-organizations

https://docs.microsoft.com/en-us/microsoft-365/community/managing-external-guest-in-sharepoint-vs-teams

Summary: With this, the Power Automate flow should send the invitation as shown below to the external user.

If it is for a Microsoft Team, the external user should be licensed for teams service to open it on their teams client. The same flow can be also configured for Microsoft 365 group. If you are visiting my blog for the first time, please do look at my other blogposts.

How to use Microsoft graph SharePoint Sites.Selected application permission in a Azure AD application for more granular control

As per this announcement made on Feb 2021, Microsoft graph now provides option to have granular permissions level using Sites.Selected application permission for the AD application instead of granting permission for all the sites in the tenant. The permission Sites.Selected does not provide access to any SharePoint site collections for the application unless the AD application has been assigned with permission roles read or write by an Admin. On this post let us see how to grant a site permission (Read or Write) to an AD Application with Sites.Selected permission by using postman client. As of the time I am writing this post there is no user interface to assign permissions to specific site collections for the application.

Pre-Requisite:

  1. Register Azure AD Application (APP 1) in Azure AD Portal with the following permissions
    • Sites.Selected (Admin Consented)
  2. Another AD Application (APP 2) with following permission only for the admins to assign selected roles to the above App
    • Sites.FullControl.All (Admin Consented)

App Registration:

Start with registering the above said two Azure AD applications

APP 1:

Register an Azure AD application with the following permission

APP 2 (Admin App):

Another app for admins for granting roles to APP 1

Grant permission role to the SharePoint site for the Azure AD Application:

This step is grant permission for the Azure AD application with Sites.Selected application permission to a given site collection. Perform the following steps to grant the role (Read/Write or Read and Write) to the AD app (APP 1)

  1. Gather the Client ID, Tenant ID and Client secret of the admin app
  2. In PostMan, make a HTTP request to generate the access token for the admin app – APP 2

Request Method: POST

Request URL: https://login.microsoftonline.com/yourtenantID/oauth2/v2.0/token

Request Header:

Key: Content-Type

Value: application/x-www-form-urlencoded

Request Body:

grant_type: client_credentials

scope: https://graph.microsoft.com/.default

client_id: adminappclientid

client_secret: adminappclientsecret

  1. Copy the access_token to be used for granting roles.
  2. Get the Client ID of the Azure AD Application – APP 1 with Sites.Selected permission
  3. Decide on the Role (Read or Write) for the granting the Site specific role for the APP 1 with Sites.Selected permission.
  4. Get the SiteId of the SharePoint site to be assigned permissions for the application (App 1). An easy way to get the siteId is by viewing the page source from the browser with the site open.
  5. In PostMan, make a HTTP request to grant the site role to the APP 1. Replace the siteId with the actual siteId which will be a guid

Request Method: POST

Request URL: https://graph.microsoft.com/v1.0/sites/siteId/permissions

Request Header:

Key: Content-Type

Value: application/json

Request Body: raw

Replace the id with APP 1 client id and the display name of the APP 1

{

  "roles": ["write"],

  "grantedToIdentities": [{

    "application": {

      "id": "xxxxxx-APP1GUID-4ad9-xxxx-4d36e68b0454",

      "displayName": "AppNamewithSelectedPermissions-App1"

    }

  }]

}
  1. Paste the access token on the token box as shown below with Authorization type selected as Bearer Token
  1. Send the request for granting the role for APP 1. After the request is made the APP 1 with the Sites.Selected permission has access to the site with write role we have granted to. The same way you can assign app access to multiple SharePoint sites.

Grant the Role using PnP PowerShell:

There is a PnP PowerShell cmdlet to grant access to SharePoint site for the registered AD application with Sites.Selected permission. The command to grant permission can be executed by the Site Collection administrator after creating a connection to the site

Connect-PnPOnline https://tenantname.sharepoint.com/sites/siteName -Interactive

You will be prompted to enter credentials including the second factor. After the connection is created, enter the following command to grant Write permission to the AD App

Grant-PnPAzureADAppSitePermission -AppId 'AzureAppIdwithSitesdotselectedpermission' -DisplayName 'App Name here' -Site 'https://tenantname.sharepoint.com/sites/sitename' -Permissions Write

To install PnP PowerShell module on the local workstation, enter the following command

Install-Module -Name PnP.PowerShell

There is also a PnP cmdlet to register an AD app in the Azure Active directory.

Grant the Role by an Admin using the Graph Explorer tool:

Role can also be assigned by an admin with out having the admin AD app (APP 2) using the graph explorer tool. This can be done only by an Admin

If there is any error related to permissions, make sure the admin consents to Sites.FullControl.All for the Graph tool. There is also an SPFx community webpart developed by a community member with User Interface for this operation

https://github.com/pnp/sp-dev-fx-webparts/tree/master/samples/react-sites-selected-admin

Reference:

Assign permission role programmatically: https://docs.microsoft.com/en-us/graph/api/site-post-permissions?view=graph-rest-1.0&tabs=csharp

Summary:

On this post we have seen how to grant access to Azure AD which has the Sites.Selected permission. You can also grant permission/role to an app with sites.selected permission programmatically. If you are using SharePoint API instead of Graph API in the Azure AD app registration, Sites.Selected is available on Application Permission as shown below

Hope you have found this informational & thanks for reading. If you are visiting my blog for the first time, please do look at my other blogposts.

Do you like this article?

Subscribe to my blog with your email address using the widget on the right side or on the bottom of this page to have new articles sent directly to your inbox the moment I publish them.

How to create & setup Dynamic Microsoft 365 Group or Distribution list based on the user’s domain for Teams, Yammer and Exchange

There are many organizations maintaining multiple domains on a single Microsoft 365 or Azure AD tenant, in those cases there might be a need to create dynamic Microsoft 365 groups, security groups & distributions list based on the user’s domain to manage the group’s membership. On this blogpost, let us see how to

  1. Create Dynamic Microsoft 365 group based on the user’s domain for Teams & Yammer
  2. Create a Dynamic distribution list based on user’s domain in Exchange online

To begin with let us see some basics of a Dynamic group. The membership of a dynamic group will automatically update as people join, leave, or move within the organization whenever the user’s Azure Active Directory attributes are changed. In simple terms, rules determines the group membership. The users will be added or removed automatically as and when the user attributes change or users join and leave the tenant which reduces the administrative effort of adding and removing users from a group. Dynamic group can be created based on variety of attributes including role, location, department etc.

Create Dynamic Microsoft 365 group based on the user’s domain for Teams & Yammer

Microsoft Teams and Yammer (Microsoft 365 Connected) supports dynamic membership. It enables the membership of Team or Yammer to be defined by one or more rules that check for certain attributes in Azure AD. Microsoft Teams & Yammer creates a Microsoft 365 group in Azure AD. For this post, the membership rule will be simple one which is based on the user’s domain and country. You can also have a complex rule involving multiple Azure AD attributes like Title, Geography, Department etc. Before we proceed further, there are some pre-requisite & facts to be considered before creating a dynamic group.

  • User Administrator or Global administrator role in Azure AD
  • Users you foresee to be part of a dynamic group membership rule should have an Azure AD premium License P1 or P2
    • Microsoft 365 E3, E5, Front line workers MF3 & MF1 has Azure AD premium 1 service which should suffice.
  • An Azure AD organization can have maximum of 5000 dynamic groups.
  • Any number of Azure AD resources can be members of a single group.

Dynamic Membership based on Domain for Teams:

To create a Dynamic membership MS team, create a Microsoft 365 group first with Dynamic membership in Azure Active directory. You can create a dynamic group from PowerShell but here I will be using Azure Ad GUI to create the dynamic Microsoft 365 group with rule to add users based on their domain and country. I have added a domain m365pal.me to my Azure AD tenant which I will be using here for this example.

  1. Sign in to Azure AD Admin center with administrator role in the Azure AD organization
  2. Click Groups and then click + New Group
  3. Select the Group type as Microsoft 365. Dynamic membership will also work with Security group but for team it should be Microsoft 365 group.
  4. Enter the Group Name & Group email address
  5. Select the Membership type as Dynamic User
  6. Select the Owner and then
  7. Under Dynamic user members section, click Add dynamic query
  8. In Dynamic membership rules panel, add rule to define membership based on users domain & country
    • First rule for Domain: under Property column select userPrinicipalName, Operator should be Contains and the Value should be the domain name in format “@yourdomain.com”. This rule will add all users with the UPN user@yourdomain.com. Now click + Add expression to add the second rule
    • Second rule for country: under Property column select country, Operator should be  Equals and the value should be the country name.
  1. You can also validate the rules by clicking the link Validate Rules and then by adding users to check if the user satisfies the rule
  2. Click Save. This is how it should look like
  1. Click Create.
  2. After waiting for couple of minutes, check the group membership. Please find below screenshot for the group which has two members satisfying the condition. You can also notice the + Add members link is disabled since the group is dynamic membership and not assigned. To modify the rules, click the link Dynamic membership rules link.
  1. Now we are ready to create the MS Teams, go to https://teams.microsoft.com/ and then click Join or create a team at the left bottom corner and then Click Create a team
  2. Click From a group or team and then click Microsoft 365 group
  3. Now select the group you have created in Azure AD and then click Create.
  1. The team is now created, you can find the team on the list. Check the membership of the team which will have the two users satisfying the rules and the owner of the group. One more thing to notice here is the message which says The membership settings prevents you from adding or removing members.
  1. Voila! Dynamic Microsoft team is now created & setup.

If you have an existing team to be converted to a Dynamic team, find the Microsoft 365 group in Azure AD for the Team you wish to convert and then update the membership status from Assigned to Dynamic user with membership rules

Dynamic Membership based on Domain for Yammer:

Yammer (Microsoft 365 Connected) also supports dynamic membership. Find the steps below to create a dynamic yammer group based on the user’s domain. Find the steps below

  1. Sign in to https://yammer.com/ with your organizational ID
  2. Click Create a Community and then Enter the name of the Community
  3. Click the button Create
  1. Now sign in to Azure AD Admin center to the update the membership settings of the Microsoft 365 group connected to the Yammer community. Find the yammer group and then click
  1. Click Properties under the Manage blade and then change the membership type from Assigned to Dynamic user
  1. After updating the membership type to Dynamic user. You will now have option to enter the dynamic query. Click dynamic query
  1. In Dynamic membership rules panel, add rule to define membership based on users domain
    • Rule for Domain: under Property column select userPrinicipalName, Operator should be Contains and the Value should be the domain name in format “@yourdomain.com”. This rule will add all users with the UPN user@yourdomain.com. Now click + Add expression to add rules based on need
    • Click Save
  1. Click Save. Wait for couple of minutes for the membership to be updated.
  2. Now check the Yammer group in Yammer.com for the membership status. Please find below screenshot for your reference which will not have the + icon on the highlighted members section for adding users since this is now a dynamic yammer group

Also, Microsoft 365 group/Security group can be used for different use cases. See some sample use cases below

  • You can use to target SharePoint page/news to specific audience with the help of Microsoft 365 group or Security group. Will it not be more powerful if you use dynamic groups within a SharePoint to target content certain group of audience!
  • Assign Microsoft Licenses to users based on Dynamic Group.
  • Grant access to an App (PowerApps etc) using the dynamic group targeting certain departments, geographies etc

Reference:

https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/groups-create-rule

https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/groups-dynamic-membership

https://docs.microsoft.com/en-us/microsoftteams/dynamic-memberships

https://docs.microsoft.com/en-us/yammer/manage-yammer-groups/create-a-dynamic-group

https://docs.microsoft.com/en-us/yammer/manage-yammer-groups/yammer-and-office-365-groups

https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/directory-service-limits-restrictions

Create a Dynamic distribution list based on user’s domain in Exchange online:

Dynamic distribution groups are mail-enabled Active Directory group to distribute email messages to all its members within a Microsoft Exchange organization. Unlike regular distribution lists that contain a defined set of members, the membership list for dynamic distribution groups is calculated each time a message is sent to the group, based on the filters and conditions that you define in the group. You can create a Dynamic Distribution list from Exchange Admin center as shown below but the options to write advanced filter conditions or rules are limited so PowerShell is preferred.

Dynamic Distribution list from PowerShell:

Make sure the Exchange online PowerShell module is installed. There are some limitations to create a recipient filter (Rules) that worked based on user’s domain with the operator like or contains but there is a workaround. The filter works based on the exchange property WindowsEmailAddress which is always the primary SMTP address, you can also consider using the property WindowsLiveID. Follow the steps below to create a Dynamic Distribution list based on user’s domain

  1. Load the module by the running the command Import-Module ExchangeOnlineManagement
  2. Connect to the Exchange online PowerShell in Microsoft 365
Connect-ExchangeOnline -UserPrincipalName userId@domain.com -ShowProgress $true
  1. After authentication, enter the following command to create the Dynamic DL based on User’s domain. I have added the RecipientTypeDetails in the RecipientFilter to apply the filter rule only to user mailboxes which excludes the SharedMailboxes
New-DynamicDistributionGroup -Name "All Users - M365PAL DL" -RecipientFilter "(RecipientTypeDetails -eq 'UserMailbox') -and (WindowsEmailAddress -eq '*@yourdomain.com')"
  1. You can also validate the users using the following script
Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup "All Users - M365PAL DL").RecipientFilter
  1. To view the attributes to be used in the recipient filter enter the following command
Get-User -Identity user@yourdomain.com | Format-List

Reference:

https://docs.microsoft.com/en-us/exchange/recipients/dynamic-distribution-groups/dynamic-distribution-groups

https://docs.microsoft.com/en-us/powershell/module/exchange/get-user

https://docs.microsoft.com/en-us/exchange/recipients/dynamic-distribution-groups/view-dynamic-distribution-group-members

Summary: On this post we have seen how to create dynamic groups based on user’s domain. Do some planning to start using the dynamic groups which will help reduce lot of administrative overhead. Hope you have found this informational & helpful. Let me know any feedback or comments on the comment section below

How to use your MS Teams as an email distribution list

When you create a Microsoft Team, a Microsoft 365 group is created to manage the team membership like Owners, members, guests. I would rather say the Microsoft 365 group is a backbone of a Team. Through the group you also get an email address for the MS team. Find the other Microsoft 365 services which gets created per this documentation whenever there is a Team provisioned

On this blogpost let us see how to enable a team which can also act as an email distribution list so that you can send an email to all the team members, by default this option is disabled. You will have to be an Owner of the team to set this up. There are couple of ways to do this

  • Graph Explorer
  • Outlook
  • Exchange Online Powershell
  • Exchange Online Administrator

Graph Explorer:

Graph explorer is a utility that will let you make requests and get responses against the different graph endpoints as a signed in user (Delegated User). To enable the email distribution functionality, we will have to get the group id of the team for setting a value to True for the property autoSubscribeNewMembers. To get the Group Id information go to the Team and click the Get link to team as shown below

Copy the content from the popup which should be in the below format

To get the group details like Email Address, Mail Nick Name, Display Name etc make a GET request to the following endpoint from the explorer

https://graph.microsoft.com/v1.0/groups/groupId

Make a PATCH request to the endpoint https://graph.microsoft.com/v1.0/groups/groupId with the payload

{
“autoSubscribeNewMembers”:true
}

Now make a GET request on the following endpoint with the group id of the team https://graph.microsoft.com/v1.0/groups/groupId?$select=autoSubscribeNewMembers

to get its status. It is all set now.

Outlook:

The Microsoft 365 group inbox for a Team is not available in Outlook but it can be accessed through the SharePoint site associated to the group. Open the SharePoint site from any of the Teams channel as shown below

Click Conversations on the left navigation

The URL of the Outlook will be in following format: https://outlook.office365.com/mail/group/domain/mailNickName/email

Access the settings of the group

Click Edit group from the Group Settings

On the Group Settings popup, enable the Subscription as shown below and then Save it. By default this setting is disabled for the Microsoft 365 group.

Exchange Online PowerShell:

The same setting can also be enabled from Exchange online PowerShell if you have Exchange online Administrator access on the tenant. Make sure the Exchange online PowerShell module is installed. Follow the steps below to turn on AutoSubscribeNewMembers which distributes emails to all users

  1. Load the module by the running the command Import-Module ExchangeOnlineManagement
  2. Connect to the Exchange online PowerShell in Microsoft 365
    1. Connect-ExchangeOnline -UserPrincipalName userId@domain.com -ShowProgress $true
  3. Set-UnifiedGroup -Identity 539818c4-XXXX-XXXX-b781-78dff1762b72 -AutoSubscribeNewMembers or Set-UnifiedGroup -Identity “Team Display Name” -AutoSubscribeNewMembers
  4. To disable the setting: Set-UnifiedGroup -Identity ” Team Display Name ” -AutoSubscribeNewMembers:$false

Refer to the documentation from Microsoft for more Exchange online commands related to the Microsoft 365 group.

Exchange Online Administrator

Login into the Exchange Online Admin center and click on Groups from the dashboard section. Execute the below steps

  1. Find the group associated to the team (Team Display Name) from the list and then select
  2. Click on Edit (Pencil Icon) from the ribbon
  3. On the General tab, Enable the property Subscribe new members and then Save

Summary: The same setting can also be applied to a Team created through a Microsoft 365 group. Hope you have found this informational. There were already lot of blogs talking about groups

Reference:

https://support.microsoft.com/en-us/office/learn-about-microsoft-365-groups-b565caa1-5c40-40ef-9915-60fdb2d97fa2

https://support.microsoft.com/en-us/office/follow-a-group-in-outlook-e147fc19-f548-4cd2-834f-80c6235b7c36#ID0EAACAAA=Web

https://sharegate.com/blog/office-365-groups-explained

https://www.jumpto365.com/blog/everyday-guide-to-office-365-groups

How to setup custom domain and email address in Microsoft 365 online tenant

On this blogpost let us see how to add a custom domain and configure exchange email address for the added domain in a Microsoft 365 tenant. This will allow you to create M365 identities for the users in the Microsoft 365 tenant like user@domain.com instead of user@domain.onmicrosoft.com. This setup is also required if you have a Hybrid setup with users from Onpremise Active directory. Azure AD connect tool helps you synchronize your AD identity from Onpremise to Azure AD or Microsoft 365 tenant directory only if there is a custom domain added to the directory. The custom domain can be added from Microsoft 365 tenant admin center or Azure Active directory portal associated to the M365 tenant.  

Pre-Requisites:

  • Own a Domain from any domain providers
  • Global administrator of Microsoft 365 tenant

If you don’t add a domain, user account in your organization will use the default onmicrosoft.com domain for their email address and UPN. To setup and configure a custom domain, you will have to

  1. Add a TXT or MX record
  2. Add DNS records to connect Microsoft 365 services

For this blog post I have used Domain.com provider to add the DNS records for the custom domain

Add a TXT or MX record:

The first step is to prove you are Owner of the domain and also make the domain is not associated to different tenant. To generate the DNS record values and to add the custom domain login to the Microsoft 365 Admin Center

  1. Select Show all > Settings > Domains
  2. Click Add domain
  3. Enter the custom domain name you own
  4. Click on the button Use this domain

Select Add a TXT record to the domain’s DNS records but you can also add a MX record or add a text file to the domain’s website. Find the different options

  1. The DNS record values for the TXT record will be generated as shown below. TTL 3600 seconds is 1 hour
  1. Add the DNS record for TXT from the domain provider interface for managing the records
  1. Go back to the Admin center and then click Verify. It takes around 15 mins to an hour for the DNS records to propagate, sometimes it may even take more time. Keep trying till the domain in verified. Once the domain is verified you will be able to proceed to the next step for configuring the Microsoft 365 services like exchange etc. You can also Skip and do the configuration later but with this setup you can create user accounts by using the custom domain as its UPN e.x user@domain.com without email address. Find instructions on this link to add a custom domain from Azure Active directory portal.

Add DNS records to connect Microsoft 365 services:

The domain is added & verified, now its time to connect the Microsoft services like Email (Exchange Online, Outlook), Mobile device Management aka MDM with the custom domain. On this post will be connecting only to Exchange online to receive email through Microsoft 365. After this setup is done Exchange online will be your new email host for the domain. After the domain is verified from the step above, select Add your own DNS records and click Continue button as shown below

The following DNS records will be generated as shown below

  • MX Records (Mandatory)
    • Sends incoming mail for your domain to the Exchange Online service in Office 365. Mails are delivered to the mail exchange server with the lowest preference number for this record, typically.
  • CNAME Records (Optional: For Outlook client to work)
    • Helps Outlook clients to easily connect to the Exchange Online service by using the Autodiscover service. Autodiscover automatically finds the correct Exchange Server host and configures Outlook for users
  • TXT Records (Optional: SPF record for prevention of spamming)
    • Helps to prevent other people from using your domain to send spam or other malicious email. Sender policy framework (SPF) records work by identifying the servers that are authorized to send email from your domain

Go back to the domain hosting provider interface to add the above DNS records, to get the values for each record expand each record shown on the above interface.

MX Record:

Set the priority to the Highest or to the number 0 and then add the DNS record. If the domain is xyz.com

Sample value/Content: xyz-com.mail.protection.outlook.com

CNAME Records:

Name: Autodiscover

Value/content: autodiscover.outlook.com

TTL: 1 hour

TXT Records (SPF):

There can be only one SPF record on the DNS records so if there are another record already (default), refer this link for more information. I already had the default one so the valye for the TXT record looked like v=spf1 ip5:XX.XX.XXX.X/XX include:spf.protection.outlook.com -all

ipX:XX.XX.XXX.X/XX is the default one

Now after all the DNS records are added, choose Continue. This will take you to the last page of the wizard with the message Domain setup is complete

Now the setup is completed, you can create users using the new custom domain or change an existing users UPN and email address on Admin center with the following steps

  1. Go to Users > Active users page
  2. Select the user’s name, and then on the Account tab select Manage username.
  3. On the Aliases box, enter the new alias@yourdomain.com and then click Add
  4. Select the new alias and if required change it to the primary email.

Summary: On this post we have seen how to configure a custom domain with email. There can also be multiple domains in one tenant. Hope you have found this informational. Let me know any feedback or comments on the comment section below

Reference:

https://docs.microsoft.com/en-us/microsoft-365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider

https://support.microsoft.com/en-us/office/connect-your-domain-to-office-365-cd74b4fa-6d34-4669-9937-ed178ac84515

https://docs.microsoft.com/en-us/microsoft-365/admin/setup/add-domain

https://support.microsoft.com/en-us/office/add-a-new-domain-in-microsoft-office-365-285437c3-d6c9-45cd-8b48-ed29c670c796

https://docs.microsoft.com/en-us/microsoft-365/admin/setup/domains-faq?view=o365-worldwide

https://docs.microsoft.com/en-us/microsoft-365/enterprise/external-domain-name-system-records

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/set-up-spf-in-office-365-to-help-prevent-spoofing?view=o365-worldwide

Tools to call Microsoft Graph API endpoints as a User and application

This blogpost will help you to explore and interact with MS graph API endpoint’s using the following tools

  • Postman client
    • Signed in as a user/On-behalf-of API call (Delegated permission)
    • Application/daemon API call (Application permissions)
  • Graph Explorer

I have used MS graph extensively on different MS cloud services like SharePoint, PowerAutomate, PowerApps, Azure services like Azure functions and on devices like Raspberry Pi. It is a very powerful service in Microsoft 365 platform. Let start with some basics

Introduction:

MS Graph API is a RESTful web API which enables you to access different Microsoft 365 cloud service resources through its unified programmability model.

Microsoft Graph exposes REST APIs and client libraries to access data on the following Microsoft cloud services:

  • Microsoft 365 services: Delve, Excel, Microsoft Bookings, Microsoft Teams, OneDrive, OneNote, Outlook/Exchange, Planner, SharePoint, Workplace Analytics.
  • Enterprise Mobility and Security services: Advanced Threat Analytics, Advanced Threat Protection, Azure Active Directory, Identity Manager, and Intune.
  • Windows 10 services: activities, devices, notifications, Universal Print (preview).
  • Dynamics 365 Business Central.

Permission Types:

MS Graph exposes granular permissions that controls the access of the apps that has to the different resources like sites, users, groups etc. There are two types of permission

  • Delegated permissions are used by apps that have a signed-in user present. For these apps, either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph.
  • Application permissions are used by apps that run without a signed-in user present. For e.g Apps that run as background services or daemons. Application permissions can only be consented by an administrator.

Access token:

To call a MS Graph API all you need is an access token in the authorization header of an HTTP request.

GET https://graph.microsoft.com/v1.0/me/ HTTP/1.1

Host: graph.microsoft.com

Authorization: Bearer EwAoA8l6BAAU … 7PqHGsykYj7A0XqHCjbKKgWSkcAg==

The access tokens are issued by the Microsoft identity platform which contains information to validate if the requestor has appropriate permissions to perform the operation they are requesting. An active directory app is a pre-requisite to generate an access token to call a Graph API endpoint.

There are also Microsoft identity platform authentication libraries for .NET, JS Android, Objective-C, Python, Java, Angular facilitating validation, cookie handling, token caching and on maintaining a secure connection. Let’s now go ahead and see the tools

MS Graph Explorer:

Graph explorer is a web-based tool which can be used to build and test requests using Microsoft Graph API. The explorer can be accessed from the following URL:

https://developer.microsoft.com/en-us/graph/graph-explorer

There will be a default Active directory application on the Organizational Active directory of the M365 tenant by the name Graph Explorer with application id de8bc8b5-d9f9-48b1-a8ad-b748da725064. This app can be accessed from the Enterprise applications blade of the Active directory as shown below

Delegated permissions are used by Graph Explorer. Based on your access role & admin consent’s you would be able to call different Microsoft Graph API from this tool. After you have signed into the Graph Explorer tool, the access token will be generated automatically

To view the token information, copy the token and paste it on the utility https://jwt.ms/

If your token has a scp (Scope) claim, then it’s a user based token (Delegated permissions). It is a JSON string containing a space separated list of scope the use has access to call different graph endpoints. You can also find other information related to the issued token, token issued at (iat), expirty not before (nbf), expiry time (exp). The data is in UNIX time stamp but you can convert this information to standard time using the online URL

https://www.epochconverter.com/

More information about JWT can be found at

https://auth0.com/docs/tokens/json-web-tokens

Postman Client:

Postman is a tool that can be used to build and test requests using the Microsoft graph API’s. To use this tool for testing the Graph API endpoint’s, register an app in Azure Active directory as per the instructions from this blog post. Provide the permission (Delegated & Application) as per your need to test it using Postman.

Copy the client id, client secret & tenant ID of the registered app. To access the various endpoints like authorization and token, click on the Endpoints from the Overview section of the Active directory app.

Setting up the environment using Postman collections:

There are Postman collections with many MS graph API requests created by Microsoft for us to explore. Import the collections and setup the environment (Client ID, Client secret, tenant id) for Application API calls and on-behalf-of API calls as per the instruction from the following article

https://docs.microsoft.com/en-us/graph/use-postman

Application API Token:

To generate an application token, make a POST request to Get App-Only Access Token from the collection Microsoft Graph. The grant_type is client_credentials since it is Application permissions.

Token Validity:

The token is valid for 3599 seconds which is 1 hour. Post that the token will expire, you will have to regenerate the token by making another call.

The AccessToken (Application API call) will be generated and automatically stored on the Environment (Microsoft Graph environment) AppAccessToken with the help of a script on the Tests tab in Postman. Copy the access token value & paste it on the utility https://jwt.ms/. Find the decoded token below which has information like the Application ID/client id of the AD app, display name and roles to which the app has access to poll the graph endpoint.

Graph API call:

The call to the Graph should have the bearer token

Signed-in user/on-behalf-of API Token:

To generate a Signed-in user token, make a POST request to Get user Access Token from the collection Microsoft Graph. The grant_type is password since it is delegated permissions.

The AccessToken (Signed-in user API call) will be generated and automatically stored on the Environment (Microsoft Graph environment) UserAccessToken with the help of a script on the Tests tab in Postman.

Copy the access token value & paste it on the utility https://jwt.ms/. Find the decoded token below which has information like the Application ID/client id of the AD app, display name and scopes (scp) to which the app has access to poll the graph endpoint. If you remember the Application API token had roles & not scopes, so this is how you can identify the token type.

Storing the production User ID and password is not recommended on the Environmental variables since the information is stored in Postman but this can be handled by generating an access token from the request Authorization tab, set the type as OAuth 2.0 and click Get New Access Token button

Fill in all the information gathered from the App in Azure AD like Appid, Secret, Endpoints (Authorization and Token), state can be any random value

Click Request token, this will prompt the user to enter the Username and password. After authentication, it will generate the token which could be used further to make API calls.

Graph API call:

The call to the Graph should have the bearer token on the Authorization tab or on the Headers tab

Summary: On this post we have seen how to use tools like Graph explorer & Postman to test different MS graph API endpoints. You can make requests like GET, POST, PUT, PATCH, DELETE based on its availability. Refer to the Microsoft documentation for v1.0 and beta endpoints. Once you have explored & tested the API, you are ready to use on applications using the available SDK’s for different programming languages. Let me know any feedback or comments on the comment section below