Microsoft Ignites a new Focus on Security (Part 4)

If you would like to read the other parts in this article series please go to:

Introduction

In Part 1 of this article series, I discussed how Microsoft held its very first Ignite conference the first week of May, in Chicago, with many of the sessions focused on security in the cloud. We talked about the announcement regarding more flexible patching cycles (and the possible end of Patch Tuesday as we know it) and the introduction of Windows 10 Device Guard. In Part 2, we started to look at more of the new security features, products and services, beginning with one that has been getting a lot of attention: Microsoft Advanced Threat Analytics. In Part 3, we looked more closely at the Ignite presentations regarding what Microsoft is doing about security in the cloud and specifically in Office 365.

Identity Management in Office 365

The focus of security efforts has shifted over the last few years from edge technologies such as firewalls to identity-based mechanisms. Identity-defined security has evolved to meet the needs in a world of “networks without borders,” which is the case when some or all of a company’s resources no longer reside on-premises but are “out there” in the cloud, and users are no longer sitting in offices at systems wired to a local network but are connecting from their homes, cars, hotel rooms and even in cross-country flight.

That means identity is now front and center in your security strategy – or if not, it ought to be. Securing your applications and data today is based on a two-pronged identity system, and identity and access management solutions are designed to ensure that only trusted users, using trusted devices, will be able to access specific resources.

Identity management has long been a challenge within the enterprise, and the cloud has made it even more complicated. However, it doesn’t have to be. Identity integration and management have been simplified in Office 365, and at Ignite this year, principal program manager David Brandt explained to attendees how Identity Management is Easy in Office 365 through his presentation of the same name.

An identity model to fit your organization’s needs

With Office 365, Microsoft has recognized the fact that there is no “one size fits all” identity model. Different sizes and types of businesses need to manage identity in different ways due to differing levels of complexity in their overall network and usage scenarios. For that reason, Office 365 offers a choice of three different identity models to fit the needs of small businesses to enterprises, including those that prefer to maintain hybrid environments.

The simplest and perhaps the most appropriate for smaller businesses is Office 365 cloud identity, in which identity management and controls are all handled in the Office 365 cloud. This involves no on-premises servers at all; you place everything in Microsoft’s hands and can drastically reduce the level of in-house IT overhead.

Many companies, due to restrictions of governing regulations and policies or concerns about security of high sensitivity resources, choose to maintain their on-premises servers in a hybrid setup while at the same time utilizing the benefits of Office 365 in the cloud. For those organizations, the best bet is going to be the synchronized identity model.

Finally, large enterprises that have implemented federated services can fully leverage that with Office 365’s federated identity model. This is, of course, the most difficult to implement so if you aren’t sure which model will work best, Microsoft recommends that you begin with the simpler synchronized model and you can move to the federated model later.

Let’s go into a little more detail about each of the identity models:

Cloud Identity Model

In this scenario, you don’t have to have any on-premises servers involved. All user accounts and account information are maintained in the Azure cloud on which Office 365 runs. Azure Active Directory authenticates the user, who logs in directly to the cloud service. Very little administrative overhead is required. Azure AD stores all the user information for your Exchange, SharePoint and Lync services in Office 365, just as the Active Directory for an on-premises domain stores user account information for that domain.

Note that you can maintain a separate on-premises directory and use the cloud model, but accounts won’t be synchronized between the two. This can be a good way to test Office 365 before deciding to move to it. The cloud model isn’t as scalable as the others; Microsoft recommends it for organizations with 200 or fewer users

Synchronized Identity Model

In this configuration, you still have on-premises identity management and the cloud-based directory syncs with your own Active Directory services so that passwords are synchronized across both the on-premises servers and the cloud. You create the user accounts on your on-premises domain controllers. Then the user accounts and their associated passwords are synchronized to the Azure AD in the cloud. That way, users are able to use the same user names and passwords to sign onto the cloud service as they use for on-premises log on to the internal network. The Azure AD verifies the password with the synchronized account information when the user signs into the cloud.

The Microsoft Azure Active Directory Sync Tool (DirSync) is used to synchronize the accounts. It’s installed on a server in your on-premises domain or on a server in Azure. This tool can sync all of the AD domains in your forest with Office 365. It’s relatively easy to use and this is likely to be the preferred model for the majority of businesses.

Note that there have been quite a few changes to these identity models over the last year or two, and those changes have made it so that you might be able to get by with a less complex identity model than you would have in the past. One of the most important changes was the addition of password hash synchronization to the DirSync utility. The practical result of that is that the same password is available on-premises and in the cloud now with the synchronized Identity model, whereas in the past users had to have separate passwords for their on-premises and cloud logons and you had to go to the federated identity model if you wanted to use the same passwords.

This is not the same as single sign-on (SSO). A user logged into the on-premises network/machine still has to log into Office 365 separately. However, synchronization simplifies that because the user name and password are always the same for both.

Another improvement that was added in 2014 is the ability of password hash sync users to use multi-factor authentication (MFA) with Office 365. Previously the federated model was required in order to use MFA. Office 365 MFA is available with the midsize business, enterprise, academic and non-profit plans, as well as standalone Office 365 plans (such as Exchange Online). No additional purchase or subscription is required to implement MFA. The second factor for authentication is a phone call, text message or app notification on the user’s smart phone.

 Federated Identity Model

This is the most complex of the models but it enables you to use a federated identity provider. The difference between the synchronized identity model and the federated identity model is that with the latter, instead of the password being verified by the Azure AD, it is verified by the on-premises identity provider so it doesn’t have to be synchronized to the Azure AD. Either AD FS or a third-party identity provider can be used.

If you already have AD FS deployed in your organization, it makes sense to also use it for Office 365 – although you don’t have to. You can still use synchronized identity for Office 365 and AD FS for your other purposes. If you don’t already have AD FS, and don’t have a reason to need federated identity, the synchronized model will probably work best. Note that if you use a third-party federated identity provider such as Centrify, IBM Tivoli Federated Identity Manager

If you switch from a synchronized to a federated identity model, you can disable the password hash synchronization (or you can leave it on for backup).

Speaking of switching from one identity model to another, you can not only “upgrade” to a more complex model, you can also “downgrade” if you need to, from federated to synchronized or from synchronized to cloud identity.

Summary

In this, Part 4, we have delved a little more deeply into the area of Office 365 security and honed in on identity management features. In Part 5, we’ll dig deeper still, showing you how to implement each of the identity models and providing some tips for best practices that will ensure your users have the greatest protections possible for their Office 365 connections with whichever identity model you ultimately choose.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top