The chronicles of a Bostonian tech geek navigating through life, technology, and general geekiness.

Menu

Tag Archives: identity

Over the past year I’ve done deep dives into both Amazon’s AWS Managed Microsoft Active Directory and Microsoft’s Azure Active Directory Domain Services. These services represent each vendor’s offering of a managed Windows Active Directory (AD) service. I extensively covered the benefits of a service over the course of the posts, so today I’m going to cover the key features of each service. I’m also going to include two tables. One table will outline the differences in general features while the other outlines the differences in security-related features.

Let’s hit on the key points first.

Amazon provides a legacy (Windows AD is legacy folks) managed service while Microsoft provides a modernized service (Azure AD) which has been been integrated with a legacy service.

Microsoft synchronizes users, passwords hashes, and groups from the Azure AD to a managed instance of Windows Active Directory. The reliance on this synchronization means the customer has to be comfortable synchronizing both directory data and password hashes to Azure AD. Amazon does not require any data be synchronized.

Amazon provides the capability to leverage the identities in the managed instance of Windows AD or in a forest that has a trust with the managed instance to be leveraged in managing AWS resources. In this instance Amazon is taking a legacy service and enabling it for management of the modern cloud management plane.

The pricing model for the services differs where Amazon bills on a per domain controller basis while Microsoft bills on the number of objects in the directory.

Amazon’s service is eligible to be used in solutions that require PCI DSS Level 1 or HIPAA.

Both services use a delegated model where the customer has full control over an OU rather the directory itself. Highly privileged roles such as Schema Admin, Enterprise Admins, and Domain Admins are maintained by the cloud provider.

Both services provide LDAP for legacy applications customers may be trying to lift and shift. Microsoft limits LDAP to read operations while Amazon supports both read and write operations.

Both services do not allow the customer to modify the Default Domain Policy or Default Domain Controller Policies. This means the customer cannot modify the password or lockout policy applied to the domain. Amazon provides a method of enforcing custom password and lockout policies through Fine Grained Password Policies. Additionally, the customer does not have the ability to harden the OS of the domain controllers for either service so it is important to review the vendor documentation.

Well folks that sums it up. As you can see from both of the series as well as this summary post both vendors have taken very different approaches in providing the service. It will be interesting to see how these offerings evolve over the next few years. As much as we’d love to see Windows Active Directory go away, it will still be here for years to come.

Welcome back fellow geek. Today I’m continuing my deep dive series into AWS Managed Microsoft AD. This will represent the seventh post in the series and I’ve covered some great content over the series including:

Today I’m going cover three additional capabilities of AWS Managed Microsoft AD which includes the creation of trusts, access to the Domain Controller event logs, and scalability.

I’ll first cover the capabilities around Active Directory trusts. Providing this capability opens up the possibility a number of scenarios that aren’t possible in managed Windows Active Directory (Windows AD) services that don’t support trusts such as Microsoft’s Azure Active Directory Domain Services. Some of the scenarios that pop up in my head are resource forest, trusts with trusted partners to maintain collaboration for legacy applications (applications dependent on legacy protocols such as Kerberos/NTLM/LDAP), trusts between development, QA, and production forests, and the usage of features features such as selective authentication to mitigate the risk to on-premises infrastructure.

For many organizations, modernization of an entire application catalog isn’t feasible but those organizations still want to take advantage of the cost and security benefits of cloud services. This is where AWS Managed Microsoft AD can really shine. It’s capability to support Active Directory forests trusts opens up the opportunity for those organizations to extend their identity boundary to the cloud while supporting legacy infrastructure. Existing on-premises core infrastructure services such as PKI and SIEM can continue to be used and even extended to monitor the infrastructure using the managed Windows AD.

As you can see this is an extremely powerful capability and makes the service a good for almost every Windows AD scenario. So that’s all well and good, but if you wanted marketing material you’d be reading the official documentation right? You came here for the deep dive, so let’s get into it.

