R
russell.lane
Greetings -
I'm trying to set up domain login impersonation and delegation for a
multi-tier web application. The goal is for the application, middle tier
services, and back end database to operate under the end user's Windows
domain login id. This is in the context of a intranet deployment, no
firewalls.
To begin sorting this out, I'm starting small. My first goal is to create a
simple service that can will query the database as the login user and return
a dataset. Here's what I've done so far:
o Set up my user id on the DB so I can login and execute the stored
procedure.
o Written the simple service in ASP.Net C# that calls the stored procedure.
o Installed the simple service on an app server remote from the DB server.
o Configured the simple service to not allow anonymous login, and to use
windows authentication.
o <identity impersonate="true"> in the test service web.config
o Created a custom domain account for the service to run under.
o Created SPN's for the custom domain account that map the account to HTTP
on my app server with both fully qualified and netBIOS name, including port
number (80).
o In ADS, enabled the custom domain account I run the service under to
delegate to MSSQLsvc on the DB server.
o Created an application pool whose identity is the custom domain account.
o Assigned my test service to the new application pool.
For initial testing, I just tried to bring the service up in IE on both the
app server (i.e., the host where the service runs) and also from my desktop.
In both cases I am logged onto the system where I'm running the browser with
my Windows domain account. On both platforms, IE is set up so that the app
server is in the intranet zone, and windows authentication is enabled.
When I bring the service up in IE on the app server, everything is great. I
can run the service (auto-generated form from the service WSDL), the service
impersonates me and forwards my identity to the database, the procedure runs
and I get the dataset back.
When I bring the service up in IE from my desktop, IE pops up a login prompt
(this did not happen on the app server). I enter my user name, password,
and domain, and it's rejected.
When I look at the security event log on the app server, I see a number of
"Failure Audit" messages. The detail on these messages states:
Logon failure:
Reason: Unknown user name or bad password
Logon type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
The user name, domain, workstation name, caller user name, caller domain,
caller logon id are all blank. The source network address has the correct
IP address for my workstation.
Another point of information -- if I set up the web service to use basic
authentication, everything works correctly when accessed from a browser on
either the app server or my desktop. I get a prompt (as is expected for
basic authentication), enter my user name, password, and domain, and I can
access the service as desired. So, it seems like there's a Kerberos issue
involved in here somewhere.
I'm not sure what I'm missing here. Can anyone offer some suggestions?
Sorry for the length. There's a lot of detail to the setup for this stuff
and I'm not sure what piece is significant and what piece is not.
Many thanks!!
R
I'm trying to set up domain login impersonation and delegation for a
multi-tier web application. The goal is for the application, middle tier
services, and back end database to operate under the end user's Windows
domain login id. This is in the context of a intranet deployment, no
firewalls.
To begin sorting this out, I'm starting small. My first goal is to create a
simple service that can will query the database as the login user and return
a dataset. Here's what I've done so far:
o Set up my user id on the DB so I can login and execute the stored
procedure.
o Written the simple service in ASP.Net C# that calls the stored procedure.
o Installed the simple service on an app server remote from the DB server.
o Configured the simple service to not allow anonymous login, and to use
windows authentication.
o <identity impersonate="true"> in the test service web.config
o Created a custom domain account for the service to run under.
o Created SPN's for the custom domain account that map the account to HTTP
on my app server with both fully qualified and netBIOS name, including port
number (80).
o In ADS, enabled the custom domain account I run the service under to
delegate to MSSQLsvc on the DB server.
o Created an application pool whose identity is the custom domain account.
o Assigned my test service to the new application pool.
For initial testing, I just tried to bring the service up in IE on both the
app server (i.e., the host where the service runs) and also from my desktop.
In both cases I am logged onto the system where I'm running the browser with
my Windows domain account. On both platforms, IE is set up so that the app
server is in the intranet zone, and windows authentication is enabled.
When I bring the service up in IE on the app server, everything is great. I
can run the service (auto-generated form from the service WSDL), the service
impersonates me and forwards my identity to the database, the procedure runs
and I get the dataset back.
When I bring the service up in IE from my desktop, IE pops up a login prompt
(this did not happen on the app server). I enter my user name, password,
and domain, and it's rejected.
When I look at the security event log on the app server, I see a number of
"Failure Audit" messages. The detail on these messages states:
Logon failure:
Reason: Unknown user name or bad password
Logon type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
The user name, domain, workstation name, caller user name, caller domain,
caller logon id are all blank. The source network address has the correct
IP address for my workstation.
Another point of information -- if I set up the web service to use basic
authentication, everything works correctly when accessed from a browser on
either the app server or my desktop. I get a prompt (as is expected for
basic authentication), enter my user name, password, and domain, and I can
access the service as desired. So, it seems like there's a Kerberos issue
involved in here somewhere.
I'm not sure what I'm missing here. Can anyone offer some suggestions?
Sorry for the length. There's a lot of detail to the setup for this stuff
and I'm not sure what piece is significant and what piece is not.
Many thanks!!
R
