Sakya's Blog

ASP.NET Menu Control getting padded with white space on IE8

sakya_dasgupta — Sat, 11 Apr 2009 19:29:00 GMT

Technorati Tags: ASP.NET,VS 2008,IE 8,CSS 2.0

Recently I was helping this developer on a particularly interesting issue. He had an asp.net web application that had been in productions for years and worked perfectly. Now they were planning to use XHTML 1.1 instead of the previous XHTML 1.0 Transitional and target the most recent browsers, primarily IE 8.

Interestingly when they tried to use the same code that was on production in there test environment using XHTML 1.1 and tested on IE 8, the menu controls were no longer rendering as expected; but had white space padding on top and bottom of the control. It was a pretty simple basic menu control with some CSS 2.0 styling. Furthermore the solution to this was simply changing to the IE 8 compatibility mode from the browser settings. Needless to say this is not a very acceptable solution :) :)

This is when I decided to repro the issue with a just a simple menu control on a default.aspx page. And interestingly I was able to reproduce the issue very quickly; in fact even without the CSS styling we can see the issue. Now we already had a known issue with the menu control rendering in IE 8 and have an available hot fix for it – here’s an excerpt from Bertrand Roy’s blog.

http://weblogs.asp.net/bleroy/archive/2009/03/23/asp-menu-fix-for-ie8-problem-available.aspx

“It so happens that the menu control is making a bad assumption on what the default value for z-index should be. We debated this at length with the IE team, but it became clear as we did so that they were right and that we were wrong. We had to fix that.”
http://support.microsoft.com/kb/962351

So the first step was to apply the hot fix, however even after this we see the white space padding. The repro can be simply done using the following code: using a simple menu control, a div tag to form a border around it and use some basic CSS styling

<%@ Page Language="vb" AutoEventWireup="false" CodeBehind="Default.aspx.vb" Inherits="WebApplication3._Default"
Trace="false" %>

<!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">
<head runat="server">
    <link href="StyleSheet1.css" type="text/css" rel="stylesheet" />
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
        <div style="border: 1px solid #FF0000;">
      <asp:MenuID="Menu1"runat="server"BackColor="#B5C7DE"DynamicHorizontalOffset=2" Font-Names="Verdana" Font-Size="0.8em" ForeColor="#284E98" Orientation="Horizontal"
            StaticSubMenuIndent="10px" BorderStyle="None" BorderWidth="0px">
            <StaticSelectedStyle BackColor="#507CD1" />
            <StaticMenuItemStyle HorizontalPadding="5px"VerticalPadding="2px" />
            <DynamicHoverStyle BackColor="#284E98" ForeColor="White" />
            <DynamicMenuStyle BackColor="#B5C7DE" CssClass="IE8Fix"/>
            <DynamicSelectedStyle BackColor="#507CD1" />
            <DynamicMenuItemStyle HorizontalPadding="5px" VerticalPadding="2px" />
            <StaticHoverStyle BackColor="#284E98" ForeColor="White" />
            <Items>
                <asp:MenuItem ImageUrl="~/Images/TM_Payments.gif" PopOutImageUrl="~/Images/PopOutImage.gif"
                    SeparatorImageUrl="~/Images/TM_SeparatorImage.gif">
<asp:MenuItem Text="New Item" Value="New Item"></asp:MenuItem>
                    <asp:MenuItem Text="New Item" Value="New Item"></asp:MenuItem>
                </asp:MenuItem>
                <asp:MenuItem ImageUrl="~/Images/TM_ExemptionsAndSavings.gif" PopOutImageUrl="~/Images/PopOutImage.gif"
                    SeparatorImageUrl="~/Images/TM_SeparatorImage.gif"></asp:MenuItem>
            </Items>
        </asp:Menu> </div> </form></body></html>

The CSS file used: StyleSheet1.css is even simpler and is being used to get around the problem of the value of the z-index being set to auto and I ’am basically manually providing a value to it. (This is what the hot fix is for, however I like to overly protective about my controls :) )

.IE8Fix
{
z-index: 1000;
}

Now here is the funny part, I would expect it to render just perfect, but we actually get a strange white space on top of the menu control.

