ASP.NET Impersonation Problem

[Ram P. Dash]

Now this is a classic. The impersonation fails for CASE I but doesn't fail
for CASE II or III.

Case I:

Client Side Code
-----------------
System.Net.Netw orkCredential credential = new
System.Net.Netw orkCredential(" myUserName", "myPassword ", "myDomain") ;
ServiceA a = new ServiceA();
a.Credentials = credential;
a.SomeMethod();

Server Side Code
------------------
Web.config
-----------
<authenticati on mode="Windows" />
<identity impersonate="tr ue" />

ServiceA
---------
[WebMethod]
public void SomeMethod() {

// Write to share drive code (the share drive has myUserName in ACL
list, myUserName should be able to write to it)
// But it fails
}

Case II:
Everything being same if I change only the Web.config as follows, it works:

<authenticati on mode="Windows" />
<identity impersonate="tr ue" userName="myDom ain\myUserName"
password="myPas sword" />

Case III:

Web.config
------------
<authenticati on mode="Windows" />
<!-- No impersonation -->

ServiceA
---------
[WebMethod]
public void SomeMethod() {

Impersonate i = new Impersonate();
i.StartImperson ate();
// Write to share drive code (the share drive has myUserName in ACL
list, myUserName should be able to write to it)
// This time it works
i.UndoImpersona te();
}

public class Impersonate {

// Usual code using the following
[DllImport("adva pi32.dll")]
public static extern int LogonUserA(...) ;
}

I've tried the following for CASE I as suggested in
http://support.microsoft.com/default...;en-us;q306158. But nothing
works.

a) Changing the "userName" attribute from "machine" to "system" in
"processMod el" node in machine.config
b) Including ASPNET user in following Group Policy:
\Local Computer Policy\Computer Configuration\W indows Settings\Local
Policies\User Rights Assignment\"Act as part of the operating system"

Infrastructure: Windows XP Pro (Service Pack 1); .NET Frmaework 1.0 (No
service pack)

Our corporate policy strongly favors doing things as in CASE I. How can I
make it work?

Thanks,
Ram

[Mark Rae]

Re: ASP.NET Impersonation Problem

"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..
[color=blue]
> Client Side Code
> -----------------
> System.Net.Netw orkCredential credential = new[/color]

How can this be client-side code...?

[Mark Rae]

Re: ASP.NET Impersonation Problem

"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..
[color=blue]
> Client Side Code
> -----------------
> System.Net.Netw orkCredential credential = new[/color]

How can this be client-side code...?

[Ram P. Dash]

Re: ASP.NET Impersonation Problem

I create an instance of NetworkCredenti al and feed that to the WebService
proxy class object. The credential do get carried to the WebService. However
the token's ACL is lost somewhere in the middle. In CASE I on server side,
if I do System.Security .Principal.Wind owsIdentity id =
System.Security .Principal.Wind owsIdentity.Get Current(); I can see my
identity.

Ram

"Mark Rae" <mark@mark-N-O-S-P-A-M-rae.co.uk> wrote in message
news:e3xwYqvYFH A.3272@TK2MSFTN GP14.phx.gbl...[color=blue]
> "Ram P. Dash" <rampr2@hotmail .com> wrote in message
> news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..
>[color=green]
> > Client Side Code
> > -----------------
> > System.Net.Netw orkCredential credential = new[/color]
>
> How can this be client-side code...?
>
>[/color]

[Ram P. Dash]

Re: ASP.NET Impersonation Problem

I create an instance of NetworkCredenti al and feed that to the WebService
proxy class object. The credential do get carried to the WebService. However
the token's ACL is lost somewhere in the middle. In CASE I on server side,
if I do System.Security .Principal.Wind owsIdentity id =
System.Security .Principal.Wind owsIdentity.Get Current(); I can see my
identity.

Ram

"Mark Rae" <mark@mark-N-O-S-P-A-M-rae.co.uk> wrote in message
news:e3xwYqvYFH A.3272@TK2MSFTN GP14.phx.gbl...[color=blue]
> "Ram P. Dash" <rampr2@hotmail .com> wrote in message
> news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..
>[color=green]
> > Client Side Code
> > -----------------
> > System.Net.Netw orkCredential credential = new[/color]
>
> How can this be client-side code...?
>
>[/color]

[Willy Denoyette [MVP]]

Re: ASP.NET Impersonation Problem


