Install-Module -Name AzureAD

You will be prompted to accept the installation, give Yes or A.

Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from 'PSGallery'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): A

You can also check whether this module is installed or not by using the command Get-Module AzureADPreview

Once you are done, it is time to connect to your Azure AD by using the command Connect-AzureAD. That will give you an output as in the preceding image.

Now, use the command below to change the properties of your user.

Set-AzureADUser -ObjectId user1@domain.com -OtherMails @("user2@domain.com") -Mobile "+353 000000000" -TelephoneNumber "+353 000000000"

You can also verify the changes by running the commands below.

Get-AzureADUser -ObjectID user@domain.com | select otherMails
Get-AzureADUser -ObjectID user@domain.com | select Mobile
Get-AzureADUser -ObjectID user@domain.com | select TelephoneNumber

After you have changed your mobile number, verify the same when it is asked, and you should be able to Enable the Two-Step Verification on the Security Information page.

References

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-authenticationdata#use-powershell-version-2

Creating Azure AD application

Before we run the command to create the application, make sure that you have installed the AzureAD module. Open your PowerShell ISE with administrator access, and then type the preceding command.

PS C:\WINDOWS\system32> Install-Module AzureAD

This will install the module for you. You can see this in the modules list in the ISE. Click on the refresh button if you don’t see it.

Now run the command “Connect-AzureAD” to connect to your Azure Account. If you have multiple directories with your account, then you must connect it with the tenant parameter. You can get the tenant id from the Tenant Properties window. Switch to the directory in the Azure Portal and search for the Tenant Properties in the search bar. Copy the Tenant ID from there and run it with the preceding command.

Connect-AzureAD -TenantId YourTenantIDHere

Login again if you are asked again. And you are ready to run the command to create the AD application.

Here the parameter “-Oauth2AllowImplicitFlow” is to enable the OAuth flow and the -AvailableToOtherTenants is to make sure that my app is available to other tenants. You can see more options here.

If you are getting an error as “Message: Hostname in ‘http://’ in property identifierUris is not on any verified domain of the company or its subdomain, make sure that you are giving the “$appUri” as your Azure AD primary domain or subdomain. You can get this value from the Azure AD applications overview window.

If you get an error as “Message: The URI scheme in property identifierUris is invalid or unsupported.”, make sure that you have included “http://” with your URI.

If you don’t see any other errors in your PowerShell, then it is more likely that the application is been created for, go to the Azure AD application registration page and see it yourself. In the overview page of your application, you can see that our application support multiple organization. If you go to the “Expose an API” section, that is where you can see your application ID URI configured. Make sure that you have created a service principal for your API application to use in the front end application.

It is also possible to create a secret of our Azure AD application using PowerShell, in one of my application it was required as I am using the Graph to fetch the users from multiple tenants with a Daemon user. You can read more about that here. Here is the command to add a secret.

$secret = New-AzureADApplicationPasswordCredential -ObjectId $myAdApp.ObjectId -CustomKeyIdentifier "GraphClientSecret"

You can see the value of the secret if you just output the same. And later, you can save this value to your Azure Key Vault and read it in your application. By default, the end date of your secret will be 1 year, and if you want to change it, you need to provide the start date and end date in your command.

Now, this is how our updated script looks like.

I have one front end application and a backend api application, I need to make sure that the consent screen of the AD application shows the permission required of my backend application too. To do this, we have something called “-KnownClientApplications”, we can set this in our script to create the backend ad application.

Here is the entire PowerShell command.

What this will do its that,

• Create an Azure AD application for the front end application
• Create an Azure AD application for API application
• Set both applications available to multiple tenants
• Set the front end application to use OAuth flow
• Add the Application ID of front end application to the KnownClientApplications of API application
• Expose the API application and add an Application ID URL, that can be added as permission to the front end application
• Create an application secret in the API application and set the expiry after 10 years