And as mentioned previously just changing the to the IE7 compatibility mode from the browser , everything works fine.

This is when I decided to put to use the new developer tool that ships in with the IE 8. After a lot of scratching my head, playing with the tool, comparison with IE 7 source view and a whole lot of caffeine, to my surprise I found a line of code that seemed a little strange as I did not put it in there.

This is line of code was present in both the view source from IE 8 and IE 7 , but strangely it was being rendered by IE 8 and not by IE 7. This skip link control is added by default for the menu control, and since on IE 8 it was being rendered it was taking the invisible white space on top of each menu control.

So eureka struck :) , I simply added a SkipLinkText="" to my code and vola!! everything renders just as expected......

<asp:Menu ID="Menu1" runat="server" BackColor="#B5C7DE" DynamicHorizontalOffset="2"
Font-Names="Verdana" Font-Size="0.8em" ForeColor="#284E98" Orientation="Horizontal"
StaticSubMenuIndent="10px" CssClass="mainmenu" BorderStyle="None" BorderWidth="0px"SkipLinkText="">

Here’s the perfect rendering......

Still not sure why this Skiplink control is being rendered for a default menu control. However this is a simple workaround that can be used to get over this issue...........

( BTW it does not matter whether you use XHTTP1.1 or XHTTP 1.0 Transitional )

Advanced digest authentication works from Internet Explorer however we receive multiple authentication prompts on each GET request from fire fox

sakya_dasgupta — Sat, 04 Apr 2009 19:46:00 GMT

Sometime back I was working on a particular issue which was particularly interesting . They had a website that was configured to use Advanced Digest authentication from IIS , however the peculiar behaviour was that while using fire fox they received multiple authentication prompts for every GET request. Basically a click on any link or even a mere refresh on the current page was causing an authentication prompt. Where as the expected behaviour would be a single auth prompt initially to access the website , much like basic authentication. This worked just as expected on Internet Explorer :) That is when I decided to get to the bottom on this ...

Problem Description:

Advanced digest Authentication not working on Firefox
For every new GET request using fire fox we receive a prompts for credentials . Refreshing any page also causes an authentication prompt
Using IE this works as expected with only a single prompt , no additional prompt for a new request

Resolution :

Running network monitor tool to capture traffic from both IE and fire fox while browsing to the website <http://fqdn.com/cgi-bin/admin/start.exe> . Comparing the two captures for HTTP traffic we see that in case of ,

Internet Explorer:

==============

For the first GET request there is no qop=”auth” parameter , the subsequent response looks like the following ,

Authenticate: Digest qop="auth",algorithm=MD5-sess,nonce="c2c8c9927f93c9019bc1181dc62db3a75823ffa6be50320d30831dcfaeb753d84a2a40b5ea3f62a8",charset=utf-8,realm="cdm.oclc.org"

Here onwards every new GET request no longer carries the qop=”auth” parameter however carries an additional parameter cnonce and nc .

Http: Request, GET http://fqdn.com/cgi-bin/admin/start.exe , Using Digest Authorization

Ø Authorization: Digest username="50005admin",realm="cdm.oclc.org",nonce="c2c8c9927f93c9019bc1181dc62db3a75823ffa6be50320d30831dcfaeb753d84a2a40b5ea3f62a8",uri="/cgi-bin/admin/start.exe",cnonce="6fa7bf203f140e0bde0cfa1b62b73215",nc=00000001,algorithm=MD5-sess

Command : GET ; URI: http://fqdn.com/cgi-bin/admin/index.exe

Ø Authorization: Digest username="50005admin",realm="cdm.oclc.org",nonce="c2c8c9927f93c9019bc1181dc62db3a75823ffa6be50320d30831dcfaeb753d84a2a40b5ea3f62a8",uri="/cgi-bin/admin/index.exe",cnonce="6fa7bf203f140e0bde0cfa1b62b73215",nc=00000002,algorithm=MD5-sess,

Command : GET ; URI: http://fqdn.com/cgi-bin/admin/collections.exe