"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> Now this is a classic. The impersonation fails for CASE I but doesn't fail
> for CASE II or III.
>
> Case I:
>
> Client Side Code
> -----------------
> System.Net.Netw orkCredential credential = new
> System.Net.Netw orkCredential(" myUserName", "myPassword ", "myDomain") ;
> ServiceA a = new ServiceA();
> a.Credentials = credential;
> a.SomeMethod();
>
> Server Side Code
> ------------------
> Web.config
> -----------
> <authenticati on mode="Windows" />
> <identity impersonate="tr ue" />
>
> ServiceA
> ---------
> [WebMethod]
> public void SomeMethod() {
>
> // Write to share drive code (the share drive has myUserName in ACL
> list, myUserName should be able to write to it)
> // But it fails
> }
>
> Case II:
> Everything being same if I change only the Web.config as follows, it
> works:
>
> <authenticati on mode="Windows" />
> <identity impersonate="tr ue" userName="myDom ain\myUserName"
> password="myPas sword" />
>
> Case III:
>
> Web.config
> ------------
> <authenticati on mode="Windows" />
> <!-- No impersonation -->
>
> ServiceA
> ---------
> [WebMethod]
> public void SomeMethod() {
>
> Impersonate i = new Impersonate();
> i.StartImperson ate();
> // Write to share drive code (the share drive has myUserName in ACL
> list, myUserName should be able to write to it)
> // This time it works
> i.UndoImpersona te();
> }
>
> public class Impersonate {
>
> // Usual code using the following
> [DllImport("adva pi32.dll")]
> public static extern int LogonUserA(...) ;
> }
>
> I've tried the following for CASE I as suggested in
> http://support.microsoft.com/default...;en-us;q306158. But
> nothing
> works.
>
> a) Changing the "userName" attribute from "machine" to "system" in
> "processMod el" node in machine.config
> b) Including ASPNET user in following Group Policy:
> \Local Computer Policy\Computer Configuration\W indows Settings\Local
> Policies\User Rights Assignment\"Act as part of the operating system"
>
> Infrastructure: Windows XP Pro (Service Pack 1); .NET Frmaework 1.0 (No
> service pack)
>
> Our corporate policy strongly favors doing things as in CASE I. How can I
> make it work?
>
> Thanks,
> Ram
>
>
>[/color]

I told you, that this can only work in a Kerberos Realm (W2K AD domain), and
this only when Delegation is enabled at the server and all clients are
delegatable. This is not something I would ever recommend.
A better solution is to authenticate the client , and access the remote
share using fixed credentials, access control can be implemented using
roles.

Willy.

[Willy Denoyette [MVP]]

Re: ASP.NET Impersonation Problem


"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> Now this is a classic. The impersonation fails for CASE I but doesn't fail
> for CASE II or III.
>
> Case I:
>
> Client Side Code
> -----------------
> System.Net.Netw orkCredential credential = new
> System.Net.Netw orkCredential(" myUserName", "myPassword ", "myDomain") ;
> ServiceA a = new ServiceA();
> a.Credentials = credential;
> a.SomeMethod();
>
> Server Side Code
> ------------------
> Web.config
> -----------
> <authenticati on mode="Windows" />
> <identity impersonate="tr ue" />
>
> ServiceA
> ---------
> [WebMethod]
> public void SomeMethod() {
>
> // Write to share drive code (the share drive has myUserName in ACL
> list, myUserName should be able to write to it)
> // But it fails
> }
>
> Case II:
> Everything being same if I change only the Web.config as follows, it
> works:
>
> <authenticati on mode="Windows" />
> <identity impersonate="tr ue" userName="myDom ain\myUserName"
> password="myPas sword" />
>
> Case III:
>
> Web.config
> ------------
> <authenticati on mode="Windows" />
> <!-- No impersonation -->
>
> ServiceA
> ---------
> [WebMethod]
> public void SomeMethod() {
>
> Impersonate i = new Impersonate();
> i.StartImperson ate();
> // Write to share drive code (the share drive has myUserName in ACL
> list, myUserName should be able to write to it)
> // This time it works
> i.UndoImpersona te();
> }
>
> public class Impersonate {
>
> // Usual code using the following
> [DllImport("adva pi32.dll")]
> public static extern int LogonUserA(...) ;
> }
>
> I've tried the following for CASE I as suggested in
> http://support.microsoft.com/default...;en-us;q306158. But
> nothing
> works.
>
> a) Changing the "userName" attribute from "machine" to "system" in
> "processMod el" node in machine.config
> b) Including ASPNET user in following Group Policy:
> \Local Computer Policy\Computer Configuration\W indows Settings\Local
> Policies\User Rights Assignment\"Act as part of the operating system"
>
> Infrastructure: Windows XP Pro (Service Pack 1); .NET Frmaework 1.0 (No
> service pack)
>
> Our corporate policy strongly favors doing things as in CASE I. How can I
> make it work?
>
> Thanks,
> Ram
>
>
>[/color]

