David
Thu Oct 07 17:32:47 CDT 2004
> I don't know what a logon type of 8 is, but I noticed that the user
> name did not match what one would expect on the local domain
> (ie, its not *exactly* IUSR_<machinename>. It seems this box
> may have gotten "renamed" after IIS was installed.
> Will this be a problem?
Renaming the computer is not a problem. IIS just needs a valid
username/password -- it doesn't care if the name is bob, IUSR_<new_machine>,
IUSR_<old_machine>, etc. However, there are plenty of broken scripts out
there that assume IIS anonymous user is named IUSR_<machinename> -- so your
machine may give them problems.
I don't know what logon type of 8 is, either, but looking it up on MSDN for
the LogonUser Win32 API explained what value were possible, a quick search
through the platform SDK for LOGON32_LOGON shows that a logon type of 8
means LOGON32_LOGON_NETWORK_CLEARTEXT, which gives sufficient context to
re-read the LogonUser API documentation.
>Also, the documentation suggests that this (IIS subauthentication)
> is not the best appraoch under IIS 6, but I didn't find a recommended
> alternative. Do you have a link to what is recommended?
There is no recommendation link because the recommended behavior is
default -- i.e. sub authentication is the alternative configuration. As
soon as you stop configuring sub authentication, the default recommended
behavior will automatically be used.
Also, on clean installations IIS6 will use the default behavior -- so you
get sub authentication only if you intentionally configured it, or you
upgraded from prior IIS version.
Your current problems seem to stem from the fact that your configured
anonymous user does not have the necessary logon type to successfully logon
to the machine -- hence IIS is failing all those requests. You either need
to use a new anonymous user that can logon to the machine, or you need to
fix the existing account. AuthDiag should detect this scenario.
Now, IIS5 tends to cover over these issues because it runs as LocalSystem
and can do whatever it wants -- but this is also insecure and easy to
exploit. IIS6 is secure and does not run as a privileged user, thus it
cannot make things automagically work -- so you need to configure everything
perfectly or else things can strangely fail. That is the way security
works.
I recommend that you migrate to IIS6 (i.e. clean install OS, then migrate
the website) instead of upgrading in place. Upgrading is a mixed bag
security-wise -- we leave some settings to old values to not break your
code, but we must change other values to secure values that may break you,
and you can hit many odd combinations that do not exist otherwise.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Bill Beacom" <BillBeacom@discussions.microsoft.com> wrote in message
news:1D555C1D-9895-4513-821A-326FB1782E08@microsoft.com...
Thanks for the tip on the tool. It seems we hadn't followed all the steps to
set up anonymous access properly. I did notice that there is an entry in the
security audit log for a logon failure, eg:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 534
Date: 10/07/2004
Time: 8:35:54 AM
User: NT AUTHORITY\SYSTEM
Computer: FTEKCWSAOMWEB01
Description:
Logon Failure:
Reason: The user has not been granted the requested
logon type at this machine
User Name: IUSR_FTEDCWSAOMWEB01
Domain: FTEKCWSAOMWEB01
Logon Type: 8
Logon Process: Advapi
Authentication Package: Negotiate
Workstation Name: FTEKCWSAOMWEB01
Caller User Name: NETWORK SERVICE
Caller Domain: NT AUTHORITY
Caller Logon ID: (0x0,0x3E4)
Caller Process ID: 3012
Transited Services: -
Source Network Address: -
Source Port: -
I don't know what a logon type of 8 is, but I noticed that the user name did
not match what one would expect on the local domain (ie, its not *exactly*
IUSR_<machinename>. It seems this box may have gotten "renamed" after IIS
was
installed. Will this be a problem? I've tried the recommended steps from the
AuthDiag tool to correctly configure anonymous access, but the problem
persists (the log above is from after following the steps to configure
subauthentication). Also, the documentation suggests that this (IIS
subauthentication) is not the best appraoch under IIS 6, but I didn't find a
recommended alternative. Do you have a link to what is recommended?
Thanks again for your help...
Bill