ADFS & Multi Factor Authentication – Force MFA for browser based access to Office 365

Azure MFA is a great concept in itself, especially when applied to Office 365 using ADFS, but quite often there is a need for granular control over when MFA is actually applied. There are GUI options for enabling MFA just for extranet requests, but this poses several problems:

  1. Issues with Autodiscover requests – these are proxied from Office 365 and thus always route via the ADFS Proxy servers. This means that all Autodiscover requests, no matter where the client is located, appear to originate from the internet, which poses a problem when applying MFA to only be enforced for Extranet requests, as Outlook clients will be prompted for MFA even when inside the Intranet.
  2. Mobile Applications – These will likely always come from Extranet locations. It is undesirable, and in some cases unsupported, for these applications to use MFA whenever they are opened.
  3. Skype for Business client – It is not desired to require MFA when Skype for Business is opened from the Extranet.

One thing worth mentioning straight off the bat is that using the Azure MFA server with ADFS requires the ADFS Proxies either use the WAP role in Server 2012 R2 or a 3rd party proxy which can add the claim “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy” to show whether the connection is coming from the Extranet or not.

If you need more granular control than Extranet or Intranet (taking into account the considerations above), you need to use the Azure MFA server option to integrate MFA with ADFS. This provides the ability to great custom rules for your relying parties. There is a great guide on installation of this service here: https://azure.microsoft.com/en-gb/documentation/articles/multi-factor-authentication-get-started-adfs-w2k12/#securing-windows-server-2012-r2-ad-fs-with-azure-multi-factor-authentication-server

In addition to the MFA Server configuration itself, a custom ADFS claim needs to configured to force MFA if certain conditions are present. This can be very fiddly and currently there are not any GUI based tools to achieve this, so PowerShell is your friend!

For my example, I wanted to force MFA if the request comes from a browser on the extranet. This ensures that Outlook, the Skype for Business client and mobile applications never require MFA, but any access from browsers outside of the local network are MFA secured. The claim looks like this:

c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && 

c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)|(/adfs/oauth2)"] 

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");

This rule was applied using the below command. First, the above rule was set as the $mfarule variable.

$mfarule='c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)|(/adfs/oauth2)"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");'

Then the Office 365 Relying Party Trust was set as a variable.

$rpt = Get-AdfsRelyingPartyTrust –Name "Microsoft Office 365 Identity Platform"

And then the Authentication Rule was applied to the Relying Party!

Set-AdfsRelyingPartyTrust –TargetRelyingParty $rpt –AdditionalAuthenticationRules $mfarule

Before this was placed into production, a similar claim rule was applied which limited MFA to only a particular group of users. The claim for this is shown below and the group is specified using the ObjectSID. This is useful for testing the rule out on a subset of users:

c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c1:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)|(/adfs/oauth2)"] && c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-3388933763-2387696048-3050347461-86618"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");

This gave us the settings we needed for compliance, and figuring out the claim rules was complicated but quite fun. I hear that all this functionality will be moving into a GUI based system in Server 2016 so that’ll be nice.

Anyway, if anybody has any particular claim types they would like for particular situations, let me know and we can try and put something together

P.S. Huge thanks to Mark Vale and his article on the same subject, it helped me find the light in a very dark tunnel!

http://skype4b.uk/2015/06/12/adfs-multifactor-authentication-not-good-for-office-365/

Advertisements

Restrict access to OneDrive for Business

Edit: A new admin centre for OneDrive has been launched as of December 2016, and allows for much more granular control over what can be synchronised, and where from. Check it out at admin.onedrive.com

A question which I get asked quite frequently is whether OneDrive for Business can be blocked, locked down, or restricted. Whatever your reasons for doing this, there are some things you can do to restrict access.

As a little bit of background information, OneDrive for Business is not the same as your personal OneDrive, and is essentially your own private SharePoint library. If you have no plans to use SharePoint Online, then the easiest way to block access to OneDrive for Business is to simply remove the SharePoint Online license from the users in question. This is done in the sub menu of the licensing options for a user and can be applied on a per user basis.

