Cloud Security 101

With Microsoft, Amazon and Google currently enticing businesses and consumers into cloud services with promises of resiliency, scalability and simplified administration, many companies are quite rightly moving services and data into the cloud in some way or other.

Before making such a leap however, questions must be asked about data security and compliance. Cloud services must be scrutinised in order to ensure that data geo location and security practices meet compliance requirements for the customer and their clients. After all, you are trusting these providers with your essential business data, and in some cases your intellectual property.

Edward Snowdens leaks regarding NSA/GHCQ snooping, along with the leakage of personally identifiable information from services at Sony, eBay and the like has left many people suspicious and wary of who exactly can get to your information. This blog post is here to show you a sample of the security features used to protect your data in Office 365 and Azure, and some of the ways your data is protected in transit.

Office 365 Security

The Office 365 service provides many layers of security. Microsoft want to be seen as a safe pair of hands to help drive adoption and for this reason they have the interests of security and privacy at the very top of their lists of priorities.

The data in all Office 365 services is encrypted at rest using BitLocker and in addition to this, as of November 2014, all Office 365 data is encrypted again on a per file basis. This means that each individual file is encrypted using different keys, which are stored in an alternate location to the master key.

All Administrative actions taken on Office 365, either by the tenant administrators or the service administrators, are audited and fully transparent. As an Office 365 customer, you can view and export a list of Powershell commands run by Microsoft Support or your own administrators. Microsoft support technicians are given administrative access when required based on the least privilege model, and this access is time limited by default.

Data theft from inside or outside of the service is a serious concern to Microsoft and the Office 365 team work on the assumption that a compromise has already been made. A Red team exists whose sole job is to attempt to compromise the systems protecting customer data. They do this by attempting to gain access to test data, and a Blue team works in parallel to identify the Red team and counteract this threat. This is the equivalent of having your IT systems constantly penetration tested, which is more than most companies can say for their own IT systems!

Compliance in Office 365 is a hot topic and is critical to getting governmental departments, and health and financial companies on board. Office 365 are compliant with many of the standards required in these sectors, such as ISO 27001, FISMA, and HIPAA.

All of these security features help to make Office 365 a platform which is likely to be far more secure and compliant than your own On Premise environment. Microsofts transparency on security and privacy are also far superior to any of their rivals, giving you the peace of mind needed to begin your move to the cloud.

Much more information can be found at the Office 365 Trust Center – http://trust.office365.com.

Azure & Microsoft Datacentre Security

The Microsoft Azure IaaS environment should be considered by customers as an extension of their Datacentre. Microsoft are staunch supporters of the concept that the data you place in cloud services is your data, not theirs. Encryption is in place across all servers, and nobody with physical access in the Datacentre has knowledge of which customer’s data is in which rack or server.

Direct access to the Azure Hypervisors is unavailable to customers and network isolation is used to separate traffic between tenants. There are also various methods customers can use to increase the privacy of their Azure traffic, such as using Azure Private Virtual Networks and Azure ExpressRoute, which creates a direct connection to Azure, keeping your inter-site traffic off the Internet.

The physical environment is highly secured and access is extremely limited by using separation of duties and roles to make sure that no one person has too much knowledge of the systems. Failure to abide by the Microsoft Datacentre security policies means instant dismissal for the employee. In addition to this, personally identifiable information is stored separately to non-personally identifiable information.

All access to customer data is blocked by default, using a zero privileges policy. If this is allowed, it is time limited and fully audited. In addition to this, staff members who receive this access to customer data will not have physical datacentre access. These same physical and data based access controls are also in place for the Office 365 and all other Microsoft Online services.

From a compliance point of view, you can rest assured that Azure complies with the majority of major standards across the world. These compliance standards are not easy to achieve by any standards, but Microsoft remain committed to keeping their compliance up to date and as broad as possible. Some of the specific compliance standards which are verified for the Azure Service are:

  • ISO/IEC 27001
  • SOC 1 and SOC 2 SSAE 16/ISAE 3402
  • UK G-Cloud
  • HIPAA BAA
  • EU Model Clauses
  • Singapore MCTS
  • FedRAMP
  • PCI DSS
  • Australia IRAP

Much more information can be found at the Azure Trust Center – http://azure.microsoft.com/en-us/support/trust-center/.

Convincing your boss, management boards and other business trustees that a move to the cloud is a secure one is a tough job, but Microsofts commitment to privacy, security and transparency makes it much easier to put together a viable business case which can help you reap the rewards of scalability, resiliency and compliance.