If everything correct, then you should have the secret values shown in the PowerShell window.

Conclusion

Congratulations and thanks a lot for being with me this far. Happy Coding!.

About the Author

I am yet another developer who is passionate about writing and video creation. I have written close to 500 blogs on my blog. And I upload videos on my YouTube channels Njan Oru Malayali and Sibeesh Passion. Please feel free to follow me.

• GitHub
• medium
• Twitter

Your turn. What do you think?

Thanks a lot for reading. Did I miss anything that you may think is needed in this article? Could you find this post useful? Kindly do not forget to share your feedback.

Kindest Regards

Sibeesh Venu

Working with Microsoft Graph is fun, but it can get way too complex when the requirement is getting complex. Recently, I was working with such a requirement. I wanted to load users from different tenants, usually, this is too easy, and you just need an admin user in the tenant to load all the users using Graph API. But, in our case, there is no guarantee that the logged-in user is actually present in that tenant. And when the user tries to get the users from a different tenant, the Graph API returns an Unauthorized error, which is obvious and well handled.

So, we wanted something that can always perform these actions, no matter the logged-in user is present or not in the tenant given. I started with adding the Delegated permission to the Azure AD app registration, and in the end, the result was the same. Then I came to know about the application permission of Azure AD application registration and that sounded worth a try.

Here in this post, I will be sharing how did I achieve this requirement, it is not that problematic as it sounds.

Azure AD Application Set Up

Go to your Azure AD and select the App registration menu from the left pane. This will open the window where you can create and manage your app registrations.

When you are registering a new Azure AD application, make sure to select Multi-Tenant Support and give a redirect URL.

Now let’s say that you have created your application and now open the application and click on the permission menu from the left-pane.

As you can see that, all the permission types are Application, instead of the delegated ones. This will make sure that our application gets the privilege to act without a user, and will act as a Daemon user in the end. Please be careful in giving the application permissions as those are critical and should only be used when it is needed. So, just select only the permissions needed to complete your requirements.

Now, to make it work, we also need to set up a Client Secret in our application, which will then be used when we create a token. To do that, click on the Certificate & Secrets menu from the left pane. And click on the +New client secret.

Remember to make a note of the secret as you will not be able to see the values later. Now that our application is ready for action, let us write some code.

Code to Get Users from Multiple Tenants

I do this in my .Net Core API application, and I have a module called Admin which does all the Admin related kinds of stuff. Here I have configured my application using a vertical layered architecture, thus this admin module is independent of any other features in our application. Having said that, let’s look at the code in AdminController.

As you can see that, nothing fancy there. Here I am just calling the method in the Admin Service and some error handlings. Let’s look at the code in the Admin Service.

Here I have some custom error handling and also I am doing some logic related to my requirement, but the important part here is” var users = await _graphFacade.GetUsersUsingGraph(selectedTenant);” Let’ see that now.

I am a fan of keeping things separate, and that is the reason why you are seeing a lot of separations here. I promise that there will only be one more. Here we have a GraphAuthService, and that is when I actually create the graph client and return the provider. Shall we see that now?

Here we are creating a client credential provider with our tenant given and then create a graph client using that provider. Sounds good? We are getting all the other values from our configuration. In the non-development environment, I am loading the secret from a Key Vault, and for the development environment I load them using the secret.json file, I have already written a blog post about this, you can read it here.

As per your need, you should select the authentication provider, this post will help you choose one. And we use this client in our façade service to get all the users. You have already seen that. Follow this link to install all the dependencies, in short, install both “Microsoft. Graph” and “Microsoft.Graph.Auth” Nuget packages at least.

Execution

It is mandatory that you should have a UI application where an admin can grant access to our application, you can also prepare a URLS and sent it to your admin to give the consent, but the UI approach is more feasible. I have an application already that does this. Let’s run it now and see whether we are able to fetch the users from the different tenants or not.

