Security & Identity

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”

Advertisements

ECTS Extension Released

I am happy to announce the release of our ECTS Extensions to CodePlex. This extension provides a bit of a performance boost especially to the User Management capability in ECTS.
ECTS provides a forms based authentication schema for SharePoint that leverages ADAM so you can allow external people access to your SharePoint to enable collaboration. With these extensions you can now allow external users to request accounts as well as manage the accounts in a more friendly UI.

How many users can ECTS Handle?

How many users can ECTS Handle?

   

This has become a common question for a couple of my clients, to which I really don’t have a good answer. However, with my clients we have found significant issues when attempting to use the User Manager web part in ECTS when we have 100+ users. In fact, recently the client has had to go to using the ECTS login so they can manage the users because the Active Directory times out before the page loads.

   

Therefore my best answer right now is: Not many.

   

While that is my current answer, that is not the final answer. I have recently been working on a series of web parts to replace the default ECTS web parts. The goal is to make fast loading and easy to use web parts, which means sacrificing some of the custom call backs in favor of just displaying the hidden capabilities when the page is loaded.

   

If interested here are a couple of screen shot on how this looks.

   

ECTS User Manager

   

    ECTS External User Manager

This web part actually shows all of the users in ADAM. When you click on the Take Action button on the far right this is what you get.

    ECTS External User Take Action

   

My ECTS Enhanced User Manager

   

    MY User Manager

This is actually two web parts, the a | b | c |… is a connection provider which controls what CNs are searched for. This could be adapted to have a more, or less, capable filtering mechanism. Notice that the Reset Password, Toggle Enabled State and Delete are all exposed immediately. This prevents us from having to recreate the list of ADAM users every time the web part is loaded, and with the filter web part we now are able to reduce our search result set to a more manageable size. I have dropped the Modify capability in the current version, in the future I will add another connectable web part that will allow for editing of the selected user.

   

One difference in my version is that when a password is reset the user’s who’s password was reset receives an e-mail with the new password. I’m not sure if ECTS is supposed to do this as well, but from my experience, I have never received an e-mail when the password was reset other than that sent manually by the help desk personnel.

   

My ECTS Enhanced User Approval

    My User Approval Part

   

Here you will notice that the Requestor has been dropped from the default ECTS User Approval Web Part (not pictured).

   

One of the key changes I have made is to use the SPUtility.SendEmail(…) rather than the crazy database settings that ECTS has used. This provides several advantages, but most of all we can see if the send succeeded or failed. If it fails we can prompt the user to manually send information like passwords to the user proactively rather than waiting for the user to again request a password reset or, worse, leave and never come back. One of the biggest issues I have seen is that once an account gets approved the approval e-mail does not get sent to the user and they never receive a password. This then requires the site support team to use the User Manger, which can time out easily, to reset the password and e-mail it to the user.

   

The other major advantage is you don’t have to manage three different locations where the SMTP settings are kept, currently ECTS stores these in the web.config, the ECTS database, and they are stored in SharePoint’s SMTP settings.

ECTS Post Installation Issue

So I have had the opportunity to go back and work on the ECTS enabled system I worked on earlier this year for DoD. Sadly in my preparation for creating a new site I began working in my ECTS Virtual Machine, but in my haste one day I removed the external USB HD the VM is located on and corrupted the entire VM. As it turns out this has been a nice refresher in installing ECTS and I have found some new issues to write about.

 
 

Ok, so after installing ECTS on the system, which had a fresh installations of SQL Server Dev 2005, MOSS EE 2007, Visual Studio 2008, .NET Framework 3.5 I was able to install ECTS successfully without issue. Using my certificate authority installed on the VM I created the Cert for the ECTS ADAM communication and checked to ensure it was working. Finally, I extended my "internal" site so I would have an "external" forms authentication site. Next step was to check the "external" site to ensure it was configured correctly, and I was immediately redirected to the login page where I got the standard "Unknown Error" MOSS page.

 
 

Since I had the generic error, I updated the web.config to allow the callstack to display and turned off the custom errors. I then accessed the login page again and had the following error:

 

The resource object with key ‘loginPageTitleInTitleArea’ was not found. at System.Web.Compilation.ResourceExpressionBuilder.ParseExpression(String expression, Type propertyType, ExpressionBuilderContext context)