Exchange Online – Lock down mail flow

By default, Office 365/Exchange Online allows mail to be received from any external source. This is done using a ‘hidden’ default inbound connector. The properties of this connector cannot be viewed or modified, even in Exchange Online Powershell.

This is all well and good and allows you to be able to send/receive mail out of the box in Office 365, however is does cause a problem if you are using a 3rd party mail solution such as Mimecast or Websense. If you do happen to be using a 3rd party mail filter and you leave the default inbound connector alone, somebody could bypass your filter by sending you mail directly to your Office 365 hostname. From a best practices and security point of view, this is most definitely a bad thing.

To combat this and limit Office 365 from receiving mail only from your mail filter, go into your Exchange Admin centre and create a new Inbound Connector under Mail Flow>Connectors.

New Inbound Connector

The settings of your Inbound Connector should be as follows:

Type: Partner
Connection Security: Force TLS (only if your mail filter supports forced TLS. This will add an extra layer of security. Otherwise, use Opportunistic TLS)
Sender Domains: *
Sender IP Addresses: 1.2.3.4 (enter your mail filters IP addresses here)

This example states that Office 365 will only receive mail from the IP address 1.2.3.4 and nothing else. The * wildcard under Sender Domains applies the connector to all mail. If I were to use Exchange Online Powershell to perform the same task, my command would look like this:

New-InboundConnector -Name Lockdown -ConnectorType Partner -RequireTls $true -SenderIPAddresses 1.2.3.4 -SenderDomains *

This simple configuration change will ensure that nobody can bypass your mail filter and spam you with invitations to enlarge something or other 🙂

Office 365 First Release Program

First of all, Happy New Year and welcome to 2015!

It’s been a long time coming, but I finally signed up for my very own Office 365 account today for my own production and testing environment. 2015 will hopefully see me develop my SharePoint Online skill set, and I’m also keen to have a test bed for problems which clients come to me with, and also just to satisfy my own curiosity when I need to!

The Office 365 teams are making a lot of UI changes at the moment, the majority of which I like a lot, but I need to be able to keep on top of the changes to avoid getting egg on my face in front of customers 🙂

For this reason, one of the important things for me to enable straightaway was the First Release program. This program is designed for the people who want to be on the bleeding edge, and gives the tenant updates as soon as they become available, sometimes as soon as one week after the announcement. This will allow me to test new functionality and become fully versed with it before my customers even receive it!

If you are one of those that live on the bleeding edge, log into your Office 365 Admin portal, and go to Service Settings>Updates and enable!

Office 365 First Release

Change Office 365 Start Page

When a user logs into the Office 365 portal, they will be presented with the below screen. But what if they want to be faced with their Newsfeed when logging in?

Office 365 Start Page

In that case, the user simply goes to their Office 365 Settings page:

Office 365 Settings

And then to the Start Page option. The user can then decide what page they would like the portal to default to when signing in:

Office 365 Start Page Customisation

You can also provide users with separate URLs for different services. For example, the OWA URL would be:

https://outlook.com/contoso.com

This could be configured as a Favourite in the users internet browser. Other options include SharePoint Online URLs such as:

Newsfeed: https://tenantname-my.sharepoint.com

OneDrive: https://tenantname-my.sharepoint.com/personal/username_contoso_com

Team Site: https://tenantname.sharepoint.com

N.B. Replace tenantname with your own Office 365 tenant name.

Synchronised User not Provisioned in Lync Online

Today I came across an issue with Lync Online during an implementation of Office 365. We synchronised the user accounts and password hashes using AADSync and applied E3 licenses to a few test users in the IT team. Their testing was successful with the exception of Lync Online, which they could not login to with their synchronised @contoso.com account. The error returned to them was as follows:

Lync couldn't find a Lync Server for contoso.com. There might be an issue with the Domain Name System (DNS) configuration for your domain. Please contact your support team.

Lync Online DNS Error

I tested using my own testuser@contoso.com account and could successfully login to Lync Online internally and externally, which showed me that the DNS records were created correctly. After looking at the firewall logs it appeared that the DNS name lyncdiscoverinternal.contoso.com was being unsuccessfully looked up. This DNS record is used for On Premise Lync installations. I also noted that in the Office 365 Lync Admin centre, the user had not been provisioned.