The first thing that popped into my mind was the question as to how Amazon would be providing this capability in a managed service model. Creating a forest trust typically requires membership in privileged groups such as Enterprise Admins and Domain Admins, which obviously isn’t possible in a manged service. I’m sure it’s possible to delegate the creation of Active Directory trusts and DNS conditional forwarders with modifications of directory permissions and possibly user rights, but there’s a better way. What is this better way you may be asking yourself? Perhaps serving it up via the Directory Services console in the same way schema modifications are served up?

Let’s walk through the process of setting up an Active Directory forest trust with a customer-managed traditional implementation of Windows Active Directory and an instance of AWS Managed Microsoft AD. For this I’ll be leveraging my home Hyper-V lab. I’m actually in the process of rebuilding it so there isn’t much there right now. The home lab consists of two virtual machines, one named JOG-DC running Windows Server 2016 and functions as a domain controller (AD DS) and certificate authority (AD CS) for the journeyofthegeek.com Active Directory forest. The other virtual machine is named named JOG-CLIENT, runs Windows 10, and is joined to the journeyofthegeek.com domain. I’ve connected my VPC with my home lab using AWS’s Managed VPN to setup a site-to-site IPSec VPN connection with my local pfSense box.

Prior to setting up the trusts there are a few preparatory steps that need to be completed. The steps will be familiar to those of you who have established forests trusts across firewalled network segments. At a high level, you’ll want to perform the following tasks:

For the first step I played it lazy since this is is a temporary configuration (please don’t do this in production). I allowed all traffic from the VPC address range to my lab environment by modifying the firewall rules on my pfSense box. On the AWS side I needed to adjust the traffic rules for the security group SERVER01 is in as well as the security group for the managed domain controllers.

To establish DNS resolution between the two forests I’ll be using conditional forwarders setup within each forest. Setting the conditional forwarders up in the journeyofthegeek.com forest means I have to locate the IP addresses of the managed domain controllers in AWS. There are a few ways you could do it, but I went to the AWS Directory Services Console and selected the geekintheweeds.com directory.

On the Directory details section of the console the DNS addresses list the IP addresses the domain controllers are using.

After creating the conditional forwarder in the DNS Management MMC in the journeyofthegeek.com forest, DNS resolution of a domain controller from geekintheweeds.com was successful.

I next created the trust in the journeyofthegeek.com domain ensuring to select the option to create the trust in this domain only and recording the trust password using the Active Directory Domains and Trusts. We can’t create the trusts in both domains since we don’t have an account with the appropriate privileges in the AWS managed domain.

Next up I bounced back over to the Directory Services console and selected the geekintheweeds.com directory. From there I selected the Network & security tab to open the menu needed to create the trust.

From here I clicked the Add trust relationship button which brings up the Add a trust relationship menu. Here I filled in the name of the domain I want to establish the trust with, the trust password I setup in the journeyofthegeek.com domain, select a two-way trust, and add an IP that will be used within configuration of the conditional forwarder setup by the managed service.

After clicking the Add button the status of the trust is updated to Creating.

The process takes a few minutes after which the status reports as verified.

Opening up the Active Directory Users and Computers (ADUC) MMC in the journeyofthegeek.com domain and selecting the geekintheweeds.com domain successfully displays the directory structure. Trying the opposite in the geekintheweeds.com domain works correctly as well. So our two-way trust has been created successfully. We would now have the ability to setup any of the scenarios I talked about earlier in the post including a resource forest or leveraging the managed domain as a primary Windows AD service for on-premises infrastructure.

The second capability I want to briefly touch on is the ability to view the Security Event Log and DNS Server logs on the managed domain controllers. Unlike Microsoft’s managed Windows AD service, Amazon provides ongoing access to the Security Event Log and DNS Server Log. The logs can be viewed using the Event Log MMC from a domain-joined machine or programmatically with PowerShell. The group policy assigned to the Domain Controllers OU enforces a maximum event log size of 256MB but Amazon also archives a year’s worth of logs which can be requested in the event of an incident. The lack of this capability was a big sore spot for me when I looked at Azure Active Directory Domain Services. It’s great to see Amazon has identified this critical use case.

