The Complete Guide To Azure Ad App Registration

An Azure AD App Registration (or AAD AppReg) provides the ability for the application we’re creating to communicate with the Microsoft Graph. This will not only provide the access to the Graph, but to the specific operations in the Graph required to perform our scenario.

Each application you want the Microsoft identity platform to perform identity and access management (IAM) for needs to be registered. Whether it’s a client application like a web or mobile app, or it’s a web API that backs a client app, registering it establishes a trust relationship between your application and the identity provider, the Microsoft identity platform.

Prerequisites

• Ensure that you have an active Office 365 subscription.
• Ensure that you have an Office 365 administrative user ID and password.

Create a new Azure AD Application Registration

Registering your application establishes a trust relationship between your app and the Microsoft identity platform. The trust is unidirectional: your app trusts the Microsoft identity platform, and not the other way around.

Follow these steps to create the app registration:

• Go to Azure portal
• Sign in with your tenant admin credentials
• Select Azure Active Directory

• Under manage, select App registrations

• Select new registration on the top

Enter the following details for your AAD authentication

Name: U#CreateTeam
Where U# = the letter ‘U’ and the number in your user id, for example User1 would be U1CreateApp
Supported account type: Accounts in this organizational directory only
Redirect URI: Web; https://localhost

Configure APIs for Configuration

• After the app is registered, click API permissions on the left

• Click Add a permission

• Select the Microsoft Graph API box

• Select the Application permissions box

• Scroll down and expand the Directory node and select Directory.ReadWrite.All

• Scroll down and expand the Group node and select Group.ReadWrite.All

• Click add permissions as the bottom of the list

• Click Grant admin consent for…

• Answer Yes for Do you want to grant consent for the requested permissions for all accounts in…

• Make sure the green check marks appear for the permissions listed.

Azure AD app registration permissions

In Azure AD, you can delegate Application creation and management permissions in the following ways:

• Restricting who can create applications and manage the applications they create. By default in Azure AD, all users can register application registrations and manage all aspects of applications they create. This can be restricted to only allow selected people that permission.
• Assigning one or more owners to an application. This is a simple way to grant someone the ability to manage all aspects of Azure AD configuration for a specific application.
• Assigning a built-in administrative role that grants access to manage configuration in Azure AD for all applications. This is the recommended way to grant IT experts access to manage broad application configuration permissions without granting the access to manage other parts of Azure AD not related to application configuration.
• Creating a custom role defining very specific permissions and assigning it to someone either to the scope of a single application as a limited owner, or at the directory scope (all applications) as a limited administrator.

It’s important to consider granting access using one of the above methods for two reasons. First, delegating the ability to perform administrative tasks reduces global administrator overhead. Second, using limited permissions improve your security posture and reduces the potential for unauthorized access. Delegation issues and general guidelines are discussed in Delegate administration in Azure Active Directory.

Restrict who can create applications

By default in Azure AD, all users can register application registrations and manage all aspects of applications they create. Everyone also has the ability to consent to apps accessing company data on their behalf. You can choose to selectively grant those permissions by setting the global switches to ‘No’ and adding the selected users to the Application Developer role.

To disable the default ability to create application registrations or consent to applications

1. Sign in to your Azure AD organization with an account that eligible for the Global administrator role in your Azure AD organization.
2. Set one or both of the following:On the User settings page for your organization, set the Users can register applications setting to No. This will disable the default ability for users to create application registrations.On the user settings for enterprise applications, set the Users can consent to applications accessing company data on their behalf setting to No. This will disable the default ability for users to consent to applications accessing company data on their behalf.

Grant individual permissions

Assign the Application developer role to grant the ability to create application registrations when the Users can register applications setting is set to No. This role also grants permission to consent on one’s own behalf when the Users can consent to apps accessing company data on their behalf setting is set to No. As a system behavior, when a user creates a new application registration, they are automatically added as the first owner. Ownership permissions give the user the ability to manage all aspects of an application registration or enterprise application that they own.

Assign application owners

Assigning owners is a simple way to grant the ability to manage all aspects of Azure AD configuration for a specific application registration or enterprise application. As a system behavior, when a user creates a new application registration they are automatically added as the first owner. Ownership permissions give the user the ability to manage all aspects of an application registration or enterprise application that they own. The original owner can be removed and additional owners can be added.

Enterprise application owners

