Microsoft

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

Bye InfoPath, Hello Apps for Office & Lightswitch

The Microsoft Office announced  on Friday that InfoPath 2013 will be the final version released.  This is a significant announcement because it means any customer with custom SharePoint workflows, Office Document Information Panels, and any other Data Entry Applications will have to move those to a new technology, but Microsoft hasn’t said which one.

My Predictions

I believe Microsoft will recommend customers utilize one of two capabilities.  First, for customized Document Information Panels (those forms that can be added to Office applications, like Word, and can tie back to LOB systems or SharePoint) I believe Microsoft will recommend the use of the new Apps for Office Applications.  The Apps for Office allow creation of custom applications built on Web technologies like HTML5 and JavaScript and a set of Office JavaScript APIs are available for handling bindings to Office Templates.  The significant advantage, and disadvantage, here is that much can be done with customizing the retrieval of information from external systems, as well as customization of the injection of that information into the Document itself, but this also puts greater responsibility on the developers to request the information and push it to the application.

Second, for other business applications where data entry forms are needed, outside of the web, I believe Microsoft will push for the use of LightSwitch.  LightSwitch is a trimmed down version of the Visual Studio environment that allows for quick development of data entry applications/forms.  The information can easily be connected to XML or SQL data sources making this an easy replacement for the InfoPath Form entry design and use.

Feedback

I’d love to hear other’s predictions about what to do with the InfoPath applications that exist out there, so please leave a comment with your thoughts.

IE11 Broke SharePoint 2010

I’ve been noticing recently my SharePoint site was behaving oddly, especially when I wanted to edit a web part. Yesterday the odd behavior hit a critical point as I was unable to connect web parts on a page. The problem was every time I clicked the drop down arrow on the web part heading the page would refresh and some of the menu content would appear in a side panel, where the web part properties are usually displayed.

Knowing we had a customized master page I was convinced some change must have caused the problem. However, after reverting the master page to the site default the problem persisted. A coworker jokingly suggested I try using Chrome or Firefox. In frustration I opened the site in Firefox and amazingly everything worked.

I went back to IE 11 and opened the emulator setting. Although the browser mode was IE8 I noticed the User Agent setting was Default. I decided to change this to the IE8 User Agent setting and after the page refreshed, the site worked as expected.

After doing a little web search I found the IE team’s blog about changes to the User Agent string, which recommends you not use the User Agent Browser Sniffing technique (maybe something to tell the SharePoint Team?).

Overall, the site’s end user experience look unchanged, but it does effect the developer’s and site owner’s experience.

Site Collection Content Type vs. Content Type Hub

I’ve been working on a project recently that has a large number of sub-agencies and the parent organization was attempting to push a standardization of Content Types.  Since no one really wanted to duplicate work the organization decided they did not want to migrate content into SharePoint (from file shares) until all the content types and metadata had been identified and created.  However, as with all large agencies some groups wanted to move forward with limited or partial capabilities because after all some limited capability is better than what they currently have.  The concern that arose from this was: What if they created a Content Type in one of their Site Collections that had the same name as one that would be published later on?

The process I followed was very simple:

  1. Create a new Site Collection
  2. Create a Content Type ‘RFP’
  3. Create a Content Type in the Metadata Hub name ‘RFP’
  4. Publish and see what happens

Once the import of the Content Types was completed I checked my Content Type Import Log in the Site Collection (created in #1 above).  What I found was an error stating: Content Type Name ‘RFP’ conflict.  In addition I checked my Site Content Type and found that the one custom field I had added in the Metadata Hub was NOT included as a field of my local ‘RFP’ Content Type.

SharePoint Published Content Types

I have done a lot of development with SharePoint workflows, especially those developed in Visual Studio.  Unless I have been working with a standard list type, I generally create a Content Type that my workflow can be associated with and to ensure the columns and values needed in the workflow will be present.  However, creating Content Types is always a painful process, because as you develop the content types and test them you need to delete the original content type, and any list depended up in before you deploy the updated version.  This is even worse when you upgrade a solution that is in use in production because you can’t easily delete the content type just to add additional fields.

Recently, I have been working with Publishing Content Types, usually designed through the SharePoint UI, and what I began to notice was that when the published Content Type was updated in the Content Type Hub those changes were reflected in the sites making use of those Content Types.

This made me wonder if the same would happen if I deployed the Content Type through a Visual Studio solution, published it and then updated the Content Type.  I initially created a Content Type that had a Title and a Choice column.  Once deployed I published the content type and created a list in my Published Content Type Consumer site.  I then added an additional text column to the Content Type and redeployed.  After the Content Type Hub timer jobs executed the List I created using the Published Content Type now had the new column.

Lesson from this: If you have to deploy and maintain Custom Content Types use a Content Type Publishing Hub to manage the Content Types, and any future updates you may need to make.

SharePoint 2010 and jQuery 2.x

Recently, I was working with a coworker who had created a javascript dashboard using jQuery and KnockoutJS in SharePoint.  The dashboard had worked perfectly for him, but when I viewed the site none of the data would render.  While we were testing the site we noticed that my browser was running in Browser Mode IE10 with Document Standard IE 7 Standard, but his was running Browser Mode IE 10 with Document Mode: Standards.  Having battled with SharePoint 2010 using an HTML5 Masterpage I began looking for the Meta tag on the page which should define the appropriate browser mode and noticed he had removed it.  I had him add the tag back to the masterpage (from my experience removing the browser mode tag in SP2010 causes all kinds of issues when editing pages, list items, etc) but still found the dashboard was not functioning properly.

When we looked at the jQuery include I noticed he was using the latest version from the Microsoft CDN, which happens to be version 2.x.  Because I had another site running with jQuery and Knockout I had him revert his version of jQuery to 1.10.x and we found this was working.

The cause of the issue is detailed in the jQuery documentation for 2.x:
jQuery 2.x has the same API as jQuery 1.x, but does not support Internet Explorer 6, 7, or 8. (source)
The reason this is relevant is because SharePoint masterpages include:
<meta http-equiv=”X-UA-Compatible”content=”IE=8″/>
Which forces IE browsers to effectively run in an IE 8 mode.

Therefore, if you are a SharePoint 2010 developer and are attempting to use jQuery, make sure you are using 1.x versions