Cloud-First Attribute Ownership for Synced Users in Entra ID Is Not Supported

Hi DeeDeeGoss​,

Hybrid - which implies ongoing coexistence - is inherently complex, with business analysis and enterprise architecture planning being of far more significance than what is required for a migration project (which is a once-and-done cost of change exercise, even if it's lengthy in execution).

1. Attribute ownership delegation.

This flies directly in the face of good data governance - specifically the concepts of source of truth and custodianship, where you want both to converge of the same body of people.

Your specific focus seems to be on Workday - and I'm guessing therefore also Workday's adoption of Microsoft's Entra ID user provisioning API.

With Workday, your integrator should have informed you there's multiple paths you can take:

1. Workday Entra ID user provisioning;
2. Workday Active Directory provisioning;
3. Custom SOAP (or REST, but this is currently inferior to their SOAP APIs for complex scenarios).

For a migration project, option 1 might be the better option for many customers (particularly if they're already cloud-native), but for hybrid customers where getting off Active Directory may be years away (typically due to critical applications), it certainly isn't.

Option 2 would be ideal for hybrid customers with simple entity-relationship (ER) designs, with option 3 being the best for those with complex ER designs (think of many one-to-many and many-to-many relationships between identities, their positions, locations, sup-org placements, etc.).

For a Workday customer operating as hybrid and wishing to retain robust governance, the correct approach would leverage either option 2 or 3, with Workday mastering the data in Active Directory and leaving AAD Connect to persistently manage the downstream data in Azure AD. This is the only model that ensures data is consistent from Workday, through Active Directory, out to Azure AD and optionally downstream into Azure-native platforms, systems and applications.

Conversely, if option 1 were somehow leveraged whilst still being in hybrid mode, data trust would be eroded due to the growing mismatch of data both at the attribute level as well as new objects (ostensibly this would be user objects) that do not exist in Active Directory since they would not be synchronised from Azure AD back into Active Directory.

Governance would similarly be eroded as a knock-on consequence since if data had to be ported back into Active Directory, it would have to be effected (be that manually or via bespoke automation) by a different body of people (i.e. your IT Helpdesk or IT automation specialists).

We already see this in practice on a very limited scale today with Microsoft's own introduction of shadow attributes. Fortunately, it's only for some key attributes (perhaps aside from "mobile", which is simply a frustration), which with proper planning, can be lived with. But trying to extend this model to potentially all attributes isn't workable. You'd end up with a multi-mastered scenario that would be a governance and operational nightmare, as well as a frustration for end users.

2. Writeable directory extensions for synced users.

Can you qualify what you mean?

If you're talking about Azure AD directory extensions, then so long as they're registered against an application that isn't the "Tenant Schema Extension App" application, you should already be able to populate those using Graph.

3. Dynamic query support for custom security attributes.

We'd all love to see this. In fact, I've always been of the opinion that all indexed attributes should be consumable in dynamic rules (and derivatives such as administrative units) but that's not what we were given, and very little has improved over the years on this front.

4. Clear guidance and tooling for cloud-first identity models.

I feel like what you're asking for is authoritative modelling - maybe even proscriptive solutions architecture - from Microsoft for all customer scenarios, which in my mind isn't practical or achievable.

Out of necessity, you're going to have to take this burden on board yourself, since while Microsoft can and does provide high-level guidelines, there's always going to be an unavoidable need to assess third party platforms/systems/applications which requires looking at the documentation from those third parties.

You'd also need to plan from the perspectives of business and technical strategy, and that's likely to look different between customers.

And of course - given the nature of this question, you need to be crystal clear on whether the customer is remaining hybrid or looking to migrate, where the architecture and orchestration of events are very different between those two.

I've made a good number of assumptions given your original post doesn't provide much detail on your specific position, and I do sympathise with where you are coming from. But I disagree with requesting a multi-master approach to data in any context - Azure AD being the specific scenario for this question, as it will undermine governance and data trust for the sake of the perception of flexibility (since flexibility is readily achievable using better-aligned architectures), which is a bridge too far in my humble opinion.

Cheers,

Lain