This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
I am doing a swing migration from a v1 Azure ad connector to a v2. In the export to the local ad I am seeing a handful of updates for users for the msDS-KeyCredentialLink attribute. I believe this attribute did not sync in the past because AADConnect v1 was installed prior to a 2016 Dc being added to the domain. We now have a 2016 dc as well that was installed before configuring AAD connect v2 so none of the current local AD users have this attribute set. A small amount of computers do though. We are currently not using intune yet but Windows Hello for business is disabled there so I am curious why it would be populated in Azure? Perhaps because a user joined or registered a device with Azure and has Hello for business enabled? Is there any danger in syncing this attribute back to AD?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(96, 4%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ET%3C/text%3E%3C/svg%3E)
Hello there!
We have pretty much the same issue here, the difference is that we migrated Azure AD Connect from Windows 2012 to 2022 and had an error with a specific user during the on-premise connector export in Azure AD Connect. That domain user wasn't inheriting the security permissions and as a result the new domain AD Connect Sync User didn't have the right permissions upon that user. The attribute that needed to be changed was the "ms-ds-key-credential-link".
I hope this helps somebody.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(275.2, 86%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJD%3C/text%3E%3C/svg%3E)
Thank you TaN for this resolution! We had 2 users that weren't exporting back to the local AD. Turns out their accounts weren't inheriting permissions. I enabled inheritance and the export completed successfully.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(140.8, 66%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDM%3C/text%3E%3C/svg%3E)
Just logged in to thank you. The inheritance disabled was our problem.
Ran into the same issue. Add the AADSync account to the "Enterprise Key Admins" group and you wont see any permissions errors on the writeback.
No problems encountered doing this.
I guess I have not gotten that far yet. I am just seeing that those attributes will be added in the export. The first question I have is where are those coming from? I am assuming from Azure device registrations or azure device joins?
I checked my Azure Ad connect configuration and in Configure device Options device writeback is not enabled, and in the Hybrid Azure Ad join settings none of the OSes are selected. I also do not see any Hybrid joined devices in azure ad. I only see azure joined and azure registered so my current sync does not sync devices. The export going to azure ad does not show any new device objects either. I don't really want to sync devices or configure any of the windows hello for business stuff at this time. My main goal is to bring up a new azure ad connect server and decommission our old crippled one. I spot checked some users with the Get-WHfBDeviceKeys-from-AzureAD mentioned on Stephan Waelde's blog and the keys seem to be for Azure Ad registered devices. Other devices don't exist in Azure ad any longer. Also since my dcs are not all 2016 and the fsmo role is not on the 2016 server I can not see the "Enterprise Key Admins" group so I am pretty sure the writeback will fail. Maybe I should just disable the "Out to AD - User NGCKey" sync rule for now and address this if and when we are ready with all the pieces?
I dont know, I would personally leave it enabed and let it run. Just my opinion
I dont know, I would personally leave it enabled and let it run. Just my opinion
@Andy David - MVP Good Morning, do you have the working link for setting the correct permissions for the service account for WHFB as the link does not have information on setting it up. For some reason I am not able to find it. I have issue where the attribute is not populated back from Entra to On-Prem AD user objects. Thanks
I would leave it enabled if I had all the prerequisites for it but currently I don't. My fsmo role is not on a 2016 dc, I also do not have any of the groups required for the sync to successfully complete so having the rules enabled will just generate errors. I disabled these sync rules IN from AAD - User NGCKey (to DeviceKey in mv) Out to AD – User NGCKey (from DeviceKey in mv to msds-keycredentialLink in AD), ran full imports and full synchronizations on both connectors but on the export to AD I still see exports for the msds-keycredentialLink for the AD connector. Why does disabling the sync rules have no effect? Something similar is referenced here https://serverfault.com/questions/1029701/disabling-synchronization-rule-out-to-ad-user-ngckey-in-azuread-connect. They mention refreshing the metaverse which I would expect a full import and sync to do?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 17%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGM%3C/text%3E%3C/svg%3E)
@Mishaua Just wanted to check are you still investigating about this msDS-KeyCredentialLink with respect to your new ad connect installation or you ran full import/full sync to resolve the above mentioned issue.
Let me know if you have any further questions.
Deleting the connector spaces and restarting an initial sync stopped the data from flowing back.
Deleting the connector spaces is, last I checked, an unsupported action and can cause problems.
I deleted the connector spaces not the actual connector. I also did that on the direction of Azure support. The server that I did this on is still in staging mode so there wasn't any risk of data loss. If you are running in production and you delete the connector spaces without disabling your sync schedule then bad things will most likely happen.
What happened to you is the exact same scenario that happened to us.
We were on Azure AD Connect v1 with a schema of Server 2016 (87).
After the migration to Azure AD Connect 2, Event 6100 was throwed for all accounts.
I checked the value that was failing to be Added and it was msDS-KeyCredentialLink.
Adding permissions for updating this value is shown in this article.
https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync#configure-permissions-for-key-synchronization
The thing is that those AD groups only appear after you have at least one Domain Controller => Server 2016.
Read msDS-KeyCredentialLink and Write msDS-KeyCredentialLink.
And since the documentation is a bit unclear, for any of those groups to appear, you have to have at least one DC on server 2016.
Looks like that 2016 or newer dc also needs to be the PDC. I.e: from the doc - Transfer the PDC emulator FSMO role to a domain controller running Windows Server 2016 (or later) to be able to search the Key Admins and Enterprise Key Admins groups (domain controllers running previous versions of Windows Server cannot translate the security identifier to a name for these groups).
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(67.2, 95%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECV%3C/text%3E%3C/svg%3E)
Hello,
We had an issue where we created a second synchronization to a second Azure AD tenant. At first it appeared to work fine. We then started getting tickets from people unable to logon to Windows Hello for Business. When we checked the AD sync logs on both AD connect on the new tenant and our normal one we saw completed with warnings on the delta import. Drilling into it further the error stated exported-change-not-reimported and looking further the attribute with the problem was msDS-KeyCredentialLink. To fix the issue we stopped the sync on our sandbox tenant and did a Full Sync on the normal AD connect and it fixed the issue. Did we do something wrong?
Kind Regards
You are seeing a different issue. The docs here say https://learn.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies#multiple-azure-ad-tenants i.e
Only one Azure AD tenant sync can be configured to write back to Active Directory for the same object. This includes device and group writeback as well as Hybrid Exchange configurations – these features can
only be configured in one tenant. The only exception here is Password Writeback – see below.
The msDS-KeyCredentialLink gets written back from the azure tenant so you would need to disable that on one if your tenants.