Unable to Delete Azure Active Directory Application Registration

Introduction

This post is meant to go over the issue when the Azure Active Directory Application Registration delete button is grayed out. This issue could occur for a few reasons, and this document will go over the current known issues with Azure Active Directory Portal issues. This post will mainly go over the issues detailed in the v1.0 endpoint (portal.azure.com).

Context

Some users will find that they have many Azure Active Directory Application Registrations and will want to clean up the list of Registrations, which makes the user want to delete a few. They will run into not being able to delete the Application as the button is grayed out like in the picture below.

Resolution

The reason that you are unable to delete the AAD Application Registration is because of some properties in the AAD Application Registration or your account doesn’t have the right permissions. I will first go over the properties for the possible issues with the AAD Application Registration.

AAD Application Registration Property Issues for Web App/APIs

If the AAD Application Registration has the multi-tenanted value checked, then the Application will not be able to be deleted. In order to resolve this issue please follow the highlighted steps in the picture below. Go to your AAD Application Registration, then go to Settings > Properties > Multi-Tenanted – Set to No. Then after saving and backing out of the Application Registration, go back into the registration and you will be able to delete the AAD Application Registration.

AAD Application Registration Property Issues for Native Applications

For users who have AAD Application Registrations that are registered as “Native” Applications, you will have to go into the manifest in order to remove the multi-tenanted setting. This can be found by following the steps in the picture below. Go to your AAD Application Registration, click on Manifest, and then set the availabletoothertenants value to false. Save the manifest and then go back in to the Azure Active Directory Application Registration, and you will be able to delete the Application Registration.

User Role Issues

Some Users will be unable to delete an Azure Active Directory Application Registration because they do not have the correct roles to delete the Application Registration. The roles can be found here : https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles

That being said, the roles that have the action : microsoft.aad.directory/applications/delete listed in the “Actions” section are the roles that have the privilege to delete AAD Application Registrations in their respective tenant.

Currently as of 10-25-2018, the only two roles that have this are the Application Administrator and Cloud Application Administrator.

Note: You can also set a Service Principal to have an admin role following the guide here : https://blogs.msdn.microsoft.com/aaddevsup/2018/08/29/how-to-add-an-azure-ad-role-to-a-enterprise-application-service-principal/ if you are interested in deleting AAD Applications using a service principal.

Deleting Azure AD Application Using Powershell

You can also utilize Powershell in order to delete an AAD Application Registration. You will need to get the ObjectID from the AAD portal, or use powershell cmdlets to get the AAD Application ID. This link describes how to install the AAD V2.0 powershell in more detail : https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-adv2?view=azureadps-2.0

First you will need to open up powershell in administrator mode.

Then you will need to install the AzureAD Module, as shown below.

If nothing shows up, you may have to press enter again to see the get provider prompt. Enter the letter Y or A on each prompt. Each prompt may require you to press enter again.

After agreeing to install the item, you will need to connect to Azure using connect-azureAD. Be sure to login to the correct tenant (best to use organization account) that has the application you are trying to delete. more about Connect-AzureAD can be found here : https://docs.microsoft.com/en-us/powershell/module/azuread/connect-azuread?view=azureadps-2.0

Now go to the portal and get the object ID of the Azure AD Application Registration you are trying to delete, this can be shown in the picture below. I’ve highlighted the objectID and the multi-tenanted property to show this will work for apps that cannot be deleted in the portal. You can also use the cmdlet : get-azureadapplication, more on this is listed here :https://docs.microsoft.com/en-us/powershell/module/azuread/get-azureadapplication?view=azureadps-2.0

Then You will be able to delete the AzureAD application using the Remove-AzureADApplication powershell cmdlet. More on the Remove-AzureADApplication cmdlet can be found here : https://docs.microsoft.com/en-us/powershell/module/azuread/remove-azureadapplication?view=azureadps-2.0

For more information on the AAD V2.0 powershell cmdlets, please refer to the reference : https://docs.microsoft.com/en-us/powershell/module/azuread/?view=azureadps-2.0

Conclusion

In this post we have gone over a few reasons why you may not be able to delete some or any Azure Active Directory Application Registrations. We went over the different property settings and the user roles that have the rights to delete an Application Registration. If you have anymore issues, feel free to open a support ticket or comment below and one of our support engineers will reach out to you as soon as possible to resolve the issue.

Unable to Modify User Email, Phone Number, Password or Other Personal Information for Azure Active Directory Users

Introduction

This post is in regards to the issues in regards to users having issues modifying Azure Active Directory User attributes such as mail, phone number, resetting passwords, or other personal attributes in user accounts. This will review the reason behind these changes and how to resolve the issue. For many users this was something that was working before and only recently stopped working properly.

