Tag Archives: Microsoft

Azure AD User Provisioning – Part 5

Posted on by

Hi everyone. I apologize for the delay in publishing the last post in this series. The past few months have been hectic. For this last post of the year I will be completing the series on provisioning in Azure AD.

As I’ve covered in earlier posts, there are a lot of options when provisioning to Azure AD including multiple GUIs and programmatic options. I’ve covered provisioning in the Azure Management Portal, Azure Portal, Office 365 Admin Center, and Azure Active Directory PowerShell v1 and v2. In this final post I will cover provisioning via the Graph API using a simple ASP .NET web application.

I was originally going to leverage the graph API directly via PowerShell using the .NET ADAL libraries and Invoke-WebRequest cmdlets. I’ve been playing around a lot with Visual Studio creating simple applications like the Azure B2B provisioning app. I decided to challenge myself by adding additional functionality to the ASP .NET web application I assembled in my previous post. I enjoyed the hell out of the process, learned a bunch more about .NET, C#, ASP .NET web apps, and applications built using the MVC architecture. Let’s get to it shall we?

Before we dive into the code and the methodologies I used to put together the application, let’s take a look at it in action. The application starts by requiring authentication to Azure AD.

1

After successful authentication, the main page for the website loads. You’ll notice from the interface that I used the sample ASP .NET MVC Web Application available in Visual Studio but added a new navigation link on the right hand side named Create User.

2

After clicking the Create User link, the user is redirected to a simple (i.e. ugly) web form where information about the new user is collected.

3

After the user hits submit, the new user is created in Azure AD and the information from the returned JWT is parsed and displayed in a table.

4

When we navigate to the Azure AD blade in the Azure Portal we see that Homer has been created and added to the system.

clearme

So you’re probably asking the question as to how complicated it was to put this application together? The answer may surprise you. It was incredibly simple. The most difficult part of the process was learning my away around C# and how MVC web apps are put together. For a skilled developer, this would have taken an hour versus the days it took me.

The first thing I did was do some reading into the Graph API, specifically around managing users. Microsoft has a number of great instructions located here and here. After getting familiar with the required inputs and the outputs, I built a new model in my application that would be used for the user form input.

6

Once I had my new model assembled, I then created two new views under a new folder named Create User. The view named Index is the view that takes the user input and the view named Results is the view that spits back some of the content from the JWT returned from Azure after the user is successfully created. Here is the code for the Index view.

7

And the code for the Results view.

8

After the new views were created, I then moved on to creating the guts of the new functionality with a new controller named CreateUserController. I was able to reuse some of the code from the UserProfileController to obtain the necessary OAuth access token to delegate the rights to the application to create the new user.

9

The remaining code in my controller came from a crash course in programming and MVC web apps. The first section of code calls the task to obtain the access token.

10

The next section of code creates a new instance of the user class and populates the properties with information collected from the form.

11.png

The final section of code attempts to create the new user and displays the results page with information about the user such as objectID and userPrincipalName. If the application is unable to create the user, the exception is caught, and an error page is displayed.

12

But wait… what is missing? I’ll give you a hint, it’s not code.

The answer is the appropriate delegated permissions. Even if the user is a global admin, the application can’t perform the actions of a global admin unless we allow it to. To make this happen, we’ll log into the Azure Portal, access the Azure AD blade, and grant the application the delegated permission to Access the directory as the signed-in user.

13

Simple right? The Azure Active Directory Graph Client libraries make the whole process incredibly easy doing a whole lot with very little code. Imagine integrating this functionality into an existing service catalog. Let’s say you have a business user who needs access to Dynamics CRM Online. The user could navigate to the service catalog and request access. After their manager approvers, the application powering the service catalog could provision the new user, assign the license for Dynamics CRM Online, and drop the user into the appropriate groups. All of this could happen without having to involve IT. This is the value of a simple API with a wonderful set of libraries.

Well folks that wraps up my last post the year. I’ll return next year with a series of deep dives exploring Microsoft’s newly announced Azure AD Pass-through authentication and SSO features. Have a happy holiday!

Azure AD ASP .NET Web Application

Posted on by

Hi all. Before I complete my series on Azure AD Provisioning with a look at how provisioning works with the Graph API, I want to take a detour and cover some Microsoft Visual Studio. Over the past month I’ve been spending some time building very basic applications.

As I’ve covered previously in my blog, integration is going to the primary responsibility of IT Professionals as more infrastructure shifts to the cloud. Our success at integration will largely depend on how well we understand the technologies, our ability to communicate what business problems these technologies can solve, and our understanding of how to help developers build applications to consume these technologies. In my own career, I’ve spent a significant time on all of the above except the last piece. That is where I’m focusing now.

Recently I built a small.NET forms application that integrated with the new Azure AD B2B API. Over the past few days I’ve been spending time diving with to ASP .NET Web Applications built with an MVC architecture. I decided to build an small MVC application that performed queries against the Graph API, and wow was it easy. There was little to no code that I had to provide myself and “it just worked”. You can follow these instructions if you’d like to play with it as well. If you’ve read this blog, you know I don’t do well with things that just work. I need to know how it works.

If you follow the instructions in the above link you will have a ASP .NET Web Application that is integrated with your Azure AD tenant, uses Azure AD for authentication via the Open ID Connect protocol, and is capable of reading directory data from the Graph API uses OAuth 2.0. So how is all this accomplished? What actually happened? What protocol is being used for authentication, how does the application query for directory data? Those are the questions I’ll focus on answering in this blog post.

Let’s first answer the question as to what Visual Studio did behind the scenes to integrate the application with Azure AD. In the explanation below I’ll be using the technology terms (OAuth 2.0 and Open ID Connect) in parentheses to translate the Microsoft lingo. During the initialization process Visual Studio communicated with Azure AD (Authorization Server) and registered (registration) the application (confidential client) with Azure AD as a Web App and gave it the delegated permissions (scopes) of “Sign in and read user profile” and “Read directory data”.

In addition to the registration of the application in Azure AD, a number of libraries and code have been added to the project that make the authentication and queries to the Graph API “out of the box”. All of the variables specific to the application such as Client ID, Azure AD Instance GUID, application secret key are stored in the web.config. The Startup.cs has the simple code that adds Open ID Connect authentication. Microsoft does a great job explaining the Open ID Connect code here. In addition to the code to request the Open ID Connect authentication, there is code to exchange the authorization code for an access token and refresh token for the Graph API as seen below with my comments.

AuthorizationCodeReceived = (context) =>
{
var code = context.Code;
// MF -> Create a client credential object with the Client ID and Application key
ClientCredential credential = new ClientCredential(clientId, appKey);
// MF -> Extract the access token from cache and generate an authentication context from it
string signedInUserID = context.AuthenticationTicket.Identity.FindFirst(ClaimTypes.NameIdentifier).Value;
AuthenticationContext authContext = new AuthenticationContext(Authority, new ADALTokenCache(signedInUserID));
// MF -> Acquire a token by submitting the authorization code, providing the URI that is registered for the application, the application secret key, and the resource (in this scenario the Graph API)
AuthenticationResult result = authContext.AcquireTokenByAuthorizationCode(
code, new Uri(HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Path)), credential, graphResourceId);
return Task.FromResult(0);
}

Now that the user has authenticated and the application has a Graph API access token, I’ll hop over to the UserProfileController.cs. The code we’re concerned about in here is below with my comments.


{
Uri servicePointUri = new Uri(graphResourceID);
Uri serviceRoot = new Uri(servicePointUri, tenantID);
ActiveDirectoryClient activeDirectoryClient = new ActiveDirectoryClient(serviceRoot, async () => await GetTokenForApplication());
// MF -> Use the access token previous obtained to query the Graph API
var result = await activeDirectoryClient.Users.Where(u => u.ObjectId.Equals(userObjectID)).ExecuteAsync();
IUser user = result.CurrentPage.ToList().First();
return View(user);
}

Next I’ll hop over to the UserProfile view to look at the Index.cshtml. In this file a simple table is constructed that returns information about the user from the Graph API. I’ve removed some of the pesky HTML and replaced it with the actions.


