File Server delegation

[Marc Castrechini]

This is a classic double hop delegation issue, however its the first time we
are setting this up so we are doing something incorrectly. If we run
through the IDE or using a localhost path on the web server the command
succeeds. However, if we use the servername or ip through IIS it fails.
For this reason we know we have permissions setup correctly on the file
server.

Can anyone identify what we could possibly be doing wrong here:

File Server: Windows Server 2003
Web Server: Windows Server 2003, IIS 6.0
Active Directory: Full Windows 2003
Web.config: Auth mode "Windows", Impersonate="tr ue"
In AD, my Web Server has Delegation Trusted to the File Server (Kerberos
only) with cifs, and HOST services.

Simple test is:
System.IO.Copy( "C:\test.do c", "\\FILESERVER\T emplate\test.do c")

TIA, any help would be greatly appreciated,

- Marc Castrechini

[Steven Cheng[MSFT]]

Hello Marc,

From your description, you're going to use kerberos delegation to make the
client authenticated user identity double hop to downstream services,
however, you found that it didn't work in some conditions in the test
environment, correct?

As for the kerberos delegation you current use, I think it should be
unconstrained delegation, yes? There're some techical reference describing
how to configure and troubleshooting kerberos delegation related scenarios,
and I will conclude them to the following key points which is most
important for kerberos delegation scenarios:

** Make sure that the client account(general ly the domain account) is
configured for delegation in AD

** Make sure that the server service's account is configured as trusted for
delegation (for target service) in AD

** If your application runs under a custom domain account, you need to
configure your domain account in Active Directory to be trusted for
delegation. You must also register a service principal name in Active
Directory to associate the domain account with the HTTP service on your Web
server. If you use domain accounts to run your Web application or the
downstream service that you are accessing, you must also ensure that
appropriate service principal names (SPNs) are created in Active Directory
for those accounts

** Make sure the authentication' s client and server will be able to use
kerberos as the authentication schema when establish connection

For your scenario, I think you should have made the first two items ready.
And since you said that the problem occurs when you try access the server
through servername(full dns name) or ip address, ti failes, I think it is
likely that you need to check the 3rd item above, have you registered the
servcie priincipal name in AD to associate them with your downstream
service(ASP.NET applications' process account)?

For general troubleshooting , I suggest you test the following things:

1. Always test from remote client machine rather than on local webserver
because the local logon session is different than the one generated through
remote authentication. You can visit your ASP.NET web application from a
remote client (XP or 2003) when test kerberos behavior.

2. In your ASP.NET application's code(after being impersonated), use the
following class to check whether the current impersonated windows identity
is the correct one and whether its AuthenticationT ype is kerberos(Neogia te)
and whether its ImpersonationLe vel is Delegation:

System.Security .Principal.Wind owsIdentity.Get Current().XXXXX (properties)

If those property value is not conform to kerberos delegation token, it
seems the problem occurs at client browser and web server's authentication.
3. One the second downstream service (where you put IO.Copy code), you can
programmtically create a file on the machine (set everyone write permision)
and check the creation owner to see what's the account that has been
forwared to the scenod service).

Here are some related reference article in MSDN which may be helpful.

http://msdn.microsoft.com/library/de...us/dnnetsec/ht
ml/SecNetHT05.asp

http://msdn.microsoft.com/library/de...us/dnpag2/html
/paght000023.asp

http://msdn.microsoft.com/library/de...us/dnnetsec/ht
ml/SecNetch13.asp

Please feel free to let me know your test result or if you have any new
findings.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

=============== =============== =============== =====

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[Marc Castrechini]

Thanks for the detailed answer. A few questions from it:

Is running the application (and by that I presume the Application Pool
Identity) using a custom domain account required for Delegation? We were
trying to use strictly the Network Service account so we could eliminate the
possiblity of SPN issues. We thought setting up Delegation on the Web
Server to talk to the CIFS service on the File Server would work around
that. Is that not correct?

Another thing we tried is the Identity recomendation you mentioned. We
found that our ImperosonationL evel is "Impersonat ion" not "Delegation ". Our
user is the current domain user in DOMAIN\USERNAME format as expected. Does
that add any insight to what we are doing incorrectly?

TIA,
- Marc Castrechini

"Steven Cheng[MSFT]" <st*****@online .microsoft.comw rote in message
news:Ag******** ******@TK2MSFTN GXA01.phx.gbl.. .

Hello Marc,

From your description, you're going to use kerberos delegation to make the
client authenticated user identity double hop to downstream services,
however, you found that it didn't work in some conditions in the test
environment, correct?

As for the kerberos delegation you current use, I think it should be
unconstrained delegation, yes? There're some techical reference describing
how to configure and troubleshooting kerberos delegation related
scenarios,
and I will conclude them to the following key points which is most
important for kerberos delegation scenarios:

** Make sure that the client account(general ly the domain account) is
configured for delegation in AD

** Make sure that the server service's account is configured as trusted
for
delegation (for target service) in AD

** If your application runs under a custom domain account, you need to
configure your domain account in Active Directory to be trusted for
delegation. You must also register a service principal name in Active
Directory to associate the domain account with the HTTP service on your
Web
server. If you use domain accounts to run your Web application or the
downstream service that you are accessing, you must also ensure that
appropriate service principal names (SPNs) are created in Active Directory
for those accounts

