Chris
Tue May 30 23:47:41 CDT 2006
Taken from Davig Wang's Blog..
http://blogs.msdn.com/david.wang/archive/2005/07/14/HOWTO_Diagnose_IIS_401_Access_Denied.aspx
401.1 Denied by Invalid User Credentials
This error indicates that IIS failed to obtain an NT user token with which
to execute the request.
In a nutshell, IIS expects to have a NT user token at the end of
Authentication (even anonymous authentication - see this URL for details),
and if this does not happen, you get 401.1.
Some common causes include:
a.. The client gave the wrong username/password (including none at all).
This could be from incorrect cached auto-login attempt by the browser, or
from a user login dialog from the browser.
b.. Invalid Kerberos configuration - on IIS6, if you have a customized
Application Pool Identity AND Integrated Authentication is used AND the web
server is in a domain, you will mysteriously get 401.1 unless you configure
SETSPN *or* change Integrated Authentication to favor NTLM. See the
following URLs on Application Pool Identity, Integrated Authentication in
IIS, and Constrained Delegation configuration as well as this URL on
additional Kerberos-related troubleshooting for more information
c.. You enabled Anonymous authentication, yet you still get 401.1 for all
requests. One common cause is if the configured anonymous user credentials
stored in the IIS metabase configuration file is DIFFERENT than the user
principle's credentials in reality (i.e. mismatched password). In all cases,
the preferred solution is to manually synchronize the username/password of
the anonymous user principle in IIS with that of the real user principle. I
have seen many amazing variations of this cause, including:
a.. For testing purposes, the user types in his/her OWN
username/password as anonymous user credentials at some point in the past
and forgets about it. Later, when password policy forces them to change
their password, the anonymous user credentials stored in IIS configuration
is now mismatched with reality. On subsequent anonymous requests, IIS fails
to login and obtain a NT user token for anonymous authentication and fails
with 401.1, and it looks like IIS is just plain buggy and could not even
support anonymous authentication.
b.. I have also seen the reverse happen - user configures IIS to use
their username/password as anonymous user, and when they changed their
password, web server traffic quickly causes IIS to incorrectly login with
wrong user credentials too many times, causing their user account to be
locked out. These users now complain that their user account is mysteriously
getting locked out as soon as it is unlocked, even before they log in
anywhere.
c.. On upgrading from IIS 5 to IIS 6, IIS Sub Authentication (i.e. the
"allow IIS to control anonymous user's password" feature) is enabled by
default for compatibility. This allows IIS to log in the anonymous user
principle without actually keeping the user credentials in sync, and
anonymous authentication looks good while in IIS 5 Compatibility Mode.
However, as soon as you switch into IIS 6 Worker Process Isolation Mode, Sub
Authentication is disabled because it requires a privileged process identity
like Local System (which is a known and quite unnecessary security risk for
the lowly purpose of password sync). This means that IIS 6 now tries to log
in the anonymous user credentials stored in the metabase, which has probably
NEVER been kept in sync with reality through the upgrade... and you now get
401.1 for every single anonymous request. To a casual user, it looks like
switching into IIS 6's native mode simply breaks anonymous authentication
and the rest of the website.
d.. The server has been reconfigured to deny necessary login privileges
for the authenticating user or its containing group (either anonymous or
through some authentication protocol). This can be done through automated
re-application of Group Policy for domain members, DCPROMO to/from Domain
Controller, or static application of security templates. What ends up
happening is that the server-side reconfiguration may remove Local/Remote
Login rights for that user, impose new restrictions (like Login hours, Logon
type), etc... preventing IIS from successfully logging in the user to
execute requests and resulting in 401.1.
e.. Your event log could be full for some reason - see KB 832981.
--
Cheers
Chris Crowe [IIS MVP 1997 -> 2006]
http://blog.crowe.co.nz
------------------------------------------------
"Paras Sharma" <paras_sharma@persistent.co.in> wrote in message
news:%23Dyg$g7gGHA.3984@TK2MSFTNGP02.phx.gbl...
> Hi,
>
> We are hosting our site containing simple html pages and fw asp.net pages
> on "Windows Server 2003 Web Edition". using IIS 6.0
> All the web pages are copied under "c:\inetpub\wwwroot " directory.
>
> Under the directory security tab, under authentication methods, anonymous
> access is enabled, with no other option for authentication selected.
>
> When we try to open the website using
http://localhost or
>
http://localhost/index.html it does not open up the page and following
> error message is displayed.
>
> You are not authorized to view this page
> You do not have permission to view this directory or page using the
> credentials that you supplied.
> HTTP Error 401.1 - Unauthorized: Access is denied due to invalid
> credentials.
> Internet Information Services (IIS)
>
> Seeking for urgent help. We have tried evrything so far, but no luck.
>
> Thanks & Regards
> Paras Sharma
>