4

I have a web application that is split into two zones: the Default zone and the Intranet zone.

The Default zone uses standard NTLM authentication. The Intranet zone was converted to FBA, but now I've switched it back to NTLM. For some reason when I access the Default zone I have no problems, however accessing the Intranet zone with the same user gives me the SP Access Denied page.

The web.config files are identical for the membership providers, roleManager providers, and everything else in the system.web section except for identity impersonation on the Intranet zone (but even turning off impersonation on the Intranet zone so they have the same settings doesn't change the fact). The people picker wildcards are the same.

The Authentication Providers configuration settings in Central Administration are the same (Integrated Windows Authentication: NTLM, Default Sign In Page).

What am I missing? The login works fine on the Default zone, and I am getting to the Intranet zone because I'm seeing the default SharePoint "Error: Access Denied" page, but I can't login continually get denied permissions on the Intranet zone...

enter image description here

| improve this question | |
  • have you checked your web.config? – Marius Constantinescu - MVP Jan 10 '14 at 16:19
  • Of course. A third of my question talks about the web.config files being nearly identical. There is little to no variation between them. It is authenticating, but I'm getting denied permission. I edited for a little more clarity on that. – RJ Cuthbertson Jan 10 '14 at 16:43
1

I fixed it, but I don't understand why it wasn't working in the first place.

I found this article that helped me, but it didn't provide a direct answer: SharePoint 2013: Access Denied to Root Site of Web Application

In the article I linked the issue experienced was in 2013 (my environment's issue was 2010), and the access denied was only occurring on the root site. So I tried to see if I could get to any of the sub-sites except I was getting access denied on all sub-sites as well. In the article, Sam Weber (the author) wrote:

It turns out this problem is a result of the Web Application Authentication settings getting corrupted and can be remedied by enabling and then disabling Anonymous Authentication. This recycles Web Application Authentication settings and clears out the corruption.

OK, well that's interesting... so I enabled anonymous access saved it and got a 404?!? I disabled it and saved it again and ended up back in the same place I started from. But it got me to thinking about how else to go about forcing the authentication settings to refresh if that could possibly be the problem. I disabled integrated authentication on both zones and re-enabled it again. And then everything started to work. I still don't what the problem stemmed from, but it's working now...

| improve this answer | |
  • 1
    +1 Nice hint! I'm struggling with the same issue here, so this is a great lead. Thanks! – Benny Skogberg♦ Jun 11 '15 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.