Previous Next

• 01-29-2008, 7:45 AM

  jhaylock Joined on 01-29-2008, 11:34 AM UK Posts 7

  Unusual Authentication Issue Reply Contact I have had an annoying authentication problem which I have been tracking down for 2 days now. Although I have now resolved the issue, I really don't understand what was happening, so I'm hoping someone might be able to shed some light on it. The web servers are all Windows Server 2003 running an in-house developed web application which is a combination of ASP.NET and ASP classic code. The problem manifest itself as about 30+ login failure audits (Event ID's 529,539 & 680) in the security log every hour. The delivery of the web app seemed to be unaffected but I felt I had to investigate and find the source of this issue. Here is an example of one of the failure audit events logged: Logon Failure:   Reason:  Unknown user name or bad password   User Name: sa_axbo2_iis   Domain:  XXXX   Logon Type: 8   Logon Process: Advapi    Authentication Package: Negotiate   Workstation Name: XXXX   Caller User Name: NETWORK SERVICE   Caller Domain: NT AUTHORITY   Caller Logon ID: (0x0,0x3E4)   Caller Process ID: 2956   Transited Services: -   Source Network Address: -   Source Port: - After tracing back the PID's from a number of logs I found that they weren't confined to a single vdir or app pool but occurred across several. The puzzling thing is that all the app pools use the Network Service identity and all the vdirs have integrated windows authentication enabled and anonymous access disabled. I searched google long and hard for solutions but very little seemed to fit with what I was seeing. Eventually I ran cscript adsutil.vbs find /anonymoususerpass to reveal which folders had any anonymous user attributes and checked these folders using metabase explorer. Some of these folders had anonymoususername attributes which matched the one logged in the failure audits. It would appear that despite anonymous access disabled, these credentials stored in the metabase were being used by some processes. I know it sounds far fetched, but when I deleted these credentials from the metabase, the failure audits stopped immediately. Again, this doesn't seem to have had any effect on the delivery of the web app. So, I guess my question is why are these anonymous user credentials being used when they are quite clearly disabled in IIS Manager? Can anyone help me out here? I hate to solve a problem (even a minor, low impact one) and not understand what was going on. Thanks for reading this.  Joel Haylock

• 01-29-2008, 7:54 AM

  In reply to

  tomkmvp Joined on 03-20-2003, 10:27 AM Lawrenceville, NJ Posts 4,078	Re: Unusual Authentication Issue Reply Contact I'm taking a wild guess here, but the first browser request in a client session is always anonymous, so IIS attempts to use the anonymous account assigned for the resource. Tom Kaminski IIS MVP http://mvp.support.microsoft.com/ http://blogs.iis.net/tomkmvp/ http://www.linkedin.com/pub/8/690/408 http://www.bluesrepublic.org/

• 01-29-2008, 9:59 AM

  In reply to

  jhaylock Joined on 01-29-2008, 11:34 AM UK Posts 7	Re: Unusual Authentication Issue Reply Contact I'm told that all our clients, who incidentally are all on our local intranet, use IE7 which has been configured to use the highest level of authentication first. Besides which anonymous access is disabled on all the IIS folders concerned.

• 01-29-2008, 5:22 PM

  In reply to

  tomkmvp Joined on 03-20-2003, 10:27 AM Lawrenceville, NJ Posts 4,078

  Re: Unusual Authentication Issue Reply Contact From http://support.microsoft.com/kb/264921: Orders of precedence: When the browser makes a request, it always considers the first request to be Anonymous. Therefore, it does not send any credentials. If the server does not accept Anonymous or if the Anonymous user account set on the server does not have permissions to the file being requested, the IIS server responds with an "Access Denied" error message and sends a list of the authentication types that are supported by using one of the following scenarios: • If Windows Integrated is the only supported method (or if Anonymous fails), then the browser must support this method to communicate with the server. If this fails, the server does not try any of the other methods. • If Basic is the only supported method (or if Anonymous fails), then a dialog box appears in the to get the credentials, and then passes these to the server. It attempts to send the credentials up to three times. If these all fail, the browser does not connect to the server. • If both Basic and Windows Integrated are supported, the browser determines which method is used. If the browser supports Kerberos or Windows NT Challenge/Response, it uses this method. It does not fall back to Basic. If Windows NT Challenge/Response and Kerberos are not supported, the browser uses Basic, Digest, or Fortezza if it supports these. The order of precedence here is Basic, Digest, and then Fortezza.  You can verify this by checking the IIS log file.  Do you see an initial anonymous request? Which setting in IE 7 tells it to use the highest level first? Tom Kaminski IIS MVP http://mvp.support.microsoft.com/ http://blogs.iis.net/tomkmvp/ http://www.linkedin.com/pub/8/690/408 http://www.bluesrepublic.org/

• 01-30-2008, 6:42 AM

  In reply to

  jhaylock Joined on 01-29-2008, 11:34 AM UK Posts 7

  Re: Unusual Authentication Issue Reply Contact Okay, looks like I was thrown a red-herring with that IE7 info, can't find any references to it anywhere. We do get the initial anonymous requests in the IIS log, they are also show up as failure audits in the security log. However, and this is the key point, the failure audits contain the details of the user accessing the resource which is exactly what I would expect. In the previously mentioned scenario the details being logged were a service account that had previously been entered for anonymous access but then anonymous access was disabled. These credentials remained in the metabase and when I manually removed them (using metabase explorer) the failure audits reverted to containing the actual user's details. Thanks for your time on this.

• 04-11-2008, 4:33 AM

  In reply to

  AndyIIS Joined on 04-11-2008, 4:28 AM Posts 1

  Re: Unusual Authentication Issue Reply Contact I suffered a similar problem, although with a slightly more complex setup. Authentication to the website, using NTLM, worked fine. But an ASP script then queried a backend resource (LDAP directory in this case). For this impersonation/delegation to work, Kerberos would have to be used. The server, client, users, etc, are all in a Windows 2000 domain (well, Windows 2003 domain running in functional level of 2000); the webserver is running IIS6 and the client Windows XP SP2. With full auditing enabled, even though security on the website was set to Integrated Windows Auth only, I was getting these Event Logs:     Logon Failure:      Reason:        Unknown user name or bad password      User Name:    IUSR_xxxxxx      Domain:        xxxxxx      Logon Type:    8      Logon Process:    Advapi       Authentication Package:    Negotiate      Workstation Name:    xxxxxxx      Caller User Name:    NETWORK SERVICE      Caller Domain:    NT AUTHORITY Where xxxxxx was the server name (not domain name). The Application Pool identity was set to NETWORK SERVICE, so my interpretation is that the Application Pool is trying to query the backend resource using an account previously configured to be the Anonymous Logon. I confirmed this by enabling anonymous access and setting it to run as a specific domain user; restarted IIS then disabled anonymous access (leaving only Integrated Windows Auth). I then got the same logon failure, but the username now showed the domain user, not the IUSR account. I can understand what IIS is trying to do, but as the website is set to ONLY use Integrated Windows Auth, this functionality is undesirable. And doesn't help, because it is always going to fail when using the IUSR account to authenticate against a domain resource. I managed to prevent this from happening by reconfiguring the website to only use Kerberos: cscript adsutil.vbs set w3svc/1/NTAuthenticationProviders "Kerberos" Unfortunately, that didn't help me, as I now get 401.2 errors!!!   Andy

  Tags: authenticationIIS Authentication Guest accountwindows authenticationdomain securityAuthentication new Thread in IIS worker processiis 6