Last but definitely not least, let’s quickly cover the scalability of the service. Follow Microsoft best practices and you can take full advantage of scaling horizontally with the click of a single button. Be aware that the service only scales horizontally and not vertically. If you have applications that don’t follow best practices and point to specific domain controllers or perform extremely inefficient LDAP queries (yes I’m talking to you developers who perform searches using front and rear-facing wildcards and use LDAP_MATCHING_RULE_IN_CHAIN filters) horizontal scaling isn’t going to help you.

Well folks that rounds out this entry into the series. As we saw in the post Amazon has added key capabilities that Microsoft’s managed service is missing right now. This makes AWS Managed Microsoft AD the more versatile of the two services and more than likely a better fit in almost any scenario where there is a reliance on Windows AD.

In my final posts of the series I’ll provide a comparison chart showing the differing capabilities of both AWS and Microsoft’s services.

Unless your organization popped up in the last year or two and went the whole serverless route you are still managing operating systems that require centralized authentication, authorization, and configuration management. You also more than likely have a ton of legacy/classic on-premises applications that require legacy protocols such as Kerberos and LDAP. Your organization is likely using Windows Active Directory (Windows AD) to provide these capabilities along with Windows AD’s basic domain name system (DNS) service and centralized identity data store.

It’s unrealistic to assume you’re going to shed all those legacy applications prior to beginning your journey into the public cloud. I mean heck, shedding the ownership of data centers alone can be a huge cost driver. Organizations are then faced with the challenge of how to do Windows AD in the public cloud. Is it best to extend an existing on-premises forest into the public cloud? What about creating a resource forest with a trust? Or maybe even a completely new forest with no trust? Each of these options have positives and negatives that need to be evaluated against organizational requirements across the business, technical, and legal arenas.

Whatever choice you make, it means additional infrastructure in the form of more domain controllers. Anyone who has managed Windows AD in an enterprise knows how much overhead managing domain controllers can introduce. Let me clarify that by managing Windows AD, it does not mean opening Active Directory Users and Computers (ADUC) and creating user accounts and groups. I’m talking about examining performance monitor AD counters and LDAP Debug logs to properly size domain controllers, configuring security controls to comply with PCI and HIPAA requirements or aligning with DISA STIGS, managing updates and patches, and troubleshooting the challenges those bring which requires extensive knowledge of how Active Directory works. In this day an age IT staff need to be less focused on overhead such as this and more focused on working closely with its business units to drive and execute upon business strategy. That folks is where managed services shine.

AWS offers an extensive catalog of managed services and Windows AD is no exception. Included within the AWS Directory Services offerings there is a powerful offering named Amazon Web Services Directory Service for Microsoft Active Directory, or more succinctly AWS Managed Microsoft AD. It provides all the wonderful capabilities of Windows AD without all of the operational overhead. An interesting fact is that the service has been around since December 2015 in comparison to Microsoft’s AAD DS which only went into public preview at in 3rd Q 2017. This head start has done AWS a lot of favors and in this engineer’s opinion, has established AWS Managed Microsoft AD as the superior managed Windows AD service over Microsoft’s AAD DS. We’ll see why as the series progresses.

Over the course of this series I’ll be performing a similar analysis as I did in my series on Microsoft AAD DS. I’ll also be examining the many additional capabilities AWS Managed Microsoft AD provides and demoing some of them in action. My goal is that by the end of this series you understand the technical limitations that come with the significant business benefits of leveraging a managed service.

Welcome! This entry continues my series in the integration of Azure AD and AWS. In my first entry I covered what the advantages of the integration are. In the second entry I walked through my lab configuration and went over what happens behind the scenes when an application is added to Azure AD from the application gallery. In this post I’m going to walk through some of the configuration we need to do in both Azure AD and AWS. I’ll also be breaking open the Azure AD and AWS metadata and examining the default assertion sent by Microsoft out of the box.

