Archive

Posts Tagged ‘bug’

Client certificate mapping in IIS 7 / 7.5 and impersonation

Recently, when migrating an application that uses client certificate authentication to IIS 7, we noticed that ASP.NET impersonation stopped working.

Client was authenticated properly, but connection to database server was being established with machine account (DOMAIN\SERVERNAME$). We didn’t find any issue in the configuration, so we raised the case with Microsoft support.

It turns out one of IIS 7 / 7.5 default configuration files has a bug. The file is called C:\Windows\System32\inetsrv\config\schema\IIS_schema.xml, and under the following section there are wrong enum entries:

<sectionSchema name="system.webServer/security/authentication/iisClientCertificateMappingAuthentication">
<attribute name="logonMethod" type="enum" defaultValue="ClearText">
<enum name="Interactive" value="0" />
<enum name="Batch" value="1" />
<enum name="Network" value="2" />
<enum name="ClearText" value="3" />
</attribute>
</sectionSchema>

And that causes IIS to use wrong logonMethod when logging in with an impersonated certificate-mapped account. The correct values to be set there are:

<sectionSchema name="system.webServer/security/authentication/iisClientCertificateMappingAuthentication">
<attribute name="logonMethod" type="enum" defaultValue="ClearText">
<enum name="Interactive" value="2" />
<enum name="Batch" value="4" />
<enum name="Network" value="3" />
<enum name="ClearText" value="8" />
</attribute>
</sectionSchema>

We set logonMethod=ClearText but as the enum entry was originally ‘3’ this told IIS to actually use the Network Token method (the real value of ‘3’) – which does not allow for the authentication mechanism we require (i.e. Kerberos delegation to a service on another server). Changing the enums to their correct value resolved the issue.

Microsoft probably won’t release a fix for that, so you’ll have to update this schema file on your own.

Categories: IIS Tags: , ,

Unexpected IIS stop

September 24th, 2010 No comments

We had a weird case some time ago on one of our Windows 2003 server. After we made changes to IIS configuration, more specifically – one virtual folder – the whole IIS stopped. This of course caused outage for some applications, some were switched over to secondary server by load balancer.

User making the change said he didn’t do a thing to whole IIS, only made changes in one virtual folder and recycled its application pool. Moreover, he checked other applications’ accessibility after making this change. All was fine.

What we cound find in the logs was:

Event Type: Information
Event Source: ASP.NET 2.0.50727.0
Event Category: None
Event ID: 1023
Date: Date
Time: Time
User: N/A
Computer: Web server name
Description:
Restarting W3SVC

That directed us to the following Microsoft KB article: If you make some changes to the ASP.NET 2.0 Web site properties and you click the ASP.NET tab in IIS Manager, the W3SVC service may be restarted unexpectedly. It turns out that if you make changes to a virtual folder, and click the ASP.NET tab, IIS can restart itself. What’s more, it does it not immediately, but after some short amount of time.

And in our case, IIS did not restart. It stopped and then couldn’t start for some reason. Simple iisreset /start did the job, but the idea of webserver stopping itself when it wants is hillarious.

Categories: IIS Tags: , ,

Nesting FORM tags in (X)HTML

Due to ASP.NET’s requirements with regards to server side controls being in one big FORM tag, I started looking at nesting FORM tags in one (X)HTML document.

Formalities

First, let’s have a look at the official documents.

HTML 4 specification says
A form can contain text and markup (paragraphs, lists, etc.) in addition to form controls.

DTD says that FORM element can contain aby block element apart from another FORM
<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT | BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form -->

However, following the nesting path, there should be no problem in using some block element and nesting another FORM within that. Let’s take DIV for example.
<!ELEMENT DIV - - (%flow;)* -- generic language/style container -->
<!ENTITY % flow "%block; | %inline;">

We can see that DTD officially forbids only nesting FORM directly within another FORM. It doesn’t say anything about nesting FORMs within block elements, within other FORMs, or even deeper within the DOM tree.

But let’s see how does it work in the real world.

Experiments

Let’s try this practically. We’ll use the standard W3 validator and Firefox DOM inspector to examine site content at each step.

Attempt 1 – the obvious

First, we’ll use a simple XHTML document with one FORM tag.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
      </fieldset>
    </form>
  </body>
</html>

Of course, validator says it’s a correct document.

Within the DOM tree, we can see our FORM successfully.

Attempt 2 – wrong

Now, let’s add another FORM within the first one

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
      </fieldset>
      <form action="#" method="post" id="inner-form-1">
        <fieldset>
          <input type="text" id="inner1-input" name="inner1-input"/>
          <input type="submit" id="inner1-submit" value="Submit inner form 1"/>
        </fieldset>
      </form>
    </form>
  </body>
