Re: IIS Setting prevents AD Query from working?
From: WenJun Zhang[msft] (v-wzhang_at_online.microsoft.com)
Date: 08/05/04
- Next message: Michael Dimento: "IIS5.0 Timeout problem"
- Previous message: David Wang [Msft]: "Re: CGI error The specified CGI application misbehaved by not returning a complete set of HTTP headers."
- In reply to: Lee Flight: "Re: IIS Setting prevents AD Query from working?"
- Next in thread: WenJun Zhang[msft]: "Re: IIS Setting prevents AD Query from working?"
- Reply: WenJun Zhang[msft]: "Re: IIS Setting prevents AD Query from working?"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 05 Aug 2004 02:35:12 GMT
Hi all,
> 1) the user account the user is logging on as using Intergated
windows authentication is marked in AD as "Account is trusted for
delegation".
This isn't completely proper. Generally ASP.net application is
running under a local account which isn't recognized by any other
machine in the domain. So IIS will use computer account to access the
AD resource ( <Domain>\<Computername>$ ). Therefore what we need to
do is allow the IIS computer account to delegate authenticated users'
account - In AD users and computers, the IIS computer object's
properties, select "Trust computer for delegation".
Also, in the ASP.net application's web.config, need set <identity
impersonate="true" /> . Otherwise, ASP.net is running under NETWORK
SERVICE(also a local account), then the delegation doesn't take
effect.
How To Configure an ASP.NET Application for a Delegation Scenario
http://support.microsoft.com/default.aspx?scid=kb;en-us;810572
To Patrick:
I think since you are using ASP.net other than ASP. There are several
solutions for you to choose and all are better than using Kerberos
delegation. We cannot disable NTLM auth( NTAuthenticationProviders
cannot only contain Negotiate, it's invalid ) and whether to use
Kerberos or NTLM is decided by client IE. Means when a client is
connecting via NTLM, it just fails immediately even if the delegation
is configured ok.
I think you can simply enable impersonation in the application's
web.config and specify a domain account in it. Then the user
authentication is totally controlled by IIS and nothing to do with
the ASP.net application. After a user passed the integrated auth at
IIS side, the ASP.net then runs with the domain account to query AD
--> which is simplest and also a safe solution. In this case, you
will not get any inconsistent access denied error.
INFO: Implementing Impersonation in an ASP.NET Application
http://support.microsoft.com/default.aspx?scid=kb;en-us;306158
Joe's suggestion is also a workable way. Set the <identity
impersonate /> to false and then the ASP.net application will run as
its application pool's identity in IIS6. Specify a domain account as
identity to make the application be able to query AD. The domain
account need to be added to the IIS server's IIS_WPG group and be
granted with 2 GPO permissions which NETWORK SERVICE has:
Adjust memory quotas for a process
Replace a process level token
INFO: Default Permissions and User Rights for IIS 6.0
http://support.microsoft.com/?id=812614
Let me know if you have further questions or meet any problem.
Best regards,
WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security
- Next message: Michael Dimento: "IIS5.0 Timeout problem"
- Previous message: David Wang [Msft]: "Re: CGI error The specified CGI application misbehaved by not returning a complete set of HTTP headers."
- In reply to: Lee Flight: "Re: IIS Setting prevents AD Query from working?"
- Next in thread: WenJun Zhang[msft]: "Re: IIS Setting prevents AD Query from working?"
- Reply: WenJun Zhang[msft]: "Re: IIS Setting prevents AD Query from working?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