@using Microsoft.Azure.ActiveDirectory.GraphClient
@model User
@{
ViewBag.Title = "User Profile";
}
"CREATE TABLE"
"TABLE ROW"
Display Name
@Model.DisplayName
"TABLE ROW"
First Name
@Model.GivenName
"TABLE ROW"
Last Name
@Model.Surname
"TABLE ROW"
Email Address
@Model.Mail

Simple right? I can expand that table to include any attribute exposed via the Graph API. As you can see in the above, I’ve added email address to the display. Now that we’ve reviewed the code, let’s cover the steps the application takes and what happens in each step:

  1. App accesses https://login.microsoftonline.com//.well-known/openid-configuration
    • Get OpenID configuration for Azure AD
  2. App accesses https://login.microsoftonine.com/common/discovery/keys
    • Retrieve public-keys used to verify signature of open id connect tokens
  3. User’s browser directed to https://login.microsoftonline.com//oauth2/authorize
    • Request an open id connect id token and authorization code for user’s profile information
  4. User’s browser directed to https://login.microsoftonline.com//login
    • User provides credentials to AAD and receives back
      1. id token
      2. access code for graph API with Directory.Read, User.Read scope
  5. User’s browser directed back to application
    • Return id token and access code to application
      1. id token authenticates user to application
      2. Access code for graph API with Directory.Read, User.Read scope temporarily stored
  6. Application accesses https://login.microsftonine.com//oauth2/token
    • Exchanges access code for bearer token
  7. Application sends OData query to Graph API and attaches bearer token.

That’s it folks! In my next post I will complete the Azure AD Provisioning series with a simple ASP .NET Web app that provisions new users into Azure AD.

Azure AD User Provisioning – Part 4

Posted on by

Today I will continue my series in Azure AD User Provisioning. In previous posts I looked at the GUI methods of provisioning users. I’ll now begin digging into the methods that provide opportunities for programmatic management of a user’s identity management lifecycle. For this post we’ll cover every IT Professional’s favorite Microsoft topic, PowerShell.

Microsoft has specific PowerShell modules for administration of Azure Active Directory. Microsoft is in the process of transitioning from the MSOnline (Azure Active Directory PowerShell v1) to the AzureAD module (Azure Active Directory PowerShell v2). At this time the AzureAD PowerShell module is in public preview with plans to migrate all the functionality from the MSOnline module to the AzureAD module. Until that point there will be some activities you’ll need to do in the MSOnline cmdlets.
Creating a new user using the MSOnline module (lovely referred to as the “msol” cmdlets) is a quick and easy simple line of code:

New-MsolUser -userPrincipalName user@sometenant.com -DisplayName "Some User"

The user can then be modified by using cmlets such as Set-MSolUser, Set-MsolUserLicense, Set-MsolUserPrincipalName, Set-MsolUserPassword, Remove-MsolUser. Using this set of cmdlets you can assign and un-assign user licenses and manage the identity lifecycle of the user account.

There are some subtle differences in the MSOnline and AzureAD cmdlets. These differences arise due to Microsoft’s drive to make the experience using PowerShell in the Azure AD module similar to the experience of using the Graph API. The AzureAD cmdlets are much more full featured in comparison to the MSOnline cmdlets. Close to every aspect of Azure AD can be managed across the board beyond just users. Here is an example of how you would create a user with the new cmdlets:

New-AzureADUser -UserPrincipalName user@sometenant.com -AccountEnabled $False -DisplayName "user" -PasswordProfile $UserPasswordProfile

You’ll notice a few differences when we compare the minimum options required when creating a user with the MSOnline cmdlets. As you’ll notice above, there are not just more required options, but one that make look unfamiliar called PasswordProfile. The Password profile option configures the user’s password and whether or not the user is going to be forced to change the password at next login. I struggled a bit with getting the cmdlet to accept the PasswordProfile, but the documentation on the Azure Graph API and a Microsoft blog that provided some information. It can be set with the following lines of code:

$UserPasswordProfile = "" | Select-Object password,forceChangePasswordNextLogin
$UserPasswordProfile.forceChangePasswordNextLogin $true
$UserPasswordProfile.password = "some password"

