Credentials not passed on when using ASP.NET

[Guest]

Hi there,

I am having trouble getting an ASP.NET web application to connect to another
computer and passing the proper credentials and I hope someone can help me.

I have a stand-alone Windows 2003 Server, ServerA, running as a Web Server
that uses ASP.NET. The default.aspx file tries to access a file in a share
on another computer, ServerB. ServerA and ServerB are on the same domain and
are both running Windows 2003 Server.



The Domain Controller is running Windows 2000 Server. I want to use
Integrated Windows Authentication to access the file. When I connect to the
Web site and then check the event viewer on ServerB, I can see that ServerA
is using the Anonymous Logon to connect to ServerB instead of passing
through my windows credentials. On ServerA, I have done the following:



In IIS, set the authentication to Integrated Windows Authentication and
deselected Allow Anonymous logon

Did the following according to
http://support.microsoft.com/default.aspx?scid=kb;en-us;871179

In my application pool, I set the Identity to a domain user,
MyDomain\SvcAcct

Added the user, MyDomain\SvcAcct to the IIS_WPG group

As the domain administrator, I ran Setspn on ServerA . When this didn't
work, I repeated it on the Primary Domain Controller of the domain and that
didn't work either. How I ran the command is listed below:

Setspn -A HTTP/<netbios name> MyDomain\SvcAcct



Then I followed the instructions at
http://technet2.microsoft.com/Windo...a055-43f7-b9be-20599b694a311033.mspx?mfr=true
and on the Primary Domain Controller of the domain I also went into Active
Directory Services Users and Groups and selected the "Trust this computer
for delegation" option for ServerA and I also followed the instructions at
http://technet2.microsoft.com/Windo...38c5-49dc-83bf-e69d8e1dbbfa1033.mspx?mfr=true
and I selected the "Account is trusted for delegation" option for the
MyDomain\SvcAcct user.

Following http://support.microsoft.com/kb/215383/, on ServerA, I ran the
following:



Cscript adsutil.vbs set w3svc/1/NTAuthenticationProviders "Negotiate,NTLM"

I signed in to my client computer as MyDomain\UserA

In IE 6.0, on the client computer, as instructed in
http://support.microsoft.com/kb/810572/, I selected the "Enable Integrated
Windows Authentication (requires restart)" option on the Advanced tab and
then cleared my cache and close my IE 6.0 session and started another.



In my web.config file for the website, I added the following line after the
</authorization> closing tag:

<identity impersonate="true" />



When I connect to the Website on ServerA from the client computer, I am not
prompted for credentials and that is what I would expect. When I turn on
auditing, I can also see that UserA is accessing the default.aspx file for
the Website and that is also what I would expect. However, the event viewer
on ServerB shows that the Anonymous Logon is what is being used to connect
to it.



When I run the Auth Diagnostics 1.0 tool from Microsoft that is refered to
in http://support.microsoft.com/default.aspx?scid=kb;en-us;871179 on my
Website on ServerA, I see the message, "Service Principal name (SPN) for
user 'MyDomain\SvcAcct' not found in Active Directory"

Anything I see on the Internet says to run Setspn for this problem but we
have done this. Am I doing something wrong when I do this? Is there another
reason why the credentials are not being passed on?

When I try this with a straight html file, I am able to access the file.

What am I doing wrong when setting up my spn?

Thanks,

Jennifer

 

[Joe Kaplan \(MVP - ADSI\)]

With your environment (Win2K AD), you'll need a pure Kerberos authentication
path to get delegation to work as S4U will not be an option. As such, the
keys to getting this to work are:

- Ensure that the browser client is authenticating with IIS using Kerberos,
not NTLM
- Ensure that the web server can access the file share using Kerberos auth,
not NTLM

If those two things happen and your IIS app pool identity is trusted for
delegation (and impersonation is enabled in ASP.NET), then this will work.

I'd start by concentrating on getting Kerberos auth between the browser and
IIS. You can tell if this is working by enabling logon event auditing in
local security policy and checking the security event log to see how the
user was authenticated.

If you are getting NTLM instead of Kerberos, you need to make sure that the
SPN on the app pool identity account is correct and *has not been duplicated
in AD anywhere* and you need to make sure that IIS is configured for
Negotiate authentication and not just NTLM. There is a metabase property
that controls this. You can see what types are requested from the server by
the values in the WWW-authenticate header that the server sends back with
its 401.1 response.

This probably goes without saying, by the server name in the URL used to
access the site must match the SPN.

The same process applies for the file share. Make sure the computer account
on the second machine has a valid CIFS SPN (although HOST should work was
well) that matches the name used to access the file share. Check the event
logs to see what type of authentication is being negotiated.

Troubleshooting Kerberos delegation can be painful, but my experience is
that it really does work the way the documentation says it does.
Unfortunately, the documentation is fairly complex and there are quite a few
variables.

Joe K.

 

[Guest]

Thanks for the information. My server name didn't match my SPN. When I fixed
that, it worked fine.

Do you know why I am still getting an error message from the Auth
Diagnostics tool on the 1st server (my WebServer)? The message is:
"Service Principal name (SPN) for user 'MyDomain\SvcAcct' not found in
Active Directory"
This message gives me the impression that I haven't set up the SPN properly
on the Web Server but it seems to work now and I don't know what I have done
incorrectly. Any suggestions?

Thanks,

Jennifer

 

[Joe Kaplan \(MVP - ADSI\)]

I'd use an LDAP query tool to check the SPN (ldp.exe, adfind, etc.). Either
query the forest by servicePrincipalName=HTTP/xxxx or query the forest by
the user (sAMAccountName=xxxx) and look at the servicePrincipalName
attribute. I have no idea what the auth diagnostics tool is doing, so I
don't know if that info is misleading or not.

If the security event log on the IIS box says you are getting Kerberos auth,
you are getting Kerberos auth.

Joe K.