at System.Web.UI.BoundPropertyEntry.ParseExpression(ExpressionBuilderContext context)

at System.Web.UI.ControlBuilder.FillUpBoundPropertyEntry(BoundPropertyEntry entry, String name)

at System.Web.UI.ControlBuilder.AddBoundProperty(String filter, String name, String expressionPrefix, String expression, ExpressionBuilder expressionBuilder, Object parsedExpressionData, Boolean generated, String fieldName, String formatString, Boolean twoWayBound)

at System.Web.UI.ControlBuilder.PreprocessAttribute(String filter, String attribname, String attribvalue, Boolean mainDirectiveMode)

at System.Web.UI.ControlBuilder.PreprocessAttributes(ParsedAttributeCollection attribs)

at System.Web.UI.ControlBuilder.Init(TemplateParser parser, ControlBuilder parentBuilder, Type type, String tagName, String id, IDictionary attribs)

at System.Web.UI.ControlBuilder.CreateBuilderFromType(TemplateParser parser, ControlBuilder parentBuilder, Type type, String tagName, String id, IDictionary attribs, Int32 line, String sourceFileName)

at System.Web.UI.ControlBuilder.CreateChildBuilder(String filter, String tagName, IDictionary attribs, TemplateParser parser, ControlBuilder parentBuilder, String id, Int32 line, VirtualPath virtualPath, Type& childType, Boolean defaultProperty)

at System.Web.UI.TemplateParser.ProcessBeginTag(Match match, String inputText)

at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding)

 

Ok, so the first thing I noticed was the statement about a "resource object" which is a tell tail sign some .resx file did not get deployed.

 
 

RESX File’s in your Solution

RESX files (.resx) usually get deployed to your site’s app_globalresources folder, so if a resource object is missing then it’s a good idea to look there to ensure your resx file was deployed.

 
 

Next step was to determine what resx file was missing, so I went to the folder, typically you’re My Documents folder, that has the ECTS installer (ECTSSetupWizard.hta). In that folder is also the ECTSSolution.wsp file, which is really just a renamed .cab file. So I copied the ECTSSolution.wsp to ECTSSolution.cab and then opened the cab, inside there are 3 resx files. I initially copied all three to the "internal" and "external" site app_globalresources folders, however you should only have to copy the ExternalCollaboration.resx file to resolve the problem above.

 
 

After copying the files to the app_globalresource I refreshed the login page, and happly ever after it has worked.

 

DirectoryEntry Exception when calling Invoke(“SetPassword”,…)

I wrote a blog a few months ago about a COMException I got when I attempted to call DirectoryEntry.Invoke(“SetPassword”, …). The issue was that I could set the password for one account but then subsequent set password attempts would throw an exception. I had contacted Microsoft and they informed me that I was only the second person ever to report the problem, and that is was intermittent at best for the previous report. Microsoft had, and to this day still does not, have a hotfix for this issue.
After testing and trying a lot of ideas I thought I had resolved the issue by just capturing the exception and continuing on in my code (later calls would set account enabled and commit, etc). However, when we deployed the solution we quickly realized our test environment was able to create the account more regularly than our production environment. Therefore our testers were able to create account with valid password and log into the test environment, but production users were getting invalid passwords.
I started looking back through our system and SharePoint logs and realized I was still having the COMException get thrown and that the password change was not getting committed later in the process, our lost password utility really triggered this since both the account provisioner and lost password used the same logic for setting the password. Microsoft had told me that when the first caller notified them of this issue they were able to reset IIS and the issue was resolved.
Although this is a high availability environment, we really couldn’t afford resetting our IIS on the server every time a new account was created. Instead I realized that I could push the DirectoryEntry.Invoke(“SetPassword”, …) into a web service and allow my provisioning code to use that. Each time a web service was called it essentially created a new process to handle the service request, and when complete the process would effectively terminate.
Just to make sure this issue could also be worked around I added a Application Pool Recycle, basically a restart of an IIS Web Application, so that if it did fail we could restart the web service’s web application. I have been monitoring the log for about a month and have NEVER seen the recycle request. To date the code has created over 200 new Active Directory, MOSS, Exchange, and OCS accounts on our system.