I told you, that this can only work in a Kerberos Realm (W2K AD domain), and
this only when Delegation is enabled at the server and all clients are
delegatable. This is not something I would ever recommend.
A better solution is to authenticate the client , and access the remote
share using fixed credentials, access control can be implemented using
roles.

Willy.

[Bruce Barker]

Re: ASP.NET Impersonation Problem

its all to due with creditial forwarding (1 hop rule). to access the
network, you creditial need to be a primary token with network access.

case I: will fail becuase the server does not have a primary token only one
passed from the client, unless the browser in on the server - localhost. (as
many develop apps on their local box and use localhost, the problem is not
seen until prod. you can dup on your own box, by hitting from another box.)

case II: works because the server has a primary token created by asp.net

case III: works becuase the thread creates a primary token

as pointed at, you can use kerberos, and enable creditial forwarding.

-- bruce (sqlwork.com)



"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> Now this is a classic. The impersonation fails for CASE I but doesn't fail
> for CASE II or III.
>
> Case I:
>
> Client Side Code
> -----------------
> System.Net.Netw orkCredential credential = new
> System.Net.Netw orkCredential(" myUserName", "myPassword ", "myDomain") ;
> ServiceA a = new ServiceA();
> a.Credentials = credential;
> a.SomeMethod();
>
> Server Side Code
> ------------------
> Web.config
> -----------
> <authenticati on mode="Windows" />
> <identity impersonate="tr ue" />
>
> ServiceA
> ---------
> [WebMethod]
> public void SomeMethod() {
>
> // Write to share drive code (the share drive has myUserName in ACL
> list, myUserName should be able to write to it)
> // But it fails
> }
>
> Case II:
> Everything being same if I change only the Web.config as follows, it
> works:
>
> <authenticati on mode="Windows" />
> <identity impersonate="tr ue" userName="myDom ain\myUserName"
> password="myPas sword" />
>
> Case III:
>
> Web.config
> ------------
> <authenticati on mode="Windows" />
> <!-- No impersonation -->
>
> ServiceA
> ---------
> [WebMethod]
> public void SomeMethod() {
>
> Impersonate i = new Impersonate();
> i.StartImperson ate();
> // Write to share drive code (the share drive has myUserName in ACL
> list, myUserName should be able to write to it)
> // This time it works
> i.UndoImpersona te();
> }
>
> public class Impersonate {
>
> // Usual code using the following
> [DllImport("adva pi32.dll")]
> public static extern int LogonUserA(...) ;
> }
>
> I've tried the following for CASE I as suggested in
> http://support.microsoft.com/default...;en-us;q306158. But
> nothing
> works.
>
> a) Changing the "userName" attribute from "machine" to "system" in
> "processMod el" node in machine.config
> b) Including ASPNET user in following Group Policy:
> \Local Computer Policy\Computer Configuration\W indows Settings\Local
> Policies\User Rights Assignment\"Act as part of the operating system"
>
> Infrastructure: Windows XP Pro (Service Pack 1); .NET Frmaework 1.0 (No
> service pack)
>
> Our corporate policy strongly favors doing things as in CASE I. How can I
> make it work?
>
> Thanks,
> Ram
>
>
>[/color]

[Bruce Barker]

Re: ASP.NET Impersonation Problem

its all to due with creditial forwarding (1 hop rule). to access the
network, you creditial need to be a primary token with network access.

case I: will fail becuase the server does not have a primary token only one
passed from the client, unless the browser in on the server - localhost. (as
many develop apps on their local box and use localhost, the problem is not
seen until prod. you can dup on your own box, by hitting from another box.)

case II: works because the server has a primary token created by asp.net

case III: works becuase the thread creates a primary token

