Azure

Azure AD MFA managed by User Account Administrator Role

Many organizations want to delegate enabling and disabling MFA for a user to their helpdesk, but the only RBAC role that allows MFA management is the Global Administrator and no one wants to grant helpdesk technicians Global Admin access to their tenant.  However, there is a way around this RBAC limitation if your organization has Azure AD Premium.

General Concept

At a high level enabling and disabling MFA will be managed by adding and removing users from a security group.  The security group will be included in a Conditional Access policy which defines the MFA requirements.

Setup

Requirements

  1. Admin with Conditional Access administrator role
  2. Helpdesk user(s) with User Administrator role assigned

Setup

Have a Helpdesk user create a security group in Azure Active Directory and assign the users your organization wants to require MFA when accessing applications.  Make sure to include a descriptive name like MFA Required Users.

NewGroup.png

Next, have the Conditional Access Admin create a new Conditional Access rule with Assignments target set to the group created by the Helpdesk user.

CATargetGroup.png

Next, select the Cloud apps you want to require MFA before allowing access, or select All Cloud Apps.

SelectCloudApps.png

Next, choose the option to Grant Access and check Require multi-factor authentication.

GrantMFAAccess.png

Finally, Enable the policy and choose Create.

CreatePolicy.png

Operations

Now, when the Helpdesk (someone with User Administrator Role) needs to enable or disable MFA for a user all they need to do is add (Enable MFA) or remove (Disable MFA) the user from your MFA Security Group.

Advertisements

O365 MFA vs Azure AD MFA

As a Technical Solutions Professional at Microsoft who covers Identity and Security I get a lot of questions about Office 365 MFA vs. Azure Active Directory MFA around the differences, benefits, and what I suggest.  Customers always assume because I concentrate on the EMS stack Microsoft offers (Intune, Azure AD, Azure Information Protection) I recommend Azure AD MFA over Office 365 MFA, but the reality is when customers really compare the experiences they will almost always go with Azure AD MFA.

Before we talk about Office 365 vs Azure AD MFA let me make this position perfectly clear.

Use MFA! If you are not using, or haven’t implemented, MFA stop reading and GO TURN IT ON especially for your Administrator accounts.

Why?  We, Microsoft, find that by enabling MFA on your accounts the your organization will reduce account compromise by OVER 99%!

Office 365 MFA

Office 365 E3, and up, subscriptions entitle an organization to enable Multi Factor Authentication for their users who will be accessing O365 resources (SharePoint, OneDrive, Office Pro Plus, etc.).  When a user is entitled and enabled to use MFA they have three (3) options:

  1. Azure Authenticator App
  2. Text Message
  3. Phone Call + PIN

To enable Office 365 MFA you must turn the feature on for each user individually (user-by-user), and once MFA is required for the user, it is always required for the user.  Therefore, when a user is authenticating to O365 resources from their work computer or home computer using Office or browser, they will be prompted for MFA verification.

Azure AD MFA

Azure AD MFA is available for organizations that purchase Azure AD Premium P1, or P2, licenses for their users and this Multi Factor Authentication solution can be use with Office 365, Azure, On-Premise applications, third party applications (SaaS), and custom built Line of Business applications.  Like the O365 MFA offering Azure AD MFA provides three (3) ‘native’ options:

  1. Azure Authenticator App
  2. Text Message
  3. Phone Call + PIN

Azure AD also offers customers the ability to use 3rd party MFA providers including the following:

  1. RSA
  2. DUO
  3. Trusona
  4. (More to come)

This additional integration with 3rd party MFA providers means that any existing investment in MFA can continue to be leveraged and we can provide MFA support even in locations where mobile or office phone access is limited or prohibited.

The way an organization applies MFA with Azure AD is also different than Office 365.  When applying MFA with Azure AD an organization does so by creating Conditional Access (CA) rules.  CA rules for MFA can be very simple:

All Users + All App + MFA = Grant Access

Basically this is what the Office 365 MFA solution provides, but limited to O365 apps that is.  However, CA can do much better, it can actually allow you to address questions and policies intelligently:

  • Why prompt for MFA when a user is connecting from a corporate network and is using a corporate device?
  • Why prompt for MFA when a user is connecting to their time card the same way you would if they were connecting to the corporate account line of business application?
  • Why MFA everyone all the time, can we target specific users when they are accessing accessing sensitive information?

Using CA to drive MFA also allows your organization to integrate MFA easily with Windows Always-On VPN solutions.  Now not only do you protect a user when their app connects to a service, but you protect your corporate network when an endpoint device connects and its all managed with the same CA, MFA, and identities.

What drive Azure AD MFA over Office 365 MFA

I find most organizations choose Azure AD MFA over Office 365 MFA for one of these two reasons:

  1. They already invested in an MFA solution, maybe RSA, so the users know it, IT trusts it, and they can continue to use it.
  2. They don’t have to use an All-Or-Nothing approach, they can apply a Who-What-When-Where approach to their MFA policy and only require MFA when necessary.

To me, the greatest benefit of Azure AD MFA is the ability to target MFA scenarios.  I’ve seen many customers push MFA for everyone all the time, and within a short period of time they turn it off because “there was too much prompting”

Azure – PowerShell Capabilities I Love

I use Azure for Development and Testing very heavily with my job as a consultant for Microsoft.  Since most of my work is done deploying systems On-Premises I usually have to build environments for testing of deployment scripts etc.  This means I have the option to go through the Azure Portal and create machine after machine, or I can use PowerShell to script these processes.  As such I have gone through many of the IAAS PowerShell commands and thought I would share some of my commonly used commands.

IAAS Commands I Always Use

Set-AzureRmVMCustomScriptExtension

