Re: application pool custom identity
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 02/08/04
- Next message: Mike: "Win2000SP4 failure"
- Previous message: Aaron: "Limit CPU resource"
- In reply to: William F. Robertson, Jr.: "application pool custom identity"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 7 Feb 2004 18:06:34 -0800
This is a FAQ and explained in IIS documentation (both on-CD and MSDN) under
how to set up configurable AppPool Identity. I think there is a KB as well.
The basic problem is that when you select "Integrated Authentication", by
default, it means "try Kerberos, and if it doesn't work, try NTLM".
Kerberos becomes a possibility when the web server is in a Domain, while
NTLM works either way.
The problem happens when the browser/server selects Kerberos authentication,
but you don't have it set up correctly. By default, Network Service and
LocalSystem credentials will work for Kerberos; custom AppPool Identity
requires an additional configuration step.
Thus, the reason it works on your dev server is probably because it's not
joined to a domain, hence you are using NTLM when "Integrated
Authentication" is enabled, and everything works.
The reason it's not working on your intranet server is probably because it's
joined to a domain and is by default configured to use Kerberos prior to
NTLM, and Kerberos with custom AppPool identity requires an additional
configuration step which you did not do.
So, the question for you to decide is: Do you want to use Kerberos or NTLM
authentication?
- If you want to use Kerberos, read this URL (you need to be a domain admin
to do the changes):
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/ca_cfgwrkridentity.asp
- If you want to use NTLM, type this at the command prompt (the URL also
gives this info):
CSCRIPT %SYSTEMDRIVE%\inetpub\AdminScripts\adsutil.vbs SET
W3SVC/NTAuthenticationProviders NTLM
BTW, based on your description, you may want to investigate URL
Authorization (introduced in Windows Server 2003).
What you are doing is a "many-to-one" mapping of user credentials for
authentication, but "many-to-many" mapping for authorization. IIS6 defaults
to "many-to-many" mapping for both authentication and authorization (most
straight-forward, top-down model where IIS6 merely "pass-thru" the
responsibilities). The vdir based solution using anonymous user credentials
is a "many-to-one" mapping for authentication and authorization (and to get
"many-to-many" authorization, you add more vdirs).
URL Authorization uses "many-to-one" for authentication and then allows
customizable and extensible "many-to-many" mapping for authorization.
Identities are authenticated up front in the usual manner, but on the
back-end, it establishes a trusted computing base for its authorized
identity.
It is essentially what you are doing (you chose aspnet as your authorized
identity, which may/not be a good thing), except it's a framework Microsoft
has designed, secured, and is going to be supporting and carrying forward.
-- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // "William F. Robertson, Jr." <wfrobertson@kpmg.com> wrote in message news:OHL6gnO7DHA.452@TK2MSFTNGP11.phx.gbl... I have a Windows 2003 Web Edition (IIS 6.0) server that host my intrAnet site. We are using only NT integrated authentication. When the AppPool identity is set to Network Service (default) everything works fine. But we are trying to use the aspnet account so the web application will have access to the directories on another machine. Currently we are using Virtual directories to link to the various docs on the file server. We would like to move away from virtual directories (too diffifult to maintain security 15,000+ user) and have the application determine what files they can and can not see. When we change the identity of the AppPool to aspnet (setting the password and created a local user account on the file server with matching username and password) all the users are prompted with the NT login screen asking for their username, password, and domain. My development group is not experiencing this problem, and I suspect it is because we are all administrators on the machine. All other users are prompted for the username and password. When they provide their domain username/password it gives them a 401.1 error invalid credentials. When I try to login with my username and password from their machine, it is giving me the same 401.1 error. The NTFS permissions on web directory are IIS_WPG everything except write and full control, Everyone group, and US\Domain Users. I have been searching this problem for quite some time now, and we are unable to roll the security "enhancements" out because we can not change the application pool identity over. Any ideas? If you need more information, please post and I will respond with any information you need. Thanks, bill
- Next message: Mike: "Win2000SP4 failure"
- Previous message: Aaron: "Limit CPU resource"
- In reply to: William F. Robertson, Jr.: "application pool custom identity"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