Reason Behind Change

There was a recent change to three different attributes that made changing the attributes require the same elevated privileges that password reset requires. The only properties that are being affected are the attributes : mobilePhone, businessPhones/telephoneNumber, and otherMails attributes. User profile changes can be made with User.ReadWrite.All except for the 3 aforementioned properties.

Fix/Resolution

In order to resolve this issue you will need to set the Service Principal or User that is trying to make the change to a Helpdesk Admins, User Account Admins and Company Admins depending on the user you are trying to modifies role is. Only these three admins can make changes to these three attributes in Azure Active Directory now.

Please note the level of power you are giving the service principal by setting the service principal or user to one of the aforementioned roles, realize that you are giving the user/service principal the ability to perform tasks at that level. This should be done with caution.

Microsoft Graph Scenario

Most users experiencing this issue are Microsoft Graph or Azure Active Directory users that are utilizing the Grant Type Client Credentials in order to make modifications to the three mentioned User Attributes. Having the Directory.readwrite.all permission is now not sufficient to make modifications to these user attributes anymore. You will get a 403 error saying insufficient permissions. In order to resolve this issue you can set the Service Principal/Enterprise Application as one of the admin roles in the resolution stated in the last paragraph.

For help on giving a Service Principal an Admin Role please go through this post : https://blogs.msdn.microsoft.com/aaddevsup/2018/08/29/how-to-add-an-azure-ad-role-to-a-enterprise-application-service-principal/

Conclusion

Here we have gone over the User Attribute change’s reasoning, how to resolve the issue, the Microsoft/AAD Graph Scenario, and a link explaining how to give a Service Principal/Enterprise Application an Admin role. If you have anymore questions in regards to this issue, feel free to comment below on this issue and I will try to get back to you as soon as possible. If you have any dire issues feel free to open a support ticket for Azure Active Directory Developer, and one of our support engineers will reach out to you to resolve the issue as soon as possible.

How to filter Fiddler capture traffic using host name and process name

This post discusses a couple of ways to filter Fiddler traffic based on domain names (or host names) and client process(es):

Note that before using filter you should make sure Fiddler is configured to capture all processes. This is indicated at the bottom left corner of Fiddler window. That area is clickable to change the selection.

Filter traffic using Fiddler’s built-in filter feature:

From Fiddler’s right pane –> Filters tab –> select “Use filters” –> under the Hosts section choose “Show only the following Hosts” –> Enter the host names you want to filter on, separated by semicolon

Note: as you edit this list the text box will change to have the yellow background to indicate the list is unsaved. Once done, you can just click on the “Actions” button to save the list and the background color should change to white.

Under the “Client Process” section, you can also select a particular process to filter on. This option is great for a standalone application. It may not be so useful for capturing browser traffic since there are multiple processes with the same name and it’s hard to tell which process is the right one to filter on.

Filter traffic using jscript code in the OnBeforeRequest function:

This option can be used especially for browser scenarios.

From Fiddler’s menu –> Rules –> “Customize Rules…” -> find the “OnBeforeRequest” function and insert the below jscript code at the beginning of the function –> Make sure to save the changes once done editting.

// begin filter
// set this to false to disable filter and true to enable filter
var filterOn: boolean = true;
if (filterOn)
{
   // hide all request by default
   oSession[“ui-hide”] = “true”;
   // here are some common processes: IE – iexplore.exe; chrome – chrome.exe, MS Edge =      MicrosoftEdgeCP.exe, IIS Express – iisexpress.exe, Powershell – powershell.exe
   // list of domain names to filter on
   var host = [“localhost”,”login.microsoftonline.com”,”graph.microsoft.com”];
   // list of processes to filter on
   var processlist = [“chrome”,”microsoftedgecp”,”iisexpress”,”powershell”];
   for (var j = 0;j < processlist.length;j++)
      {
         if (oSession.LocalProcess.Contains(processlist[j])){
            for (var i = 0;i < host.length; i++)
            {
               if(oSession.HostnameIs(host[i]))
               {
                  oSession[“ui-hide”] = null;
               }
         }
      }
   }
}
// end filter

variables:

filterOn: true to enabe filter and false to disable filter

host: contains the list of domains to filter on

processlist: contains the list of process names to filter on

References:

Modifying a Request or Response

FiddlerScript CookBook

Understanding FiddlerScript

Capture http(s) traffic with Http Fiddler

1 – Download the Fiddler 4 application and install it on the machine used to reproduce the problem (if you have not already). Go to http://www.telerik.com/download/fiddler

