Microsoft Ignites a new Focus on Security (Part 5)

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


In Part 1 of this article series, I discussed the announcement at Ignite 2015 regarding more flexible patching cycles 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 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. In Part 4, we began talking about identity management in the cloud and particularly how identity management works in Office 365.

Implementing the cloud Identity model

Implementing a cloud identity model is easy (but be sure to read part 4 for a discussion of the limitations of this model). The accounts are created in the Office 365 online portal. The administrator sets the properties for the accounts and manages them through the portal. Everything happens in the cloud.

To add user accounts, go to the Office 365 admin center when you log onto Office 365 with your administrative account. Only users who are admins will see the admin center tile in the Office 365 portal interface when they log on, as shown in Figure 1.

Figure 1

Once you’re in the admin center, expand the Admin selection in the navigation list in the left-hand pane. The admin centers will differ a little, depending on whether you have an Office 365 business plan or an enterprise plan. Find the “Add new users” link under users and groups, as shown in Figure 2 in the business plan portal.

Figure 2

Here you can create the user accounts, assign Office 365 licenses, set their permissions and reset their passwords. You can also assign full or limited admin roles to users through this selection.

Once their accounts have been set up, users log onto the Azure Active Directory on the domain controllers that are running on the Azure network hosting Office 365 in the cloud. They log in with their user names and passwords that were set for this account through the portal, which might or might not be the same as the user name and password they use for any on-premises resources, but there is no connection between the two accounts. If the two accounts (Office 365 and on-premises) have different passwords, users will have to remember an extra set of credentials. Some users may be confused as to what account is associated with their Office 365 account.

Implementing the synchronized identity model

Synchronized identities are cloud identities, in that the verification of the user credentials takes place in the cloud as described above. The difference is that the accounts in the Azure Active Directory on the cloud-based domain controllers are replicated from the Active Directory on the DCs in your on-premises network.

Thus instead of creating the accounts through the Office 365 Admin Center in the web portal, you create them in the usual way through ADUC (Active Directory Users and Computers) on your on-premises domain controllers. Management, assignment of roles and permissions and deletion of user accounts also takes place on the on-premises DCs.

The DirSync tools that we introduced in Part 4 of this series are used to then sync the on-premises accounts to the Azure AD in the cloud. Password policy follows the policy that is set on-premises and users can always use the same username and password for both on-premises logon and logon to Office 365.

Here are the basic steps for deploying DirSync:

  • You might need to use the IdFix tool to review your on-premises AD and perform necessary remedial tasks such as fixing invalid or duplicate data in directory attributes and can be used to migrate from a local UPN that isn’t routable to a domain name that’s routable over the Internet.
  • Prior to deploying, decide whether a new server will be needed on which to run DirSync. Small businesses can install DirSync on an existing domain controller but for larger numbers of users, it’s recommended to have a separate server. Note that you may also need a separate SQL server installation if the directory has a large number of objects (more than 50,000). Another option is to deploy DirSync (and SQL databases if necessary) on a virtual machine in Azure.
  • The Office 365 account will need to be set up to allow synchronization of Active Directory. This is done through the Office 365 portal’s Admin Center. When you select Users, then select Set up next to “Active Directory Synchronization,” then select Activate.
  • To deploy DirSync on Azure, after installing the tool on the Azure virtual machine, open the DirSync configuration wizard. You will need to provide the Azure AD administrator account and the on-premises Enterprise Admin account, and enable password synchronization, then run the tool to sync the directories.

You will, of course, need to assign licenses to your users. To do this, select Users in the Admin Center, check the box(es) beside the user(s) you want to activate, and select Activate synced users. You’ll then need to enter the users’ work location in the Set user location field. In the Assign licenses field, select the licenses you want to assign to the users and select Next. Be sure you have the proper number of licenses available for assignment. The next page of the wizard is Send results in email. Here you need to enter the email addresses of the users. Separate each address with semicolons. Finally, on the Results page, you’ll see a list of the new user(s) and temporary password(s) for each. Click Finish and the user names and temporary passwords will be sent via email.

Implementing a federated identity model

With a federated identity model can be implemented via Active Directory Federation Services (AD FS), your users get the benefit of true single sign-on, as opposed to just identical accounts on the on-premises and cloud domain controllers that still require you to log onto each. It takes a bit more time and effort to configure and manage AD FS, so you will have to decide whether the extra overhead is worth the advantages. If you already have AD FS implemented for other purposes, it makes the decision easier.

If Office 365 is the first federation-aware application you’ve dealt with, be aware that setting up an AD FS infrastructure from scratch can present a bit of a challenge. Designing and architecting the infrastructure properly takes some forethought and a deep understanding of technical issues such as DNS, trusts, and SAML aware applications. SSL certificates are required for single sign-on, so you also need to be able to plan for deployment of these.

Under the federated identity model, users are authenticated by the on-premises AD FS servers on-premises (or alternately, by one of the third-party identity providers such as those we discussed in Part 4). For the purposes of this discussion, we’ll assume that you will be using AD FS as the identity provider.

Federated identity requires that you construct a federated trust between your Active Directory on your local domain controllers and the Azure Active Directory in the cloud. In direct opposition to the synchronized identity model, the password policy is managed by the on-premises AD so there is no need for password policies on the cloud AD.

You can deploy AD FS in a single server configuration. However, best practice when implementing AD FS is to configure the on-premises infrastructure with two AD FS servers on the internal network (for high availability), and two AD FS proxy servers in the DMZ (perimeter network). These are all Windows 2008 R2 or higher servers. The ones in the internal network are members of the local AD domain, whereas the ones in the DMZ are standalone servers.

High availability is especially important in the federated identity scenario because since this is where the authentication takes place, not in the cloud, if the AD FS infrastructure becomes unavailable, users won’t be able to log onto their Office 365 accounts.

As with the synchronized identity model, you use DirSync to synchronize the two directories when you set up the federated identity model. You’ll be walked through the steps of preparing for single sign-on, planning for and deploying AD FS and installing the Azure AD module for Windows PowerShell.

Users will still need to sign on to Office 365 when they want to use Exchange Online or the other Office 365 services, using the same credentials they use for the local domain. Then a token is issued that is sent to the cloud server. These are typically SAML (Security Assertion Markup Language) tokens and this type of authentication is known as claims based authentication.


In this, Part 5 of our multi-part article on Ignite 2015’s focus on security, we wrapped up the discussion of identity management in Office 365 and how to deploy each of the three identity models: cloud identity, synchronized identity and federated identity. In Part 6, we’ll talk about how to deploy multi-factor authentication in Office 365.

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

Leave a Comment

Your email address will not be published.

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

Scroll to Top