In my last entry I added the AWS application to my Azure AD tenant from the Azure AD Application Gallery. The application is now shown as added in the All Applications view of the Azure Active Directory blade for my tenant.

After selecting AWS from the listing of applications I’m presented with a variety of configuration options. Starting with Properties we’re provided with some general information and configuration options. We need to ensure that the application is enabled for users to sign-in and that it’s visible to users so we can select it from the access panel later on. Notice also that that I’m configuring the application to require the user be assigned to the application.

On the Users and groups page I’ve assigned Rick Sanchez to the application to allow the account access and display it on the access panel.

After waiting about 10 minutes (there is a delay in the time it takes for the application to appear in the application panel) I log into the Access Panel as Rick Sanchez and we can see that the AWS app has been added for Rick Sanchez.

Back to the properties page of the AWS application, my next stop is the Single sign-on page. Here I drop down the Single Sign-on Mode drop box and select SAML-based Sign-on option. Changing the mode to SAML-based Sign-on exposes a ton of options. The first option that caught my eye was the Amazon Web Services (AWS) Domain and URLs. Take notice of the note that says Amazon Web Services (AWS) is pre-integrated with Azure AD and requires no mandatory URL settings. Yeah, not exactly true as we progress through this series.

Further down we see the section that allows us to configure the unique user identifier and additional attributes. By default Microsoft includes the name, givenName, surName, and emailAddress claims. I’ll need to make some changes there to pass the claims Amazon requires, but let’s hold off on that for now.

Next up a copy of the Azure AD metadata (IdP metadata) is provided for download. Additionally some advanced options are available which provide the capability to sign the SAML response, assertion, or both as well as switching the hash algorithm between SHA1 and SHA256.

Now like any nerd, I want to poke around the IdP metadata and see what the certificate Azure AD is using to sign looks like. Opening up the metadata in a web browser parses the XML and makes the format look pretty. From there I grab the contents X509Certificate tag (the base-64 encoded public-key certificate), dump it to Notepad, and renam it with a file extension of cer. Low and behold, what do we see but a self-signed certificate. This is a case where I can see the logic that the operational overhead is far greater than the potential security risk. I mean really, does anyone want to deal with the challenge of hundreds of thousands of customers not understanding the basics of public key infrastructure and worrying about revocation, trust chains, and the like? You get a pass Microsoft… This time anyway.

Before I proceed with the next step in the configuration, let’s take a look at what the assertion looks like without any of the necessary configuration. For this I’ll use Fiddler to act as a man-in-the-middle between the client and the web. In session 6 of the screenshot below we see that the SAML response was returned to the web browser from Azure.

Next up we extract that information with the Text Wizard, base-64 decode it, copy it to Notepad, save it as an XML file, and open it with IE. The attributes containing values of interest are as follows:

Destination – The destination is the service provider assertion consumer URI

NameID – This is the unique identifier of the used by the service provider to identify the user accessing the service

Recipient– The recipient attribute references the service the assertion is intended for. Oasis security best practices for SAML require the service provider to verify this attribute match the URI for the service provider assertion consumer URI

Audience – The audience attribute in the audienceRestriction section mitigates the threat of the assertion being stolen and used to impersonate a user. Oasis security best practices require the service provider to verify this when the assertion is received to ensure it is recognizes the identifier. The way in which this is accomplished is the value in the audience attribute is checked against the service provider EntityID attribute.

Additionally we have some interesting claims including tenantid, objectidentifier of the user object in Azure AD, name, surname, givenname, displayname, identityprovider, and authnmethosreferences. I don’t think any of these need further explanation.

Let’s now take a look at the AWS (service provider in SAML terms) metadata. The AWS metadata is available for download from here. After it’s downloaded it can be opened with IE.

The fields of interest in this set of metadata is:

EntityID – The entityID is the unique identifier AWS will provide in its authentication requests. Let’s note the value of urn:amazon:webservices for later as it will come in handy due to some issues with Microsoft’s default settings.

