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.
This article was originally published in the KuppingerCole Analysts' View Newsletter.