** Make sure the authentication' s client and server will be able to use
kerberos as the authentication schema when establish connection

For your scenario, I think you should have made the first two items ready.
And since you said that the problem occurs when you try access the server
through servername(full dns name) or ip address, ti failes, I think it is
likely that you need to check the 3rd item above, have you registered the
servcie priincipal name in AD to associate them with your downstream
service(ASP.NET applications' process account)?

For general troubleshooting , I suggest you test the following things:

1. Always test from remote client machine rather than on local webserver
because the local logon session is different than the one generated
through
remote authentication. You can visit your ASP.NET web application from a
remote client (XP or 2003) when test kerberos behavior.

2. In your ASP.NET application's code(after being impersonated), use the
following class to check whether the current impersonated windows identity
is the correct one and whether its AuthenticationT ype is
kerberos(Neogia te)
and whether its ImpersonationLe vel is Delegation:

System.Security .Principal.Wind owsIdentity.Get Current().XXXXX (properties)

If those property value is not conform to kerberos delegation token, it
seems the problem occurs at client browser and web server's
authentication.
3. One the second downstream service (where you put IO.Copy code), you can
programmtically create a file on the machine (set everyone write
permision)
and check the creation owner to see what's the account that has been
forwared to the scenod service).

Here are some related reference article in MSDN which may be helpful.

http://msdn.microsoft.com/library/de...us/dnnetsec/ht
ml/SecNetHT05.asp

http://msdn.microsoft.com/library/de...us/dnpag2/html
/paght000023.asp

http://msdn.microsoft.com/library/de...us/dnnetsec/ht
ml/SecNetch13.asp

Please feel free to let me know your test result or if you have any new
findings.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

=============== =============== =============== =====

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Steven Cheng[MSFT]]

Thanks for your reply Marc,

Yes, for ASP.NET application the running process account is the IIS6's
application pool identity. And you're right that if you use the Network
service account as the web application's process identity, you can avoid
registering the host name (SPN) for the web appliation service since by
default the network service account(can represent machine account) has two
SPNs associated with it,(the netbious computer name and the full qualified
dns name) you can verify this through the setspn.exe tool. However, if you
want to use other custom host name or DNS name for the web application
site, you need to register that hostname as SPN in AD also.

As for the WindowsIdentity you mentioned, have you checked its
"Authentication Type" property? Is it Negotiate or NTML?

Not sure whether you've already read the following reference. here is a
complete troubleshooting reference about kerberos delegation:

#Troubleshootin g Kerberos Delegation
http://www.microsoft.com/technet/pro.../technologies/
security/tkerbdel.mspx

You can also download a local version:

http://www.microsoft.com/downloads/d...94f-e28a-4726-
bffe-2f64ae2f59a2&di splaylang=en

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

[Marc Castrechini]

Thanks for the reply, at least I am sure I have that setup correctly.
Also, I did go ahead and try a custom domain application account as the
application pool identity as well. After registering the SPNs for that
account and granting the custom domain account delegation permissions I
received the same access denied error.

As to your Authentication Type question, here are my results after
impersonation has taken place:

..GetCurrentUse rName: {DOMAIN}\{USER} (Currently logged in user)
..Authenticatio nType: Kerberos
..Impersonation Level: Impersonation

I have not seen this Kerberos Delegation troubleshooting document. Thank
you for pointing it out. I will go through this and see if I can find out
what I am doing incorrectly. Should I come across any questions I will
continue to ask them here.

Thank you for your help,

- Marc Castrechini

"Steven Cheng[MSFT]" <st*****@online .microsoft.comw rote in message
news:jI******** ******@TK2MSFTN GXA01.phx.gbl.. .

Thanks for your reply Marc,

Yes, for ASP.NET application the running process account is the IIS6's
application pool identity. And you're right that if you use the Network
service account as the web application's process identity, you can avoid
registering the host name (SPN) for the web appliation service since by
default the network service account(can represent machine account) has two
SPNs associated with it,(the netbious computer name and the full qualified
dns name) you can verify this through the setspn.exe tool. However, if
you
want to use other custom host name or DNS name for the web application
site, you need to register that hostname as SPN in AD also.

As for the WindowsIdentity you mentioned, have you checked its
"Authentication Type" property? Is it Negotiate or NTML?

Not sure whether you've already read the following reference. here is a
complete troubleshooting reference about kerberos delegation:

#Troubleshootin g Kerberos Delegation
http://www.microsoft.com/technet/pro.../technologies/
security/tkerbdel.mspx

You can also download a local version:

http://www.microsoft.com/downloads/d...94f-e28a-4726-
bffe-2f64ae2f59a2&di splaylang=en

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no
rights.

[Steven Cheng[MSFT]]

Thanks for your followup Marc,

Yes, the doc has a complete TS list. Also, at the end of the document, it
has mentioned using network tracing to check the kerberos authentication,
this will be very helpful to verify whether the kerberos ticket has been
successfully be forwarded from client to middle server and backend.

Please feel free to post here if you get any update.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

[Steven Cheng[MSFT]]

Hello Marc,

How are you doing on this issue, have you got any progress? Please feel
free to let me know if there is still anything we can help.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.