After quizzing the customer, we discovered that a proof of concept Lync server had been installed a while back and enabled for a few test users in the IT department. This server was not properly decommissioned so AD attributes still existed for these test users. In order to get Lync Online to provision the accounts we had to go into ADSIEdit and clear the following attributes so that they were empty:

msRTCSIP-DeploymentLocator
msRTCSIP-FederationEnabled
msRTCSIP-InternetAccessEnabled
msRTCSIP-Line
msRTCSIP-OptionFlags
msRTCSIP-PrimaryHomeServer
msRTCSIP-PrimaryUserAddress
msRTCSIP-UserEnabled
msRTCSIP-UserPolicies

We then ran a delta sync and hey presto, our user accounts were provisioned in Lync Online and the users could successfully login. The error message we initially given was fairly misleading, but this just shows you how important proper decommissioning is when it comes to essential services like Lync and Exchange.

Purge a user account from Office 365

Today I made a mistake and accidentally linked together a standalone Office 365 account with an account synchronised from Active Directory. The ‘in cloud’ user became linked to the AD account and became ‘synchronised with Active Directory’. This wouldn’t usually be a problem and is done by design if the two UPNs match each other. My main problem was that the ‘in cloud’ user already had a mailbox, and so did the user in AD. This leads to a split-brain scenario whereby both systems believe to be hosting the mailbox. As I was about to configure a Hybrid Deployment, this is not a good thing.

Luckily the Office 365 account did not hold any required information in Exchange Online or SharePoint/OneDrive. In order to clean up the objects I moved the affected user into an OU which was not being synchronised and then performed a delta sync. This moved the object in Office 365 into the Deleted Users container. A deleted user in Office 365 remains in this container for 30 days before it is removed, however I did not have the luxury of waiting this long.

In order to purge the user account from Office 365 completely, I went into Office 365 powershell and ran the following command:

Remove-MsolUser -UserPrincipalName username@domain.com –RemoveFromRecycleBin –Force

This purges the item from the Deleted Users container. In Active Directory, I then moved the user object back into it’s original OU, and forced a sync. This provisioned a new user in Office 365. When applying the license to said user, I was correctly informed that the on premise mailbox had not been migrated to Exchange Online. Success!

Just Announced – Office 365 Video!

Office 365 development continues on at a fast pace, and the latest product to be added to the portfolio comes in the shape of Office 365 Video. Video is becoming a more and more prevalent way to share content, ideas and information and using Office 365 Video, you will be able to have your own corporate YouTube style portal for video content. The portal allows for Yammer conversations to take place in line with the video content, and allows for uploading and consuming video content on any device, right in line with Microsoft’s vision for a mobile-first, cloud-first world.

SharePoint Online is required for Office 365 Video to be functional, and it will become available worldwide in early 2015 on a per tenant basis. Enterprise and Academic plans only will be able to use the feature, and I can see it being a hit with the Academic plans in particular! For all the government Office 365 customers out there, this features is planned but no release dates set yet.

There will be no additional cost for the storage of videos, however it will count against your Team Site pooled storage, so this needs to be kept in mind with regards to large file sizes. Like most Office 365 features, you will also be able to enable and disable Office 365 Video at will.

To find out more information, check out http://blogs.office.com/2014/11/18/introducing-office-365-video/

Allow login to Azure AD/Office 365 using Primary SMTP address

The new Directory Synchronisation tool from Microsoft, AAD Sync, went into General Availability a few weeks back. This new tool is toting new features such as Password Write-back, AD Attribute Filtering and multi-forest synchronisation. All in all it is a great replacement to the now defunct DirSync product.

One issue which AAD Sync allows you to solve is the use of UPNs for usernames in Azure Active Directory. A UPN appears as if it is an email address, and often AD user accounts have different UPNs to their Primary SMTP addresses. This can cause confusion for users who expect to be able to login using their email address, just like they would in any cloud service out there. You could change the users UPN to match this, however in some situations this is not possible, either due to existing applications which use the UPN or due to Security policies which do not permit internet routable UPN suffixes.

Before I explain how this works, I must say that this process should only be done on initial synchronisation as you could cause issues if you change this parameter on existing Azure AD instances. More information on the limitations and risks of doing this can be found here: http://social.technet.microsoft.com/wiki/contents/articles/24096.dirsync-using-alternate-login-ids-with-azure-active-directory.aspx

