Stop having MobilePhone attribute overwritten by Office 365 portal
Office 365 recently changed their logon process to have admins verify/update their alternate contact information. Message like the following is presented:
don't lose access to your account!
To make sure you can reset your password, we need to collect some info so we can verify who you are. We won't use this to spam you - just to keep your account more secure. You'll need to set up at least 2 of the options below.
Authentication Phone is set to xxxxx (verify)
Authentication Email is set to xxxxx (verify)
While that seems like a great idea on the surface, the problem is that when they verify the phone, it modifies the MobilePhone attribute.
The e-mail address is updated in AlternateEmailAddresses as expected, but the phone number modifies MobilePhone, not AlternateMobilePhones as one would expect for this type of thing.
This causes problems because now the MobilePhone information is no longer synchronized by Azure AD Connect/DirSync or whatever it will be called in 5 minutes.
So, we have information on O365 that doesn't match our AD.
Once set in 365, it won't accept the value from AD anymore. Even forcing a full sync doesn't fix the issue (despite what O365 support claims).
The formatting and inconsistent information causes problems for applications that pull that data and aren't getting properly formatted numbers for automated signatures and possibly in accurate information since AD will be accurate while this feature we couldn't care less about for service administrators gets in the way of accuracy.
Have case SRX616030994605831ID regarding this if additional details are needed.
option 1: Stop mucking with properties that are synched from AD. Use the AlternateMobilePhones option if you want to store a value. Our AD is accurate and vetted and formatted properly, I don't need various admins putting in their own version of numbers, plus O365 changes the formatting as well.
option 2: give us an option to disable the prompt. We have password recovery in place where it is needed. Not every admin role needs this feature. And since these particular accounts & passwords are synchronized and we don't have SSPR enabled, it doesn't do them any good anyhow. So you're asking for information that doesn't help at all, so stop asking for it. We're not going to lose access to the account like you claim.
Joar Borgli commented
PS: The only fix I have gotten to get around the problem for normal endusers until Microsoft actually fixes this issue is this:
1. Disable the option for end users to edit contact information directly in Office 365.
This will stop users from changing mobile number to alloq Azure AD to be the SOA over this attribute.
2. To fix a user were Azure AD already is the SOA:
- Move the user in AD onprem to and OU that is not synced to O365, PS this will delete the user from Office 365. This is safe as if you reassigning the licence within 30 days the mailbox and all data is still there.
- Run a manual sync and wait for the user to dissapear from O365 portal.
- Move the user back to the original OU + run a manual sync.
Wait for the user to appear in the portal and add the license back to the user.
Now the Mobile attribute is back to its original state.
No a proper solution, but the onlyone I have found.
Chris Phillips commented
@twan-van-beers I am in agreement - I was driven round the bend when my personal mobile number started to appear on our email signatures, then our accounts manager had the same (which led to some wholly inappropriate direct customer calls), but what made me maddest - even more than the mobile phone number leakage, was the regular service / account status emails that go to all the O365 admins - not BCC, but in the plain - To: ALL the admins' emails, not just their primary - thus leaking ALL admins' private account-recovery emails, to ALL the other admins. When I brought up this blatant leak of PII (Personally Identifiable Information), and I asked for my concerns to be escalated as high as possible, I was poo pooed #SurelyAGDPRIssue
Jonathan Fox commented
I am also experiencing this issue and it's very annoying.
Twan van Beers commented
I'd suspect that this will fall foul of GDPR too, since the information regarding 2FA email/mobile is being collected for 2FA only, it is not intended to be published in the company directory...
I just became the victim of this exact issue, so it has not been addressed, and as a result many of the mobile numbers are screwed up. ADSYNC only synchronizes the first time a user is added. If they get a mobile number after that it no longer updates. Even worse is the mobile number field remains locked out in exchange admin, and for each user under their portal contact settings. Only the admin can change this in active users on the O365 portal.
Martin Meraner commented
Hi, first of all, thanks a lot that you wrote this entry. I searched for answers for about a day now. Skype for Business all of a sudden showed a mobile phone number of an admin user (and the admin was not really happy). AD did not show anything, ECP on our on-premise exchange either, only the O365 and EOL contact information (obviously no edit in the GUI, as we run dirsync). Powershell update to the MSOL user did the trick, thanks a lot.
Vinicius Silva de Matos commented
Being able to manually set it back with set-msoluser is not a solution to this problem. As John stated this shouldn't have happened to begin with.
This can be worked around by manually running set-msoluser to correct the MobilePhone information. It allows you to overwrite the value even when the user is synced from on-prem.
Hey, did you ever get a proper fix?