In short, when the consent is given a new service principal of our application will be created in the tenant to which the admin is granted the consent. You can see this in the Enterprise application section in your Azure AD, check the left-side-pane. This is how the consent screen will look like.

Now, as you can see that in the above image, whatever permission our application is requesting, is showing in the consent screen, and some admins will not give the consent if they see a lot of permissions there. This is the reason why it is important to choose the permissions that are needed. In my case, I have one Azure app for the front end and one for the backend, that is the reason why my backend application name is mentioned in the consent screen.

You can update the permissions of your application anytime you wish, and delete the consent given by going to the Enterprise application section in the Azure AD (remember that this is something that you do in the tenant where the application consent is given) and click on the Delete button in the Properties window.

Now I have updated my application API permission to use only “User.Read.All” permission and let’s see the consent screen now.

As my requirement is to fetch only the users, this would still work as it is and here are the debug screenshots to show you that this is actually working.

Conclusion

Congratulations and thanks a lot for being with me this far. In this post, we have seen that how we can get the users from different tenants using the Azure AD App registration with application permission. Happy Coding!.

About the Author

I am yet another developer who is passionate about writing and video creation. I have written close to 500 blogs on my blog. And I upload videos on my YouTube channels Njan Oru Malayali and Sibeesh Passion. Please feel free to follow me.

• GitHub
• medium
• Twitter

Your turn. What do you think?

Thanks a lot for reading. Did I miss anything that you may think is needed in this article? Could you find this post useful? Kindly do not forget to share your feedback.

Kindest Regards

Sibeesh Venu

How does authentication work?

Before we go and set up our application it is important that you should understand how the authentication mechanism works here.

There are two kinds of authentication in the Partner Center.

1. App-only, which will just be using the AD app we create.
2. App + User, that will require both app and the user context.

Microsoft had created a new authentication model when we create App + User, which is the Secure application Model. This uses, multi-factor-authentication. This model is recommended and more secure, and with this approach, we can make sure that it supports all the operations as App-only authentication does not support some complex scenarios, for example, invoice operations.

We use a multi-tenant application and the initial registration for the application lives in the Host Azure AD tenant. When a user from a different tenant signs into the application for the first time, Azure AD asks for the consent and then a representation of the application (Service Principal) will be created in the user’s tenant.

This consent experience is based on the delegated permission we set in the app. And for us, it is important to give the appropriate permissions as we may have to act as the user. Below are the minimum set of permissions.

1. Azure Active Directory delegated permissions: Access the directory assigned user.
2. Partner Center APIs delegated permission: Access.

Please be noted that you will not be able to configure this application with your account, even though you create a new tenant with your MPN account, as both Azure Active Directory and Microsoft Partner Center application must be present in your tenants, then only you will be able to give the delegated permissions.

Read more about authentication here. You can also download the Secure Application Model framework document.

Partner Center Authentication – For better understanding!

Configure the Partner Consent Application

Once you clone the repository go to the secure-app-model folder in the root folder. Go to the folder keyvault and click on the solution file PartnerConsent.sln. Go to the Web.config file and that’s where all the configuration needs to be done. But if you working with the Partner Center for the first time, then things can be messy, it just won’t work. Let’s review the configuration one by one.

<!-- AppID that represents CSP application -->
<add key="ida:CSPApplicationId" value="ceec9e0d-d555-4472-952b-0ef9a77acba5 " />

This one is easier, this is the ID of the application that you had created using your SandBox account or using your Primary Partner Account. A Sandbox is for testing. No need to pay for the invoices, and will have a disclaimer “DO NOT PAY. THIS IS A SANDBOX INVOICE AND NO ACTION IS REQUIRED”.

Key things to consider:

1. Both accounts act independently and do not share the same accounts, customers, etc.
2. Supports transactions with a limited number of customers, orders, subscriptions, etc.

To create an integration sandbox, click here.