Ø Authorization: Digest username="50005admin",realm="cdm.oclc.org",nonce="c2c8c9927f93c9019bc1181dc62db3a75823ffa6be50320d30831dcfaeb753d84a2a40b5ea3f62a8",uri="/cgi-bin/admin/collections.exe",cnonce="6fa7bf203f140e0bde0cfa1b62b73215",nc=00000003,algorithm=MD5

Basically the qop=”auth” is there only for the first response for all subsequent request the client sends a Client Nonce (cnonce) along with a Nonce counter (nc) since the user is already authenticated

The cnonce value is persisted and for every request only the nonce counter increments telling the server this is a new request from the same client who has been authenticated.

Mozilla Fire Fox :

=============

For the first GET request there is no qop=”auth” parameter , the subsequent response looks like the following ,

Authenticate: Digest qop="auth",algorithm=MD5-sess,nonce="a84a4bc67c93c901b9f6606b20651d47a7c3d4a5b00f09103f3b85598472f451ea8f4818e582bdcb",charset=utf-8,realm="cdm.oclc.org"

(Till here it behaves exactly like internet explorer)

Now unlike IE every new GET request contains the qop=<Blank> and the AuthData a qop=”auth” parameter and does not contain the client nonce (cnonce) , however there is a nc .

HTTP:Request, GET /cgi-bin/admin/start.exe , Using Digest Authorization

Ø Authorization: Digest username="50005admin", realm="cdm.oclc.org", nonce="a84a4bc67c93c901b9f6606b20651d47a7c3d4a5b00f09103f3b85598472f451ea8f4818e582bdcb", uri="/cgi-bin/admin/start.exe", algorithm=MD5-sess, response="17f92115fa201b3186c5a9737d777d6b", qop=

Ø AuthData: username="50005admin", realm="cdm.oclc.org", nonce="a84a4bc67c93c901b9f6606b20651d47a7c3d4a5b00f09103f3b85598472f451ea8f4818e582bdcb", uri="/cgi-bin/admin/start.exe", algorithm=MD5-sess, response="17f92115fa201b3186c5a9737d777d6b", qop="auth", nc=00

HTTP:Request, GET /cgi-bin/admin/index.exe , Using Digest Authorization

Ø Authorization: Digest username="50005admin", realm="cdm.oclc.org", nonce="a84a4bc67c93c901b9f6606b20651d47a7c3d4a5b00f09103f3b85598472f451ea8f4818e582bdcb", uri="/cgi-bin/admin/index.exe", algorithm=MD5-sess, response="979d6d56916877dda6620569f8f63a12", qop=

Ø AuthData: username="50005admin", realm="cdm.oclc.org", nonce="a84a4bc67c93c901b9f6606b20651d47a7c3d4a5b00f09103f3b85598472f451ea8f4818e582bdcb", uri="/cgi-bin/admin/index.exe", algorithm=MD5-sess, response="979d6d56916877dda6620569f8f63a12", qop="auth", nc=0000

Therefore what happens here is that every GET request has a qop=”auth” section and there is no cnonce ; hence you’ll also notice that the nonce counter (nc) never increments. As a result for every request the server fails to authenticate the client and there is a new prompt .

In short by sending a cnonce, the client could gain some assurance that its request arrived unchanged at the server. But if the qop/response/cnonce attributes got deleted by an agent in the middle, the server wouldn't know it and would just assume it was dealing with an older client. In which case, when the client eventually checks the Auth-info header's "response=" directive, the check will fail.

For information on Advanced Digest authentication follow the RFC 2069 http://en.wikipedia.org/wiki/Digest_access_authentication

Enforcing SSL 3.0 and removing weak encryption vulnerability over SSL ( IIS 6.0 and ISA )

sakya_dasgupta — Thu, 11 Dec 2008 15:12:00 GMT

Running a Custom Penetration test on IIS 6.0 server having SSL enabled may show vulnerability reports as a weak encryption on IIS . ISA server 2000 acts as proxy in front of the IIS server and also has certificate installed on it. The following is the error report generated by the Custom penetration test when we have already forced SSL 3.0 , however still have the weak encryption keys supported on the server , which may be used by attackers to exploit man in the middle like attacks on the server.