SharePoint License

Another thing you can do is to hide the OneDrive button from the portal. This is done under the SharePoint Admin section of the Office 365 portal, under the Settings Tab. This setting applies to all users.

Hide OneDrive for Business

With this option selected, OneDrive will not show up in the Portal menu, along with the Office Web Apps.

Hide OneDrive for Business

We can also stop users from being able to create a personal site at all, by going into the User Profiles area of the SharePoint admin center. Go into Manage User Permissions and remove ‘Everyone except external users’. This will stop any users from being able to create their own OneDrive for Business sites. If you like, you can then add users or groups into this list who you would like to be able to create a OneDrive for Business site.

Personal Site Lockdown

This doesn’t stop any users who have already created their OneDrive for Business sites from accessing it if they know the direct URL or have added it as a favourite into their Internet Browser. I won’t be covering that scenario here, however if this is something you would like more information on, let me know in the comments and I will put a post together!

Built-in MDM for Office 365 is launched!

MDM Philosoraptor

Fantastic news follow nerds….one of my must have features for 2015 has been launched! I am super excited about this one and I believe that it will help give many new customers the peace of mind and confidence to start moving to Office 365 in earnest.

One of the great things about Office 365 is that you can get to your corporate data from anywhere, on any device. This is what users expect in todays modern world, and Office 365 lets us give our users the functionality they expect. However the services greatest benefit was also its greatest drawback. How can we make sure that data is secure if users can access it from anywhere. The answer to this before today was to either;

a. Use Microsoft Intune to control access to specific, enrolled devices. This came at additional cost and was a hard sell if a company had already got in bed with a different MDM provider.

b. Use ADFS and Conditional Access Policies to control access. This functionality was limited in scope and took away an awful lot of the benefits of Office 365 from a portability perspective.

c. Use the only control method available to try to limit data leakage; Exchange ActiveSync Quarantine. The problem with this is that it only applies to ActiveSync connections, and cannot control OneDrive for Business use. It also lacks granularity with regards to compliance.