2 – Enable the option to decrypt HTTPS traffic: Tools -> Options -> Https -> select ‘decrypt HTTPS Traffic’ (you may be prompted to install the Fiddler certificate – make sure to select Yes)

Ensure this option is checked when collecting the trace as the data will have to be recollected if it is not.

3 – Restart the Fiddler program

(For browser-based apps)

4a. Either use private browsing mode or clear the client browser cache on the machine you will be testing from (many files are downloaded once by the browser and then cached and so will be missing from the trace unless the cache is clear; we need to see javascript and stylesheet files etc. to look for rewrite errors).

(For non browser-based apps)

4b. Launch your client application

5 – Reproduce the problem and you should see https traffic showing up in the Fiddler window.

6 – Save the resulting session output as SAZ files (File -> Save -> All Sessions)

How to Add an Azure AD Role to a Enterprise Application (Service Principal)

Introduction

This post is to help users be able to assign administrative roles to Enterprise Applications/Service Principals so that they can perform duties that would otherwise require a user with elevated permissions to accomplish. This is convenient when a user wishes to use a service principal in order to reset a password, or to perform some activity that requires admin privileges programmatically without an interactive sign in (using client credentials grant type flow).

In this post we will go over installing MSOnline (MSOL) PowerShell module, finding the Object ID for your Enterprise Application, and then giving the Enterprise Application an administrative role.

Note: We will be using MSOnline powershell cmdlets, these are a bit outdated. So as of 8-29-2018 they have not been deprecated yet, however please be sure to check the status of MSOL library. The history for the AAD libraries can be found here: https://social.technet.microsoft.com/wiki/contents/articles/28552.microsoft-azure-active-directory-powershell-module-version-release-history.aspx

We will be using Version 1.1.166.0 (PowerShell V1 General Availability)

You can also utilize AAD powershell V2.0. We will be going over this as well.

Prerequisite

In order to add an Application role to a Service Principal, you will need to have the proper permissions to assign roles to objects. Per the documentation here : https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#details-about-the-global-administrator-role

You will need to be a Global Administrator in order to set the roles to the Enterprise Application. Please be sure to get the global admin to perform to set the Enterprise Application to have the administrative privilege.

Getting Started with MSOL

In order to add the application role to a service principal we will have to utilize the older MSOL powershell Cmdlets.

In order to install MSOL, open up PowerShell and type in :

Install-Module -Name MSOnline

You can find the library in the PowerShell gallery here : https://www.powershellgallery.com/packages/MSOnline/1.1.183.17

After you have installed MSOL, you will need to login to your Azure Active Directory using MSOL. In order to do this use the command :

Connect-MsolService

There should now be a popup asking you to login to Azure. Be sure to use a global admin account, otherwise you won’t be able to follow the next step to give an enterprise application an administrative role.

Getting Started with AAD PowerShell V2.0

This document goes over install AAD Powershell V2.0:

https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-adv2?view=azureadps-2.0

Similar to installing MSOL.

You will utilize the commands :

Install-Module AzureAD

Connect-AzureAD

Getting the ObjectID of the Enterprise Application

Now we need to get the Object ID from the Enterprise Application. There are two ways you can do this, you can get the Object ID from the powershell CMDlet, or you can go to the Azure Portal and get the object ID from the Enterprise Application under the properties blade.

Using MSOL Powershell

Here we will take a look at a short script you can utilize in order to get the object ID of the Enterprise Application assuming you know the Application Registration Application ID.

$tenantID = “<ID for Tenant>”

$appID = “<Application ID>”

$msSP = Get-MsolServicePrincipal -AppPrincipalId $appID -TenantID $tenantID

$objectId = $msSP.ObjectId

Using AAD V2.0 PowerShell

You can also utilize AAD powershell v2.0 using the command :

$mysp = Get-AzureADServicePrincipal -searchstring <your enterprise application name>

$mysp.ObjectId

Now we have the service principal stored in the variable $mysp. We will use it later to associate a role to the enterprise application.

Using the Azure Portal

To get the ObjectID through the Azure Portal, you will need to go to portal.azure.com. From there go to Azure Active Directory on the left side bar. Then to Enterprise Applications > All Applications > (Your Enterprise Application to set to an Admin Role) > Properties > Object ID.

Assigning an Administrative Role for an Enterprise Application

First please make sure you have the Administrative Role Name on hand as you will need it in order to add the Admin Role to the Enterprise Application. You can find all the roles here: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles

In this Example we will be using Helpdesk Administrator

Using MSOL to Add a Role Member

All we have to do is run the MSOL PowerShell cmdlet Add-MsolRoleMember.

This PowerShell Cmdlet is described in detail here : https://docs.microsoft.com/en-us/powershell/module/msonline/add-msolrolemember?view=azureadps-1.0.