SSL Server Supports Weak Encryption Vulnerability port 443/tcp over SSL
QID: 38140
Category: General remote services
CVE ID: -
Vendor Reference: -
Bugtraq ID: -
Modified: 10/16/2008
Edited: No
THREAT:
The Secure Socket Layer (SSL) protocol allows for secure communication between a client and a server.
SSL encryption ciphers are classified based on encryption key length as follows:
HIGH - key length larger than 128 bits
MEDIUM - key length equal to 128 bits
LOW - key length smaller than 128 bits
Messages encrypted with LOW encryption ciphers are easy to decrypt. Commercial SSL servers should only support MEDIUM or HIGH strength ciphers to
guarantee transaction security.

IMPACT:

An attacker can exploit this vulnerability to decrypt secure communications without authorization.

Further the "require 128 bit Encryption " on IIS 6.0 dose not enforce strong SSL/TLS ciphers. It only ensures that 128 bit keys are used for encryption.The setting “Require 128-bit encryption” enables all 128-bit encryption algorithms, including RC2 and RC4. It also enables suites that use MD5 for integrity. Since all of them wont provide utmost security, we need to disable them separately.

Resolution

SSL/TLS supports a range of algorithms. For symmetric encryption, it can use AES, 3DES, RC2, or RC4. For message integrity, it can use MD5 or SHA. For asymmetric encryption, the algorithm is RSA.

A cipher suite is a combination of algorithms. RSA_AES_SHA is an example of a cipher suite. FIPS has approved specific cipher suites as strong. These use AES or 3DES for encryption, and SHA for integrity. FIPS does not consider other cipher suites strong.

Now why we want to enforce SSL3.0 when it is almost a completely different protocol as compared to SSL 2.0 ?

The reason being SSL2.0 as compared to SSL 3.0 is a much weaker protocol and prone to security hacks.

SSL Version 3.0 uses the BSAFE 3.0 implementation from RSA Data Security, Incorporated. BSAFE 3.0 includes a number of timing attack fixes and the SHA-1 hashing algorithm. The SHA-1 hashing algorithm is considered to be more secure than the MD5 hashing algorithm. SHA-1 allows SSL Version 3.0 to support additional cipher suites which use SHA-1 instead of MD5.

SSL Version 3.0 protocol reduces man-in-the-middle (MITM) type of attacks from occurring during SSL handshake processing. In SSL Version 2.0, it was possible, though unlikely, that a MITM attack could accomplish cipher specification weakening. Weakening the cipher could allow an unauthorized person to break the SSL session key.

A Possible scenario can be , someone intercepting the initial message in an SSL2.0 handshake can force the server and client to agree to the weakest mutually supported encryption standard. So if you are connecting to servers that support 40 bit export-weakened encryption, and transmitting sensitive info, you could have trouble

This is fixed by enforcing SSL3.0 from the registry and disabling older verions of SSL from here ,

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols

refer KB 187498

Now coming to the second error as reported by the penetration testing , this occurs since although we have SSL3.0
enforced but due to the weak encryption schemes still configured in the registry we may reach a scenarion where in we fall back on the weakest mutually supported encryption standard as mentioned earlier.

SSL encryption ciphers are classified based on encryption key length as follows:
HIGH - key length larger than 128 bits
MEDIUM - key length equal to 128 bits
LOW - key length smaller than 128 bits

To get around this we need to make the changes in the registry to restrict certain algorithms and protocols in schannel.dll
To ensure that only high encryption keys are used , we need to make the following registry changes :

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers]
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56/56]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNULL]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 128/128]
“Enabled”=dword:ffffffff
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 56/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128]
“Enabled”=dword:ffffffff
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 64/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168]
“Enabled”=dword:ffffffff

For detailed description refer KB http://support.microsoft.com/kb/245030

Note: If ISA server uses HTTPS and we want only the high encryption keys to be used we need to check
"Require 128 bit, encryption over HTTPS" in ISA (upto ISA Server 2006) , however this dose not enforce 128 bit encryption .

Refer KB : http://support.microsoft.com/kb/937293

Technorati Tags: IIS 6.0,ISA Server,SSL 3.0,schanell.dll,128 bit encryption

Process and Thread Identity in ASP.NET – A Practical Approach

