A: 

What you are describing should work without issue.

Your connection string should look like:

<add name="IntegratedAuthConnectionString" connectionString=
 "Data Source=DATABASEINSTANCE;Integrated Security=True"
 providerName="System.Data.SqlClient"/>

Your web.config should also specify windows authentication

<authentication mode="Windows"/>

Create a test page which dumps everything from the Request.ServerVariables collection and ensure that you are seeing the authenticated username and domain. Something along the lines of the code below

foreach (string s in Request.ServerVariables)
{
    Response.Write(s + ": " + Request.ServerVariables[s] + "<br />");
}
ahsteele
Hi, thanks for the response. My connection string is actually built dynamically by some code. I dumped it for debugging, and it is such: `"Data Source=DBSERVER\SQLEXPRESS05;Initial Catalog=myDb;Integrated Security=True".`
eidylon
In my web.config I have: `<authentication mode="Windows" ></authentication>``<identity impersonate="true" />``<authorization>`` <deny users="?"/>``</authorization>`And from the ServerVariables, I see the following lines: `AUTH_TYPE: Negotiate``AUTH_USER: MYDOMAIN\myuser``AUTH_PASSWORD: ``LOGON_USER: MYDOMAIN\myuser``REMOTE_USER: MYDOMAIN\myuser`In my webcode, putting out User.Identity.Name shows the right name, and putting out User.Identity.IsAuthenticated shows True, so I am apparently authenticating to the web server, it's just not hopping.
eidylon
+6  A: 

Download the Troubleshooting Kerberos Delegation. Its a life saver.
At page 17 you'll find the Active Directory Checklist. Follow the checklist step by step.
At page 30 you'll find the Client Application Checklist. Verify the checklist step by step.
At page 35 is the Middle Tier Checklist. Verify it step by step.
At page 48 is the Back End Checklist. Verify it step by step.

If you still have problems, the document contains a detailed list of troubleshooting tools (kerbtray, klist, ldifde etc), detailed explanation on how to enable logging and auditing of authentication errors in the system event log, detailed explanation of all error codes in the event log entries from the authentication audit and so on and so forth.

Once you figure out what is wrong, it will be much easier to fix.

Remus Rusanu
+3  A: 

The answer ultimately DID lie in the SPNs.

This system was set up on our test site, which is test.ourcompany.com, so i needed to add a new SPN for that reference. So in addition to the following:

HTTP/server 
HTTP/server.ourdomain.com

I also needed to add an additional one for:

HTTP/test.ourcompany.com

Geez, what a battle! At least it's over! :)
Thanks for the help guys!

eidylon
Ultimately, what led me to the solution, was installing wireshark on the PDC, and watching for traffic on port 88 (the Kerberos port), which then showed that it did not recognize the entity being called, which showed the web name... test.ourcompany.com. That then hinted me to add an additional SPN for that, and voila! Thanks all for your help getting there!
eidylon
Oy! I spoke too soon; it was only working for ONE user, other users it's not working for. BUT - other projects to move on to, ... will have to come back to this.
eidylon
Actually, now it IS working for all our test users. Apparently it just took a VERY long time for the changes in AD to 'propogate' or whatever you want to call it.
eidylon