As an owner, a user can manage the organization-specific configuration of the enterprise application, such as the single sign-on configuration, provisioning, and user assignments. An owner can also add or remove other owners. Unlike Global administrators, owners can manage only the enterprise applications they own.

In some cases, enterprise applications created from the application gallery include both an enterprise application and an application registration. When this is true, adding an owner to the enterprise application automatically adds the owner to the corresponding application registration as an owner.

To assign an owner to an enterprise application

1. Sign in to your Azure AD organization with an account that eligible for the Application administrator or Cloud application administrator for the organization.
2. On the App registrations page for the organization, select an app to open the Overview page for the app.
3. Select Owners to see the list of the owners for the app.
4. Select Add to select one or more owners to add to the app.

Assign built-in application admin roles

Azure AD had a set of built-in admin roles for granting access to manage configuration in Azure AD for all applications. These roles are the recommended way to grant IT experts access to manage broad application configuration permissions without granting access to manage other parts of Azure AD not related to application configuration.

• Application Administrator: Users in this role can create and manage all aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to consent to delegate permissions, and application permissions excluding Microsoft Graph. Users assigned to this role are not added as owners when creating new application registrations or enterprise applications.
• Cloud Application Administrator: Users in this role have the same permissions as the Application Administrator role, excluding the ability to manage application proxy. Users assigned to this role are not added as owners when creating new application registrations or enterprise applications.

For more information and to view the description for these roles, see the Available roles.

Follow the instructions in the Assign roles to users with Azure Active Directory how-to guide to assign the Application Administrator or Cloud Application Administrator roles.

Create and assign a custom role (preview)

Creating custom roles and assigning custom roles are separate steps:

• Create a custom role definition and add permissions to it from a preset list. These are the same permissions used in the built-in roles.
• Create a role assignment to assign the custom role.

This separation allows you to create a single role definition and then assign it many times at different scopes. A custom role can be assigned at organization-wide scope, or it can be assigned at the scope if a single Azure AD object. An example of an object scope is a single app registration. Using different scopes, the same role definition can be assigned to Sally overall app registrations in the organization and then to Naveen over only the Contoso Expense Reports app registration.

Tips when creating and using custom roles for delegating application management:

• Custom roles only grant access in the most current app registration blades of the Azure AD portal. They do not grant access in the legacy app registrations blades.
• Custom roles do not grant access to the Azure AD portal when the “Restrict access to Azure AD administration portal” user setting is set to Yes.
• App registrations the user has access to using role assignments only show up in the ‘All applications’ tab on the App registration page. They do not show up in the ‘Owned applications’ tab.

For more information on the basics of custom roles, see the custom roles overview, as well as how to create a custom role and how to assign a role.

Configure Secret for the App Registration

• Select Certificates & secrets

• Scroll to the bottom and select new client secret

Enter the following details for your client secret:

Description: U#CreateAppSecret
Where U# = the letter ‘U’ and the number in your user id, for example User1 would be U1CreateAppSecret
Expires: Never

• Click Add

1. Copy the generated secret value and place it in Notepad

Note: this must be done as the secret value display will disappear and cannot be copied later

• Click overview

Copy the Application (client) ID and Directory (tenant) ID and keep them with your secret.

When registration completes, the Azure portal displays the app registration’s Overview pane, which includes its Application (client) ID. Also referred to as just client ID, this value uniquely identifies your application in the Microsoft identity platform.

Your application’s code, or more typically an authentication library used in your application, also uses the client ID as one aspect in validating the security tokens it receives from the identity platform.

Azure ad app registration reply url

A redirect URI, or reply URL, is the location where the authorization server sends the user once the app has been successfully authorized and granted an authorization code or access token. The authorization server sends the code or token to the redirect URI, so it’s important you register the correct location as a part of the app registration process.

The following restrictions apply to redirect URIs:

• The redirect URI must begin with the scheme https. There are some exceptions for localhost redirect URIs.
• The redirect URI is case-sensitive. Its case must match the case of the URL path of your running application. For example, if your application includes as part of its path .../abc/response-oidc, do not specify .../ABC/response-oidc in the redirect URI. Because the web browser treats paths as case-sensitive, cookies associated with .../abc/response-oidc may be excluded if redirected to the case-mismatched .../ABC/response-oidc URL.

Maximum number of redirect URIs

This table shows the maximum number of redirect URIs you can add to an app registration in the Microsoft identity platform.

Accounts being signed in

Maximum number of redirect URIs