sakya_dasgupta — Thu, 20 Nov 2008 00:43:56 GMT

The following scenarios establish the way the process identity and the thread identity are defined while building asp.net websites and publishing using the IIS webserver.

IIS supports the following authentication types :

· Anonymous – In this case the default credentials are of the IUSR_Machinename user .

· Integrated Windows Authentication (IWA) : This can either use NTLM challenge/Response or can be configured to use Kerberos. However for this discussion we will not delve into those details. In general while using IWA IIS authenticates using the credentials of the logged on user.

· Basic authentication

· Digest authentication

Here we are interested in the anonymous and IWA authentication types and how it impacts ASP.NET

ASP.NET Impersonation

Impersonation is when ASP.NET executes code in the context of an authenticated and authorized client. By default, ASP.NET does not use impersonation and instead executes all code using the same user account as the ASP.NET process, which is typically the ASPNET account. This is contrary to the default behavior of ASP, which uses impersonation by default. In Internet Information Services (IIS) 6, the default identity is the NetworkService account.

Eg. <identity impersonate = “true”/>

Using impersonation, ASP.NET applications can optionally execute the processing thread using the identity of the client on whose behalf they are operating. If you enable impersonation, ASP.NET can either impersonate the authenticated identity received from IIS or one specified in the application's Web.config file.

Now we’ll have a look at the scenarios inorder to get a better under standing of the process identity and the Win32 thread identity under which ASP.NET is executing.

The following code is used to get the current process identity for asp.net and the win32 thread identity rideing on top of it.

System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString()

System.Threading.Thread.CurrentPrincipal.Identity.Name.ToString()

Now lets take a look at the scenarios :

Scenario 1 : ASP.NET Website located on the local machine and IIS uses IWA . Impersonation is set as “false” .

Observation : The process identity =NT AUTHORITY\NETWORK SERVICE and the Thread identity is the default logged on users credentials

Scenario 2: ASP.NET Website located on the local machine and IIS uses IWA

Impersonation is set as “true” .

Observation : Both the Process Identity and the Thread Identity is the default logged on user credentials .

Next We’ll look at the way the process identity is affected if we place the website contents on a remote UNC share path.

Scenario 3: ASP.NET website placed on a remote share location and Impersonation is set as “false” and IIS uses IWA. In the connect as option check the box which says , Always use the authenticated users credentials when validating access to the network directory.

Observation : The process Identity = NT AUTHORITY\NETWORK SERVICE.

You may receive one or more error messages when you try to access an ASP.NET application that is hosted by using pass-through authentication in a UNC virtual directory in Internet Information Services 6.0

CAUSE

This problem occurs because ASP.NET applications are not supported when you select the Always use the authenticated user's credentials when validating access to the network directory check box in IIS 6.0.

RESOLUTION

To resolve this issue, enter a valid user name and password on the Security Credentials page in the Virtual Directory Creation Wizard when you intend to host an ASP.NET application that is located on a UNC share.

Refer KB : http://support.microsoft.com/kb/897110

Scenario 4 : ASP.NET website placed on a remote share location and Impersonation is set as “true” and IIS uses IWA. In the connect as option specify a user name and password to reach the path.

Note : The username and password specified should also be there on the folder being accessed . i.e the same user should be explicity added and the password should be in sync on that folder.

Observation : Both the Process identity and the thread identity is that of the one used to access the UNC path .

For further information visit :

http://support.microsoft.com/kb/910449

http://support.microsoft.com/kb/891031

http://msdn.microsoft.com/en-us/library/aa302393.aspx

Webdav on IIS 6.0 Troubleshooting

sakya_dasgupta — Wed, 19 Nov 2008 23:52:23 GMT

Web Distributed Authoring and Versioning (WebDAV) extends the HTTP/1.1 protocol to allow clients to publish, lock, and manage resources on the Web.

Integrated into IIS, WebDAV allows clients to do the following:

• Manipulate resources in a WebDAV publishing directory on your server. For example, users who have been assigned the correct rights can copy and move files around in a WebDAV directory.

• Modify properties associated with certain resources. For example, a user can write to and retrieve a file's property information.