For our intents and purposes, we can use this one liner in order to set the Enterprise Application to have the Admin Role :

Add-MsolRoleMember -RoleName “Helpdesk Administrator” -RoleMemberType ServicePrincipal -RoleMemberObjectId $objectId

Replacing ObjectID with the enterprise application’s ObjectID if you don’t have $objectID saved.

We have successfully added the admin role to the enterprise application.

Note: This may require some time to take effect.

Using Azure AAD Powershell V2 to Add a Role Member

When using AAD PowerShell v2, you will need to get the object ID of the AAD role, you can utilize this command below to get the information.

$myAADRole = Get-AzureADDirectoryRole | Where-Object {$_.displayName -eq ‘Helpdesk Administrator’}

$myAADRole.ObjectId

Now that we have the object IDs for the AAD role, we will need to get both object IDs to add the role to the enterprise application. We can use the command below :

Add-AzureADDirectoryRoleMember -ObjectId $myAADRole.ObjectId -RefObjectId $mysp.ObjectId

Replacing the variables with the object IDs if you don’t have the variables saved.

We have successfully added the admin role to the enterprise application.

Note: This may require some time to take effect.

Conclusion

In this article we have gone over downloading MSOL and AAD V2.0, connecting with MSOL and V2.0, getting the object id for the enterprise application, getting the Application Role in MSOL and AAD V2.0, and giving the enterprise application the admin role using both AAD V2.0 and MSOL. you should now have an enterprise application that can do the actions that typically require a user with the admin privileges described in the role. If you have anymore issues feel free to open a support ticket or comment below and either one of our support engineers or I will try to assist you in this endeavor.

How to Create a New Schema Extension Using the Microsoft Graph Explorer

Introduction

This post is to provide a tutorial on how to create a schema extension utilizing the Microsoft Graph Explorer. In this post we will, login to Microsoft Graph Explorer, create the V1 AAD Application, and make the Microsoft Graph Schema Extension call.

Getting the Access Token

Please navigate to the Microsoft Graph Explorer at :

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

Once the page loads, on the left, below authentication you will see the button that says sign in with Microsoft. Click this and go ahead and login.

Now that you have logged in with an account, click on modify permissions underneath your name.

From there find the permission required listed in the Create schemaExtension documentation.

The permission is listed here : https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/schemaextension_post_schemaextensions

If you need help finding permissions for APIs, please go through this article : https://blogs.msdn.microsoft.com/aaddevsup/2018/05/21/finding-the-correct-permissions-for-a-microsoft-or-azure-active-directory-graph-call/

This will help you when working with other Microsoft APIs that you need help finding permissions to. That being said, once you find the permission, click on the box next to it to check it.

It will say that to change permissions you will need to login again. So when you press the modify permissions button, it will bring you back to the login page. From there, login and consent to the graph explorer application.

Now, by logging in you should have an access token for the Graph Explorer to use.

We can now press the run query button and get some information about ourselves, and have the correct permissions to make the call to the create Schema Extension Graph API.

Creating the AAD Application Registration

Now going back to the Azure portal, go to Azure Active Directory > App Registrations > New Application Registration

From here you are now at the Create AAD Application Blade, fill out the name and sign-on URL with your own values. They won’t matter too much in this example.

Now click on your new web app, and copy the Application ID.

Making the createSchemaExtensions Call

Now we have everything we need to make the create schema extensions call from the Microsoft Graph using the Graph Explorer. The nature of the createSchemaExtensions call is to add a schema extension to the application that is making the call. Since we are using the Graph Explorer, it will try to add it to the Graph Explorer’s AAD Application. You won’t be allowed to do this, as it is managed by Microsoft. So we have to set the Application ID of the application we would like to add the schema extension to in the body of our request. This is actually described in the documentation, although not very obvious, in the owner attribute for the request body.

owner
String
(Optional) The appId of the application that is the owner of the schema extension. This property can be supplied on creation, to set the owner. If not supplied, then the calling application’s appId will be set as the owner. So, for example, if creating a new schema extension definition using Graph Explorer, you must supply the owner property. Once set, this property is read-only and cannot be changed.

I am going to copy the request from the documentation and put it into my request body, and then add the owner attribute with my application ID. You must also modify the ID, because if you wish to utilize the Domain_schema ID format, you must provide a domain that you own.

So now my request looks like :

{
“id”:”2cd76e65″,
“description”: “Graph Learn training courses extensions”,
“owner” : “3f434c47-5229-40fc-be95-e6e1583ac4fc”,
“targetTypes”: [
“Group”
],
“properties”: [
{
“name”: “courseId”,
“type”: “Integer”
},
{
“name”: “courseName”,
“type”: “String”
},
{
“name”: “courseType”,
“type”: “String”
}
]
}