as pointed at, you can use kerberos, and enable creditial forwarding.

-- bruce (sqlwork.com)



"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> Now this is a classic. The impersonation fails for CASE I but doesn't fail
> for CASE II or III.
>
> Case I:
>
> Client Side Code
> -----------------
> System.Net.Netw orkCredential credential = new
> System.Net.Netw orkCredential(" myUserName", "myPassword ", "myDomain") ;
> ServiceA a = new ServiceA();
> a.Credentials = credential;
> a.SomeMethod();
>
> Server Side Code
> ------------------
> Web.config
> -----------
> <authenticati on mode="Windows" />
> <identity impersonate="tr ue" />
>
> ServiceA
> ---------
> [WebMethod]
> public void SomeMethod() {
>
> // Write to share drive code (the share drive has myUserName in ACL
> list, myUserName should be able to write to it)
> // But it fails
> }
>
> Case II:
> Everything being same if I change only the Web.config as follows, it
> works:
>
> <authenticati on mode="Windows" />
> <identity impersonate="tr ue" userName="myDom ain\myUserName"
> password="myPas sword" />
>
> Case III:
>
> Web.config
> ------------
> <authenticati on mode="Windows" />
> <!-- No impersonation -->
>
> ServiceA
> ---------
> [WebMethod]
> public void SomeMethod() {
>
> Impersonate i = new Impersonate();
> i.StartImperson ate();
> // Write to share drive code (the share drive has myUserName in ACL
> list, myUserName should be able to write to it)
> // This time it works
> i.UndoImpersona te();
> }
>
> public class Impersonate {
>
> // Usual code using the following
> [DllImport("adva pi32.dll")]
> public static extern int LogonUserA(...) ;
> }
>
> I've tried the following for CASE I as suggested in
> http://support.microsoft.com/default...;en-us;q306158. But
> nothing
> works.
>
> a) Changing the "userName" attribute from "machine" to "system" in
> "processMod el" node in machine.config
> b) Including ASPNET user in following Group Policy:
> \Local Computer Policy\Computer Configuration\W indows Settings\Local
> Policies\User Rights Assignment\"Act as part of the operating system"
>
> Infrastructure: Windows XP Pro (Service Pack 1); .NET Frmaework 1.0 (No
> service pack)
>
> Our corporate policy strongly favors doing things as in CASE I. How can I
> make it work?
>
> Thanks,
> Ram
>
>
>[/color]

[Mark Rae]

Re: ASP.NET Impersonation Problem

"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:eQRhUyvYFH A.3184@TK2MSFTN GP15.phx.gbl...
[color=blue]
>I create an instance of NetworkCredenti al and feed that to the WebService
> proxy class object.[/color]

Not client-side you don't...

[Mark Rae]

Re: ASP.NET Impersonation Problem

"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:eQRhUyvYFH A.3184@TK2MSFTN GP15.phx.gbl...
[color=blue]
>I create an instance of NetworkCredenti al and feed that to the WebService
> proxy class object.[/color]

Not client-side you don't...

[Ram P. Dash]

Re: ASP.NET Impersonation Problem

Thanks a lot Bruce,

As rightly pointed out by you, it's a double hop issue which can be resolved
via kerberos delegation. However, our corporate security group will never
allow it.

I know this question is stupid but is there any way that on the server side
I can create a primary token based on the credentials supplied from client?

Ram

