Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have a new SP 2010 web-application configured for Claims authentication, with both 'windows' and 'forms' authentication.

Initially, I created a root site collection, set a windows site-collection-administrator and logged in with windows authentication without problem.

Note: I did not 'extend' into another zone, I applied changes to the original web-app.

Then, I followed the process of updating all 3 web-configs (web-app, central-admin, token-service) , create the fba database and added fba admin-users. I have configured the secondary site collection administrator as a fba user.

When I go to the login page, I get the 'choose forms/windows' authentication. The FBA user logs in successfully, and as a site-collection-admin, can mange the site, add users etc.

When I choose Windows auth though, it does authenticate but redirects to the initial login-choice page with additional URL parameters including 'access denied'

When I update the providers and remove forms auth, then Windows does work properly

Any thoughts?

thanks

share|improve this question
    
Did you extend your web app to a new zone to use another auth method? –  AlexPoint Mar 31 '11 at 7:01
    
Hi ... Not extended. Claims with both windows and forms configured –  Rob Mar 31 '11 at 17:38
    
I am also having the same problem. But If I add all domain users group in USER Policy permission with Full read. Then I can log in with windows authentication. But even though after logging in site, their not getting their old permissions. How do you fixed your issue? –  Sree Oct 10 '11 at 13:57
add comment

1 Answer

My guess is that you didn't set claims provider to be default membership and role provider. This is common mistake and I reproduced exactly the same error on my machine.

After setting up FBA providers in web.config (most likely with IIS manager) in most explanations next step is to set FBA provider as default membership and role provider. This is 'required' because it is easiest way to add some user accounts to FBA. After that next logical step is that you immediately check if your newly created account can log on SharePoint. And everything works like a charm, but only because your site collection is not running claims but it is using only FBA provider. And that is why windows user cannot access site.

After removing FBA authentication from web application (in Central Administration) SharePoint automatically resets default membership and role providers back to claims so everything is again working as expected.

To avoid it you just need to recheck your default membership and role providers with IIS manager. When using claims default membership provider name is i and default role provider name is c. When setting providers to i and c IIS manager will inform you that your current provider is not trusted provider - there is nothing wrong here so just ignore it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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