Yesterday, the Office team announced that built-in MDM will be rolled out to all Office 365 commercial plans over the next 4-6 weeks. I am on the First Release program (http://doubledit.co.uk/2015/01/08/office-365-first-release-program/) and have not got the feature yet, but as soon as I do I will be playing around and reporting back!

The main features are as follows:

Conditional Access – this ensures that only managed, compliant devices can connect to your corporate data. This is the biggie and helps us control which mobile devices can access data stored in Office 365, not just Exchange Online.

Device Management – Jailbreak detection, PIN lock controls and rich reporting.

Selective Wipe – Remove corporate data from a managed device while leaving personal data in place.

For those wanting more advanced capabilities such as VPN/Wi-Fi profile management, PC Management and Mobile App management, InTune is still the go to Microsoft product.

You can find out more about the MDM capabilities being rolled out to Office 365 customers at the official blog here: http://blogs.office.com/2015/03/30/announcing-general-availability-of-built-in-mobile-device-management-for-office-365/

Modify AADSync Default Schedule

When using the AADSync tool to synchronise your Active Directory environment with Azure Active Directory (AAD), the default schedule for an incremental sync is 3 hours. This is done using a Scheduled Task. There are many reasons why you may want to change this schedule; maybe you have a high rate of change in your AD environment and you need a 1 hour sync to keep Office 365 up to date, or it might be that you have such a slow rate of change in your AD environment that you only want to sync your identities once every few days. It is worth mentioning that Password Synchronisation does not follow this schedule and is done immediately following a change of password, so this shouldn’t play a part in your decision to modify any scheduling of sync tasks.

Whatever your reasons, you are likely to become a little befuddled when trying to modify the regularity of your scheduled task. If you go into Task Scheduler, find the Azure AD Sync task and go into Properties, you can change the frequency of the task to make it run more or less often. However when you try to save the task it will ask you for the password of the account under which the task runs, the name of which looks something like ‘AAD_a6a4cefedc741’. It uses a random hex code at the end of the name so this could be slightly different to the example I’m using.

Modify AADSync Schedule

This account is used to run the AADSync service, is the account used to access the MIIS client database, and also to run the Scheduled Task. It is a local account which is created during the initial installation of AADSync, and the password is randomly generated. It may be tempting to change the password of this account, but please don’t. I have only come across this happening twice but both times have involved the internal database becoming completely inaccessible, meaning that the service simply won’t start, even with correct credentials.

If you really must change the frequency of your sync, create a new Scheduled Task and configure it to run the following application:

“C:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCMD.exe”

Ensure the Task is running with the highest possible priveleges and configure the task to use a user account which is a member of the following groups:

  • ADSyncAdmins
  • ADSyncBrowse
  • ADSyncOperators
  • ADSyncPasswordSet

This new task will run under whatever schedule you fancy, and for good measure you can disable the original task if you’d like. When dealing with default configuration items in any piece of software, I would always recommend creating cloned configurations rather than modifying the default, as it gives you a way to back out of changes and allows you to compare old with new.

Office 2016 Preview & Skype for Business

Big news today from the Office team!

The Office 2016 IT Pro and Developer Preview is now available! This is a very early build however those who choose to use the preview will receive updates and new functionality along the way, much like the Windows 10 Technical Preview. From an Office 365 point of view there are some lovely new features such as MAPI/HTTP built into Outlook, much better deployment and update management options for Click to Run deployments. If you want to grab the Preview, you can log in or sign up for a Microsoft Connect account and get your grubby mitts on it!

More information can be found here: http://blogs.office.com/2015/03/16/announcing-the-office-2016-it-pro-and-developer-preview/

In other news, the Skype for Business Preview has also been announced. This is the replacement for the Lync client and has been forthcoming for some time now. The concept is to bring the Skype experience to Office 365 customers, whilst retaining the Enterprise features which make Lync such a popular product, much like OneDrive and OneDrive for Business. Just like the Lync client, this will be built into Office 2016, however this product is much further down the development timeline and will be rolling out to Office 365 Lync Online customers starting next month!

The announcement can be found here with further information: http://blogs.office.com/2015/03/16/get-ready-for-skype-for-business/

Office 365 MSOnline PowerShell and Proxy Servers

If you administrate Office 365 regularly, especially from different locations, you may well have seen this error:

There was no endpoint listening at https://provisioningapi.microsoftonline.com/provisioningwebservice.svc

The number one cause for this error is a proxy servers. The likely cause is that your Internet Explorer browser has a proxy server configured. If this is in the format of a .pac file, you will need to go into IE>Internet Options>Connections>LAN Settings and remove the Proxy entry. Your connection will now be successful.

However if you have a proxy server manually set to a specific server, you need to tell PowerShell to go via the proxy. First though, check your winhttp configuration by running CMD as Administrator and running the following command:

netsh winhttp show proxy

This will probably show the following result:

netsh winhttp show proxy

Now run the following command:

netsh winhttp import proxy ie

This will import your proxy settings into your winhttp configuration and PowerShell should now navigate through the proxy and (hopefully) get to Office 365. Remember to restart PowerShell before attemping this! If this still doesn’t work, try removing the proxy settings in IE completely and retrying. If even this doesn’t do it, then you likely have a web filter blocking your traffic, in which case you will need to make sure the Office 365 IP addresses and/or URLs are allowed through your filter.

A lot of the above information depends on your network configuration and whether you are using transparent proxies or not, so information may not be 100% accurate to your specific setup. If you end up with incorrect winhttp settings and need to reset to defaults, run:

netsh winhttp reset proxy

from an Administrative CMD prompt and you will be back to square one.

Hopefully this helps some of you suffering from issues when trying to connect to Office 365 PowerShell.