Solved

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

Posted on 2014-02-25
15
866 Views
Last Modified: 2014-12-14
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 –DomainName “domain.com” –SupportMultipledomain
Then
Convert-MsolDomainToFederated –DomainName “newdomain.com” –SupportMultipledomain

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.onmicrosoft.com.
Sign out

Close Support Information  
Correlation ID:
ncu#35287ea9-bcb1-448d-928a-91f21dfa1120


Error code:
0
0
Comment
Question by:claudiamcse
  • 8
  • 6
15 Comments
 
LVL 38

Expert Comment

by:Adam Brown
ID: 39887090
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.
0
 
LVL 38

Expert Comment

by:Vasil Michev (MVP)
ID: 39887120
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-MsolDomainToStandard)? If so, did you also convert the users?
0
 

Author Comment

by:claudiamcse
ID: 39887192
No we didn't convert back the domains to Standard, just re-ran the switch with -supportmultile domain switch
0
 
LVL 38

Expert Comment

by:Vasil Michev (MVP)
ID: 39888092
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/
0
 

Author Comment

by:claudiamcse
ID: 39889763
Would you suggest runnning this command Convert-MsolDomainToFederated  instead of removing trust and steps identified in the article below:

Option 1:
http://www.msexchange.org/blogs/walther/news/office-365-adfs-support-for-mutiple-upns-724.html
Update-MsolFederatedDomain –DomainName “domain.com” –SupportMultipledomain
Convert-MsolDomainToFederated –DomainName “newdomain.com” –SupportMultipledomain

Option 2:
Convert-MsolDomainToStandard

Should we use switch to convert users as well with this command?

Convert-MsolDomainToStandard at command pipeline position 1
Supply values for the following parameters:
SkipUserConversion: $True or $False??
0
 
LVL 38

Expert Comment

by:Vasil Michev (MVP)
ID: 39889964
If you run the Convert-MsolDomainToStandard cmdlet, it will actually remove the trust, so it's similar to what you already did. If the trust settings was the problem, all users would've been affected, or at least all users from specific domain. Since this is not the case, I suggest we focus on finding out what is so 'special' about those users instead.

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.
0
 

Author Comment

by:claudiamcse
ID: 39893548
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.
0
Are end users causing IT problems again?

You’ve taken the time to design and update all your end user’s email signatures, only to find out they’re messing up the HTML, changing the font and ruining the imagery. What can you do to prevent this? Find out how you can save your signatures from end users today.

 

Author Comment

by:claudiamcse
ID: 39893568
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.com
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.
0
 
LVL 38

Accepted Solution

by:
Vasil Michev (MVP) earned 500 total points
ID: 39894175
OK that's really strange. Any chance that there are different proxy settings configured in IE/Firefox? Check if there is any difference in logging to https://sts.domain.com/adfs/ls/idpinitiatedsignon.aspx with using IE and Firefox.

Can they login with other applications? Do Outlook or Lync work for example?

Can you verify if they actually get authenticated by the AD FS when they are using IE, or if the process fails beforehand. You can check this from the event log, but you might need to configure AD FS logging settings first. Here's how: http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-configuring-computers(v=WS.10).aspx.
You can also check the IIS logs to see if the request gets to the AD FS or if it's denied on O365's part.




As for the UPN, dirsync often fails to update changes to it. In principle, you can easily change it with the Set-MsolUserPrincipalName cmdlet, it will work even when dirsync is active. But the issue you are describing looks like an autodiscover issue to me, and they 'trick' you to switch to the onmicrosoft.com domain because autodiscover for it will always work.
0
 

Author Comment

by:claudiamcse
ID: 39901354
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.
0
 
LVL 38

Expert Comment

by:Vasil Michev (MVP)
ID: 39901517
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
0
 

Author Comment

by:claudiamcse
ID: 39905396
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.
0
 
LVL 38

Expert Comment

by:Vasil Michev (MVP)
ID: 39905560
Have you tried Outlook with manual configuration for these users?

What's your domain name?
0
 

Author Comment

by:claudiamcse
ID: 39923657
Actually we switched to using DirSync with password sync....Thank you all for all your help!
0
 

Author Closing Comment

by:claudiamcse
ID: 40499680
Thank you for your help
0

Featured Post

Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

Join & Write a Comment

Utilizing an array to gracefully append to a list of EmailAddresses
We are happy to announce a brand new addition to our line of acclaimed email signature management products – CodeTwo Email Signatures for Office 365.
In this video we show how to create an email address policy in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Mail Flow…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now