Oct 04 2019 12:36 AM
Oct 04 2019 12:36 AM
Oct 06 2019 09:34 PM
From my understanding the command Convert-MsolFederatedUser is supposed to be used after the conversion of the sign in domain back to the standard authentication type. A new password has to be specified for the user as well. With federation it is all or nothing when it comes to domain. All users will use the same authentication method federated or standard. I have however successfully tested sign in issues by changing the UPN suffix in Active Directory for the user. This can be accomplished by using the .onmicrosoft.com domain or if your company owns a second domain that is verified in Office 365. Let me know if I can assist any other way!
Convert-MsolFederatedUser Doc - https://docs.microsoft.com/en-us/powershell/module/msonline/convert-msolfederateduser?view=azureadps...
Oct 07 2019 10:08 AM
Yeah you're right, I believe the convert-msolfederateuser command is used to migrate 1 off users that didn't get successfully converted when you convert the entire domain from federation to standard.
That being said, I'm just trying to remove federation authentication services for a single user, don't want to switch an entire domain. I know I can change their logon to onmicrosoft.com and then that will be local authentication … however that means I'd have to make the user's UPN to onmicrosoft.com as well right?
Oct 07 2019 10:37 AM
I assume the users are coming from your local AD through AD connect correct? If that is the case you can just change the UPN suffix for that particular user on the domain controller to .onmicroosft.com or another domain that is not federated and force a sync. What is important to note about this is don't change the proxy addresses in the attributes as that will change their actual email address and could make mail for that user bounce. Once that is completed you should see that the users sign in address switch to .onmicrosoft.com and you can then test authentication with the domain password. There is one more method you could try if this does not work for you. Let me know and I can explain the second method if needed.
Oct 07 2019 10:58 AM
Yes you are correct, on prem AD with AAD Connect with password sync turned on (eventhough we are using federated authentication through PingFederate)
Ok the only change I'll make is to the UPN for the user. I just want to make sure this doesn't impact his day to day activities like logging into windows...etc which it shouldn't. Do I need to recreate Outlook profile or should I just let it prompt for updated credentials?
Let me try this method first, its easy enough.
Oct 07 2019 11:08 AMSolution
Do your users authenticate with Domain\Username? If so this change will not affect how the user is logging on to their local machine. I usually just let Outlook prompt stating that it is no longer connected to Microsoft Exchange and prompts for the username and password. Hope this helps! @ch0wd0wn
Oct 07 2019 11:37 AM
Yes they use domain\username for the most part. THanks so much for the tip!
Oct 09 2019 11:38 AM
Changing the UPN worked, however the user now can't get into Outlook and authenticate or his mobile device... he basically has to use OWA. The authentication keeps prompting over and over even if we created a new Outlook profile. I thought that this should authenticate the user regardless of the application he was using... any thoughts?
Oct 12 2019 10:47 AM
Sorry for the slow response! Have you tried clearing out the credential manager on the local machine? @ch0wd0wn
Oct 12 2019 11:10 AM
It may be an issue with the domain federation. If AAD detects the domain requires to sign in from services like AD FS etc., then the domain will be redirected when the user enters the email address into M365.
So what may be happening is, when the user connected to outlook on the device, it performs a domain check. If the domain requires authentication via AD FS, then the user would be redirected to that endpoint to login. At this point, the claim token would not match for the users in AAD. The login would fail.
If you can not switch off the redirection for the domain authentication, try getting the user to use the onmicrosoft.com address. All users in AzureAD have email@example.com address.