NameIDFormat – This tells me both transient and persistent are accepted. I won’t go into details on Name ID format, you can review that for yourself in the Oasis standard. Suffice to say the Name ID format required by the service provider can throw some wrenches into integrations when using a more basic security token service (STS) like AD FS.

AssertionConsumerService – This is where our browser will post back the SAML assertion after a successful authentication. Note the URI in the location field.

RequestedAttributes – This provides us with a listing of all the attributes AWS will accept in an assertion. Note that the only two required attributes are Role and RoleSessionName.

We’ve added the AWS application to Azure AD, granted a user access to the application, and have started the SAML setup within Azure AD (Identity Provider). Let’s continue that setup by configuring which attributes Azure AD will include in the assertions delivered to AWS. From review of the AWS metadata we know that we need to send claims of Role and RoleSessionName. The RoleE will match to an an AWS IAM Role handling authorization of what we can do within AWS and the RoleSessionName provides a unique identifier for the user asserting the entitlement.

Back in the Azure AD Portal I’m going to click the option to View and edit all other user attributes. The exposes the attributes Microsoft sends by default. These include givenName, suName, emailAddress, and name. Since the AWS metadata only requires RoleSessionName and Role, I’m going to delete the other attributes. No sense in exposing additional information that isn’t needed!

After the extra attributes are deleted I create the two required attributes as seen in the screenshot below.

I’m now going to bounce over to the AWS Management Console. After logging in I navigate to the Services menu and choose IAM.

On the IAM menu I choose the Identity providers menu item and hit the Create Provider button.

On the next screen I’m required to configure the identity provider settings. I choose SAML from the drop-down box enter a provider name of MAAD and upload the IdP metadata I downloaded from Azure AD referenced earlier in the blog entry and hit the Next Step button.

On the next page I verify the provider name and the type of identity provider and hit the Create button. Once that is complete I see the new entry listed in identity providers list. Easy right?

We have an identity provider, but that identity provider needs some IAM roles to be associated with the identity provider that my fictional users can assert. For that I go to the Roles section and hit the Create Role button.

On the next screen I select the SAML button as the type of trusted entity since the role is going to be asserted via the SAML trust with Azure AD. Here I select the MAAD provider and choose the option to allow the users to access both the AWS Management Console and the API and then hit the Next: Permissions button.

As I referenced in my first entry to this series, the role I’m going to create is going to be capable of managing all EC2 instances. For that I choose the AmazonEC2FullAccess policy template and then hit the Next:Review button.

On the last screen I name the new role AzureADEC2Admins, write a short description, and hit the Create Role button.

The new role is created and can be seen associated to the identity provider representing the trust between AWS and Azure AD.

Let’s sum up what we did for this entry. We examined the key settings Microsoft exposes for configuration with the AWS integration. We examined the Azure AD (IdP) and AWS (SP) metadata to understand which settings are important to this integration and what those settings do. We examined an assertion generated out of Azure AD prior to any of the necessary customization being completed to understand what a canned assertion looks like. Finally, we completed a majority of the tasks we need to complete on the AWS side to create the SAML trust on the AWS end and to create a role JoG users can asserts. Are your eyes bleeding yet?

In my last post in this series I’ll walk through the rest of the configuration needed on the Azure AD end. This will include going over some of the mistakes the Microsoft tutorial makes as well as covering configuration of Azure AD’s provisioning integration as to what it means and how we can effectively configure it. Finally, we’ll put all the pieces of the puzzle together, assert our identity, and review logs at AWS to see what they look like when a federated user performs actions in AWS.

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.

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.

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.

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.

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

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.

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.

And the code for the Results view.

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.

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.

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

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.

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.

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!

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.

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.

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.

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).

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?

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.

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.

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.

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.

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.

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

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!

Welcome back! Over the past year I’ve done a number of deep dives into Azure AD authentication, but what is authentication without an identity? They have to get there somehow, right? Gone are the days of legacy protocols such as LDAP or executing a command to a database to provision a local user. Identity as a service offerings such as Azure AD introduce whole new ways to provision users, both manually through the GUI and through programmatic methods such as PowerShell or the Graph API. For this upcoming series of blogs I’m going to cover the many options available with Azure AD and the plusses and minuses of each.

