3

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.

pk.
  • 6,451
  • 2
  • 42
  • 63
  • On-Premises you're querying the user object, in the cloud you are querying the mailbox object. I note that Get-MSOLuser doesn't return an object with a SAMaccountname attribute. – BlueCompute Jun 02 '14 at 10:46
  • What you're saying is all technically correct, but I maintain that it used to return an identical `SamAccountName` value in the past. I, too, noticed that `Get-MSOLUser` doesn't return any `SamAccountName` value and found that the only way to get at it was to query the associated mailbox. I'm going to dig through some archived PowerShell logs and see if I can't prove my hypothesis. – pk. Jun 02 '14 at 15:12
  • 1
    Even if you could, which you can't, you likely don't want these to sync up. Azure Sync Engine, which is in preview and is the next-gen DirSync, can sync multiple forests to the same tenant, which creates the possibility of SamAccountName collisions. If I had to guess, support for multi-forest sync is likely part of the reason for this change. – MDMarra Jun 02 '14 at 15:46

1 Answers1

2

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 old SamAccountName 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 that SamAccountName should be removed from the list of synchronized properties in the official documentation.

pk.
  • 6,451
  • 2
  • 42
  • 63
  • Ah, thanks for clearing that up. By the by, I just checked and my mailbox SAM is blue.123456789101112 so presumably we're about to undergo whatever change this is. I still don't understand why the mailbox gets the SAM rather than the user though. – BlueCompute Jun 02 '14 at 15:48