So what is the big difference between the MSOnline and AzureAD cmdlets? Well it comes down to the API each uses to interact with Azure AD. The MSOnline (aka Azure AD PowerShell v1) uses the old SOAP API. Oddly enough it uses the same SOAP API that Azure AD Connect uses. If you’ve read my Azure AD Connect – Behind the Scenes series, you’ll know notice the similarities in the Fiddler capture below.

pica-1

The AzureAD cmdlets (aka Azure AD PowerShell v2) uses the Graph API. In the Fiddler capture below you can see the authentication to Azure AD, obtaining of the authorization code, exchange for bearer token, and delivery of the bearer token to the graph API for the user information on Dr. Frakenstein. Check out the screenshot from Fiddler below:

picb

As you can see, PowerShell presents a powerful method of managing Azure AD and its resources. Given how familiar IT professionals are with PowerShell, it presents a ton of opportunities for automation and standardization without a significant learning curve. Microsoft’s move to having PowerShell leverage the power of the Graph API will help IT professionals leverage the power of the Graph API without having to break out Visual Studio.

In my next post I’ll write a simple application in Visual Studio to demonstrate the simplicity of integration with the Graph API and the opportunities that could be presented to integrating with existing toolsets.

Azure AD User Provisioning – Part 3

Posted on by

In this entry I’m going to look at how provisioning users differs in the Azure Management Portal and the Azure Portal. The Azure Management portal was used heavily for all Azure administration prior to the introduction of the Azure Resource Manager deployment model a year or so ago. To my knowledge there isn’t much functionality that hasn’t been migrated to the Azure Portal exempting management of Azure Active Directory. This remaining piece is in the process of being moved to the Azure Portal and is currently in public preview with some limitations. This means that if you’re administering Azure AD you’re going to need to use the Management Portal for a while longer.

Unlike the Office 365 portal, the Management portal feels very dated. The initial dashboard that appears after authentication will list any classic deployment model resources and directories the authenticated user has control over.

pic10

First I will select one of the directories and dig into the interface. Immediately you’ll notice a number of configuration options available. Since I’m focused on user provisioning, I’ll very briefly describe the purpose of the other sections.

  • Groups – Used to manage the group lifecycle of Azure AD groups
  • Applications – Used to add new applications from the application gallery and register custom and third party applications
  • Domains – Used to manage additional DNS domains that have been associated with the tenant
  • Directory Integration – Used to configure support for synchronization using a tool such as Azure AD Connect
  • Configure – Used to manage the configuration of Azure AD including password reset policies, MFA, device authentication options, group management, who can invite guests, and the like
  • Reports – Used to run the many reports available with standard Azure AD and Azure AD Premium
  • Licenses – Used to assign Azure AD Premium licenses; not sure if any licenses beyond that, but does not seem capable of handling O365 licenses.

Now let’s get back to user provisioning. Next up I’ll head to the Users section. Here there is a listing of all members and guests within the directory.

pic11

To create a new user I’ll click the Add User icon at the bottom of the page which will bring up the window below where I can configure the user name.

pic12

In the next window I will add a first name, last name, display name, and pick a role. Notice anything different? Here the only options to configure the Azure AD roles as described here. There are no Office 365 roles to choose from here. Additionally the user can be enabled for Azure MFA (the checkbox is hidden under the listing of roles).

pic13

In the last window I’m prompted to create an auto-generated temporary password for the user. Notice the option to create a password and enforce password change at first sign in aren’t there like O365? After the create button is hit a password will be automatically generated and will need to be delivered to the user out of band. Quite basic when compared to the Office 365 Admin Center isn’t it?

pic14

After the user is created the user can be modified in the Profile and Work Info sections. Profile is for your basic information and configuration while Work Info is similar to the contact information section in the Office 365 Admin Center with some additional options to configure the users authentication phone number and email address. The Devices and Activity sections providing reporting on the user’s activities.

pic15

