Using this official documentation as a guide, I would expect the SamAccountName
property to sync from my on-premise AD to Office 365. I think that it used to do exactly that, but now it seems that it doesn't so much sync the attribute as it does create an entirely new, unlinked value and store it in Office 365. This has caused some minor issues for me (broken scripts, annoying permissions management, etc.) and may be part of a more major issue regarding ADFS authentication.
On-Premise
PS C:\Windows\system32> Get-ADUser jdoe -Properties SamAccountName | fl SamAccountName
SamAccountName : jdoe
Office 365 Sync'ed Objects
PS C:\Windows\system32> Get-Mailbox jdoe | fl SamAccountName
SamAccountName : $1A7H20-K1LCOJFFBHGS
I understand how to work around this issue in my scripts -- there exists the ImmutableId property which can be mapped back to the on-premise GUID. As far as the issue I'm having with ADFS, I'm less certain how to proceed and if this is causing my issues. At this point I really would just like some verification that I'm not crazy and that this used to be sync'ed at some point in the past and that Office 365 broke it relatively recently. I also think that MS documentation should perhaps be updated to exclude SamAccountName
from the list of synchronized properties on the page I linked.
I checked my archived logs and it appears that the
SamAccountName
attached to the Mailbox objects did indeed change somewhat recently. They did not however previously match the on-premise value. My oldSamAccountName
looked something like this,jdoe484563154684
, and the new one is$1A7H20-K1LCOJFFBHGS
. Furthermore, this was not causing my ADFS issues. Those were fixed with the most recent Update Rollup. I still think thatSamAccountName
should be removed from the list of synchronized properties in the official documentation.