views:

80

answers:

3

We have an ASP site using Windows authentication to connect to a SQLServer database. There are three instances of the web site, a Dev environment (located on my Workstation), an UAT environment and a production environment, which are on separate servers.

When I access the Dev site (which uses the same DB as the UAT site) I have no issues, the site connects to the database using my Windows account. However when I connect to the UAT site, it uses a different account (one which belongs to me but is not connected to my default Windows login) which is not permissioned on the DB, so the site returns the following error:

Microsoft OLE DB Provider for SQL Server error '80004005' Cannot open database requested in login 'ANAML'. Login fails.
/inc/dbconnect.asp, line 4

The ASP files on the Dev and UAT sites are identical, so can anyone explain why the UAT site might be using the incorrect Windows account? This only affects me, from all workstations, and no other users.

Have rebooted the server and my workstation, and cleared my internet files locally.

A: 

"There are three instances of the web site, Dev environment (located on my Workstation), an UAT environment"

You should understand the the differences between impersonation (used only locally) and delegation (used connecting to another machine). This is "double hop" issue. These terms should be enough to find descriptions of IIS and SQL Server fundamentals to get acquainted yourself with in order to configure your web sites.

You had not given even a bare minimum in order to answer you more specifically.

vgv8
To clarify: there is enough expertise in the organisation to know the difference between impersonation and delegation. The UAT site worked until very recently; what I'm trying to establish is why it has suddenly started picking up the incorrect Windows account. What further information would help you answer more specifically?
Nick
A: 

Well, my ASP knowledge has mostly faded but I'll see what comes out of my brain. My first thought would be that the Virtual Directory security is configured differently on the server where it is failing. It sounds like you would need it to be set to "Integrated Windows Authentication" only.

If that is set correctly then I'd ask about your connection string. Does your connection string specify Trusted Connection (e.g. it does not specify a username and password)?

Where does the ANAML account come from? Is it a SQL only login or is it a windows account?

Russell McClure
The connection string specified "Integrated Security=SSPI;"; 'ANAML' is just the name of the database, not the login. The account that should be used to log in to the DB is the Windows account I am using when accessing the website in a browser; however this is not the account it is using, for some reason.
Nick
+2  A: 

I found the answer at this page on ServerFault. Seems the login details for the UAT server had been stored in the Users control panel at some point. Deleting the relevant entry in the control panel restored the correct login when connecting to the website.

Nick