Let’s now ditch the old and embrace the new by examining provisioning in the Azure Portal. Prior to a few months back, the only some of the Azure AD functionality could be administered in the Azure Portal including Azure AD Privileged Identity Management, Azure AD Identity Protection, Azure AD Connect Health, Azure AD Cloud App Discovery and Azure AD B2C (which is even mixed with the Management Portal). Microsoft has recently begun to migrate the administration of Azure AD to the Azure Portal to centralize administration of Azure resources.

The Azure portal is accessible through by navigating to this link. After authentication the dashboard will load up displaying any resources that have been pinned. Click on the Azure Active Directory blade as highlighted in red in the screenshot below.

pic16

You’ll notice right off the bat that the interface is very slick, is intended for power users, and provides some useful summary analytics. I hadn’t poked around the new blade in a while and it looks like they’ve improved the functionality quite a bit. There doesn’t seem to be much missing beyond the ability to create new directories, assigning licenses, and reviewing the holistic audit logs. One item I did observe which is worth calling out is the app registration interface has been refined and made more slick. This is a big improvement from the similar interface in the Management Portal.

pic17.png

By navigating to the All Users blade and clicking the add button a new user can be created. This will bring up a new blade that allows for basic configuration of key pieces of information like user, first name, last name, job title, description, group membership, and Azure AD roles. The experience is quite similar to the Management Portal experience. Notice that the password again is pre-generated and does not allow setting a customer password or the option to turn off the enforcement of a password change at first login.

pic18

After the user is created it can be modified by clicking on the user which opens a new blade. This new blade allows for contact information about the user to be edited, assignment of Azure AD Roles, and assignment Azure AD group memberships. One neat feature is the Azure Resources option. This opens up a new blade that enumerates the user’s effective access to various Azure resources. Providing reporting on an effective user’s access is one thing Microsoft has never done effectively on-premises so a feature like this is nice to see, especially with the additional complexity the scale of cloud introduces. Finally, you’re provided some options to review the audit logs and sign in reports for the user (another neat feature). Like the Azure Management Portal, there is no quick and easy GUI-based functionality to restore deleted users in the Azure Portal at this time.

pic19

Well folks that is the overview of three out of four of the GUI provisioning methods. The fourth option is to provision natively through an on-premises Active Directory and synchronize those users to the cloud with a synchronization tool such as Azure AD Connect. There is plenty of documentation on what that process looks like already available. If you’re hungry for more, you can check out my previous series Azure Active Directory Connect – Behind the Scenes.

Let’s take a moment to summarize what we’ve learned:

Office 365 Admin Console

  • Simple and ideal for business users and Tier 1 support
  • Limited in its ability to administer Azure AD
  • Only GUI option for assigning Office 365 licenses
  • Only GUI option for assigning Office 365 roles
  • No B2B or B2C support
  • Bulk user creation capabilities
  • Best option for restoration of a deleted user

Azure Management Portal

  • Legacy portal being replace by Azure Portal
  • Only GUI option for creating additional standard and B2C directories
  • Only GUI option for adding B2B users
  • No support for bulk user creation or restoration of deleted users
  • Support of legacy Azure AD configuration items; no support for configuration of B2C policies, Identity Protection, Privileged Identity Management

Azure Portal

  • Future one-stop shop for Azure AD administration
  • Seems to supports all functionality of Azure Management Portal except creation of new directories
  • GUI options for B2C policies, management of Identity Protection, Privileged Identity Management, Azure AD Connect Health, and Azure AD Proxy
  • No GUI option for adding B2B users
  • No support for bulk user creation or restoration of deleted users
  • Analytics built into administrative tools
  • Robust application registration features

So what does this all mean? Well it means that if you need to administer identity functionality via the GUI, you’re going to need to use a combination of the Office 365 Admin Console, the Azure Management Portal, and the Azure Portal. I expect within the next 3-6 months the remaining functionality in Azure Management Portal will be completely migrated to the Azure Portal. Businesses should focus their Tier 1 and business staff on learning the Office 365 Admin Console while Tier 2 and Tier 3 staff should focus on learning the Azure Portal.

Now that I’ve dug into the GUI options, I’ll next explore how the APIs and PowerShell provide opportunities for automation and integration with 3rd party and custom identity management solutions that may already exist on premises. See you then!