"Bruce Barker" <brubar_nospamp lease_@safeco.c om> wrote in message
news:uQDxBIwYFH A.3188@TK2MSFTN GP09.phx.gbl...[color=blue]
> its all to due with creditial forwarding (1 hop rule). to access the
> network, you creditial need to be a primary token with network access.
>
> case I: will fail becuase the server does not have a primary token only[/color]
one[color=blue]
> passed from the client, unless the browser in on the server - localhost.[/color]
(as[color=blue]
> many develop apps on their local box and use localhost, the problem is not
> seen until prod. you can dup on your own box, by hitting from another[/color]
box.)[color=blue]
>
> case II: works because the server has a primary token created by asp.net
>
> case III: works becuase the thread creates a primary token
>
> as pointed at, you can use kerberos, and enable creditial forwarding.
>
> -- bruce (sqlwork.com)
>
>
>
> "Ram P. Dash" <rampr2@hotmail .com> wrote in message
> news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..[color=green]
> > Now this is a classic. The impersonation fails for CASE I but doesn't[/color][/color]
fail[color=blue][color=green]
> > for CASE II or III.
> >
> > Case I:
> >
> > Client Side Code
> > -----------------
> > System.Net.Netw orkCredential credential = new
> > System.Net.Netw orkCredential(" myUserName", "myPassword ", "myDomain") ;
> > ServiceA a = new ServiceA();
> > a.Credentials = credential;
> > a.SomeMethod();
> >
> > Server Side Code
> > ------------------
> > Web.config
> > -----------
> > <authenticati on mode="Windows" />
> > <identity impersonate="tr ue" />
> >
> > ServiceA
> > ---------
> > [WebMethod]
> > public void SomeMethod() {
> >
> > // Write to share drive code (the share drive has myUserName in[/color][/color]
ACL[color=blue][color=green]
> > list, myUserName should be able to write to it)
> > // But it fails
> > }
> >
> > Case II:
> > Everything being same if I change only the Web.config as follows, it
> > works:
> >
> > <authenticati on mode="Windows" />
> > <identity impersonate="tr ue" userName="myDom ain\myUserName"
> > password="myPas sword" />
> >
> > Case III:
> >
> > Web.config
> > ------------
> > <authenticati on mode="Windows" />
> > <!-- No impersonation -->
> >
> > ServiceA
> > ---------
> > [WebMethod]
> > public void SomeMethod() {
> >
> > Impersonate i = new Impersonate();
> > i.StartImperson ate();
> > // Write to share drive code (the share drive has myUserName in[/color][/color]
ACL[color=blue][color=green]
> > list, myUserName should be able to write to it)
> > // This time it works
> > i.UndoImpersona te();
> > }
> >
> > public class Impersonate {
> >
> > // Usual code using the following
> > [DllImport("adva pi32.dll")]
> > public static extern int LogonUserA(...) ;
> > }
> >
> > I've tried the following for CASE I as suggested in
> > http://support.microsoft.com/default...;en-us;q306158. But
> > nothing
> > works.
> >
> > a) Changing the "userName" attribute from "machine" to "system" in
> > "processMod el" node in machine.config
> > b) Including ASPNET user in following Group Policy:
> > \Local Computer Policy\Computer Configuration\W indows Settings\Local
> > Policies\User Rights Assignment\"Act as part of the operating system"
> >
> > Infrastructure: Windows XP Pro (Service Pack 1); .NET Frmaework 1.0 (No
> > service pack)
> >
> > Our corporate policy strongly favors doing things as in CASE I. How can[/color][/color]
I[color=blue][color=green]
> > make it work?
> >
> > Thanks,
> > Ram
> >
> >
> >[/color]
>
>[/color]

[Ram P. Dash]

Re: ASP.NET Impersonation Problem

Thanks a lot Bruce,

As rightly pointed out by you, it's a double hop issue which can be resolved
via kerberos delegation. However, our corporate security group will never
allow it.

I know this question is stupid but is there any way that on the server side
I can create a primary token based on the credentials supplied from client?

Ram

