Hello again,
I've decided to take notes on the steps I took in hope that someone could pinpoint flaws or mistakes with what I've done regarding implementing kerberos. The scenario is described in the post above, so please refer to it for context. Ok, here goes:
In the AD, created a domain account named "kerberossvc" to be used on the middle tier computer.
In the Back-End (SQL), made sure that the expected user account had permissions to access the database (i'll use impersonation in the middle-tier). Also created the SPNs for the account running sqlserver, both for computername and FQDN using port 1433 (like, setspn -A MSSQLsvc/FQDN:1433 SqlServerAccount).
In the middle-tier computer, added the kerberossvc account to the IIS_WPG group. Also gave "adjust memory quotas" and "replace process-level token" rights to it and in IIS associated the account with the AppPool runnig the default website. In the site's web.config added <authentication mode="windows"/> and <identity impersonation="true"/> lines. Created the computer name and the FQDN SPNs for the AppPool account (like, setspn -A HTTP/FQDN domain\kerberossvc). In the IIS, made the site auth protocol be "windows integrated" only.
Back in the AD, went to the users and computers, selected the middle-tier machine, delegation tab and selected "trust this computer... (kerberos only)". I know I should use constrain delegation but I'm trying to avoid probable pithfalls at this stage.
Finally, in the front-end computer, in IIS default website, allowed for ASP.impersonation, windows integrated and anonymous auth. This site AppPool is run by a machine account (networkservice). Back in the AD configured the front-end computer to "trust this computer... specified services only" + "use any aut protocol" and added the SPNs created for the kerberossvc account as the services allowed here.
This was basically what I did. What I was expecting was that, for example, I used JonSmith account and it would be "carrying" my user credentials from tier to tier to the back-end (and yes, JonSmith has permissions to access the target SQL database). What happens is a "dead stop in your tracks!" like the following event (captured in the front-end):
An account failed to log on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Account For Which Logon Failed:
Security ID: NULL SID
Account Name:
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc000006a
Process Information:
Caller Process ID: 0x0
Caller Process Name: -
Network Information:
Workstation Name: -
Source Network Address: 10.0.0.100
Source Port: 49182
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
So yeah.. I'm pretty sure I'm messing up somewhere. Btw, my testing as been done all in intranet environment and I'm forcing my test client machine to connect to the front-end by means of modifying the HOST file (I'm not really sure if this is relevant but I'm mentioning it anyway). I'm hoping some of you can provide me with some insight here. Thanks for the time reading this.
Best regards,
Nuno Cruz