Azure App Cloud Discovery & PAC Files

Azure App Cloud Discovery is a seriously cool piece of technology. Being able to scan your entire computer estate for cloud SaaS applications in either a targeted, or catch-all manner can really help discover the ‘Shadow IT’ going on in your environment. Nowadays, users not having local admin rights won’t necessarily stop them from using cloud SaaS apps in any way which is going to increase their productivity. Users don’t generally think about the impact of using such applications, and the potential for data leakage.

But, as with lots of Microsoft’s other cloud technologies which are being launched left, right and centre at the moment, the Enterprise isn’t catered for as it might hope. Most Enterprise IT departments leverage some kind of web filtering, or proxying. This may be using transparent proxying, in which case you can count your blessings as Cloud App Discovery will work just fine. If you are explicitly defining a proxy in your internet settings, then you can get around that by adding particular registry keys. However if you are using a PAC file to control access to the internet, then unfortunately Cloud App Discovery will not work for you. This is a shame as it is, in my opinion, the best way to approach web proxying in an Enterprise, but that’s another story. From what I have heard, a feature is in the works which will allow you to configure Cloud App Discovery agents to log their findings to an internal data collector. This data collector can sit on a local server and then upload data to Azure on your behalf, which is a much more elegant solution to the problem of data collection from multiple machines. However as far as I know, this feature is not available yet. I’ll be keeping my ear to the ground and will let you know if this changes.

In the meantime, if you are desperate to get your data collection up and running in the meantime, you could change to explicitly defined proxying, and configure registry settings for your clients as per the following MS article:

https://azure.microsoft.com/en-gb/documentation/articles/active-directory-cloudappdiscovery-registry-settings-for-proxy-services/

Cloud App Discovery is a feature of Azure Active Directory Premium, a toolkit designed to take your Azure Active Directory to new, cloudier heights. Azure AD Premium can be bought standalone, or comes bundled with the Enterprise Mobility Suite. I would highly recommend it to Office 365 customers as it can give you and your users some great new features which can help make your Azure AD the best it can be!

Edit: It looks like PAC file support has been added rather surreptitiously. No announcement was made, and the KB articles haven’t been updated. I happened to check the Change Log today and Release 1.0.10.1 includes an option to tweak your PAC file to support Cloud App Discovery. https://social.technet.microsoft.com/wiki/contents/articles/24616.cloud-app-discovery-agent-changelog.aspx

Alternatively, if you use a PAC file (Proxy Auto Configuration) to manage proxy configuration, please tweak your file to add https://policykeyservice.dc.ad.msft.net/ as an exception URL.

I’m yet to test this myself but it looks promising!

Advertisements

Shameless TechNet self promotion

I’ve just realised that I never shared this link. I wrote this technical piece for the TechNet UK Blog back in July 2015, and just thought I’d give it a bump. The subject matter is regarding the post-hybrid Office 365 landscape, and what you should be doing once you’ve migrated all your mailboxes (apart from get yourself an ‘I am a cloud god’ mug).

Office 365 – The Journey Continues

Exchange 2013 Hybrid – Content was blocked because it was not signed by a valid security certificate

Hello again. The last few days have given me lots of new things to do, so apologies if you are being inundated with blog posts!

So today I went to enable a new Exchange 2013 Hybrid configuration. I used the Start Menu launcher for ‘Exchange Administrative Centre’, which to be honest I don’t usually do. This took me to https://localhost/ecp/?ExchClientVer=15. I then went to Hybrid and enabled the Hybrid Configuration. I logged into Office 365 and was greeted by this friendly message of doom:

Content was blocked because it was not signed by a valid security certificate

This error is quite easily solved; do not use localhost as the server name when you access the ECP. Use your client access namespace instead. For example, if my CAS name was mail.misstech.co.uk, I would browse to https://mail.misstech.co.uk/ecp/?ExchClientVer=15.

Just be sure to put outlook.office365.com and your CAS name into your Intranet Zone too or you’ll then get an error about Cookies!

412 - Cookies are disabled

Thanks for reading!

Exchange Online Public Folder Migration Fail