So, you create a VM and now you want to configure it before you actually log in, like make it a domain controller or join it to a domain.  No problem, the Set-AzureRmVMCustomScriptExtension allows you to push and run a script file on the Azure VM without needing to log in, and you can even pass arguments to the script. This command does require a bit of information (Resource Group Name, Storage Account Name, Container, and others) but being able to create a VM AND set it up as the domain controller without ever logging in first…you can’t beat that.

Set-AzureStorageBlobContent

This command is a MUST KNOW because it allows you to move content from your local machine to an Azure Storage Blob, and if you want to use Set-AzureRmCustomScriptExtentions, your scripts have to be in an Azure Storage Blog.  This command is actually pretty straight forward, give it the filename (blob), Container, Storage Account Context and the local file path and upload away.

New-AzureRmResourceGroup

Every time I create a new “Environment” I create a new resource group partly because I’m lazy, but also because I’m really picky.  I don’t like having 2,  3,  4, … environments inside of one resource group because when I script things I really just want to say something like “Start My Resource Group xyz” and let the script handle the rest.  Also when I’m done with an environment I can easily clean it up by using the Remove-AzureRmResourceGroup, and poof its gone.

New-AzureRmVm

Need a new VM, here you go.  This command isn’t as straight forward as it seems, really to use New-AzureRmVm you must create the Azure RM Config object and all the necessary elements, but this inside of a simple ForEach-Object loop can save you hours of entering information into the Azure Portal forms.

Runbooks – Stay under that spending limit

Azure Runbooks are one of my favorite capabilities available.  First, the interface is web based so you can write and test your PowerShell directly in the Azure Portal which is a really nice capability.  Second, you can schedule these books to run so if you forget to shutdown and environment, the scheduler will do it for you.  Third, if there was a problem your output from each run is available for review so you can always go back and review the Runbook output and check the script health.  Finally, Runbooks have access to variables stored Outside of the Runbook, so no need to include the admin account’s info in your PowerShell script, just save it in the Runbook’s variables (as a Credential, so the password is hashed) and make nice generic runbooks.

I highly recommend using runbooks to at least stop your development, and possibly test, environment on a daily basis.  My Stop-Daily runbook is configured to run every day at 6PM so I know all of my VMs will be shutdown.  I typically keep my runbook(s) in a separate Resource Group from the different Development/Test environments I create, this way I can destroy the environment without losing the runbooks.

Runbook(s) work within a single subscription, so if you have multiple Subscriptions you will need to create runbooks for each.

Azure Mobile Angular Services

I recently had a request for a more detailed example of how to use the Azure Mobile Angular Services so I went ahead and created a single page application that has very little capability but is a good example for those getting started with AngularJS and Azure Mobile Angular Services and have pushed it to the GitHub site.  The example is built using Visual Studio but is just a single HTML page and a Scripts folder with the necessary .js files inside.  Once you have pulled the project you will find it does actually read from my Azure Mobile Services, although write is disabled, so you can follow along.

AngularJS Module for Azure Mobile Services

A few months back a coworker introduced me to AngularJS as an alternative to using KnockoutJS.  Around the same time Microsoft was pushing a bunch of videos and “How To’s” on the Azure Mobile Services.  After walking through the AngularJS tutorial and playing with the Azure Mobile Services “To Do” Demo I decided it would be interesting to mesh these two items together, use AngularJS in the UI to communicate with Azure Mobile Services for data storage, and who know what else in the future.

The first thing I did was create the To Do demo application and then I started to create the AngularJS partial views for everything.  Once the views and all worked I began working on the actual communication with the Azure Mobile Services, and this is where things went south.

Don’t Assume AngularJS Behaves

So the major problem I ran into was that I *ahem* Assumed that AngularJS would behave with JQuery Deferred objects, in particular with the Ajax objects and the ‘Then’ chaining.  I know AngularJS has its own Ajax methods, but the Azure Mobile Services utilize JQuery and I wanted to stick as close to the “To Do” code as I could.  Well, what I found was AngularJS doesn’t behave well with JQuery Then chaining, and this has to do with Angular’s $q object.  If you read the documentation for $q you will find, somewhat glossed over I believe, the following statement in the section “Differences between Kris Kowal’s Q and $q” the following statement:

$q is integrated with the $rootScope.Scope Scope model observation mechanism in angular, which means faster propagation of resolution or rejection into your models and avoiding unnecessary browser repains, which would result in flickering UI.

The first part of that statement is key: $q is integrated with the $rootScope.Scope which means other deferred objects that change values linked to UI components won’t trigger the $rootScope.Scope to repaint the browser display.  Therefore code like:

$get([some url]).then(function() { someUiBoundVariable = "in then"; });

would fail to update the UI with the “in then” string value.

Solution

So after realizing the issues of $q Deferred objects vs. other JavaScript Library Deferred objects I rewrote my Azure Service to utilize the $q deferred object.  Interestingly, my coworker who introduced me to AngularJS soon contacted me about how to integrate AngularJS with the Azure Mobile Service, so I took my object and made it more generic so he and I could both use the same AngularJS Module.  After we both used this for a little we realized we had a reasonably solid AngularJS Module for the Azure Mobile Services, and so was born the AngularJS Module for Azure Mobile Services NuGet Package and AngularJS Module for Azure Mobile Services Codeplex Project.

Get AngularJS Module for Azure Mobile Services

There are two ways you can use the AngularJS Module for Azure Mobile Services.  First you can use NuGet and add AngularJS Module for Azure Mobile Services to your project.

NuGet Package: http://www.nuget.org/packages/AzureMobileAngularServices

Or you can download the js file directly from CodePlex and add this to your project.

CodePlex Project: http://azuremobileangularservices.codeplex.com/