"Bruce Barker" <brubar_nospamp lease_@safeco.c om> wrote in message
news:uQDxBIwYFH A.3188@TK2MSFTN GP09.phx.gbl...[color=blue]
> its all to due with creditial forwarding (1 hop rule). to access the
> network, you creditial need to be a primary token with network access.
>
> case I: will fail becuase the server does not have a primary token only[/color]
one[color=blue]
> passed from the client, unless the browser in on the server - localhost.[/color]
(as[color=blue]
> many develop apps on their local box and use localhost, the problem is not
> seen until prod. you can dup on your own box, by hitting from another[/color]
box.)[color=blue]
>
> case II: works because the server has a primary token created by asp.net
>
> case III: works becuase the thread creates a primary token
>
> as pointed at, you can use kerberos, and enable creditial forwarding.
>
> -- bruce (sqlwork.com)
>
>
>
> "Ram P. Dash" <rampr2@hotmail .com> wrote in message
> news:%23sri7mvY FHA.3864@TK2MSF TNGP10.phx.gbl. ..[color=green]
> > Now this is a classic. The impersonation fails for CASE I but doesn't[/color][/color]
fail[color=blue][color=green]
> > for CASE II or III.
> >
> > Case I:
> >
> > Client Side Code
> > -----------------
> > System.Net.Netw orkCredential credential = new
> > System.Net.Netw orkCredential(" myUserName", "myPassword ", "myDomain") ;
> > ServiceA a = new ServiceA();
> > a.Credentials = credential;
> > a.SomeMethod();
> >
> > Server Side Code
> > ------------------
> > Web.config
> > -----------
> > <authenticati on mode="Windows" />
> > <identity impersonate="tr ue" />
> >
> > ServiceA
> > ---------
> > [WebMethod]
> > public void SomeMethod() {
> >
> > // Write to share drive code (the share drive has myUserName in[/color][/color]
ACL[color=blue][color=green]
> > list, myUserName should be able to write to it)
> > // But it fails
> > }
> >
> > Case II:
> > Everything being same if I change only the Web.config as follows, it
> > works:
> >
> > <authenticati on mode="Windows" />
> > <identity impersonate="tr ue" userName="myDom ain\myUserName"
> > password="myPas sword" />
> >
> > Case III:
> >
> > Web.config
> > ------------
> > <authenticati on mode="Windows" />
> > <!-- No impersonation -->
> >
> > ServiceA
> > ---------
> > [WebMethod]
> > public void SomeMethod() {
> >
> > Impersonate i = new Impersonate();
> > i.StartImperson ate();
> > // Write to share drive code (the share drive has myUserName in[/color][/color]
ACL[color=blue][color=green]
> > list, myUserName should be able to write to it)
> > // This time it works
> > i.UndoImpersona te();
> > }
> >
> > public class Impersonate {
> >
> > // Usual code using the following
> > [DllImport("adva pi32.dll")]
> > public static extern int LogonUserA(...) ;
> > }
> >
> > I've tried the following for CASE I as suggested in
> > http://support.microsoft.com/default...;en-us;q306158. But
> > nothing
> > works.
> >
> > a) Changing the "userName" attribute from "machine" to "system" in
> > "processMod el" node in machine.config
> > b) Including ASPNET user in following Group Policy:
> > \Local Computer Policy\Computer Configuration\W indows Settings\Local
> > Policies\User Rights Assignment\"Act as part of the operating system"
> >
> > Infrastructure: Windows XP Pro (Service Pack 1); .NET Frmaework 1.0 (No
> > service pack)
> >
> > Our corporate policy strongly favors doing things as in CASE I. How can[/color][/color]
I[color=blue][color=green]
> > make it work?
> >
> > Thanks,
> > Ram
> >
> >
> >[/color]
>
>[/color]

[Willy Denoyette [MVP]]

Re: ASP.NET Impersonation Problem


"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:%23OJz%23k wYFHA.3220@TK2M SFTNGP14.phx.gb l...[color=blue]
> Thanks a lot Bruce,
>
> As rightly pointed out by you, it's a double hop issue which can be
> resolved
> via kerberos delegation. However, our corporate security group will never
> allow it.
>
> I know this question is stupid but is there any way that on the server
> side
> I can create a primary token based on the credentials supplied from
> client?
>
> Ram
>[/color]

If You mean passing the credentials from the client to the server, yes there
is call "LogonUser" at the server using the credentials supplied. But again
this is a real bad idea, calling LogonUser for each service request can kill
the performance of the server application when handling multiple
simultaneous requests, and I wonder if the security group will allow this.
Do as I said, authenticate as close to the client as possible, once
authenticated use roles for authorization handling.

Willy.

[Willy Denoyette [MVP]]

Re: ASP.NET Impersonation Problem


"Ram P. Dash" <rampr2@hotmail .com> wrote in message
news:%23OJz%23k wYFHA.3220@TK2M SFTNGP14.phx.gb l...[color=blue]
> Thanks a lot Bruce,
>
> As rightly pointed out by you, it's a double hop issue which can be
> resolved
> via kerberos delegation. However, our corporate security group will never
> allow it.
>
> I know this question is stupid but is there any way that on the server
> side
> I can create a primary token based on the credentials supplied from
> client?
>
> Ram
>[/color]

If You mean passing the credentials from the client to the server, yes there
is call "LogonUser" at the server using the credentials supplied. But again
this is a real bad idea, calling LogonUser for each service request can kill
the performance of the server application when handling multiple
simultaneous requests, and I wonder if the security group will allow this.
Do as I said, authenticate as close to the client as possible, once
authenticated use roles for authorization handling.

Willy.