Today I have been migrating Public Folders (yuk!) from Exchange 2010 to Exchange Online, and have come across a slightly odd issue.

I had followed the lovely guide to Public Folder migrations provided by Microsoft here, however I could not complete my migration as the migration batch had completed with errors. The error I was receiving was as follows:

Error: MigrationMRSPermanentException: Error: There are 2 mail public folder‎(s)‎ in Active Directory that were not linked to any public folder during migration.

The Public Folders referenced in the error message were both Exchange system folders, so I wasn’t sure why it was bothering to try and synchronise them. Luckily the error message does give us a clue as to what to do;

You may also run "Set-MailPublicFolder -IgnoreMissingFolderLink:$true" for each AD object that is a legacy system folder and resume the migration

Being the silly person I am, I assumed that this command needed to be run against the legacy Public Folders On Premise, but apparently -IgnoreMissingFolderLink is not a parameter in Exchange 2010. What I actually needed to do, which is not obvious from the error message,  was to run this command in Exchange Online. I ended up using a catch all command, which looked like this:

Get-MailPublicFolder | Set-MailPublicFolder -IgnoreMissingFolderLink:$true

Once this was done, I stopped the migration batch, and then started it again. It then performed it’s initial sync and I was able to continue the migration!

 

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/

Office 365 Hybrid – On Premise Room Mailboxes not available in OWA

I came across an issue today wherein a user whose mailbox was hosted on Office 365 attempted to use OWA to book a meeting On Premise, and was told that there were no rooms available. The list simply didn’t contain any rooms. The Room Mailboxes were synchronised to Office 365 using the AADSync tool, however OWA knew nothing about them. When using Outlook, the Rooms were shown correctly, so this was just an issue with OWA, not with Room Mailboxes per se.

After a little digging, I found the following KB article: https://support.microsoft.com/en-us/kb/2904381 which explains that a Room List should be created and synchronised to Office 365 to get this working in OWA.

However the PowerShell cmdlet in the KB article fell a little short as I had over 100 Rooms to add into the Distribution Group. This was the PowerShell I ended up using:

$members=Get-Mailbox -RecipientTypeDetails RoomMailbox
New-DistributionGroup -Name "RoomList" -RoomList -Members $Members

I then moved the newly created Distribution Group into the correct OU and performed a Directory Sync. The RoomList showed up instantly, but it took 5-10 minutes for it to become populated. Once this was all done, the Rooms were available!

RoomOWA

Restrict OneDrive for Business synchronisation to domain joined machines only

Edit: This can now be done in a GUI by using the OneDrive Admin Centre at admin.onedrive.com. It also allows Mac clients by default now.

A quick preface to this post; making the changes listed below will stop all Mac clients from being able to sync their OneDrive, and will not stop mobile devices from connecting to OneDrive using the app. It also doesn’t stop the downloading or uploading of files from the web access of OneDrive. It’s sole purpose is to limit the functionality of the Windows OneDrive for Business sync client!

Firstly you need to find out the GUID for the Active Directory domain which you want to be able to sync OneDrive for Business from. To do this, log onto a Domain Controller and run the Active Directory Module for PowerShell, or run a normal PowerShell window and run

import-module ActiveDirectory

in order to get the correct cmdlets imported. Get a list of your domains by running

(Get-ADForest).Domains

And then use this command to get a list of GUIDs which will be in the same order as your domain list

$domains = (Get-ADForest).Domains; foreach($d in $domains) {Get-ADDomain -Identity $d | Select ObjectGuid}

From this you should be able to work out the correct GUID for your Active Directory domain name. Copy and paste that sucker into notepad. Now head on over to a SharePoint Online PowerShell session using the SharePoint Online Powershell module and Connect-SPOService and run

Set-SPOTenantSyncClientRestriction  -Enable -DomainGuids "b45b7d67-e68b-430e-bb76-2a31948b3221”

Make sure you replace the GUID here with the GUID you copied and pasted earlier and this setting will lock down your OneDrive for Business synchronisation to client which have the same domain GUID. If you want to enter more than one GUID, separate them with commas.

Hope this helps and sorry if it’s a bit of a haphazard blog post, it was written in a bit of a hurry!