IE prompts for credentials when accessing an Integrated Authentication site in the Trusted Sites zone

I encountered a problem earlier today where when accessing a website set up to use Windows Integrated Authentication on my development machine across the LAN from my copy of Internet Explorer 7 (beta 3) on my test machine, Internet Explorer 7 was unexpectedly prompting me for credentials. I expected my credentials to be provided automatically via Integrated Authentication.

At first I thought that this might be an IE7-specific issue, but Googling for variations on "IE7 Integrated Authentication prompt" didn't turn up anything.

I then supposed that the issue might be a general Internet Explorer configuration issue, not specific to IE7. A Google search on "ie 'integrated authentication' prompt" turned up as its first hit a useful Microsoft Knowledge Base article, Internet Explorer May Prompt You for a Password.

Among other useful information, the article mentions that IE will prompt for credentials if it thinks the site being connected to is an Internet site (a site not located on the local LAN). This prompted me to check on my client machine IE's Tools menu | Internet Options | Security tab. In the Security tab, my web server machine was set as a member of the Trusted Sites zone.

I removed the web server machine from Trusted Sites and restarted IE. Somewhat ironically, Integrated Authentication then started working as expected; I could access the website on the server machine without being prompted for credentials. Apparently, at least in this case, IE interpreted the machine being present in the Trusted Sites zone as meaning that the machine was located out on the Internet (not internally on the LAN).

On another test machine running Windows 2003 Server that I used as a client to test the Integrated Authentication on my internal web site, I needed to not only remove my server machine from the Trusted Sites zone, but to explicitly add the machine to the Local Intranet zone before Integrated Authentication worked properly.

For both client machines, I had also verified that in the Internet Options dialog, in the Advanced tab, the "Enable Windows Integrated Authentication" checkbox was checked. (Apparently this checkbox is not checked by default on some Windows 2000 Server machines, which can cause Integrated Authentication to not work properly.)

Bounds Test v2.0.1 Released

I've posted an update, v2.0.1, to Bounds Test, my on-screen ruler utility. Updated in this release:

• The window Width and Height properties are now displayed in bold, and at the top of the properties list.
• Removed the display of window X and Y properties (as they were redundant with the Left and Top properties, which are also displayed).
• Windows XP themes/styles are now used by the application if they are supported by and enabled in the host operating system.
• Added a right-click context menu with an "About" dialog.

Get it from my utilities page, or just download it directly: BoundsTest 2.0.1 (9k)

Using XP Styles in Windows Forms 2.0 controls hosted in IE

As part of my investigation for an upcoming project at work, I've done some work to determine whether and how Windows Forms controls hosted in Internet Explorer can be made to use Windows XP Styles without having to use a .manifest file on the client machine. (We make an effort to minimize or eliminate client-based requirements for our application, so that clients can simply point their copy of IE to the app and have everything "just work.")

I found that including a call to Application.EnableVisualStyles() causes the control to be rendered using Visual Styles. For example, a simple Windows Forms 2.0 test control that I put together is normally rendered by IE 6 as show in the image on the left; with the call to Application.EnableVisualStyles() placed in the control's constructor method, the control renders like the image on the right:

XP Styles Disabled

XP Styles Enabled