Once you have your sandbox account is configured go to the https://partner.microsoft.com and login with your Sandbox credential, click on the setting button on the right side of the page, and then click on the Account settings. Now from the left blade menu, click on the App management. This is where you actually create your application. You can create a Web App and Native App as per your requirement. If you are visiting this page for the first time, you will be given an option to create an application, and once that is done this is how it looks like.

As you can see that every application has App ID, Account ID, Commerce ID, and Domain. Now copy the App ID of your application and paste it as the value of the key ida:CSPApplicationId in the web config file.

<add key="ida:CSPApplicationSecret" value=".Gqs~Qhfdq8.eO-_6DtJrDNn32.VavwP_C208" />

This is the key we generate for our application, and you can create it by clicking on the Add key button (please see the above image). Make sure to copy this value before you refresh the page. Now, if you go to your tenant (tenant you create the Partner Center app), you should see that there are applications registered for your Partner Center applications. Go to your Azure AD, and then click on App Registration from the left-side blade.

Just to be clear, click on the application, and go to the API permissions from the left-side pane, you should see that some delegated permissions are given to the Azure Active Directory and Microsoft Partner Center. Go to the Authentication page and add Redirect URI there, you can do this by clicking on the +Add platform button, from the next page select web and give the redirect URI, this is the URL of our MVC or .NET core application. For example, https://localhost:44395/.

Make sure that you add it correctly, even the trailing slash matters here. I was getting an error as ““error”:”invalid_client”,”error_description”:”AADSTS500112: The reply address ‘https://localhost:44395/‘ does not match the reply address ‘https://localhost:44395‘ provided when requesting Authorization code.”

And if you don’t provide this reply URI, you will get an error “AADSTS500113: No reply address is registered for the application”

<!-- Endpoint address for the instance of Azure KeyVault -->
<add key="KeyVaultEndpoint" value="https://my-access-key-vault.vault.azure.net" />

You need a KeyVault to store your token, and you create one by using PowerShell or using a portal. If you are following this document, and prefer using PowerShell, make sure that you run all the steps as mentioned there. For now, let’s say that you had created the KeyVault and update the key KeyVaultEndpoint with the Vault URI, you can get this value from the Overview page of the Key Vault resource.

<!-- AppID that is given access for keyvault to store the refresh tokens -->
<add key="ida:KeyVaultClientId" value="e0d59487-585f-4b90-8ce1-f5f784246218" />

This is the ID of the application that we are going to register in Azure AD. You can either create this with the PowerShell command or using the portal.

Make sure you note down the Application ID and Application Secret. If you are using the portal to create this application, go to your Azure AD and click on the App registration blade from the left-side pan and click on the +New registration. As per your requirement, select the Account Type.

Once the application is created, we need to make sure that we give access to the Key Vault we created, so that this can get/post the token to the secret in our Key Vault. Copy the application ID and go to your Azure Key Vault and click on the Access Policy from the left-side pane.

Click on the +Add policy, and then select the Secret management from the Configure from template dropdown. Now click on the link “None Selected” near the service principal, and then paste the App ID of the Azure AD application we just created in the “Select a principal” screen. Click the add button make sure you click on the Save button on the next screen. You can also do this via PowerShell by following this command.

Set-AzureRmKeyVaultAccessPolicy -VaultName access-key-vault -ObjectId 296546541096da-acc2-4576-a4a2-47654a4389e45d7 -PermissionsToSecrets get

Here the ObjectId is the object ID of your Azure AD app. Make sure that you give enough permission, otherwise, you will get an error as follows.

Operation returned an invalid status code ‘Forbidden’

at Microsoft.Azure.KeyVault.KeyVaultClient.d__63.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable1.ConfiguredTaskAwaiter.GetResult() at Microsoft.Azure.KeyVault.KeyVaultClientExtensions.<SetSecretAsync>d__46.MoveNext() at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()

