Azure AD Sync Transform Map

[Chris Sanford1]

We have recently set up an Azure AD integration with automatic user provisioning. I followed the steps at https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/servicenow-tutorial which included giving Azure admin credentials and having them automatically create an IDP. I see there was also a transform map created, but my question is, does Azure even use this transform map?

I've been seeing user fields getting set that are not even mapped in the transform map at all, and it looks like the admin account I gave them has been making SOAP transactions directly into our user table. It also appears these SOAP transactions are ignoring business rules. We have a business rule to check for duplicate email addresses, but this Azure SAML sync is bypassing it. Is there a way to make sure Azure only sets the user fields in the transform map, and that business rules are run on every transaction?

[kevclark]

Hi Chris - did you ever get an answer to this?  I've noticed that the Transform map is ignored too.  I suspect that the mapping is done on the AzureAD side of things.

[Chris Sanford1]

Never got an answer from anyone else officially, but we did do some more testing and I became more familiar with the process. The transform map is indeed ignored and the Azure admin account will make direct web services calls into the user table. The mappings are configured on the Azure side using "Attribute Mappings". The schedule of the loads is pretty unpredictable, and the Azure AD admins have to ensure that when users are deprovisioned, they are set inactive prior to having their enterprise application role removed to ensure auto deprovisioning from ServiceNow. Even then, the service account would sometimes make bizarre transactions into ServiceNow that you have very little control over from my experience.

The part I mentioned about business rules was actually incorrect. Business rules are run on the Azure transactions, but sometimes Azure may do multiple transactions to update a single account so your business rule conditions would have to be set up to account for this.

Ultimately we decided to stick with LDAP authentication/provisioning, using regular AD and an LDAP server hosted on the Azure platform.

[kevclark]

Thanks for your reply and sharing your experience Chris! This has confirmed my understanding too.  The issue you alluded to where the accounts get deactivated in the wrong sequence has caused issues for us too - it was escalated to Microsoft who are apparently attempting to address this as a bug in future.

[Stephan S_]

Hi Kevclark,

have you any Feedback from MS yet?