Archive for July, 2006

A couple of days ago a friend asked me a question about a problem he had with Windows Authentication and I thought I’d share some of the information about it.

They have an ASP.NET web application that have Windows authentication enabled. That application is accessing another server using an API. So far so good.

When they logged into the web application using Windows authentication, the credentials were automatically transfered and validated through IIS and the thread executing the current request was automatically impersonating using the credentials that were passed from the browser, but the call to the API within the application that accesses the other server failed.

This happens due to the fact that NTLM, the protocol that is used be default in Windows Authentication (and even used by default when installing a new domain server) does not support, due to various reasons, credentials delegation.

This means, that only the hop from the browser to the web server is supported and the credentials are not being transfered again from the web server to the other server through the API.

This will happen in every ASP.NET web application or web service that uses Windows authentication.

There is a nice post in this blog, that describes the problem as well as the possible solutions which includes (in a very short list):

  • Basic Authentication – An IIS feature that uses clear text over the wire to authenticate, which is not secure so consider using HTTPS to perform that.
  • Kerberos – a security protocol that is supported in Active Directory (Windows domains start are based on Windows 2000 and above). Kerberos is a bit annoying to configure, so it might not be the best possible solution (and sometimes your IT guys won’t even support it anyway).
  • Specify explicit credentials – This means that the second hop to the other server from the web server will always use the same predetermined fixed credentials. Sometimes you simply cannot do that, but that solely depends on your implementation.

The blog post also contains some links to knowledge base articles that can help you configure Kerberos as well as how to use explicit credentials.

There is a new WinDbg version (6.6.7.5) available here (it was released yesterday – July 18th).
You can check out some of the new stuff here.

Be careful though, the previous version had more than a few bugs and problems. Hopefully, this version fixed some (if not all) of them.

I still haven’t had much time to check it more thoroughly, but you are more then welcome to try it out, just don’t forget to report back! 🙂

Update: I’ve checked whether there is a new verison of SOS for .NET Framework and there isn’t any. There is only a new SOS version for .NET Framework 1.1 (which was compiled about 11 days ago).
Anyhow, this is kind of annoying. I’m really looking forward to get a new version of the .NET 2.0 SOS with at least all the features that were in the 1.1 version and are missing in the 2.0 version.

On my previous post about the dubious “Ambiguous match found” exception, I talked about the fact that the ASP.NET runtime is case sensitive and if you are writing in C# you better be careful about how you name your private, protected and public variables.

Not so long ago, I’ve encountered another problem which is relatively similar. It manifests itself in the runtime but it is actually related to the ASP.NET compiler.

When first accessing an ASPX page in an application after the server was started, the ASP.NET runtime will try to compile that page. One of the first steps in doing so is to parse the ASPX page and figure out what controls were placed on it. It will then create these controls and the Page object behind the page and render the page outputting the result back to the client.

When the ASP.NET runtime tries to create the various controls placed on the ASPX page, it will use the GetType function, but for some reason, it will only pass the name of the control and not its full namespace.

In my case, we had a custom user control named HtmlAnchor which was suppose to overcome a few quirks with HTML anchors in some browsers. ASP.NET already contains a control named HtmlAnchor which its full namespace is System.Web.UI.HtmlControls.HtmlAnchor.
Our control, had no namespace, since we simply created a user control in our application.

Even though we didn’t use even a single System.Web.UI.HtmlControls.HtmlAnchor, but only our custom HtmlAnchor control we got a strange error about not being able to load a certain .NET assembly which was suppose to be generated when the page first renders to produce the page’s code cache.

I fired up WinDbg and when the exception occurs, search for objects of type CompilerError by issuing:

!dumpheap -type CompilerError

This will list all CompilerError objects in the heap. After that I issued:

!do 0xXXXXXX
Where 0xXXXX is the address of the CompilerError object that I’m inspecting (!do = !dumpobject)

And inside there is a private member that contains the error text which I also dumped (using !do).

The error that I saw was that .NET cannot cast HtmlAnchor (my HtmlAnchor) to System.Web.UI.HtmlControls.HtmlAnchor.

I issued “!clrstack -p” to see the call stack and the parameters that were passed to each function and along the way there was call to GetType with the name parameter that was equal to “HtmlAnchor”.

This was the problem. For some reason .NET figured out that my HtmlAnchor is suppose to be the HtmlAnchor the resides in System.UI.HtmlControls.

As it turns out, the namespace System.UI.HtmlControls is ALWAYS included when the ASP.NET compiler compiles an ASPX page and, for some reason, request the type of the object WITHOUT its full namespace and find the wrong HtmlAnchor even though I have a different TagPrefix for my HtmlAnchor in the ASPX page.

The is a combination of a number of problems.
First, when adding a user control to an ASP.NET web application, there is no specific namespace in the file. It will eventually get the namespace of ASP.XXXX when compiled using the ASP.NET compiler like the rest of the ASCX and ASPX pages.

I haven’t checked it for user controls that are not ASCX, meaning, someone wrote a control in some DLL and does get a namespace. The difference is that when including that control on an ASPX page we do provide the exact namespace and assembly, so it might works without a problem.

Second, if the user control has the same name as any of the control that are in the System.Web.UI.HtmlControls and System.Web.UI.WebControls namespaces, they will, for some reason, get loaded in GetType instead of your controls.

Third, in the @Register tag at the top of the page, where we declare and include our user control (we include the ASCX file), there is no additional information such as namespace to help the ASP.NET compiler resolve this issue.

Conclusion:

Be careful when you name your User Controls (ASCX controls) and make sure they do not have the same name as other controls in System.Web.UI.*.

Sometimes when you have a big DataSet with elaborated relationships you might get the following error when trying to add or load data into the dataset:
Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints

Some of the causes for this error are usually “regular” violations of the foreign-key constraints, which means you are referencing a certain key that does not exist in the parent table. If that is the case, you can check this article on MSDN that explains a bit on how to resolve these issues.

If you are still having problems with your dataset and ADO.NET code, you might just want to try this little trick.
It appears that inside a DataRow there is a property called RowError.

RowError is a string value that can be set or read in numerous other occasions, but the situation in which I encountered was due to a bad relationship that was added on a table which caused the code to throw an exception at runtime. In that case the RowError property hold the exact name of the troublesome relationship.

So, how do you access it?
When you code at runtime throws an exception and you are with a debugger attached, check the following thing using the “immediate window” or Quickwatch:

myDataSet.Tables[“YourTableName”].Rows[0].RowError

Don’t forget to replace “myDataSet” with the variable name of your dataset and “YourTableName” with the table that is (probably) causing the problems.

In the case I’ve described above, this property told me exactly what is the problematic foreign-key that I had and from there I figured out what is the problematic relationship.