• Lock and unlock resources so that multiple users can read a file concurrently. However, only one person can modify the file at a time.

• Search the content and properties of files in a WebDAV directory.

The steps for setting up a simple Webdav publishing directory can be found at the following knowledge base location : http://support.microsoft.com/kb/323470

Webdav is a pretty straight forward protocol , however there are a number of things one needs to keep in mind while configuring it and using .

In addition to the above mentioned benefits of Webdav , it comes in handy specially in scenarios where one wants to setup a secure FTP site , as this is the only alternative available on IIS 6.0 . By default FTP is not a secure protocol and the username and password are sent across as clear text, to be more specific it is a hashed value , and can be easily decoded , making it quite vulnerable . Off-course the entire question depends on whether security is a major factor or not.....which I think is quite a rhetorical question to ask.

Note : On IIS 7 We can have FTP over a secure channel (FTPS) giving it more security options... but then again that’s a completely different topic.

By-default webdav doesn’t have a security measure which we can enable with a simple click or tick , however we can couple it with Basic Authentication in IIS and SSL to make it quite secure. But I’ll discuss more on this a little later .

There can be numerous frontiers to explore on Webdav , however in this article I’ll be covering some of the most common issues with webdav configuration and share my personal experience while working on one of my recent cases.

Webdav can be accessed through one of the following webdav clients ( using Microsoft technologies) :

• Windows clients (Windows 2000 and Windows XP): Connect to a WebDAV directory by adding the directory to the list of Network Places and display the contents as if it were part of the same file system on your local computer. Once connected, you can drag and drop files, retrieve and modify file properties, and complete many other file-system tasks.

Note: As far as Windows Vista is concerned , It behaves a little differently and I’ll discuss that later in this article .

You can also connect using the command-line client (known as WebDAV Redirector). This client allows you to use existing applications across the Web and share files through firewalls and proxy servers.

• Internet Explorer (versions 5.0 and 6.0): Connect to a WebDAV directory by opening the target directory as a Web folder and complete the same file-system tasks as Windows clients.

• Microsoft Office products (Office 2000 and Office XP): Create, publish, edit, and save documents directly into a WebDAV directory through any application in Office 2000 or Office XP.

Note : After the Webdav Configurations on Windows Server 2003 testing the Webdav from the server itself is not a very good idea. It is always best practice to test its working from a client machine. After all that’s the whole intention of setting up webdav right, using from client machines .

In general the one should keep in mind the following steps while configuring Webdav on IIS 5.0 or IIS 6.0 :

· Create the webdav user account(s)

· Give the user “log on locally permissions”

· Enable Webdav from Web service Extensions (only on IIS 6.0)

· Create the content folder

· Create the website (or virtual directory) with directory browsing and write

Permissions

· Adjust “Security tab” (NTFS) permissions on the content folder

· Adjust “Web Sharing tab” settings on the content folder

· Test with browser using File > Open > open as webfolder > http://www.fqdn.com/virtdir

Note : Preliminary: If the webserver is a Windows 2000/IIS5 box, I highly recommend that
you ensure that the machine is on latest service pack and latest cumulative fixes.
This can save from many headaches as there were many functionality and security
inclusions particularly in the various service packs for Windows 2000.

Common Issues with Webdav Configuration :

1. As Mentioned earlier In IIS6, unlike IIS5, webdav must be enabled in the ISM’s “Web Service Extensions” before Webdav will ever work.

It should be (and probably will be ) mapped to c:\windows\system32\inetsrv\httpext.dll

However on a 64 bit Server make sure that the physical path for webdav from web service extensions is c:\Windows\syswow64\inetsrv\httpext.dll When the Enable32bitApponWin64 has not been set to TRUE. This can be easily checked by starting the windows task manager. If you see inetinfo.exe *32 or w3wp.exe *32 then the above mentioned switch has been set to TRUE in the IIS metabase.

