API-driven provisioning field mapping changes resynchronize all users and groups
We have configured API-driven provisioning for on-premises Active Directory, along with Azure AD Connect, to synchronize on-premises AD users with Azure Entra ID. As part of the provisioning setup, we have used a separate Organizational Unit (OU) in on-premises AD (designated as the default OU for new users) while configuring API-driven provisioning. We are attempting to make some changes to the API field mapping, specifically the ‘UserPrincipalName’ regular expression (custom domain) and the ‘manager’ field, and saving the configuration. Upon attempting to save, a prompt appears (as highlighted below screenshot), indicating that this action will resynchronize all users and groups. Could you please clarify: Will this resynchronization update any existing users outside the default provisioning Organizational Unit (OU)? Specifically, what does the resynchronization operation update? For instance, will it modify the 'UserPrincipalName' and 'manager' attributes for all users including old users outside of provisioning Organizational Unit (OU)? Screen Shot - While Saving Mapping.
Cloud-First Attribute Ownership for Synced Users in Entra ID Is Not Supported
📝 Description As an enterprise architect working to modernize identity provisioning, I’ve encountered a major limitation in Microsoft Entra ID’s hybrid identity model. While Microsoft promotes a cloud-first strategy, the current architecture forces reliance on on-premises Active Directory for attribute ownership when users are synced via Entra Connect. Key issues: Directory extension attributes, even when created in the cloud, are read-only for synced users. Custom security attributes are not queryable and cannot be used in dynamic groups or claims. There is no supported mechanism to allow cloud apps (e.g., Workday provisioning) to own or update specific attributes for synced users. Breaking sync to convert users to cloud-only is disruptive and not scalable for large enterprises. This creates a conflict between cloud-first provisioning goals and technical limitations, making it difficult to fully transition away from on-prem AD. ✅ Requested Improvements Attribute-Level Ownership Delegation Allow cloud apps to own and update specific attributes for synced users, even if the user is still managed by AD. Writable Directory Extensions for Synced Users Enable Graph API write access to cloud-created directory extensions for hybrid users. Dynamic Query Support for Custom Security Attributes Make custom security attributes usable in dynamic groups, claims, and app filtering. Clear Guidance and Tooling for Cloud-First Identity Models Provide supported patterns and tools for transitioning identity provisioning and attribute management to the cloud. 🙏 Why This Matters Organizations are actively trying to reduce reliance on legacy infrastructure and embrace cloud-first identity. The current limitations in Entra ID make this transition unnecessarily complex and inconsistent with Microsoft’s cloud-first messaging. ---copiloted response for sure after many days of trying to work a solution that does not create more tech debt...
Cross-tenant synchronization and resource access
Hello My company is investigating options pertaining to the separation of a splitting a set of users into a separate Entra ID tenant. This is being driven from a political and governance perspective whereby a portion of the organisation is looking to split away from the conglomerate for their cloud identifies only (not the on-premises AD). They effectively want their users and Entra ID identities to be moved to a new Entra ID tenant however still want to maintain access to the source tenant resources and applications for a period of time (potentially ongoing). For the purpose of my questions, assume that: existing on-premises domain is orga.internal existing EntraID tenant is OrgA.onmicrosoft.com new EntraID tenant is OrgB.onmicrosoft.com Ultimately the goal is to migrate user identities, their M365 license and mailbox to OrgB.onmicrosoft.com whilst still enabling them to access the cloud resources attached to OrgA.onmicrosoft.com. Looking at the capabilities of the cross-tenant synchronisation service to sync users from OrgA.onmicrosoft.com to OrgB.onmicrosoft.com, I'm not sure if this will meet my requirements as it will effectively sync the users from OrgA.onmicrosoft.com to OrgB.onmicrosoft.com as B2B guests. Is that correct? If my understanding is correct what we really need to do is: Migrate EntraId identities and mailboxes to OrgB.onmicrosoft.com, removing the OrgA.onmicrosoft.com account in the process Use cross-tenant synchronisation to sync the new OrgB.onmicrosoft.com identities back to OrgA.onmicrosoft.com as B2B guests whereby access to resources is provided to the guest account. If this is correct then is it technically supported to have multiple instances of Entra ID Cloud Sync synchronsing a subset of the orga.internal users to Entra ID OrgB.onmicrosoft.com whilst another instance of the Cloud Sync continues to sync orga.internal users to the existing OrgA.onmicrosoft.com EntraID tenant? I can't seem to find any reference to this architecture in the MS doco. I can see this scenario references in the legacy Cloud Connect doco but not the newer Cloud Sync agent doco. Any advise is appreciated.
Generating proxyaddresses during user provisioning
Hi All, we have requirement to generate alias email addresses during user provisioning. we tried to use selectunique function in the proxyaddresses generation and mapping to ad proxyaddresses but we are not able to achieve it. can you please help thanks, shashidhar joliholiAzure AD SCIM Validator is in General Availability (GA) Status
You can now validate the compatibility of your SCIM provisioning endpoint and Azure AD code base using our Azure AD SCIM Validator. This tool can be used by ISVs who want to build SCIM compatible servers either for gallery app or generic app and developers building their line of business SCIM apps. https://learn.microsoft.com/azure/active-directory/app-provisioning/scim-validator-tutorialMigration to Cloud Sync (passwords)
We want to migrate from AAD Connect Sync to Cloud Sync. When provisioning new users we could use temporarily passwords in AAD Connect Sync, through this feature: Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true Is this feature still available in Cloud Sync? If not what is the workaround?
API-driven provisioning to on-premises Active Directory mapping of the manager not working anymore
Hello Guys, I have a problem with the provisioning service of the above enterprise application. The whole time it was working fine until yesterday when I changed an attribute mapping (not the manager mapping) and now the manager is not sync because he can't lookup the manager, with every user even though the all worked before. Error: UnableToResolveReferenceAttributeValue Someone have an Idea or the same problem?
SCIM and mapping to a 3rd party app
hello, got a SCIM question: we have a 3rd party application we are hooking up to SCIM (call it AppXYZ). The group we want to put people into in AppXYZ is called 'Group1'. On the MS Entra side, the MS Entra group is called "Testing Users". When I setup SCIM, how do I map the MS Entra group "Testing Users" to the group inside of AppXYZ called Group1. Note: I cannot change the name of the group in AppXYZ - it must be called Group1, no exceptions and the MS Entra user group must be called "Testing Users" cannot alter the name. thanks everyone.Entra Hybrid Join - Problems with Server 2016 and userCertifiate
Dear Community, I am having some troubles with the hybrid join of a group of servers (Windows Server 2016). The basic problem is that Windows is not creating the required self signed certificate and therefore the AD attribute “userCertificate” is empty. As we now, while it is empty, the objects are not getting synced to EntraID. (https://www.amobileattempt.com/2018/07/hybrid-join-azure-ad-and.html) And I don’t find out, why this certificate is not created. As mentioned, it affects only some Server 2016, which are our RDS Terminal Server. All other Windows Server and Clients are successful synced and have a userCertificate (including other Server 2016). All our servers are VM, based on VMWare. Some more words about these RDS Server: They are cloned from a VMWare template The deployment process is as follows: o On a Master VM we install all updates / software It is domain joined and has a userCertificate o Master VM gets converted into a VMWare template o New RDS TS are created from this template With a configuration to reset SID and automatic domain join The have no userCertificate Test lab for troubleshooting I created some new VMs to test and verify the behavior. Here is what I did: Installed a new Windows Server 2016 VM from DVD Installed all latest updates Converted it into a VMWare Template -> Srv2016_Template This should be my new template for Server 2016 Created new VM from this template: Srv2016RDSMaster Used a configuration to generate new SID and automatic domain join This should simulate my Master template for new Terminal Server --> It has a “userCertificate” in its AD Object Converted it into a VMWare Template Created new VM from this template: Srv2016RDS01 Used a configuration to generate new SID and automatic domain join --> It has no “userCertificate” in its AD Object Troubleshooting steps Networking No proxy, direct Internet No DENY on our firewall -> Internet available Verified that these URLs are accessible https://enterpriseregistration.windows.net https://login.microsoftonline.com https://device.login.microsoftonline.com https://autologon.microsoftazuread-sso.com Active Directory and Infrastructure Service Connection Point (SCP) is set in the forest and has the tenant name and ID (otherwise no computer would be synced) GPOs are not linked to the OU in which the computers are Local troubleshooting on the VM Scheduled Task for “Workplace Join” is enabled and runs dsregcmd /status EventLog – “Application and Service protocols” -> “Microsoft” -> “Windows” -> “user Device Registration” Two errors, each time the Workplace Join task starts: Sysprep Also tried on the VM a sysprep, rebooted, manually joined it to AD --> Still no userCertificate Tried the same again and deleted also the AD object --> Still no userCertificate Activated TLS 1.2 https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-server -> no affect Articles I read and verified https://learn.microsoft.com/en-us/entra/identity/devices/hybrid-join-plan https://office365concepts.com/configure-hybrid-azure-ad-join/ https://www.amobileattempt.com/2018/07/hybrid-join-azure-ad-and.html https://learn.microsoft.com/en-us/entra/identity/devices/troubleshoot-hybrid-join-windows-current My conclusion I guess it has something to do with Server 2019. Why I am saying this: I have tested the same setup with an old, existing Server 2019 template (created “Master VM” -> converted into template -> created VM from this template) --> all VMs have userCertificates in their AD object So I would be glad if someone has ideas about it. Thanks, Chris
SCIM provisioning - custom app authentication
Hi, in the documentation for https://learn.microsoft.com/en-us/entra/identity/app-provisioning/use-scim-to-provision-users-and-groups#handling-endpoint-authentication, two methods are given: 1) a "long-lived token" (i.e. a secret key that has to be pasted in-clear by the admin) 2) "Microsoft Entra bearer token" - similar to other services (e.g. callbacks for MS Teams bots), Microsoft sign the outgoing calls, and the app being provisioned can validate them against Microsoft's public keys To me, option (2) is by far the best - each message is signed individually, there is no manual handling of secrets etc. As said in the documentation - "Apps that use Microsoft Entra ID as an identity provider can validate this Microsoft Entra ID-issued token." - great! So why on earth does it then say "The token generated by the Microsoft Entra ID should only be used for testing. It shouldn't be used in production environments." ? Why not? The whole system of Entra bearer tokens is only for test? And production should go back to secret keys, with all the problems they have? It doesn't seem right.. What am I missing here?