When you configure AAD Sync, you can select which username your AAD users receive based on particular AD attributes, for example, the Primary SMTP address. This allows us to give users with strange/non-conformed AD usernames (such as 17047dd) a useable and memorable AAD username which is the same as their Primary SMTP address (David.Dixon). This configuration is performed in the User Matching section of the configuration, and you must change the userPrincipalName attribute to use the mail attribute.

UPN Matching in AAD Sync

If your organisation is planning to use ADFS, this poses a problem as the authentication is performed on premise, and your users cannot authenticate using their SMTP address if their UPN is different! To get around this, we can configure ADFS to use the mail attribute for authentication, as per the article below.

http://technet.microsoft.com/en-us/library/dn659436.aspx

There are a couple of issues with this concept of user provisioning and authentication in Office 365, particularly when hybrid deployments are in use. The first is that when users authenticate against ADFS internally using IWA, the UPN will be the authentication mechanism. For domain joined machines this is not a problem (as long as the ADFS hostname eg. sts.doubledit.co.uk is added to Trusted Sites in IE) however if a machine is non domain joined or outside of the internal LAN, the user will receive 2 authentication prompts, one against Exchange Autodiscover (using the UPN) and another to Office 365 once the Autodiscover redirection has taken place (using the Primary SMTP). The second issue is that ActiveSync devices cannot support double authentications and will need to be manually reconfigured to use outlook.office365.com when the users mailbox is moved.

For these reasons it is generally good practice to only implement this solution for migrations with no autodiscover redirection in place, such as pure Office 365 or cutover/staged migrations. It can be successfully used with either AADSync/DirSync w/ Password Sync or ADFS.

Quite often, a users UPN will be different from their Primary SMTP address, and this is a way to allow your Azure AD users to login using their Primary SMTP address without changing the User Principal Name, reducing confusion for the users and creating a more consistent experience.

TechEd Europe 2014

TechEd Europe 2014

Today I am packing my bags and preparing myself for a week away in sunny Barcelona for TechEd Europe 2014. This will be the first TechEd event I have ever been to, and to say I am excited is a bit of an understatement!

I’ve got my schedule all planned out using the Content Builder, and have at least 2 sessions scheduled for every single time slot. What with the breakout sessions, hands on labs and focus groups it’s going to be a very busy week!

My focus for the breakout sessions will be around Office 365/Exchange, Hybrid Identity and the Enterprise Mobility Suite. I’ve also got a couple of Windows 10 sessions in there for light relief, but we will see how things pan out.

I am hoping to be writing a daily blog to sum up each days events and I hope you’ll join me on my TechEd journey.

Controlling Autodiscover using Group Policy

27/03/2015 – Update: This has turned into my second most popular blog post, and is also one of the first I ever wrote. For that reason, I have given it a major update and hopefully made it more readable and helpful!

Autodiscover is a very important part of any Exchange deployment these days, whether it is a cloud-based Office 365 deployment or an On Premise deployment. It is the primary method by which your clients discover where their Exchange Server is located and what configuration is set. Manual configuration of Outlook profiles is still possible, but is very much a thing of the past.

How does Autodiscover work in Outlook?

When you configure a new Outlook profile, or open Outlook with a profile already configured, the client will go through a series of lookups to discover the correct server to connect to. This process looks something like this:

1. SCP object lookup – Outlook performs an Active Directory query for Service Connection Point (SCP) objects. When an Exchange Server is installed, it registers an SCP object in Active Directory. As this is the first lookup that Outlook does, this means that if your Outlook client can contact a Domain Controller, and you happen to have an Exchange Server installed in your forest, it will find the SCP record and attempt to connect to that Exchange Server.

2. Root domain query based on your primary SMTP address – Outlook uses the root domain of your primary SMTP address to try to locate the autodiscover service, and then tries to connect to that URL to retrieve the autodiscover XML file: https://autodiscover/autodiscover.xml. For example, my Outlook client will look up https://misstech.co.uk/autodiscover/autodiscover.xml. If it can find the autodiscover XML file here then it will obtain it’s configuration information from that file.

3. Query for the autodiscover sub-domain – Outlook uses the autodiscover sub-domain to try to locate the service. This is the most commonly configured way of deploying autodiscover from my experience. Outlook will attempt to connect to that URL to retrieve the autodiscover XML file: https://autodiscover.domain.com/autodiscover/autodiscover.xml. For example, my Outlook client will look up https://autodiscover.misstech.co.uk/autodiscover/autodiscover.xml. If it can find the autodiscover XML file here then it will obtain it’s configuration information from that file.

