• Introduction
• History & Background
• Part 1: Application Authentication — Azure AD Application Registrations (you are here)
• Part 2: Request Storage — SharePoint
• Part 3: Request Process Automation — Microsoft Power Automate & Microsoft Graph
• Part 4: Enhanced User Interface — PowerApps
• Part 5: Next Steps — Security

As you’ve read in the opening “how did we get here” post, we landed on a combination of a number of Microsoft cloud services that allow us to pull this off. One of the major pieces required for all this stuff to work is that this process requires the proper level of access and permissions.

Enter Azure Active Directory Application Registrations.

An AAD AppReg is a required item for this process. It is the plumbing that we’ll need for our flow to use, when calling the relevant operations in the Microsoft Graph. This App Reg can be tailored and scoped to do only specific operations, as well as secured so that a token is required for it to be used. More information on application registrations can be found here. But, let’s walk through setting up the one we need for our desired process.

Step 1: Create a New App Registration

This is the easy step. We’ll need to create this app reg first, and then tailor it with the relevant permission and security bits. So, from the Overview page (figure 1 above) select New Registration. A new pane will appear to enter some information in (figure 2 below).

Enter the name that you’d like for this registration. As we’re only dealing with this process starting from within our tenant we’ll stick with the default account type of Single Tenant. For the Redirect URI enter https://localhost. After clicking Register you’ll see the following Overview pane for your brand new App Reg (figure 3). Note the IDs have been obscured to protect the innocent.

Step 2: Set Up API Permissions

To provide a wee bit more security, as well as scope the actual operation(s) that our process will utilize, we need to grant it the relevant permissions to the APIs that it needs to use. To do this we click View API Permissions. This results in a blade that shows what permissions this registration currently has (Figure 4 below).

Basically, this area allows us to assign the relevant permissions that our process will use in this registration. How do we do this? Well, we start with clicking +Add a permission. This surfaces to us the various APIs we can utilize. For our process here we’re all about the Microsoft Graph. So that’s what we select (Figure 5: API Permissions).

Because we’re utilizing Flow for this, and want our process to execute, we select Application permission type(Figure 6).

After selecting the type we need to select the specific permissions we want this registration to govern. Because we like following least-privilege, we’ll only want to give this registration the minimum required permissions to execute our process. Per the Microsoft Graph documentation we only need 2 permissions for the Create Team operation and the Update Group Setting operation. Select these two, and click Add Permissions (Figure 7).

After adding the relevant permissions you’ll be returned to the API permissions page and it should look something akin to the below (figure 8).

Again, in the spirit of least-privilege, we want to be using only the permissions required by this operation. So, we should remove the User.Read permission from this area. Select that permission, then select Remove Permission from the flyout that appears.

After removing the permission, we need to proactively grant consent to the tenant, so that our users who want to request teams can do so through our process. We can do so by clicking the Grant admin consent for Contoso button. This action grants consent for the entire tenant, so the organization’s users won’t see a consent page for the application.

Step 3: Create a Client Secret

In order for us to properly secure this registration, so that only those that have the proper credentials can call it, we need to set up a Client Secret. This secret will allow us to request a token that can be used for this call. To start, click on +New client secret.

Secrets can expire in 1 year, 2 years, or never expire. Enter the name of it (in the Description field), pick an expiration, then click Add.

Note that after you add the client secret you are shown its value. It is *extremely* important you copy/paste this for later as after you leave/sign out, signing back in will not give you access to the actual value. We will need this when we get to our flow, so store this in a safe place.

Conclusion

At this point you’ve created a new AAD App Registration for us to use in our process going forward. In our next article we’ll spin up a SharePoint Online site and list to hold our Team requests.

About the Author:

Michael Mukalian is the Modern Workplace Technical Architect at the Microsoft Technology Center in Philadelphia (Malvern), PA. covering Office 365. He is co-owner of the Tri-State Office 365 User Group (https://www.meetup.com/TSSPUG/), was a contributing author on the SharePoint 2010 Administrator’s Pocket Consultant, speaks at a number of SharePoint Saturdays and Code Camps around the country and was awarded Microsoft’s MVP award in CY2010 for SharePoint Services. With over 25 years of IT experience and certifications in SharePoint and Office 365, Michael has architected and developed solutions for enterprises of all sizes.

Reference:

Mukalian, M. (2019). Automating the Provisioning of Selective Teams with Guest Access: Part 1 — Azure AD App Registrations. Available at: https://medium.com/@michael.mukalian/automating-the-provisioning-of-selective-teams-with-guest-access-part-1-azure-ad-app-ef1498ebf8f9 [Accessed: 18th February 2020].

Check out more great Microsoft Teams content here or join our mailing list to stay up to date.