Note : In IIS5 webdav will almost certainly be enabled by default. If there are problems with it working in IIS5, consider KB 241520 to see if someone disabled it in the registry (HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters > Value name: DisableWebDAV / Data type: DWORD / Value data: 1) and re-enable it by removing that key (or by setting its value to 0?). Otherwise check to see if there is a urlscan.ini which is denying webdav verbs. (A third alternative may be with appmappings and a fourth could pertain to ACLs on the httpext.dll? But that’s really getting ahead of ourselves here!) The exception for IIS6 may be that if IIS5 was upgraded to IIS6, webdav will probably be enabled by default.

2. Webdav Configured properly in the server However on tying to open as Webfolder from a

client machine we get the following error message :

Internet Explorer could not open http://www.fqdn.com /testvir as a web Folder. Would you like to see its default view instead?

Try to isolate the issue further .

· If the webdav folder is on local machine. Make sure proper NTFS permissions have been set.

· Make sure all the above mentioned steps to set up Webdav have been followed

· Try to access Webdav folder from different Client machines XP/2003 Client/Vista etc. It is observed that at times webdav related issues can be client specific.

· In case of Windows XP and Vista make sure that the Web Client Service is set to automatic and is currently started. You can configure this from Start>Run>services.msc>Web Client Service>Properties .

· Try to test Webdav from the network places and not from Internet Explorer. Make sure you delete the webdav folder that is created by default when one uses IE to test it , and then test webdav once again from network places.

3. Webdav Not working from Windows Vista Client machine :

Note : The Web Extender Client (codename Rosebud) is not shipped with Windows Vista, and WebDAV functionality in Vista is limited to the capabilities of the Web Client
service (the WebDAV redirector.) Applications written to leverage Rosebud and
previously working without issue on Windows XP machines may fail in Windows Vista.

Resolution :

=========

The additional WebDAV functionality of the Web Extender Client had been exposed
previously in Windows 2000 and Windows XP as the Web Folders component, MSDAIPP,
and was accessed in Windows 2000 via Windows Explorer and in Windows XP via the Add
Network Place Wizard. Web Folders have been not been included in Windows Vista, but
the Web Folders component is still available as part of a Microsoft Office
installation. Installing Office 2007 on a Windows Vista client experiencing Web
Extender Client-dependent connectivity failure resolves the issue.

Note on 64 bit System Compatibility :

Rosebud is a 32-bit component, so although it will install on a 64-bit operating
system, Explorer (shell, common dialogs, My Network Places, etc.) and other 64-bit
applications will not be able to use it. 64-bit applications will be limited to
leveraging the native Web Client service redirector for WebDAV. There are currently
no plans for porting this deprecated Windows component to future 64-bit versions of
the operating system.

In order to get Webdav Working Install the following update for windows vista available at http://support.microsoft.com KB 907306

Here is the Public Download Site:

http://www.microsoft.com/downloads/details.aspx?FamilyID=17c36612-632e-4c04-9382-987
622ed1d64&DisplayLang=en

4. Webdav Configured to work with Basic authentication not working from Windows Vista Client machines :

By default basic authentication is turned off in windows vista and windows 2008 box's as a security measure . Because a user's credentials can be sent in clear text and can be possibly compromised, Windows Vista and Windows XP SP2 include functionality that permits you to enable or to disable the use of Basic authentication by the DAV redirector

When Basic authentication is disabled, either the client computer uses a different authentication method (if the server supports a different authentication method), or the request fails.

Resolution:

=========

Go to the following registry location: Start> run> Regedit

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

By default the DWORD value UseBasicAuth is set to 1 in vista

Set this to a value of 2.

Restart the machine and if all other configurations are as expected webdav should be up and running using Basic Authentication.

Find the relevant information in the following KB 841215

http://support.microsoft.com/default.aspx?scid=kb;EN-US;841215

As mentioned earlier since we don’t have a secure FTP in IIS 6.0 we can set up a secure webdav using Basic Authentication. However since Basic auth passes password as a hashed value which can easily be compromised , It can be coupled with a server certificate to enhance security .

Setting Up Webdav From Network Places in Windows Vista :

Please Visit the Following Website For step by step set up instructions along With useful screenshots

http://kb.wisc.edu/luwmad/page.php?id=6280

I have tried to cover some most common configuration issues while configuring Webdav. However there can be many more areas to explore for ex. Webdav Publishing folder from a remote location etc. I’ll try to cover these topics in my next post :)