20. června 2011 19:01
I have a 2011 deployment with ADFS and IFD. 9 out of 10 users can successfully sign in and use the system, while 1 sees a 404 error. There's no navigation pane, and no ribbon - no CRM components are displayed at all. A couple of things that have been tried without success:
- The log-in happens successfully, the user is redirected to https://blah.blahblah.com/main.aspx and then to https://blah.blahblah.com/default.aspx - this is where they get the 404
- Tried IE 8 and IE9 both with Vista SP2
- Tried Compatibility Mode and not
- Disabled Windows Firewall
- Nothing in the trace log on the server
- *trupanion.com added to trusted sites
- Rollup 1 is installed
- This happens on all 3 computers at the user's home
Any ideas on what to try next?
- Přesunutý Andrii ButenkoMVP, Moderator 21. června 2011 6:00 (From:CRM)
21. června 2011 10:30
This is DNS issue, i was having the same problem.
when i login with my credentials i will get 404 page with https://auth.blahblah.com/default.asps
and again when i change the URL to proper organization URL it works fine.
So i have created a separate web publishing rule(TMG) for auth.domain.com later it works perfect.
so please check your external dns enties.
- Navržen jako odpověď Paul Conroy 13. října 2011 0:41
21. června 2011 15:52
This only doesn't work for 1 out of 10 users. The other 9 can get to the site just fine. That tells me that the external DNS entries work just fine.
Still having this issue - anyone else run into this?
22. června 2011 19:33Moderátor
Are internal claims working ?
check for any kerberos failures on the client that is failing.
That would indicate SPN reading failure due to DNS/Kerberos failures. In the field we have seen certain client machines that have issues with their machine accounts in AD.
Curtis J Spanburgh
23. června 2011 6:09
Ugh, what an ugly problem. Got a solution, finally.
Somehow, I have no idea how, the user's account was missing from the Config database, while being present in the main database. This caused the user to appear everywhere it should, be able to be assigned to teams, and be able to athenticate successfully against AD - but not view any CRM components.
The remedy was to create a brand new domain account, associate the user with that account, and then associate the user back with their old domain account. They can now log in just fine.
- Označen jako odpověď Andrew Ornatov 23. června 2011 6:09
13. října 2011 0:42
This is a real sticky one and I wouldn't have thought to create a new publishing rule for the auth URL ! :)
10. března 2012 18:01
Issue has been fixed in RU6 http://support.microsoft.com/kb/2600640.
24. dubna 2012 18:03This happens in RU 6 too!!!!!! Microsoft should be embrassed releasing this product.
5. prosince 2012 13:00
I am also using TMG and was getting the 404 on auth.mycompany.com and not redirecting to orgname.mycompany.com.
Creating a seperate Publishing Rule on TMG for auth fixed the issue, so thank you for your post.
On further investigation, you can keep it all in the one Publishing Rule on TMG. On the properties of the rule in the "To" tab, the "This rule applies to this published site" field must be "auth.mycompany.com".
You can then list your other dns entries - dev.mycompany.com, orgname.mycompany.com, orgname2.mycompany.com, etc under the Public Name tab of the publishing rule.