Re: localhost vs. macinename in URL (access denied)
From: Joe Kaplan \(MVP - ADSI\) (joseph.e.kaplan_at_removethis.accenture.com)
Date: 01/06/04
- Previous message: irf: "Retrieving custom Permission Sets programatically"
- In reply to: Braden: "RE: localhost vs. macinename in URL (access denied)"
- Next in thread: Holly Mazerolle: "Re: localhost vs. macinename in URL (access denied)"
- Reply: Holly Mazerolle: "Re: localhost vs. macinename in URL (access denied)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 5 Jan 2004 21:15:44 -0600
Impersonation with Integrated Authentication will work if you are accessing
a resource on the same machine. If the security context must access a
resource on a machine on the network (such as SQL or AD or another
application server), then you must have delegation enabled for the user's
credentials to delegate to the remote machine. That is what was being
referred to as a "double-hop" issue.
With integrated authentication, the windows token that gets created on the
IIS server is an impersonation token. These do not hop to a different
machine without delegation. With Basic authentication, a primary token is
created, and that type of token can make one network hop. That's why Basic
authentication works.
Do some searches in the knowledge base on Delegation. You should find some
useful documents. Essentially, you need to change either the user accounts
being delegated to allow delegation or change the computer account to allow
it to delegate. You must also have Kerberos binds to your IIS server as
Kerberos is required for delegation. NTLM will not work. Thus you need
Win2K+ clients.
HTH,
Joe K.
"Braden" <anonymous@discussions.microsoft.com> wrote in message
news:039601c3d3cf$3b8c0930$a301280a@phx.gbl...
> Thanks for the information... The Basic Authentation
> option works but I can not get it to impersonate.
>
> To impersonate I have the web.config setup with:
>
> <authentication mode="Windows" />
> <identity impersonate="true"/>
>
> The virual directory security is "Integrated Windows
> Authentication"
>
> According to the KB article I have tried both:
>
> System.Security.Principal.WindowsImpersonationContext
> impersonationContext;
> impersonationContext =
> ((System.Security.Principal.WindowsIdentity)
> User.Identity).Impersonate();
>
> and
>
> when I kick out the user with
>
> Response.Write
> (System.Security.Principal.WindowsIdentity.GetCurrent
> ().Name.ToString());
>
> //my code is in here....
>
> impersonationContext.Undo()
>
>
> I get the proper users.
>
> But I still get access denied. Am I doing something wrong
> or misunderstanding what you are saying?
>
>
>
> >-----Original Message-----
> >Whenever you access resources not on the local IIS
> server you are creating
> >what is called a double-hop scenario. Basically the
> token gets lost when
> >you leave the IIS machine and go to the other machine.
> If you are on the
> >IIS machine and you access the resource using localhost
> in the browser this
> >means you are only doing a single-hop in which the token
> is not lost. If
> >you use a specific user name and password and that
> account exists in the
> >permissions on the remote machine then you will be able
> to gain access to
> >the resource.
> >
> >When you do this in your test without the user name and
> password, you are
> >attempting to go to the remote machine with the ASPNET
> account and no
> >token. However, if that account existed with the same
> password on the
> >remote machine you would be able to access the resource.
> >
> >ASP.Net offers you the ability to do per thread
> impersonation with the
> >authenticated IIS user. If the authenticated user is a
> domain account and
> >it has permission to the remote resource this will work
> for you.
> >306158 INFO: Implementing Impersonation in an ASP.NET
> Application
> >http://support.microsoft.com/?id=306158
> >
> >In a double hop scenario here are your options:
> >1. Impersonate
> >2. Run the process as a Domain Account in the
> machine.config file
> >3. Use Basic Authentication
> >4. Use Anonymous Authentication with a domain account as
> the Anonymous
> >Account
> >
> >This posting is provided "AS IS" with no warranties, and
> confers no rights.
> >Holly
> >
> >.
> >
- Previous message: irf: "Retrieving custom Permission Sets programatically"
- In reply to: Braden: "RE: localhost vs. macinename in URL (access denied)"
- Next in thread: Holly Mazerolle: "Re: localhost vs. macinename in URL (access denied)"
- Reply: Holly Mazerolle: "Re: localhost vs. macinename in URL (access denied)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|