claudiamcse
asked on
This doesn't look like a valid user ID. Make sure you typed the user ID assigned to you by your organization. It usually looks like
Hello,
WE are getting this error below when users who have been migrated to Office 365 try to sign in using SSO:
So, surprisingly some users can sign in to Office 365 with no error and others get this error below. UPN is all set correctly for those users and I verified that I can update user's property on premise and it is synched to the cloud.
I have to note that I had issues with federating domains and had to remove the relaying trust on ADFS server and then add second domain using the switch –SupportMultipledomain.
I verified that both test accounts from both domains were able to signin to Office 365. But now we have more users and most of them are not able to sign in and get this error:
Below are the steps I performed on ADFS server to enable support for multiple domains:
Update-MsolFederatedDomain
Then
Convert-MsolDomainToFedera
Did not do anything on Proxy servers....
I am going to try to re-run the ADFS wizard on all ADFS proxies.
Please let me know your thoughts. I am also seeing some errors on the DirSync log, but as I said NO issue with syncing updates.
Below is the error:
This doesn't look like a valid user ID. Make sure you typed the user ID assigned to you by your organization. It usually looks like someone@example.com or someone@example.onmicrosof
Sign out
Close Support Information
Correlation ID:
ncu#35287ea9-bcb1-448d-928
Error code:
0
WE are getting this error below when users who have been migrated to Office 365 try to sign in using SSO:
So, surprisingly some users can sign in to Office 365 with no error and others get this error below. UPN is all set correctly for those users and I verified that I can update user's property on premise and it is synched to the cloud.
I have to note that I had issues with federating domains and had to remove the relaying trust on ADFS server and then add second domain using the switch –SupportMultipledomain.
I verified that both test accounts from both domains were able to signin to Office 365. But now we have more users and most of them are not able to sign in and get this error:
Below are the steps I performed on ADFS server to enable support for multiple domains:
Update-MsolFederatedDomain
Then
Convert-MsolDomainToFedera
Did not do anything on Proxy servers....
I am going to try to re-run the ADFS wizard on all ADFS proxies.
Please let me know your thoughts. I am also seeing some errors on the DirSync log, but as I said NO issue with syncing updates.
Below is the error:
This doesn't look like a valid user ID. Make sure you typed the user ID assigned to you by your organization. It usually looks like someone@example.com or someone@example.onmicrosof
Sign out
Close Support Information
Correlation ID:
ncu#35287ea9-bcb1-448d-928
Error code:
0
Adam Brown
Not 100% sure, but I would recommend looking into the ADFS services log on the server. Open event viewer, then go to Applications And Services. There should be a folder or entry there for ADFS. Look through there for any errors and you should be able to get a better idea of what is failing when those users log in. The Correlation ID that comes up can be used to search through that log for the exact entry that recorded the failure.
So if I understand correctly, you federated some domain, then removed the trust and readded it? Did you at any point convert that domain back to standard (Convert-MsolDomainToStand
ASKER
No we didn't convert back the domains to Standard, just re-ran the switch with -supportmultile domain switch
Well the error corresponds to mismatching UPNs, but you have verified that already. Can you check the immutableID of one of the affected users and compare it with the GUID locally? You can use this script:
http://gallery.technet.microsoft.com/office/Covert-DirSyncMS-Online-5f3563b1#content
You can also run the Sign-on test from ExRCA, it gives some more troubleshooting information: http://aka.ms/rca
If you have UPNs that are from subdomains, there is a know issue with the claims rule that prevents such users from logging in. You can read more about it here: http://blog.kloud.com.au/2012/08/26/office-365-ad-fs-2-0-with-multiple-domains-and-subdomains-2/
http://gallery.technet.microsoft.com/office/Covert-DirSyncMS-Online-5f3563b1#content
You can also run the Sign-on test from ExRCA, it gives some more troubleshooting information: http://aka.ms/rca
If you have UPNs that are from subdomains, there is a know issue with the claims rule that prevents such users from logging in. You can read more about it here: http://blog.kloud.com.au/2012/08/26/office-365-ad-fs-2-0-with-multiple-domains-and-subdomains-2/
ASKER
Would you suggest runnning this command Convert-MsolDomainToFedera
Option 1:
http://www.msexchange.org/blogs/walther/news/office-365-adfs-support-for-mutiple-upns-724.html
Update-MsolFederatedDomain
Convert-MsolDomainToFedera
Option 2:
Convert-MsolDomainToStanda
Should we use switch to convert users as well with this command?
Convert-MsolDomainToStanda
Supply values for the following parameters:
SkipUserConversion: $True or $False??
Option 1:
http://www.msexchange.org/blogs/walther/news/office-365-adfs-support-for-mutiple-upns-724.html
Update-MsolFederatedDomain
Convert-MsolDomainToFedera
Option 2:
Convert-MsolDomainToStanda
Should we use switch to convert users as well with this command?
Convert-MsolDomainToStanda
Supply values for the following parameters:
SkipUserConversion: $True or $False??
If you run the Convert-MsolDomainToStanda
Can you get one of the affected user to run the Single Sign-On test from http://aka.ms/rca? Make sure that they can login locally from: https://sts.domain.com/adfs/ls/idpinitiatedsignon.aspx. You can also download and run MOSDAL with one of the affected users.
Can you notice anything in common with the affected users? Can you reproduce it with a newly created user or it only affects users that were previously synced?
If their UPNs match any subdomain, refer to the article in my previous post.
Can you get one of the affected user to run the Single Sign-On test from http://aka.ms/rca? Make sure that they can login locally from: https://sts.domain.com/adfs/ls/idpinitiatedsignon.aspx. You can also download and run MOSDAL with one of the affected users.
Can you notice anything in common with the affected users? Can you reproduce it with a newly created user or it only affects users that were previously synced?
If their UPNs match any subdomain, refer to the article in my previous post.
ASKER
Thank you. Single Sign-On test is successful.
As I mentioned, this is random issue and it is happening for some users and not the others.
I tested the user that gets this error from different PCs as well as from inside and outside- ALL successful.
When I test it from his PC from IE and Chrome, I get this error but from Firefox it is working fine!
Although, it does look like PC or browser issue, we see this issue happening from other PCs as well randomly even when you clear browser's cache. It is hard to replicate.
As I mentioned, this is random issue and it is happening for some users and not the others.
I tested the user that gets this error from different PCs as well as from inside and outside- ALL successful.
When I test it from his PC from IE and Chrome, I get this error but from Firefox it is working fine!
Although, it does look like PC or browser issue, we see this issue happening from other PCs as well randomly even when you clear browser's cache. It is hard to replicate.
ASKER
Newly created users don’t get affected at all. I have another issue but NOT sure how can they be related, but please let me know if there is any correlation btw the two and if this could be causing signing in problem.
After the mailbox is migrated to the cloud, users can SSO to the portal but Outlook can’t connect to Exchange Online as well as you can’t configure the devices with Active Sync.
So, Microsoft suggested the following resolution which actually fixes Outlook and Active Sync issue: change the UPN from federated UPN to internal UPN in local AD. Then, run DirSync. So, the user’s UPN in the cloud becomes username@domain.onmicrosft
Then, switch the UPN back to federated domain username@domain.com and run DirSync
This does the trick and Outlook connects to Exchange Online but those users have problem with logging in to Portal afterwards.
How could this possibly affect the authentication for users if you switch UPNs from onmicroosft.com to domain.com? I verified that UPN in the cloud is synced properly from AD.
Please, advice.
After the mailbox is migrated to the cloud, users can SSO to the portal but Outlook can’t connect to Exchange Online as well as you can’t configure the devices with Active Sync.
So, Microsoft suggested the following resolution which actually fixes Outlook and Active Sync issue: change the UPN from federated UPN to internal UPN in local AD. Then, run DirSync. So, the user’s UPN in the cloud becomes username@domain.onmicrosft
Then, switch the UPN back to federated domain username@domain.com and run DirSync
This does the trick and Outlook connects to Exchange Online but those users have problem with logging in to Portal afterwards.
How could this possibly affect the authentication for users if you switch UPNs from onmicroosft.com to domain.com? I verified that UPN in the cloud is synced properly from AD.
Please, advice.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
THank you very much Vasilcho for your answer. Looks like you are correct and the issue is not related to SSO. We did try to convert the domain back to standard and then back to federated. THat didn't make any difference. Thank you for the hint on why the oultook connects to Exchnage online after you change the UPN. But do you have a solution on how to resolve this without switching the UPN to onmicrosoft and then back?
THank you very much.
THank you very much.
Not sure what you are thanking me for as the issue is still not solved :)
Can you perform any of the tests above and post some more detailed information here? I have a feeling we are missing something obvious there, but it's a bit hard to diagnose it like that. Plus, I always enjoy working on strange issues :)
As for Outlook, this is again just a guess, we cannot be sure until you perform some tests. It might as well be an issue with the client not being able to connect to your AD FS server, see for example here: http://support.microsoft.com/kb/2466333
Can you perform any of the tests above and post some more detailed information here? I have a feeling we are missing something obvious there, but it's a bit hard to diagnose it like that. Plus, I always enjoy working on strange issues :)
As for Outlook, this is again just a guess, we cannot be sure until you perform some tests. It might as well be an issue with the client not being able to connect to your AD FS server, see for example here: http://support.microsoft.com/kb/2466333
ASKER
Autodiscover shows all green! So, Outlook is unable to connect to Exchange Online after the move unless you do the steps I mentioned above with UPN.
Have you tried Outlook with manual configuration for these users?
What's your domain name?
What's your domain name?
ASKER
Actually we switched to using DirSync with password sync....Thank you all for all your help!
ASKER
Thank you for your help