Azure AD ASP .NET Web Application

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

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

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!

Azure AD User Provisioning – Part 2

Hello again. Today I will continue this series by examining the GUI options available within Microsoft’s Azure offerings to provision new user accounts. I am going to focus on member user objects and not guests for this series.

There are four native GUI options available that can be used to provision new user accounts in Azure Active Directory.

  1. Office 365 Administration Center
  2. Azure Management Portal
  3. Azure Portal
  4. ADUC/ADAC then synchronization to Azure AD

I’ll start with the Office 365 Admin Center. The Office 365 Administration Center is where most business will find themselves provisioning user accounts due to the popularity of the products under the Office 365 umbrella. The Admin Center provides an interface that is sleek and simple to navigate. The simplicity comes with a price. Administration of many aspects of Azure AD must be done outside of the Admin Center. This registering custom applications and applications from the application gallery, creation of additional directories such as B2C directories, B2B imports, and much more. Microsoft seemingly intends this interface to be business friendly administration endpoint for the Office 365 suite and rightfully assumes the consumers of this endpoint need simplicity.

I’ll now create a new user account. We first need navigate and login to the Office 365 portal. After the user authenticates the Office 365 home page that lists out the various applications the user has access to. I’ll next click on the Admin icon to enter the Admin Center. Next I will navigate to the Users section and select the Active Users section. This will bring us up a listing of the users currently in the Azure AD tenant associated with the Office 365 subscription.

pic1

When I hit the Add User button a new blade opens where the key components of the user’s account can be configured. This includes the first name, last name, user name and the like as seen in the screenshot below.

pic2

Let’s take some time to dig through the remaining sections.

First up is the contact information section. On-premise Active Directory administrators will recognize these fields from the various tabs in ADUC.

pic3

Next up is the password section. Here I have the option of creating a password or auto-generating a password and turning on or off the enforcement of a password change at first sign-in. I don’t recall there being an option to create a password a few months back when I was playing with the Admin Center, but that is one of the many lovely aspects of SaaS, continuous change and improvement.

pic4

Next up is the Roles section. Here there is an option to assign the user to the standard Azure AD roles or Office 365 roles. You can read more about these roles here.

pic5

Finally, the Licenses section allows for assignment of Azure AD and Office 365 licenses to the user account.

pic6

After the user is created it can be modified by clicking on the user object. Contact information about the user, membership into Azure AD groups, MFA enforcement, and product specific settings for the user can be modified in this blade.

pic7

The restoration of deleted users is simple and quick via the Deleted Users section. If only Microsoft had made it this easy in the old days of on-premises Active Directory prior to the Active Directory Administration Center.

pic8

Users can also be added in bulk by uploading a CSV file by hitting the More button in the Active Users section.

pic9.png

The Office 365 Admin Center interface is sleek and simple, perfect for a business user or Tier 1 support staff. So what’s the problem? No matter how simple the interface, it’s another process and interface staff need to learn. There is also no way to technically enforce standards for data input. What if what user puts MA and another puts Massachusetts? What about a user who misspells accountant in the job title field? Human error and lack of standardization can make for some nasty operational headaches, not to mention security risks. If an organization wants to limit the new processes and interfaces its staff needs to learn (because really, where is the business value in that?) as well as making sure the data about a user is standardized and correct, making these changes programmatically is the way to go.

In my next post I’ll cover both the Azure Management Portal and the Azure Portal.