In addition to that I also copied and pasted the request endpoint in the request example into the graph explorer URL box.(https://graph.microsoft.com/v1.0/schemaExtensions)

I also then changed the blue box on the left of the URL box from GET to POST as we want to create the schema extension.

Conclusion

In this post we have gone through, logging in, getting the right permissions, modifying the request body example for your application, and then adding the schema extension to your application. For more information on the schema extension please go through the schema extension attribute documentation here : https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/schemaextension

You will see the different resource types and other information that you can use to create your Schema Extension.

If you have any issues, feel free to open a support ticket and one of our support engineers will reach out to you as soon as possible to resolve the issue. Also feel free to comment below and I will try to reach out to you to resolve the issue.

Testing B2C Resource Owner Password Credentials ( ROPC ) policies using PostMan

Below are the basic steps for using PostMan to test a B2C Resource Owner Password Credentials ( ROPC ) policy. You will need a set of user credentials along with a Application ID of a B2C Native application that will be used to retrieve the token.

Obtain the token endpoint from the B2C ROPC Policy

1. In the portal, locate the B2C blades by searching for B2C, then locate the “Resource Owners Policies” item and click it.

2. In the list of policies to the right, Click the name of the policy.

3. Locate the ROPC Policy URL and click.

4. In the JSON that is displayed in the Brower, make a note of the “token_endpoint” property.

{
“issuer”: https://login.microsoftonline.com/f06c2fe8-709f-4030-85dc-38a4bfd9e82d/v2.0/,
“authorization_endpoint”: https://login.microsoftonline.com/casalaola.onmicrosoft.com/oauth2/v2.0/authorize?p=b2c_1_maxv_b2c_ropc_policy,
“token_endpoint”: https://login.microsoftonline.com/casalaola.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_maxv_b2c_ropc_policy,
“jwks_uri”: https://login.microsoftonline.com/casalaola.onmicrosoft.com/discovery/v2.0/keys?p=b2c_1_maxv_b2c_ropc_policy,
“response_modes_supported”: [
“query”,
“fragment”,

“form_post”

….<JSON content removed for brevity>

}

In this example the token URL would be:

https://login.microsoftonline.com/casalaola.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_maxv_b2c_ropc_policy

Obtain the Application ID of the B2C Native application that will be used to request the token.

1. In the B2C main blade click the Applications menu item.
2. Then click the target application from the list of applications to the right.

3. On the Properties blade of the application. Locate the Application ID and click the clipboard icon to its right.
You will need this GUID when you build the PostMan request

In this example the application id would be:

9dd348b1-8f19-49c9-82ee-10e382eddba6

Build the token request using PostMan

1. Start PostMan desktop application. If you need to install PostMan visit the following URL:

https://app.getpostman.com/app/download/win64

2. Click the New button or if you allow the Create New wizard to launch at start up, click Request region.

3. In the SAVE REQUEST box, give the request a name, in this example the name chosen is “B2C ROPC Test Post”. Add a description that makes sense to you.

4. If you have no collections, create “B2C API Testing” collection, you can name the collection whatever you like or add the request to an existing collection.

5. Click the “Create Folder” or select a collection from the folder list.

6. Click the “Save To….” Button.

7. Select “POST” from the operation type drop down.

8. Place the token URL for the application in the “Enter Request URL” edit control. In this example post, the URL would be:
https://login.microsoftonline.com/casalaola.onmicrosoft.com/oauth2/v2.0/token?p=b2c_1_maxv_b2c_ropc_policy

9. Click “Body” section of the request

10. Click the “x-www-form-urlencoded” radio button .

NOTE:

If you add the key value pairs before clicking the radio button, you will be required to renter the key values pairs once again. Be sure to click the x-www-form-urlencoded radio button first.

11. Add the key value pares from the following table:

Key	Value
username	UPN Of User you want to request a JWTToken for
password	Corresponding Password for the username
grant_type	password
scope	openid <appId Guid> <other scoping parameters>
client_id	<application ID of the app you want to test>
response_type	token id_token

The values for this example would be:

Key	Value
username	zbfp@outlook.com
password	(HeartOfGold)
grant_type	password
scope	openid 9dd348b1-8f19-49c9-82ee-10e382eddba6
client_id	9dd348b1-8f19-49c9-82ee-10e382eddba6
response_type	token id_token

The “Headers” tab will be automatically populated.

The post should look similar to the following:

12. Click the Send button.

13. The Status code will be 200 if the request is successful. If there is an error. The body of the request will contain the specific error.

14. The response will contain the token information if successful. You can use a site like http://jwt.ms to decode, both, the access_token and id_token properties. The following illustration is an example of a successful POST to a B2C ROPC Policy token end point:

GUID Table for Windows Azure Active Directory Permissions

Introduction

This blog is meant to help users who need to get the Windows Azure Active Directory Permissions (WAAD) Globally Unique Identifiers (GUIDs) in order to create AAD Applications using the Microsoft Graph API, or for other reasons where they just need to get the GUID for a certain WAAD permission. For further information regarding AAD permissions please refer to the blog post : https://blogs.msdn.microsoft.com/aaddevsup/2018/05/21/finding-the-correct-permissions-for-a-microsoft-or-azure-active-directory-graph-call/

Note: That these GUIDs are subject to change in the future and may not be the same anymore.

Table

The Resource App ID for the Windows Azure Active Directory is : 00000002-0000-0000-c000-000000000000

GUID of Permission	Permission
5778995a-e1bf-45b8-affa-663a9f3f4d04 Type : Role	Read directory data
abefe9df-d5a9-41c6-a60b-27b38eac3efb Type : Role	Read and write domains
78c8a3c8-a07e-4b9e-af1b-b5ccab50a175 Type : Role	Read and write directory data
1138cb37-bd11-4084-a2b7-9f71582aeddb Type : Role	Read and write devices
9728c0c4-a06b-4e0e-8d1b-3d694e8ec207 Type : Role	Read all hidden memberships
824c81eb-e3f8-4ee6-8f6d-de7f50d565b7 Type : Role	Manage apps that this app creates or owns
1cda74f2-2616-4834-b122-5cb1b07f8a59 Type : Role	Read and write all applications
aaff0dfd-0295-48b6-a5cc-9f465bc87928 Type : Role	Read and write domains
a42657d6-7f20-40e3-b6f0-cee03008a62a Type : Scope	Access the directory as the signed-in user
5778995a-e1bf-45b8-affa-663a9f3f4d04 Type : Scope	Read directory data
78c8a3c8-a07e-4b9e-af1b-b5ccab50a175 Type : Scope	Read and write directory data
970d6fa6-214a-4a9b-8513-08fad511e2fd type: Scope	Read and write all groups
6234d376-f627-4f0f-90e0-dff25c5211a3 type: Scope	Read all groups
c582532d-9d9e-43bd-a97c-2667a28ce295 type: Scope	Read all users’ full profiles
cba73afc-7f69-4d86-8450-4978e04ecd1a type: Scope	Read all users’ basic profiles
311a71cc-e848-46a1-bdf8-97ff7156d8e6 type: Scope	Sign in and read user profile
2d05a661-f651-4d57-a595-489c91eda336 type: Scope	Read hidden memberships

Conclusion

If you have anymore issues in regards to this please file a support ticket and one of our support engineers will reach out to you to resolve the issue. Please include a fiddler trace of a repro of the issue occurring as well as a summary of the expected behavior versus the current behavior.

How to Create and Add Keys to Enterprise Applications for Expired Keys

Introduction

This article is broken up into a couple of different sections based on what you are trying to do.

Trying to modify the service principals credentials typically is meant for accessing an application that is multi-tenanted and the client secret has expired and they need a fix to resolve a wide outage due to an expired client secret.

This typically has to do with a key expiring, many people wish to extend their keys for their service principal however you cannot do this. You have to add a new key to your service principal moving forward.

By changing the enterprise application key and then rolling it out with the correct key, this will resolve the issue for all users using the application in a separate tenant.

Note that enterprise applications and service principals are the same in the Azure portal. We refer to the Service Principals as SPs or Service principals when accessing them in PowerShell. But when in the portal, they are called enterprise applications. More on enterprise applications can be found in the link : https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-application-objects Please refer to this link to learn more about the AAD Application Objects and Service Principals and how they work together.

Adding a New Secret to An Enterprise Application Using MSOL

This section is assuming that you have MSOL installed on your machine for PowerShell.

For more information about install MSOL please go here : https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-msonlinev1?view=azureadps-1.0

The below PowerShell script needs the end date to be changed to whatever date you choose.

Please replace the client ID field with the client ID of your AAD Application Registration. You can find the client ID in your enterprise Application blade.

Also remember to change the $Enddate to whatever you would like the expiration date to be for your new secret.

$startdate = Get-Date
$Enddate = "November 28 2029"
$clientid = "xxx"
# (Enter you client ID / Application ID)
$ClientID = $clientid 
$bytes = New-Object Byte[] 32
$rand = [System.Security.Cryptography.RandomNumberGenerator]::Create()
$rand.GetBytes($bytes)
$rand.Dispose()
$newClientSecret = [System.Convert]::ToBase64String($bytes)
# (This command will provide you with the new secret.  Please record it because you will not be able to get it again)
$newClientSecret
# (Enter an Tenant Admin account that can create Service Principal and Directory Objects)       
$msolcred = Get-Credential  
Install-Module MSOnline
Connect-MsolService -credential $msolcred
$AppSP = Get-MsolServicePrincipal -AppPrincipalId $ClientID
#  (Verify that this is the correct Application)
$AppSP     
New-MsolServicePrincipalCredential -AppPrincipalId $AppSP.AppPrincipalId -Type password -Value $newClientSecret -StartDate $startdate -EndDate $Enddate
Get-MsolServicePrincipalCredential -ObjectId $AppSP.objectId -ReturnKeyValues $true

Reading the PowerShell script we are doing these actions procedurally : get today’s date, create a random secret, and then add the secret to your service principal based on the Application ID.

Please remember to login to the correct tenant otherwise it won’t be able to find the ApplicationID.

Adding a Credential to An Enterprise Application Using Azure Resource Manager

This section will assume that you have installed the Azure Resource Manager.

Please see the following links to learn more about Azure’s PowerShell Module, this also tells you how to install AzureAD into your PowerShell environment :

https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-adv2?view=azureadps-2.0

Following this guide, we will be installing the module AzureRM. Then we will be able to utilize Connect-AzureAD, I have multiple tenant IDs so I’m specifying the tenant ID I would like.

You can get the tenant ID by going to the portal and then clicking on the top right

Then once we have the tenant ID we will be able to connect using connect-azuread. I have cropped out my tenant ID in the picture below.

After running this command you’ll get the interactive pop up to sign-in.

First we are going to want to get the correct service principal.

There are two ways to get the ServicePrincipal’s details.

You can get some details from the Azure Portal under enterprise applications and then clicking on the one you would like to add the secret to. From there you will want to get the Application ID.

You can get all of a service principal’s details using the command below. If you have too many enterprise applications your PowerShell might stop responding so you may have to utilize a filter to get the specific service principal you want. The documentation goes into these options to filter on a specific Service Principal. I am just listing all the service principals in the picture below.

Get-AzureADServicePrincipal, please keep track of the objectID as you will need it later. Also note that the display name and the serviceprincipalname are different.

This link goes to the documentation for getting the SPs.

https://docs.microsoft.com/en-us/powershell/module/azurerm.resources/get-azurermadserviceprincipal?view=azurermps-6.0.0

The command below will get your service principals/enterprise application credentials which are the keys

Get-AzureRMAdSPCredential, here I don’t have any credentials for the Service Principal which is why the command doesn’t return anything.

The documentation for this command is here.

https://docs.microsoft.com/en-us/powershell/module/azurerm.resources/get-azurermadspcredential?view=azurermps-6.0.0

The command below will create a new SP/Enterprise Application Key/credential,

New-AzureRMAdSPCredential

https://docs.microsoft.com/en-us/powershell/module/azurerm.resources/new-azurermadspcredential?view=azurermps-6.0.0

In the examples it shows how to utilize the commands to create a password and then to add the password to your service principal, this is also documented below. After logging in you to the correct tenant you will be able to utilize this command to add a credential to your SP.

$SecureStringPassword = ConvertTo-SecureString -String “password” -AsPlainText -Force
New-AzureRmADSpCredential -ObjectId <your-objected> -Password $SecureStringPassword

Adding Certs with Your Service Principal

The PowerShell command New-AzureRMAdSPCredential also allows you to add a certificate to your Service Principal to be used for as authentication.

This is described in the documentation linked below.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-authenticate-service-principal

Conclusion

We have gone over how to utilize MSOL and AzureRM Powershell 2.0 to add a secret, password, and certificate to your service principal. This should help to handle users who need to add secrets passwords to your multi tenanted applications. If there are anymore issues please file a support ticket and one of our support engineer will reach out to you to resolve the issue as quickly as possible.

Using Postman to call the Microsoft Graph API using Authorization Code Flow

Introduction

This article will help guide you through utilizing Postman to call a Microsoft Graph Call using the authorization code flow. This is part of a 5 part blog on accessing the Microsoft Graph API utilizing grant types : authorization code, implicit flow, client credentials, password, and refresh token flow. We will be utilizing the same Microsoft Graph call to reduce extraneous details on having to include setting up and finding the correct permissions for every Microsoft Graph Calls while still maintaining the consistency of setting up for the entire Microsoft Graph Call from start to finish.

Setting Up the AAD Application

The first step to getting access to the Microsoft Graph REST API is to setup an AAD Application Registration.

First we are going to want to create the AAD Application registrations in the portal. For this we will need to configure the application to be able to work with Postman so that we can make the call to the Microsoft Graph API. First we go to the Azure Active Directory Blade, go to App Registrations, and then create a new application registration.

From there we are going to want to create a web app with any name. Here I have set the name as web app and then we want to set the callback url to : https://www.getpostman.com/oauth2/callback and set the application type to web app/ API.

Note: that you can set whatever URLs you would like

You will have to click out of the sign-on URL to make it check whether or not if it’s correct.

After that we have created our web app, we will want to create a secret. Please keep track of the secret as you won’t be able to see the secret again. You will have to press save in order for the secret to generate.

With this information in hand, we will be able to move forward and connect to this AAD registration. But without the correct permissions we won’t be able to get an access token to make calls to the Microsoft Graph API.

Finding Which Permissions We Need for a Microsoft Graph Call Using Authorization Code Flow

Assuming we would like to have granular control on what the AAD Application registration has access to and what it doesn’t have access to. We are going to want to make sure that the AAD Application registration only has the permissions it needs to make the Microsoft Graph API calls that we are wanting to make.

There has been a separate blog post on finding the correct permissions for your graph API call listed below :

https://blogs.msdn.microsoft.com/aaddevsup/2018/05/21/finding-the-correct-permissions-for-a-microsoft-or-azure-active-directory-graph-call/

For this Authorization Code flow, we will want to set the required permission for Read all users’ full profiles under Delegated Permissions. You can utilize the Application Permission as well, however you won’t get the permissions based on the user logging in, instead you will receive the permission on behalf of the Application.

Retrieving an Access token Using Authorization Code Grant Type Flow

When using the Authorization Code flow to get the access token, the preview feature of postman when requesting for an HTML page doesn’t properly load the HTML page. In addition to that I’m not sure if the preview feature would even properly add the cookies to Postman, so you won’t be able to make requests to the authorization endpoint and get the authorization code back and send that to the token endpoint.

However, Postman does include a way to get an Access token via OAuth2’s Authorization Code Grant type by going to the authorization tab in Postman and then requesting a new access token.

After opening up Postman click on the authorization tab shown in the picture below. After that, click on the highlighted drop down menu.

After clicking on the menu, we will want to click on OAuth 2.0

This will now change the User Interface and there will be a “Get a New Access Token” button on the right side now. Click on the button on the right side and that will open a new pop up section.

You will now be able to choose your grant type, this article is meant to follow the grant type authorization code.

The callback URL will be your first reply URL for your AAD Application Registration, I have set mine to orange.com.

The Auth URL will be the auth endpoint for the tenant that your AAD Application Registration is in. You can find this in the picture below in your AAD App Registration blade.

Note that you will need to add the resource you are asking access to as a query parameter in your auth url. For example: https://login.microsoftonline.com/8839a17c-5ebf-496f-858e-0bd6c3038589/oauth2/authorize?resource=https://graph.microsoft.com This auth url is asking for authorization to get access to the Microsoft Graph.

The Access token URL is highlighted in the picture above, the OAuth 2.0 token endpoint URL.

The client ID is the application ID/Client ID for your AAD Application Registration. This is found when you first enter the blade for your AAD Application.

The client secret can be found by following the directions described here : https://blogs.msdn.microsoft.com/aaddevsup/2018/04/25/how-to-get-to-the-keyssecrets-from-azure-active-directory/

Note: There are some issues with Postman and utilizing the “Get New Access Token feature” when the client secret has a # and +. So you will need to continue to get a new secret until it doesn’t have a + or # symbol in the client secret. This issue is described in the GitHub issue : https://github.com/postmanlabs/postman-app-support/issues/4555

The Client Authentication will work using either option, here I’m using “Send Client Credentials in Body”

Now when you click on request token, an interactive pop up will show asking you to login. After you login with your username and password, it will then automatically go through the flow and send the authorization code to the token endpoint. After logging in you will receive the Access token, and it will look like the picture below.

Now that you have the access token you will want to add it to your headers. Postman will do this for you, but you have to remember to scroll down in the “Manage Access Tokens” frame and press “Use Token”.

Conclusion

We have gone through the steps to get an access token utilizing postman’s feature to request access tokens from the token endpoint by getting the authorization code from the authorization endpoint. If you would like to learn more about how the OAuth 2.0 flow works in terms of AAD Web Applications please take a look at this documentation that reviews how it works : https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code

If you have anymore issues feel free to open a support ticket and one of our engineers will reach out to you to resolve the issue.