This is because there is no enough permission given in the access policy of our Key Vault. And also the access policy was showing as Unknown on the Access Policy page. I will be discussing this when we register our Azure AD application.

 <add key="ida:KeyVaultClientSecret" value="Hewhfhu42Wz~Rs6UVna9-10.4lcdhdfh6krH-.TWK" />

You can create this secret for your Azure AD application via the portal or by using PowerShell. If you have created the AD application using the PowerShell command above, then you already have the secret value from the command Write-Host "ApplicationSecret = $($password.Value)".

Go to your Azure AD application and click on the Certificates & secrets menu from the left-side pane, and then click on the +New client secret button under the client secrets header. Copy the value and paste in the value of key “ida:KeyVaultClientSecret”. Make sure you don’t change the secret value, otherwise, you will get an error as ““error”:”invalid_client”,”error_description”:”AADSTS7000215: Invalid client secret is provided.”

If you are getting an error as “IDX10214: Audience validation failed. Audiences: ‘ceec9htdhe0d-d56564657-4472-952b’. Did not match: validationParameters.ValidAudience: ‘ceec6536463ef9a77acba5 ‘ or validationParameters.ValidAudiences: ‘null’.”, you should add ValidAudiences in the OpenIdConnectAuthenticationOptions in ConfigureAuth method.

ValidAudiences = new List<string>()
{
  "ceec9e0d-d557-6564-96542b-0ef9a6546acba5"
}

Here the audience is the ID of the Azure AD web application that we created using the Partner Center (https://partner.microsoft.com).

Wow, that’s it. Now you have configured your partner consent application. It is time to run our project. If you have configured everything correctly, you should get a response as follows.

Now, if you go and check your Azure Key Vault, you can see that there is a new secret created with our access token.

Whenever the same user login to the application again, the Token will be refreshed in the Azure Key vault with a new version.

When you try with any other accounts outside of your tenant, they should be seeing a service principal of our Azure AD application in their Tenant. You can check this in the Enterprise Application page in the AD.

Please be also noted that if your Tenant Admin doesn’t grant permission to this application, you will get an error as ““error”:”invalid_grant”,”error_description”:”AADSTS65001: The user or administrator has not consented to use the application with ID“. This behavior is intended.

If you are trying to login with one of your tenants that don’t have the Partner Center App, then you will get an error as “OpenIdConnectMessage. An error was not null, indicating an error. Error: ‘access_denied’. Error_Description (may be empty): ‘AADSTS650052: The app needs access to a service (\”https://api.partnercenter.microsoft.com\”) that your organization \”50-865e-dd8763cd2cd4\” has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service subscriptions.“.

This error is also intended.

Debugging Tips

While working with this application, I was getting a lot of errors, and the sad part was that the application was not throwing any errors, so I had to go place the debugger in almost all the places I could. And some errors were not having enough information too. To get detailed error information, I had to set “IdentityModelEventSource.ShowPII = true” in the COnfigureAuth method in the Startup.Auth.cs file. You should install the Nuget package “Microsoft.IdentityModel.Logging” to use this feature.

After that, I was getting detailed errors and I was just fixing errors one by one. And it took me quite a lot of time to make this application working, and that is the reason why I write this post.

When you try with other accounts, make sure that MFA is configured for that account.

Conclusion

Congratulations and thanks a lot for being with me this far. We now have a sample web application that has access to Azure AD, Partner Center, Azure Key Vault, and does the Authentication against a user. Please do not forget to share this post if you find it is useful. Happy Coding!.

About the Author

I am yet another developer who is passionate about writing and video creation. I have written close to 500 blogs on my blog. And I upload videos on my YouTube channels Njan Oru Malayali and Sibeesh Passion. Please feel free to follow me.

• GitHub
• medium
• Twitter

Your turn. What do you think?

Thanks a lot for reading. Did I miss anything that you may think is needed in this article? Could you find this post useful? Kindly do not forget to share your feedback.

Kindest Regards

Sibeesh Venu