Let’s begin this series by talking about “legacy” tools versus “modern” tools. What do I mean by legacy? Well I mean administrative graphical user interface (GUI) options. Why are administrative GUIs legacy? Well, cloud is primarily about automation, scale, and simplicity. To achieve those ideals, “cloud” services (whether they are IaaS, PaaS, SaaS, or IDaaS) must be capable of integrating well with other solutions, whether they be COTS or custom. Pay attention to the word “integration” people. It is more important than ever.

Administrative GUIs represent the old IT where the business had to depend on IT to administer and support its technologies. This was costly in the ways of labor, time, and complexity. The focus on standardized application programming interfaces (APIs) that is happening in the cloud is attempting to streamline this process for the business. These APIs provide a programmatic method of integration with the cloud solutions to take the middle man (IT) out of the equation and put the business users in the driver’s seat. Existing COTs or custom applications can be integrated directly with these APIs to simplify and automate a number of processes that typically fell into IT’s realm.

So what are some examples?

Scenario: Business user needs to share a document with a partner company

In the “old” days, the business would have to rely on IT to setup complicated VPN solutions to allow for connectivity and either provision users directly in the identity data store or configure Active Directory trusts. With the standardized APIs emerging in the cloud, an existing identity management system can be directly integrated with an IDaaS API.

If the business takes advantage of the programmatic access, the business user clicks a button of the person or persons he or she wishes to share the document with, the request goes to an approver such as the data owner, and the provisioning is done automatically by the application. No service requests or multiple day turnarounds from IT required here. The value presented by IT in here was the initial integration, not much else.

Scenario: Business focuses on application development and a developer requires a new web instance to test code

In “legacy” IT the developer would need to submit a request to IT to provision a server, install and configure the appropriate middleware, and have security staff verify the server and applications have been configured for compliance. The developer would then need to wait to be provisioned for access as well as deal with the continued maintenance of the web instance. All of this took time and this was time the developer wasn’t developing, which impacts the businesses ability to deliver the product and service they’re in business to deliver.

We know the value that PaaS provides here, but what about the APIs? Well, envision a service catalog where a developer requests an instance of a web platform that is automatically provisioned and configured to the businesses baseline. Where was IT in this scenario? They setup the initial integration and keep the baselines up to date, and that’s it. Not only does the business save money by needing less IT support staff but its key assets (developers) are able to do what they’ve been hired to do, develop, not submit requests and wait.

In the above two scenarios (and there are oh so many more), we see that IT professionals can no longer focus on a single puzzle piece (server, OS, networking, identity, virtualization, etc), but rather how all of those puzzle pieces fit or “integrate” together to form the solution. Cloud as-a-service offerings made the coffin and simple APIs are the nails sealing the coffin finally putting the “legacy” IT professional to rest.

So why did I spend a blog entry talking about the end of the legacy IT professional? I want you to think about the above as I cover the legacy and modern provisioning methods available in Azure AD. As we explore the methods, you’ll begin to see the importance programmatic access to cloud solutions will play in this cloud evolution and the opportunities that exist for those IT professionals that are willing to evolve along with it.

In my next post to this series I will cover the various GUI methods available for user provisioning in Azure AD.

About Me

Hi there! My name is Matt Felton and I am a long time geek with a passion for technology. I have over 10 years experience in the industry that spans the technology stack. Over the past few years I’ve had the opportunity to dig deeper into security and identity which I’ve been more than happy to do.

I started Journey Of The Geek over 6 six years ago when I saw an opportunity to provide in-depth technical deep dives to peel back the onion on technologies and products. I enjoy sharing what I’ve learned and giving back to the industry. Plus there is no better way to learn a topic than to teach it.

I hope you enjoy and if you have questions feel free to reach out via the comments, LinkedIn, or Twitter.

DISCLAIMER

All views expressed on this site are my own and do not represent the opinions of any entity whatsoever of which I have been, am now, or will be affiliated.