Description

Microsoft work or school accounts in any organization’s Azure Active Directory (Azure AD) tenant

256

signInAudience field in the application manifest is set to either AzureADMyOrg or AzureADMultipleOrgs

Personal Microsoft accounts and work and school accounts

100

signInAudience field in the application manifest is set to AzureADandPersonalMicrosoftAccount

Maximum URI length

You can use a maximum of 256 characters for each redirect URI you add to an app registration.

Also Read:

https://techieberry.com/securing-azure-functions/https://techieberry.com/azure-automation-account/

Azure AD app registration vs Enterprise application

There are many apps which are published by companies. Enterprise apps are apps that are deployed and used within your organization and you can manage single sign-on settings for them by azure portal. If your you want to add your own app and integrate it with Azure AD, you need to register the app in App registrations. Also, if you grant permissions to your App, it will occur in Enterprise applications. If your app is added from gallery, you cannot configure the Reply URL. You can only configure your own app in Application registrations

The enterprise applications blade represents Service Principals, rather than applications. A Service Principal can be thought of as an instantiation of your application into the tenant. In the example of multi-tenancy, you as an app developer may register an application, then have multiple tenants sign in & consent to the app. At that point, each of those tenants will get a Service Principal provisioned into their tenant and it will show up in the Enterprise Apps section. To prompt a Service Principal to be provisioned in the same tenant as the app registration, you simply need to complete a sign in request and consent to the application. It should show up after that.

Azure native app registration

You can use Azure Active Directory (Azure AD) Application Proxy to publish web apps, but it also can be used to publish native client applications that are configured with the Microsoft Authentication Library (MSAL). Native client applications differ from web apps because they’re installed on a device, while web apps are accessed through a browser.

To support native client applications, Application Proxy accepts Azure AD-issued tokens that are sent in the header. The Application Proxy service does the authentication for the users. This solution doesn’t use application tokens for authentication.

To publish native applications, use the Microsoft Authentication Library, which take care of authentication and supports many client environments. Application Proxy fits into the Desktop app that calls a web API on behalf of a signed-in user scenario.

For more information about the native app registration, see How to enable native client applications to interact with proxy applications?

Azure AD app registration powershell

We are going to see how to register an app to Azure AD via PowerShell to take advantage of this.

Prerequisite

The Azure AD Module needs to be added to PowerShell prior to getting started. Execute the command below in PowerShell using elevated or Administrative status:

Install-Module AzureAD

Once the Azure AD Module is installed, run the following command in the same PowerShell window to connect to the required Azure AD tenant:

Connect-AzureAD

Note: The required TenantId will be required in subscriptions with multiple tenants. The TenantId value can be found in the Azure Portal navigating to Azure Active Directory > Properties and is listed under Tenant ID.

Run the following command in the same PowerShell window to connect to the specific Azure AD TenantId (if required):

Connect-AzureAD -TenantId “Insert Directory ID here“

Creating the Azure AD App Registration

Next, the following cmdlet is run, now that required Azure AD tenant is connected to PowerShell, to capture the name of the application and the IdentifierURI.

$appName = “SalesApp”
$appURI = “https://techieberrysalesapp.techieberry.onmicrosoft.com”
$appHomePageUrl = “Techieberry | Tips on Azure, Exchange and Teams
$appReplyURLs = @($appURI, $appHomePageURL, “https://localhost:1234”)
if(!($myApp = Get-AzureADApplication -Filter “DisplayName eq ‘$($appName)’” -ErrorAction SilentlyContinue))
{
$myApp = New-AzureADApplication -DisplayName $appName -IdentifierUris $appURI -Homepage $appHomePageUrl -ReplyUrls $appReplyURLs
}

Adding the App Key

With the required URIs now captured, it is time to add the application key. The key will be stored in the Azure Key Vault which ensures it’s security and disallows unauthorized access. Run the following command to invoke this process:

$Guid = New-Guid
$startDate = Get-Date

$PasswordCredential = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordCredential
$PasswordCredential.StartDate = $startDate
$PasswordCredential.EndDate = $startDate.AddYears(1)
$PasswordCredential.KeyId = $Guid
$PasswordCredential.Value = ([System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes(($Guid))))

NOTE: The PasswordCredential value is created as a Base64 value and is saved in the Azure Key Vault.

This process can also be completed via the Azure Portal but will take much more time to complete.

This completes the azure ad app registration.