Re: File Server delegation
- From: "Marc Castrechini" <castro_9@xxxxxxxxxxxxxxxx>
- Date: Wed, 1 Nov 2006 14:25:35 -0500
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 ImperosonationLevel is "Impersonation" 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]" <stcheng@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:AggcgUY$GHA.1984@xxxxxxxxxxxxxxxxxxxxxxxx
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(generally 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 AuthenticationType is
kerberos(Neogiate)
and whether its ImpersonationLevel is Delegation:
System.Security.Principal.WindowsIdentity.GetCurrent().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/default.asp?url=/library/en-us/dnnetsec/ht
ml/SecNetHT05.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html
/paght000023.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.
.
- Follow-Ups:
- Re: File Server delegation
- From: Steven Cheng[MSFT]
- Re: File Server delegation
- References:
- File Server delegation
- From: Marc Castrechini
- RE: File Server delegation
- From: Steven Cheng[MSFT]
- File Server delegation
- Prev by Date: Re: Label.Text controls in an array
- Next by Date: Re: 403 forbidden error
- Previous by thread: RE: File Server delegation
- Next by thread: Re: File Server delegation
- Index(es):
Relevant Pages
|
