locked
Claims Based Authentication - Access Denied for NTLM - Network Related RRS feed

  • Question

  • Hello,

    We have setup a test SharePoint environment on a single box. If we create a new classic authentication web application using NTLM the site works fine, and recognizes AD users correctly. Users can then login successfully. If we create a new claims based authentication web application using NTLM all users receive an Access Denied error when trying to view the site. The application will recognize AD users when applying permissions in Central Admin's User Policy section, but none of those users are able to access the site.

    If I turn on Fiddler Capture, the sites will work fine. Once I turn it off the sites no longer work and we are again presented with an Access Denied exception (or sometimes 403 Forbidden in Firefox and Chrome). I know that Fiddler create a local proxy so I'm curious what that proxy is doing that allows claims based to work correctly.

    Has anyone seen this before? Does this sound Firewall/Antivirus related? Client or server?

    Thank you,
    Sam

     


    www.sawyercreativedesign.com
    Tuesday, October 5, 2010 6:40 PM

Answers

  • Hi Eric,

    I solve my issue by making secure store application pool account "local system". It was "Network service" before. Now it is working fine.


    Comrade
    Monday, January 24, 2011 4:37 PM

All replies

  • Interesting! Can you do some debugging. Is secure token service setup right or what kind of errors are logged etc.

    Are you doing FBA ? Claims based users are treated different than AD users . so you have to give permissions exclusive to Claims based users.

    I came across this article that might help you

    http://sharepointchick.com/archive/2010/05/06/configuring-claims-and-forms-based-authentication-for-use-with-an.aspx

    Hope this will take you in right direction!

    Tuesday, October 5, 2010 8:50 PM
  • Thanks for the reply. We actually don't see any errors in the log. Any ideas on how to setup better debugging (for STS or SharePoint)? I'm assuming it's because there were no exceptions. The pages act as normally, but SharePoint just doesn't think we have permission to view the site. We went down this path because we do want to do dual authentication (AD and FBA), but we can't get the NTLM/AD part working using claims based (which is required by FBA). The sharepoint chick article is actually the one I have been using to set this up, however it doesn't describe any additional setup for the AD/NTLM portion of the login. I'm pretty sure it's supposed to work out of the box without any config. FBA, on the other hand, is what requires additional setup.

     

    Thank you,
    Sam


    www.sawyercreativedesign.com
    Wednesday, October 6, 2010 7:28 PM
  • For what it is worth, I have been able to get what you described to work just fine. I have a site that is accessible via both NTLM and FBA user. The one catch is the single sign on does not work because brings the out of the box setup will being you to landing page that asks you if you want FBA or NTLM. If you select NTLM, life works good, if you select FBA you are given a login in screen and life is good.

    Krishna, You are correct that CLaims based and Classic based NTLM users are not the same. There are some scripts on the internet to help with converting them if you have restoring a classic site to Claims based.

    The one issue I am having is around searching the claims based site, but that is another post entirely.

    Eric VanRoy

    Tuesday, November 2, 2010 9:24 PM
  • Hi Eric,

    I solve my issue by making secure store application pool account "local system". It was "Network service" before. Now it is working fine.


    Comrade
    Monday, January 24, 2011 4:37 PM
  • Are you using the IIS rewrite module?

    We have a similar issue in the authoring (NTLM on Claims) site unless we deactivate the rewrite section.

    After hacking in some rules that do nothing except stop the processing, things are working in Chrome and IE, however Firefox only works if Fiddler is running, if Fiddler isn't running, Firefox ends up in a redirect loop. The loop is caused by my hack because FF never gets authenticated.

     

    -A

    Tuesday, April 19, 2011 4:20 PM
  • Changing to local system account on the app pool, also did the trick for me.

    Thanks Caglar.

    Tuesday, May 1, 2012 1:18 PM