Impersonated login to web service from outside domain

[uggis]

I'm having trouble connecting to a web service through a web server,
when using a client not part of the same domain as the servers.

The setup is as follows:
A client connects to a web server configured with windows
authentication and impersonate enabled. The web server connects to a
web service (also windows authentication) on a different server also
on the domain. The impersonated user?s credentials are used when
connecting to the web service (accomplished by apiService.Credentials
= System.Net.CredentialCache.DefaultCredentials). This works fine as
long as the client computer is part of the same domain as the two
servers. However, if the client is not part of the domain (logs on to
the domain using the standard windows pop up) the following error is
displayed:

There was an error downloading 'path/Service.asmx'

When I view the User.Identity.Name and the
System.Security.Principal.WindowsIdentity.GetCurrent().Name on the web
server, they both show the correct impersonated user, both when using
a client from outside the domain and when using one inside the domain.

The impersonated user is shown correctly on the web service server?s
log, when the client on the domain is used:

2004-05-10 13:34:30 xx.xx.47.7 GET Service.asmx - 80 domain\username
xx.xx.47.84 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+1.1.4322.573)
200 0 0

No user is shown in the logs when a client outside the domain is used:

2004-05-10 13:34: xx.xx.47.7 GET Service.asmx - 80 - xx.xx.47.84
Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+1.1.4322.573)
401 2 2148074254

Can anyone tell me why this happens? Is there a reason for the two
behaving differently? It seems to me that DefaultCredentials does not
get hold of the credentials when a client from outside the domain is
used. Is this correct? Is there a way to get around this problem?

Any help is appreciated
-uggis-

 

[Paul Glavich [MVP - ASP.NET]]

Not sure but here is an educated guess.

I am assuming you are on Win2000 or better and are using Kerberos protocol.
The account you are using is marked for delegation and thus succeeds when
the client is part of the domain group.

When not part of the domain group, no KDC (Key Distribution centre) can be
located to grant authentication tickets that can also be delegated, so the
integrated windows auth fails.

You can try creating an identical local user on the server (as the one you
are using on the client - same id/pwd) but while this may successfully
authenticate on the web user and show the user id you are expecting, the
next call to the web service (ie. the process requiring the credentials to
be delegated may fail) as it will probably drop back to NTLM if no KDC can
be found, and NTLM does not support delegation.

Any other windows server gurus care to clarify? Ken...?

 

[Ken Schaefer]

I think Paul's analysis is spot on. Have you considered using Basic Auth +
SSL?

I don't know if creating a local user on the webserver will work, because
that local user can't be assigned permissions to remote resources.

Cheers
Ken



message : Not sure but here is an educated guess.
:
: I am assuming you are on Win2000 or better and are using Kerberos
protocol.
: The account you are using is marked for delegation and thus succeeds when
: the client is part of the domain group.
:
: When not part of the domain group, no KDC (Key Distribution centre) can be
: located to grant authentication tickets that can also be delegated, so the
: integrated windows auth fails.
:
: You can try creating an identical local user on the server (as the one you
: are using on the client - same id/pwd) but while this may successfully
: authenticate on the web user and show the user id you are expecting, the
: next call to the web service (ie. the process requiring the credentials to
: be delegated may fail) as it will probably drop back to NTLM if no KDC can
: be found, and NTLM does not support delegation.
:
: Any other windows server gurus care to clarify? Ken...?
:
: --
: - Paul Glavich
: Microsoft MVP - ASP.NET
:
:
: : > I'm having trouble connecting to a web service through a web server,
: > when using a client not part of the same domain as the servers.
: >
: > The setup is as follows:
: > A client connects to a web server configured with windows
: > authentication and impersonate enabled. The web server connects to a
: > web service (also windows authentication) on a different server also
: > on the domain. The impersonated user?s credentials are used when
: > connecting to the web service (accomplished by apiService.Credentials
: > = System.Net.CredentialCache.DefaultCredentials). This works fine as
: > long as the client computer is part of the same domain as the two
: > servers. However, if the client is not part of the domain (logs on to
: > the domain using the standard windows pop up) the following error is
: > displayed:
: >
: > There was an error downloading 'path/Service.asmx'
: >
: > When I view the User.Identity.Name and the
: > System.Security.Principal.WindowsIdentity.GetCurrent().Name on the web
: > server, they both show the correct impersonated user, both when using
: > a client from outside the domain and when using one inside the domain.
: >
: > The impersonated user is shown correctly on the web service server?s
: > log, when the client on the domain is used:
: >
: > 2004-05-10 13:34:30 xx.xx.47.7 GET Service.asmx - 80 domain\username
: > xx.xx.47.84
:
Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+1.1.4322.
: 573)
: > 200 0 0
: >
: > No user is shown in the logs when a client outside the domain is used:
: >
: > 2004-05-10 13:34: xx.xx.47.7 GET Service.asmx - 80 - xx.xx.47.84
: >
:
Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+1.1.4322.
: 573)
: > 401 2 2148074254
: >
: > Can anyone tell me why this happens? Is there a reason for the two
: > behaving differently? It seems to me that DefaultCredentials does not
: > get hold of the credentials when a client from outside the domain is
: > used. Is this correct? Is there a way to get around this problem?
: >
: > Any help is appreciated
: > -uggis-
:
: