Quantcast
Channel: Troubleshooting
Viewing all articles
Browse latest Browse all 1814

If Physical Path Credntials are not set, the Application Pool Identity will be passed to SQL Server as the login ID regardless of the Anonymous User credentials. Why is this?

$
0
0
  • Machines:
    • Web Server: Windows Server 2012 R2
      • Internet Information Services (Version 8.5.9600.16384)
    • Database Server: Windows Server 2012 Standard
      • Microsoft SQL Server Standard (64-bit) 11.0.5343.0

On the web server, we have a Website called AppSite it has its Anonymous Authentication is set to "App Pool User".

Under the Apps Website we have a Web Application called "SpecialApp". This application is running an ASP.NET WebForms application that hits the DB using a ConnectionString defined in the Web.Config like so;

<add name="SpecialCS" connectionString="Data Source=OurDatabaseServ\SomeInstance;Initial Catalog=SpecialDB;Integrated Security=True" providerName="System.Data.SqlClient"/>

SpecialApp has its Anonymous Authentication set to a Custom User called "Apps-SpecialApp-User", and BOTH SpecialApp and its parent site AppSite  have ASP.NET Impersonation set to "Authenticated user".

Our App Pool Identity (App Pool -> Advanced Settings -> Process Model -> Identity) is set to a Custom Account we can call "App-Pool-User"

The SQL Server has a group under SQL Server Instance -> Security -> Logins. The group is tied via User Mapping to SpecialDB and is configured with full ownership permissions, and our user Apps-SpecialApp-User is in the group.

Thats the setup, the problem is that if you navigate to AppSite/SpecialApp you get:

Server Error in '/SpecialApp' Application.

Cannot open database "SpecialDB" requested by the login. The login failed.
Login failed for user 'DOMAIN\App-Pool-User'.

This is what is confusing our team. Why is IIS passing the App-Pool-User to the SQL Server? We have clearly defined A specific user in Anonymous Authentication, and we enabled ASP.NET Impersonation to "Authenticated user" if that even has anything to do with this.

The workaround: The fix we found was to go to SpecialApp -> Advanced Settings -> Physical Path Credentials -> and set it to the Anon User (Apps-SpecialApp-User).  But why do we have to do this? And why would the Physical Path Credentials be the ones to get passed up the chain to the SQL Server? Have we done our auth all wrong? 


Viewing all articles
Browse latest Browse all 1814

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>