This behavior may be different from previous .NET framework versions; my boss (the team's former technical lead -- a guy who knows his stuff) reported to me that he spent a fair amount of time back when we first migrated to using Windows Forms controls hosted in IE trying to get XP Styles enabled, when we were using the 1.1 .NET framework, without success.

The behavior is also directly contrary to the Microsoft documentation of the EnableVisualStyles method, which states:

This method will have no effect for controls hosted in Internet Explorer.

This makes me nervous about depending on this behavior, since Microsoft might decide to change it as a "bug fix" to make the behavior be in line with the documentation. (However, why making a change to create a difference in behavior between Windows Forms controls hosted in IE and WinForms controls hosted elsewhere would be a desirable change, I'm not sure, so perhaps no change is likely to be made.)

I also found that if the EnableVisualStyles() method is called for any particular control in a given IE window, it affects all controls on the page. (This does make sense, given that the method being called is a member of the Application object, with the application in this case being the IE instance itself.) Even controls which were rendered to the control calling the method are affected -- in the case I tested, a control which was already rendered in the IE window prior to the control calling EnableVisualStyles() repainted itself to use the XP styles, which it wasn't using when it was initially painted.

This isn't a major concern since my company's controls will be the only Windows Forms controls in any IE window where they appear, so inadvertently affecting any 3rd-party controls which might be present on the page shouldn't be an issue. (And generally, using the functionality of IE hosting WinForms controls at all seems to be a pretty rare practice!) We will need to be careful to coordinate the change among our own various controls, though, to make sure everything looks right when using the new styles.

Update 8/18/2006: This morning, I tested the same control using Internet Explorer 7 (beta 3), and it also does display the XP styles/themes. (I did hit a snag where at first, I thought that it wasn't working in IE7; however, this was because the test machine where IE7 was installed was set to have XP styles disabled OS-wide. When I enabled XP styles in the operating system display settings, the control as displayed in the IE7 window immediately updated to use the XP styles.)

IE doesn't respect set-only properties in hosted Windows Forms controls

While working on a simple Windows Forms control to determine how Windows XP styles are supported in Windows Forms 2.0 controls hosted in Internet Explorer -- more on that later -- I found that Internet Explorer 6 doesn't respect public properties of hosted/embedded controls that define a "set" but not a "get".

I had a property like this in my test control:

public bool UseRedBackgroundColor
{
  set
  {
    if (value == true)
    {
      this.BackColor = Color.Red;
    }
  }
}

I had a param set in the object tag in my test HTML page to set the property to true, but the control didn't render with the red background:

<object id="XPTest" name="XPTest"
classid="http:/webtest/XPStylesTest.dll
#XPStylesTest.XPStylesTest"
    width="158" 
    height="250">
  <param name="UseRedBackgroundColor" value="True" />
</object>

I changed my public property to have a "get" section, and after a rebuild of the project and a reopen of IE, the control rendered with a red background as expected:

public bool UseRedBackgroundColor
{
  get
  {
    return (this.BackColor == Color.Red);
  }
  set
  {
    if (value == true)
    {
      this.BackColor = Color.Red;
    }
  }
}

So if a public property of a Windows Forms control hosted in IE isn't being activated as expected, check to make sure that a "get" section has been defined for the property.

Avoid being prompted for credentials when accessing Windows Integrated Authentication sites using Firefox

I recently authored a simple ASP.NET internal website at my office to act as a repository for proposed enhancements for an upcoming release of our product. (Visual Studio .NET 2005 made authoring the site really quick and easy, such that the small amount of dev time I needed to put in to create the site was worth the gain in usability over a solution like Excel or Access.)

Since only internal employees would be using the site, I decided to set it up to use the Windows Integrated Authentication provided by IIS 5, so users of the site would automatically be logged in using their domain credentials (rather than being prompted for a set of credentials).

This worked great when accessing the site in Internet Explorer. However, when using Firefox, I would get prompted by Firefox for a set of credentials when first accessing the site. Entering my domain username and password did allow me to access the site successfully.

I wanted to avoid the login prompt with Firefox, so I Googled for firefox integrated authentication prompt. This turned up a couple of good results that pointed me to the solution:

• In the Firefox Location bar, type about:config and press enter.
• In the Filter bar that appears, type Network.automatic-ntlm-auth.trusted-uris and press enter.
• Under "Preference Name", double-click on Network.automatic-ntlm-auth.trusted-uris, and enter the name of the web server machine in the dialog that appears.

Now users are able to access the site without being prompted for credentials -- Firefox uses Integrated Authentication and automatically uses the user's domain credentials to log in.