Thanks for replying. Can I just clarify one thing: the web user is already
successful in retrieving information from AD. Doesn't that mean he is
already authenticated?
kk
It is most likely that authentication was successful as something, although
that is not necessarily true. However, if impersonation was not enabled in
web.config, that would mean that you are authenticating as the process
account instead of the account of the authenticated browser user. You can
find out the account you are attempting to use by examining the value
returned by System.Security.Principal.WindowsIdentity.GetCurrent().Name.
I say "not necessarily" here because it depends on a bunch of factors. With
Win2K3+ AD, authentication is required by default to perform any operations.
You get an "operations error" is you attempt an operation such as a search
and are not authenticated. However, that can be disabled. If using Win2K
AD, authentication is not required by default, so if you accidentally
authenticate as anonymous you can still perform some operations. However,
you usually can't see much in the directory because anonymous users don't
have much read access. Once again though, those permissions can all be
changed as well.
So, the bottom line is that without knowing all the details of both your app
and your AD infrastructure, I can't tell you for sure what is happening. I
can say for sure that Kerberos delegation IS required for the web app to
forward the credentials of the user authenticated via IWA to a remote
resource.

Signature
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
> Thanks for replying. Can I just clarify one thing: the web user is
> already
[quoted text clipped - 15 lines]
>> Joe K.
>> --
K Kong - 10 May 2008 16:04 GMT
Thank you. I understand now. The browser is having the credentials of
userA. The web server authenticates against some domain controller that the
browser is indeed userA. But the web server is still running as NT
AUTHORITY\NETWORK SERVICE. The mobile number request is retrieved by NETWORK
SERVICE, which is permitted. Earlier I was mistaken that the credentials of
userA are passed through to the domain controller. That requires Kerberos
delegation as you have pointed out. And from what I read, Kerberos delegation
requires the domain administrators to come in and permit trust. So it's not
something I could spring a surprise to everyone in the company. :(
While we are on this, what is NT AUTHORITY\NETWORK SERVICE? I can't find
the NT AUTHORITY folder nor the user NETWORK SERVICE in ADUC although it is
available when I am assigning access rights to a file.
THanks.
> It is most likely that authentication was successful as something, although
> that is not necessarily true. However, if impersonation was not enabled in
[quoted text clipped - 18 lines]
> forward the credentials of the user authenticated via IWA to a remote
> resource.
Joe Kaplan - 11 May 2008 17:30 GMT
NETWORK SERVICE is a built-in account introduced as of WinXP that it used to
run services. It has a counterpart called LOCAL SERVICE. They are both
intended to be used instead of the SYSTEM account for services that do not
need full system privileges as this reduces the attack surface of the
machine.
The key difference between network service and local service is that network
service has network credentials (like the system account) and local service
does not. Thus when network service (or system) access the network, they
use the credentials of the machine account. For a domain joined machine,
this the domain computer account for the machine.
So, when you are not impersonating (basically just using the IIS process/app
pool identity) to access the directory, the net result is that your query to
AD executes with the privileges of the computer account which generally has
the same read privileges of a normal user.
HTH,
Joe K.

Signature
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
> Thank you. I understand now. The browser is having the credentials of
> userA. The web server authenticates against some domain controller that
[quoted text clipped - 50 lines]
>> forward the credentials of the user authenticated via IWA to a remote
>> resource.