KuppingerCole Analysts' View on Active Directory



Extending your Active Directory to the Cloud

Martin Kuppinger

Most organizations have a Microsoft Active Directory in place. The Active Directory (or, in short, AD) builds the foundation of their on-premises infrastructure for managing users, performing their primary network authentication and authentication to AD-integrated applications such as Microsoft Exchange Server, and some network infrastructure services including client configuration management based on Group Policies. AD is a purpose-built directory service that is optimized for supporting these requirements. One of the specific capabilities are Group Policies – client management commonly is out-of-scope of directory services. Another example are the sophisticated replication features of AD. These are required to provide (amongst others) seamless authentication and load-balancing of authentication requests and user management.

This works well for the employees and the on-premise IT infrastructure. However, when it comes to external users, things becoming more challenging. While most organizations manage the “long term” externals – the ones who spend a lot of time on-premises, need access to internal IT systems and frequently even have a company e-mail address – in the Active Directory, organizations struggle with managing all the other externals such as employees of business partners with occasional access only to a selected application or customers.

The purpose-built AD is not targeted towards these use cases. On-boarding and off-boarding thousands of employees of an insurance broker or managing the local operators of an airline across the world are not the standard use cases for AD. And what about managing millions of customers that need access to some applications?

There are workarounds, but none of these workarounds is really convincing. These external users might be managed in a separate forest or in a separate domain within an existing forest. They might even be managed within an existing domain (particularly in ADs that follow a single-domain approach), but that makes security management pretty cumbersome. And we do not yet speak about some challenges such as schema changes for specific requirements or the replication issues caused by managing a multitude of users than just the employees in the Active Directory.

The common answer on these challenges is to set up another, separate directory service for external users or customers. Microsoft’s lightweight answer is AD LDS (Active Directory Lightweight Directory Services). Other vendors provide their LDAP (Lightweight Directory Access Protocol) directory servers to manage these users and authenticate them.

But there is another answer now: cloud-based User and Access Management as part of the emerging cloud IAM offerings. Several vendors deliver solutions that allow managing customers and external users in integration with the existing on-premise infrastructure. Microsoft’s own answer in that field is the Azure Active Directory, a cloud-based directory service that it is quite different from the traditional Active Directory. It supports flexible schemas, scales virtually unlimited (Microsoft Office 365 is based on it), and provides functionality that helps managing external users far better than the on-premise Active Directory can do – and potentially better than other on-premise directory services can do. With upcoming extensions, Microsoft will further add capabilities for managing external users.

There are challenges such as synchronizing and/or federating the existing users of AD and other directory services to Azure Active Directory (or other services in that field).

Nevertheless, there are new options now to extend the existing AD to the cloud and to serve new business demand of on-boarding, off-boarding, and managing business partners and customers – delivered by Microsoft and other players in the market. This creates a situation for organizations using AD in which they should start reviewing and rethinking their Active Directory strategy. There are various options for extending the on-premise AD to the cloud, and it is time for defining the future strategy around AD. That future, for most organizations, will be hybrid.



Managing Users in Office 365

Alexei Balaganski

Office 365 is a popular cloud-based office productivity service built around Microsoft Office platform. Initially released in 2011, it has gone through a major upgrade in 2013 and is currently offered with different plans for home, small business, midsize and enterprise customers. Internally, Office 365 platform uses Microsoft Azure Active Directory for identity management and, with the exception of home and small business plans, offers three identity models for different user management scenarios. Recommended approach is to always start with the simplest model and transition to the more complicated one (or back) any time as requirements change. Let’s have a quick look at these models.

Cloud Identity

This is the simplest identity model and also the only one available for home and small business users. It’s typically used when an organization has no existing on-premise directory. In this case, user's details are stored in the cloud directory only and can be managed using the standard Office 365 admin portal, which supports individual account management, as well as rudimentary batch processing using CSV files. Administrators can also reset user passwords or assign certain users (such as helpdesk staff) to perform this for other users. There is no way for a user to reset their own password.

Microsoft also provides a set of modules for Windows PowerShell to enable automation of common administration tasks. Another convenient option is using the Azure AD Graph API, which is a RESTful programming interface for developers to easily build applications integrating with Azure Active Directory.

Synchronized Identity

The majority of organizations that already have an on-premise directory will definitely choose this model, which relies on several tools to synchronize existing user accounts with the cloud directory. Since Microsoft has introduced password hash sync in 2013, this model can also provide a “single sign-on” user experience with the same password on-premises and in the cloud without the complexity of identity federation.

Microsoft provides several different tools for directory synchronization, starting with the old and proven DirSync tool suitable for organizations that have a single Active Directory. In the simplest case DirSync can be installed directly on the domain controller and does not require any additional infrastructure.

Next-generation Azure AD Sync tool is being designed to replace DirSync with many new functions including support for other directories such as LDAP or SQL. More complex scenarios are possible using Microsoft Forefront Identity Manager and different connectors (currently this is still the only solution to synchronize with non-AD directories).

It should be noted that identity synchronization with Office 365 has several limitations. For example, synchronizing a single on-premise directory with several cloud tenants leads to multiple problems and is actively discouraged by Microsoft. Therefore, an organization having several Office 365 subscriptions should consider merging them into one using third party tools before setting up synchronization.

Federated Identity

Since Synchronized Identity model covers the vast majority of use cases with significantly less administration effort, organizations should really consider deploying the federation infrastructure only for certain complex scenarios, for example:

  • An ADFS infrastructure is already in place or there are existing third party identity providers;
  • Special technical requirements, like smartcard authentication or support for password reset via Office 365 portal;
  • Special policy requirements, like login auditing requirement or regulations prohibiting password synchronization.

Important note: one should not forget that federation still requires user accounts to be synchronized with the on-premise directory, so one should never jump directly to federated model without setting up synchronization first. Azure Active Directory currently supports multiple protocols for identity federation with Active Directory Federation Services 2.0 or other third party Security Token Services. The most recent addition to this list has been SAML 2.0, which was announced in March 2014.

Microsoft has established “Works with Office 365 – Identity program”, which is a qualification for third party identity providers for federation with Office 365. A list of qualified providers is maintained here.

Unfortunately, current versions of Office desktop applications have a major incompatibility with many third party identity providers, since they only support the so called active authentication, which can only be accomplished using WS-Trust protocol. Until an update is released later in 2014, Microsoft officially only supports federation with AD FS 2.0 or with qualified third party providers from the list above.


Microsoft has gone a long way since the initial release of Office 365. Current generation of the Azure Active Directory enables different identity models that support nearly all possible usage scenarios. While there are still several major interoperability issues the company has to solve, unless you have a really unusual on-premise identity environment, you should be covered by one of the options above.



Microsoft’s Taking Aim at the Hybrid Cloud

Graham Williamson

One of the most strategic moves Microsoft ever made was the release of Active Directory (AD). It was released with Windows Server 2000 and, depending on the statistics you use, between 85 and 95% of Fortune 1000 companies now run Active Directory, because it is the authentication source used by the Windows operating environment.

But with the increasing migration to cloud services there’s a problem – the same companies that have so overwhelmingly adopted AD in their on-premise environments now need a solution for the cloud, where AD is anything but the right answer. Firstly it’s not a good idea to expose your on-premise LDAP service outside the organisation to cloud-based applications. Secondly, Windows is too verbose; with Exchange, SharePoint and Office tightly bound to AD, network latency precludes the use of an on-premise AD instance by these applications when they are operating in the cloud.

So, it became obvious to Microsoft that they would need a solution to support hybrid environments where customers could enjoy the efficiency of their on-premise Windows operation when accessing their cloud applications in the Azure environment. Microsoft’s answer is Azure Active Directory (AAD).

Microsoft first released Azure AD in 2012 and, as with anything significantly different, it initially received criticism. The core schema that we had become used to in AD was no longer so important and the LDAP interface that we had come to embrace for all our directory work was gone. In its place was an OData interface and a very different Graph API. But it didn’t take long for the industry to understand the need for a higher-level interface in a cross-boundary environment, and Azure AD (AAD) is now well adopted as the standard for Microsoft Azure. Refer to Martin Kuppinger’s article in this newsletter for more detail.

The next problem for Microsoft was how to populate AAD and keep it current. Initially the DirSync tool provided this function with a replication of the on-premise AD to the cloud-based AAD. This was a bit of a brute-force approach requiring the whole directory to be resident in the cloud. A further problem was how to achieve single sign-on (SSO) between on-premise and Azure applications. Microsoft’s answer was Active Directory Federation Services (ADFS) to maintain session details between the two environments. While it worked – it was not an elegant solution.

These issues were comprehensively fixed with Windows Server 2012 R2 and the release of Azure AD Premium Enterprise Suite. It is now no longer necessary to replicate the whole on-premise AD to the cloud but more importantly synchronising the password hash allows two-way password reset so users can maintain their passwords in either environment and it will be replicated to the other. Group management has been improved and a self-service feature is available. Federation is supported and integration with other directories and Identity Providers, beyond on-premise AD, is a real option. Multi-factor authentication services have also been extended. ADFS has been improved with support for Microsoft’s Device Registration Service to extend authentication services to registered mobile devices, a highly desirable feature when managing mobile device access to cloud-based applications.

So – what is the right choice when it comes to adopting cloud services?

If you are a Microsoft shop i.e. you use Windows extensively, you use Exchange and Office – and particularly if you are a big SharePoint user then embracing the Azure environment is a logical decision at least for that part of your IT infrastructure. Check the article by Alexei Balaganski in this newsletter to decide what level of adoption is appropriate. One word on hybrid – try not to stay there too long. The cloud has an impressive economic imperative, but not when everything remains hybrid. So if you opt for Office 365, do it consequently.

If you only dabble in the Microsoft ecosystem, maybe you have Windows clients but you maintain a mixed server environment and your applications are primarily web-based, look to the open cloud suppliers such as AWS as an alternative to Azure. If you’re going this route you’ll need to solve the Identity-as-a-Service (IDaaS) issue anyway. This is not done only by replicating your AD to the cloud. There is an increasing number of services for managing Identities in the cloud, including Okta, PingOne – or Microsoft AAD, that can do more than just being your AD in the cloud. If you’re a Salesforce user you might want to adopt their identity management solution as your IDaaS service. Have a look at the upcoming KuppingerCole Leadership Compass on Cloud User and Access Management which will be published later this month to understand the vendor landscape for managing identities and access in the cloud.

We’re on the cusp of a real polarisation in the adoption of cloud services. The main service providers offer an unprecedented ease-of-use in the movement to the cloud whether it be cloud-based storage, cloud-based virtual machines or a complete Office/SharePoint/Exchange cloud-based infrastructure. But the decision to adopt cloud services is a strategic one. It should not be made lightly and, even if your initial implementation of just a proof-of-concept, you need to do it under the umbrella of a “cloud roadmap” to ensure it archives the outcomes you need. For assistance along the journey check out the KuppingerCole CLoud Assessment Service (KC Class); it will help to keep you on the right road.

But whatever way you look at it, the cloud future has a light blue hue.

Related KuppingerCole Research

Related KuppingerCole Podcasts

Related KuppingerCole Blog Posts