</html>

As expected, validator says it’s incorrect – true, we cannot nest FORM directly within a FORM.

If we look at the DOM tree in a browser, we see how the browser is trying to glue both FORMs together

Attempt 3 – theoretically correct

Now, let’s put the inner FORM within a block level container. This markup is correct according to specification and DTD.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
        <form action="#" method="post" id="inner-form-1">
          <fieldset>
            <input type="text" id="inner1-input" name="inner1-input"/>
            <input type="submit" id="inner1-submit" value="Submit inner form 1"/>
          </fieldset>
        </form>
      </fieldset>
    </form>
  </body>
</html>

Validator indeed says the document is OK.

Let’s try the DOM inspector.

What happens? The browser is still gluing the two forms together, although the markup is correct. This is something, that should not happen. Let’s experiment a bit more

Attempt 4 – the quirks begin

Now, let’s add some more properly marked up nested forms and see what happens.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
        <form action="#" method="post" id="inner-form-1">
          <fieldset>
            <input type="text" id="inner1-input" name="inner1-input"/>
            <input type="submit" id="inner1-submit" value="Submit inner form 1"/>
          </fieldset>
        </form>
        <form action="#" method="post" id="inner-form-2">
          <fieldset>
            <input type="text" id="inner2-input" name="inner2-input"/>
            <input type="submit" id="inner2-submit" value="Submit inner form 2"/>
          </fieldset>
        </form>
        <form action="#" method="post" id="inner-form-3">
          <fieldset>
            <input type="text" id="inner3-input" name="inner3-input"/>
            <input type="submit" id="inner3-submit" value="Submit inner form 3"/>
          </fieldset>
        </form>
        <form action="#" method="post" id="inner-form-4">
          <fieldset>
            <input type="text" id="inner4-input" name="inner4-input"/>
            <input type="submit" id="inner4-submit" value="Submit inner form 4"/>
          </fieldset>
        </form>
      </fieldset>
    </form>
  </body>
</html>

Again – validator says it’s fine.

Let’s see what DOM insepctor tells us this time.
.
Now we can see some weird behaviour here. The browser is gluing the first inner form, but processes the other forms properly

Conclusions

Despite the fact that nesting forms is theoretically possible, browsers do not render it properly. A workaround needs to be used. On the other hand, specifications can be updated to clearly prohibit nesting FORM tags.

Workaround

The basic workaround is to nest additional, unnecessary form, just for this bug’s sake. Say, for 1 main and 2 nested forms, you would create such document then

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>Test doc</title>
  </head>
  <body>
    <form action="#" method="post" id="container-form">
      <fieldset>
        <input type="text" id="container-input" name="container-input"/>
        <input type="submit" id="container-submit" value="Submit container form"/>
        <form action="#" method="post" id="nested-form-bug"></form>
        <form action="#" method="post" id="inner-form-1">
          <fieldset>
            <input type="text" id="inner1-input" name="inner1-input"/>
            <input type="submit" id="inner1-submit" value="Submit inner form 1"/>
          </fieldset>
        </form>
        <form action="#" method="post" id="inner-form-2">
          <fieldset>
            <input type="text" id="inner2-input" name="inner2-input"/>
            <input type="submit" id="inner2-submit" value="Submit inner form 2"/>
          </fieldset>
        </form>
      </fieldset>
    </form>
  </body>
</html>

Then you just have to hide the dummy form

#nested-form-bug {
	position: absolute !important;
	left: -2500px !important;
	width: 20px !important;
}

Validator still treats is as valid document.

In the DOM tree, we get what we want – 3 forms, 2 nested into the container form.

To do

  1. A validator bug is already reported.
  2. Check if it’s browser-consistent
  3. Check what browsers are sending to server for such nested forms
Categories: Internet Tags: , , , ,

It’s a feature, it’s not a bug

OK, I know all of you heard this once or twice. Or even said that sometimes, maybe to cover up some bug, maybe because it was true. But I think there should be some border, after which you don’t say that maic phrase anymore. The “IT-guy” inside you (AKA conscience in the real world) should start screaming that this is not right. And that it went too far. But he didn’t, at least for the ones designing and supporting FireWire.

See – FireWire allows DMA from one device to another. Which of course can be used to do some bad things, like bypassing authentication or getting BIOS passwords. Which was reported to Microsoft 2 years ago (other OSes are affected too, but it’s always better seen to bash Microsoft than Open Source). Who, in turn, said the famous words “It’s a feature, it’s not a bug” and did nothing.

Well… when you can just unlock a working desktop without a password, I would say this is far behind the border. I would feel this in my guts. But the Microsoft guys must be thick-skined.

Bug versus Feature picture

Categories: IT Tags: , , ,