[this post is my personal view on Azure AD and AD – and does not contain technical instructions – happy to go into discussion on this topic – you know how to find me… ]

Last few weeks, out of nostalgia I’ve been installing Windows Server 2000 on a Compaq Proliant with dual Pentium Pro 200Mhz CPU’s and 392MB of memory. Windows Server 2000 was the first operating system to include Active Directory, and apart from cosmetic changes and (some) new functionality, the core has always remained the same. Even the UI still looks the same. The product has been kept up to date in the last 2 decades as Windows Server 2000 was introduced in December 1999. For a 20-year-old application; not bad and it even produced a kid along the way: Azure Active Directory. Most companies embracing Office365 and/or Azure have a tenant in there as well as they embrace cloud in many forms. Azure Active Directory gives you the central identity management platform for not only your Microsoft (cloud) services, but also others as I’ve mentioned a few times on my blog already. You use GSuite, Oracle, AWS even – the power that AAD brings with conditional access, hybrid / AAD join, MFA, self-service combined with Identity Protection is bizar. And in most cases for enterprises Azure Active Directory is in most cases linked to Active Directory using Azure AD Connect for your users to have a single-sign-on experience, but it is time for a big change in my view.

Active Directory is a directory service that houses your users, computers and other objects and has become the policy engine for your servers, workstations and users to disable/enable stuff essentially to make life easier or very hard for the end user depending on the policy setting. I remember disabling the command prompt to avoid students sending net-send messages. But times have changed, device preferences have changed, personal and work-life is interwoven now which is why Azure AD should be leading! Forget GPO’s and go for Intune policies, forget VPN’s and go for Secure Hybrid Access architectures and forget resetting passwords as users can do that themselves.

When you are building a brand new organization this is a bit easier, but as soon as legacy applications come into play things get harder and you need an LDAP store, you need the Kerberos Protocol for access to your backend applications, but all these do not require the password in AD and do not require your AD to be leading over Azure AD. Which is why I’m proposing to reverse Azure AD Connect: Azure AD users will replicate (without password) to an on-premises AD. Now before you start screaming that’s what Azure AD Domain Services is for, you are right. You even get the password in Azure AD DS, but what you don’t get is multi-region redundancy, close to your application (in the datacenter) for low latency, etc. So, this setup allows you to keep your sites-and-services, your multi-forest setup and much more, while focusing on the future!

The road to… freedom!

Before you start demoting your existing domain controllers, we need to take a look at the function they have and how those can be replaced. Only when there is a good overview of what is actually used, and a good replacement is found can we start planning the removal of users from your AD.

Workstations – the biggest of them all I’d say – your users logging on with username and password (or smartcard) to their laptops and desktops. Group Policies keep everything nice and tight and ensure users receive the right settings to not annoy them with proxy settings, fixed background (do companies still do this?) and mandatory security settings. While it did make sense to work this way when people were all using Windows corporate devices, this setup itself was already rubbish from the day the first OSX based Mac entered the building. Let alone blackberries, iPhones, Android Tablets, and other devices. Today’s end-user computing world looks like a zoo where cages were left open. And it’s up to the IT department to be the guardians of security, SSO capabilities and data loss prevention. But instead of locking everyone up in cages and making sure they can’t move at all – other options are available today in terms of Intune, Azure Information Protection and Office 365 Cloud App Security.

Servers – The second one would be backend servers and the ability for your workstations and servers to work together. Servers themselves however don’t do anything but host applications. And it’s the applications that require integration with Identity services. Many applications have already been re-invented or adjusted to new standard, such as SAML and oAuth. Even if you use legacy authentication protocols (Kerberos, HTTP Header or Cookies) you can easily link these applications to Azure Active Directory to provide authentication and authorization information. The advantage of de-linking application servers from a central store is also that micro-segmentation is now possible!

Identity – Maybe I’ve should have started with this one first. After all, Active Directory is an Identity store. But the reason that I didn’t is because Azure Active Directory should become the authoritative store for identities, rendering this function a bit useless. We probably still need this functionality but only to provide us access to legacy protocols such as LDAP and Kerberos.

Certificate Services – Active Directory consists of many smaller services. Certificate Services being one of them. While it is still possible to utilize this function separately, obviously handing out certificates to users is not possible anymore if those users are not in the directory service anymore. But some devices can act on behalf of a user to still receive smartcard certificates.

Zero Trust Model

When you are letting your users roam free and use any device they want, you still want to ensure control. This is called the zero-trust model. Social networks do not check their user’s device for compliance, and yet, users send all their sensitive information to them. The information on those networks is worth a multitude of gold and yet, while breaches sometimes happen, they don’t seem to happen every day. This is because of the zero-trust model. When you adopt a native zero-trust model your users’ devices do not matter. Your applications and your data matters. For your users, the accessibility to these applications and data is of essence. And in pure-cloud architectures this is “more” easy to achieve as we use SalesForce, Office 365, HRWeb and Dynamics. But for legacy applications this is a bit harder to implement. Old rules and architectures stand in the way of adopting the zero-trust model and we often go back to Internal versus External users and a DMZ as semi-trusted zone. It’s time to get rid of all of that nonsense. No-one is to be trusted, with different devices going in and out of the corporate network it is near impossible to check everyone of them and make sure they are patched, not hacked into and running proper AV software that can actually detect 0-day malware attacks. And I’m sure many administrators fully trust their security software that they pay big money for, but 0-day is called 0-day for a reason. Adopting a zero-trust model where you don’t distinguish between internal and external is the only way to ensure a common operating model and equal playing field for your security devices.

The distinction between “internal” and “external” should become a “dedicated user device” (allowing for WHfB login’s) and “public devices” (requiring MFA).

Secure Hybrid Access

Which brings me to the topic for the next few months on this blog. Secure Hybrid Access. While officially this is still using the existing architecture of on-premises Active Directory to Azure Active Directory and unlocking legacy applications on-premises I think we should kick it up a notch. Remove as many legacy applications depending on Active Directory protocols (LDAP lookups for firewalls, Radius, NTLM and Kerberos) and move them to Azure Active Directory supported protocols. I’ve already published a number of examples for F5 and using MIM and Azure AD App Proxy. But in case we can’t, lets use Active Directory as a protocol translation engine only, and focusing on Azure Active Directory as the authentication provider.

In short – the advantages that Azure AD brings (Identity Protection, Windows Hello for Business, FIDO/2, Conditional Access , Office 365 integration) must be leveraged not only for “cloud” applications.. but all your applications.. everywhere, make it easier for your users and your administrators and get everything more secure in 1 go…