Future of On-Prem Active Directory/ Active Directory Directory Services

SallyWeston 

Oh! That's embarrassing! Clearly a copy-and-paste fail there.

I've done a quick bit of searching and can't find any articles that ring any bells, however, I vaguely recall that it spoke to the ongoing need for Active Directory for large enterprise customers who are expected to remain hybrid for the foreseeable future.

I'll keep looking for that "authoritative" post I claim to have found, but in the meanwhile, here's some (highly-opinionated, but experiential all the same) additional concerns I've got where the marketing rhetoric doesn't match the on-the-ground deliverables.

The first is aimed squarely at Graph, since this is how Azure AD and many other Azure-centric Microsoft services are being exposed.

My biggest issues with Graph are that:

1. It's focused almost exclusively at front-end automation, leaving it next-to-useless in dealing with hybrid-specific back-office automation;
2. Azure AD is effectively the only back-office component integrated and even then it's only done to an average degree. The flexibility you have in controlling an on-premise Active Directory schema - such as control over indexing, leveraging multi-valued attributes to represent business structures accurately, and create new classes - isn't even remotely well matched in Azure AD. This presents multiple challenges, particularly in the space of identity management where you find yourself scratching around trying to create sub-optimal solutions to work around Graph's limitations;
3. Rather than enumerating the raft of issues with other products, I'll just focus on Teams, where if you measure what can be achieved through Graph against the APIs and commandlets that exist for Skype for Business and SharePoint Server, there's just too many gaps with respect to getting Teams into alignment with corporate policy requirements.

Point 2 reflects limitations of Azure AD itself when compared to on-prem Active Directory, however, Graph has more issues. The multi-valued attributes is a good example where, technically, Azure AD does indeed handle them properly but it let down by Graph, which doesn't surface them in the JSON response, leaving things like often-asked for features like using multi-valued attributes in dynamic licencing groups still out of reach.

This - for me - raises questions around the overarching Azure strategy which is further evident in the availability of no less than three Azure AD PowerShell modules. I feel like what we're getting as enterprise customers is a "make it up as you go" Agile-based approach to product development that's delivering a lot of new - and potentially nice - features, but poorly thought through and executed with a great many holes in the implementation.

Bringing the discussion back to Active Directory for a moment, I've listened to some people saying there's no further development planned and that's evidence of it's limited future. This to me only serves to demonstrate their lack of understanding of a directory service's obligation, which is firstly to act in accordance with the relevant standards, and from a practical perspective, deliver on its purpose which is to provide authorisation services. Additional roles and features were always a vendor add-on designed to benefit the customer, but you have to ask yourself, what more do I need from a directory service?

In that context, I don't really feel that further development of the service has really been all that important for at least the last decade. I think this is somewhat reflected in the schema changes from Server 2012 onwards where by and large, the only changes have largely been to facilitate cloud integration. To me, this is an acknowledgement that not much more could be added to the directory service itself.

Shifting contexts for a minute, on-premise Active Directory (or any other directory service, really) has tremendous value - when paired with a formal identity management strategy - in the context of handling on-boarding and offloading (think merger and divestment-like activities) where it's quite possible the external entity is not positioned well for integrating natively with Azure AD.

Lastly, but importantly, from a data governance perspective - particularly sovereignty as a subtopic; you're implicitly operating at a higher level of risk in storing your entire identity data set in Azure AD (or any cloud-based alternative) rather than just the operational metadata that if compromised might be embarrassing, but not in breach of legal frameworks such as your country's legislation (which we're seeing an increasing amount of here in Australia in the past five years).

This all reads like a lot of naysaying and that isn't deliberate for my part. I think Azure (and the other cloud platforms) is a wonderful tool that could use a good deal of love in playing catch-up to important feature parity with on-premise Active Directory as well as other on-premise products.

Where I diverge from the marketing fluff is that it is just that: a valuable tool in your arsenal that when adopted strategically can improve service delivery (including the over-touted, poorly understood "digital transformation"), not a panacea where wholesale adoption makes sense when considering your legal and commercial requirements. That I've seen a couple of clients back out from the cloud seems to lend some credibility to that observation (though I only have superficial awareness of the "whys" in those cases - I think OpEX cost was actually a prominent component).

I'd love to do more with Azure - particularly via Graph which enjoys good support from all the key identity management system vendors, but it's simply not mature enough to be all-encompassing when compared to the benefits from a hybrid approach.

Cheers,

Lain