4. HTTP redirect – Outlook uses HTTP redirection if Outlook cannot reach the Autodiscover service through method 2 or 3. This is an unlikely scenario as all Exchange traffic should be going over HTTPS, not HTTP.

5. SRV record query in DNS Outlook uses an SRV record lookup in DNS to try to locate the Autodiscover service. It is not uncommon to use SRV records, is frequently used for providing autodiscover services for customers with multiple Primary SMTP domains. This feature has been deprecated with the launch of the Autodiscover Domain feature in Exchange 2013 and 2010 SP3 RU1. More information on the concept of Autodiscover for multiple domain names can be found in this excellent article: http://www.msexchange.org/articles-tutorials/exchange-server-2010/mobility-client-access/using-autodiscover-large-numbers-accepted-domains-part1.html

Why would I want to control this behaviour?

There are many situations in which you may want to control which of these lookups are actually performed. Here are a few examples:

1. You are performing a Cutover migration from Exchange>Office 365. In this case, when you make the switch and move your MX records to Office 365, you will need to do one of two things:

a. Remove Exchange completely from your environment before attempting to configure new Outlook profiles for your users. Doing this will remove the SCP record from Active Directory.

b. Configure your Outlook clients to skip the SCP lookup.

Both of these methods will ensure that your clients discover their autodiscover settings using method 3 (as long as you have your DNS configured properly!). If you don’t do this, your Outlook clients will always discover their Exchange server using method 1 (SCP lookup). Of course, you could manually configure each Outlook profile, but that is way more hassle than it’s worth!

2. You are moving back to an On Premise environment from Office 365 (god forbid!). If you are doing this you must disable SCP lookups before implementing Exchange, as otherwise your Outlook clients will find your Exchange Server before they find your Office 365 autodiscover settings. SCP lookups can then be re-enabled once you have offboarded.

3. You may simply want to optimise your autodiscover experience. For example, if you are using pure Office 365 (no Hybrid), you might aswell disable all types of lookup except for method 3, as that is the only method which will work. This can lead to speed improvements, particularly when launching Outlook.

How do I control Autodiscover?

The best way of doing this is to use the magic of Group Policy! Firstly, if you don’t already have it, download and install the .adm or .admx file for managing your preferred version of Office, be it Office 2007, 2010 or 2013. The Autodiscover settings for Office 2013 are built into the ADMX file for the whole application, whereas Office 2010/2007 use a special Autodiscover .adm file.

Office 2007: http://download.microsoft.com/download/C/5/2/C5252326-202E-4674-A5A2-BC9F5C8F53BE/outlk12-autodiscover.adm

Office 2010: http://download.microsoft.com/download/C/5/2/C5252326-202E-4674-A5A2-BC9F5C8F53BE/outlk14-autodiscover.adm

Office 2013: http://www.microsoft.com/en-gb/download/details.aspx?id=35554

To learn how to install these files, please see the ‘Loading the ADMX templates’ section of this article: https://technet.microsoft.com/en-us/library/cc179081(v=office.14).aspx

You may already have these files installed and have a Group Policy object for managing Office settings. If you do, then edit your existing policy. If not then create a new Group Policy Object and link it to the required OU. Edit your policy and navigate to the following setting:

    • Outlook 2013: User Configuration>Policies>Administrative Templates>Microsoft Outlook 2013>Account Settings>Exchange
    • Outlook 2010/2007: User Configuration>Administrative Templates>Classic Administrative Templates>Microsoft Outlook 2010>Account Settings>Exchange>AutoDiscover

As counter-intuitive as it sounds, Enable the ‘Disable Autodiscover’ parameter and select between the options shown in the screenshot below. In this example I’ve just disabled the SCP lookup.

Disable Autodisover GPOYou can confirm what lookups your Outlook client is performing by doing an Autodiscovery test. If you’ve never done this before, here’s how:

1. Go to the Outlook icon in your taskbar, hold Ctrl and right-click on it. You should see a couple of hidden options, select ‘Test E-mail AutoConfiguration’

Untitled

2. Untick ‘Use Guessmart’ and ‘Secure Guessmart Authentication’, enter your e-mail address and password and test.

3. Once the test is complete, go to the Log tab to see which lookups were performed and which was successful.

Hopefully this blog post will help you out, please leave comments with suggestions or feedback. Thanks for reading!

Assosiated TechNet article: http://support.microsoft.com/kb/2612922