Microsoft Windows WebDAV Client does not support Server Name Indication (SNI)

“\\syXXXXXXXXXXXXX.ro@SSL\DavWWWRoot is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. A device attached to the system is not functioning.”
\\syXXXXXXXXXXXXX.ro@SSL\DavWWWRoot is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. A device attached to the system is not functioning.

Recently on one of my SharePoint farms I noticed the “Open with Explorer” is not working. After couple of minutes of digging into the settings and performing network traffic captures I realized is not the SharePoint farm fault. In fact is the Microsoft Windows WebDAV Client who’s not capable to handle the Server Name Indication (SNI).

From Wikipedia: “Server Name Indication (SNI) is an extension to the TLS protocol that indicates to what hostname the client is attempting to connect at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 virtual hosting for HTTPS.”

When you have only one IP address available, you host multiple domains, multiple services and all of the communication traffic must be encrypted, then the only solution is to use Server Name Indication (SNI).

Let’s start with what IETF (Internet Engineering Task Force) RFCs are saying about Server Name Indication:
RFC 3546 - Transport Layer Security (TLS) Extensions (June 2003)
RFC 4366 - Transport Layer Security (TLS) Extensions (April 2006)
RFC 6066 - Transport Layer Security (TLS) Extensions: Extension Definitions (January 2011)
“TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting.  It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple ‘virtual’ servers at a single underlying network address.

In order to provide any of the server names, clients MAY include an extension of type “server_name” in the (extended) client hello.  The “extension_data” field of this extension SHALL contain “ServerNameList”

A server that receives a client hello containing the “server_name” extension MAY use the information contained in the extension to guide its selection of an appropriate certificate to return to the client, and/or other aspects of security policy. In this event, the server SHALL include an extension of type “server_name” in the (extended) server hello. The “extension_data” field of this extension SHALL be empty.”

According with the latest update (RFC 6066 - Transport Layer Security (TLS) Extensions: Extension Definitions), the client has an important role – to include an extension of type “server_name” that will help the server to identify the appropriate certificate that will be used to secure the connections. If the client doesn’t provide this “server_name” extension, the server will not know what certificate to use and most likely will reply with a default one (which could be not issued for the FQDN the client is connecting to – case in which the communication channel should not be trusted).

SNI is not a recent extension. It was mentioned since June 2003 by the RFC 3546 - Transport Layer Security (TLS) Extensions. However not all the clients (majority of them web browsers) are compliant with SNI. This is a sad. Why does the software companies are not really taking serious these standards?

Microsoft Internet Explorer is SNI compliant starting with Microsoft Windows Vista and Internet Explorer 7.
I highlighted the key sections from the RFC, now let’s see how IE 11 and Microsoft Windows WebDAV behave with SNI. This will demystify the problem.

IE11 and IIS 8 (with/without SNI)

Request & response between IE 11 and IIS 8 (without SNI) Request & response between IE 11 and IIS 8 (with SNI)
IIS 8, site binding, no SNI.
The client is SNI compliant, so by default is specifying Extension: server_name (where the host_name is the FQDN of my SharePoint web application).
There is no Extension: server_name because the IIS was not configured to use SNI. The certificate associated to that IP is provided.
IIS 8, site binding with SNI.
The client is SNI compliant, so by default is specifying Extension: server_name (where the host_name is the FQDN of my SharePoint web application).
The server response includes Extension: server_name because the IIS was configured to use SNI. The server provides the certificate issued for the host_name mentioned in the client request.

As we see, IE 11 always sends extension “server_name” and IIS 8 responds with extension “server_name” only when is configured to use SNI.

 

 

Microsoft Windows WebDAV Client and IIS 8 (with/without SNI)

Request & response between MS WebDAV and IIS 8 (without SNI) Request & response between MS WebDAV and IIS 8 (with SNI)
IIS 8, site binding, no SNI.
SSL v2
Because IIS 8 is configured to not use SNI, the certificate associated to that IP is provided. MS WebDAV validates the certificate and will continue the secure communication channel.
IIS 8, site binding with SNI.
SSL v2 – explains pretty much why does MS WebDAV doesn’t work with SNI. No Extension: server_name sent to the server!  MS WebDAV not compliant with SNI.
Because IIS 8 is configured to use SNI and because the client is not compliant with SNI, a default certificate is provided by the server (notice the certificate is issued for a different FQDN). MS WebDAV will not continue the secure communication channel because the FQDN’s are not matching.

 

In conclusion:

  1. Microsoft Windows WebDAV Client does not support Server Name Indication (SNI).
  2. If you troubleshoot “Open with Explorer” from SharePoint, have look over the SNI configuration.

 

 

So far I found only one thread on the MSDN forums regarding Microsoft Windows WebDAV Client and SNI compliance. Unfortunately the moderator closed that thread due to lack of understanding.
http://social.technet.microsoft.com/Forums/windows/en-US/608765c8-0cc6-4e72-9255-9c436d2fd0e6/sni-support-in-webdav-over-https

 

 

For those who would like to read more about TLS:
http://en.wikipedia.org/wiki/Transport_Layer_Security
RFC 2246 - The TLS Protocol Version 1.0 (January 1999)
RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1 (April 2006)
RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (August 2008)

Software bug in OneDrive for Business 1.2.2 (iOS)

Straight to the subject. You are not able to connect using OneDrive for Business 1.2.2 (iOS) to your SharePoint 2013 OneDrive personal site if your user name has space characters in it.
“Oops! … I did it again” (I am not a Britney Spears fan, but Microsoft is since is not the first time when their products are failing to work when your user name account contains space charters).

From the very beginning – I am using SharePoint 2013 (15.0.4617.1000 June 2014 CU) and my setup corresponds with the OneDrive for Business App requirements.

 

Let’s reproduce the software bug
As I mentioned, the user account has a space character in the user name (sAMAccountName).
The user logon name has a space character in it.

With this account (ITECH\John Smith) I am connecting to SharePoint 2013 and trigger the OneDrive personal site creation.
The URL of the OneDrive personal site is composed based on your user name. If your user name has space characters in it, then the URL will also have them (note the %20 in the URL). http://drive002.informationtechnology.ro/personal/itech_john%20smith/_layouts/15/start.aspx
Trigger the OneDrive personal site creation. The personal site (OneDrive).

The personal site is created. Now let’s move to the iOS device.
First, using Safari I am connecting to the OneDrive personal site and test the device connectivity with the SharePoint 2013 farm.
Test the iOS device connectivity with the SharePoint 2013 farm. Test the iOS device connectivity with the SharePoint 2013 farm.

The device is able to communicate with the personal OneDrive site. Now let’s configure OneDrive for Business 1.2.2 (iOS).
User name: ITECH\John Smith
SharePoint Server URL: http://drive002.informationtechnology.ro/
(this is my WebApplication FQDN where I host the personal sites)
Configure OneDrive for Business 1.2.2 (iOS) using an account that has space characters in the logon name.

When I tap the Sign In button I am informed I’m not using a SSL connection. In this case (testing/troubleshooting) this warning message can be ignored.
Configure OneDrive for Business 1.2.2 (iOS) - warning message because we are not using HTTPS.

I tap the Proceed button and I get some Signing In progress wheel and after that … nothing – same login screen. Tapping again Sign In will not help.
Configure OneDrive for Business 1.2.2 (iOS) using an account that has space characters in the logon name. Configure OneDrive for Business 1.2.2 (iOS) using an account that has space characters in the logon name - authentication loop.

:) if I quit the OneDrive app and open it again, the app is showing like it’s configured, but in fact is not connecting, or doing anything.
Configure OneDrive for Business 1.2.2 (iOS) - the app looks like is configured, but it doesn't work.

Let’s see whats going on the network when I tap Sign In.
Capture with what OneDrive for Business 1.2.2 (iOS) sent through the network.
Click to see the HTTP requests performed by the App.

 

 

Now let’s prove is working for the user accounts that doesn’t have space characters (sAMAccountName)
Let’s do a cleanup of the existing John Smith personal site, user profile and update the AD from ITECH\John Smith to ITECH\John.Smith.

Delete the user profile from SharePoint.
Delete the existing user profile.

Delete the personal site collection.
Delete the personal site.

Update the AD account.
Update the user account - no space characters in the logon name.

Run the User Profile Synchronization Service Proxy – User Profile to SharePoint Full Synchronization SharePoint timer job.
Run the User Profile Synchronization Service Proxy – User Profile to SharePoint Full Synchronization SharePoint timer job.

OK, now we are ready for a clean “start” with ITECH\John.Smith.
Again, with ITECH\John.Smith I am connecting to SharePoint 2013 and trigger the OneDrive personal site creation.
This time the URL of the OneDrive personal site will not contain anymore %20 because the user name doesn’t have any space characters in it. http://drive002.informationtechnology.ro/personal/itech_john_smith/_layouts/15/start.aspxTrigger the OneDrive personal site creation. The personal site (OneDrive).

The personal site is created. Now let’s move again to the iOS device.
Using Safari I am connecting to the OneDrive personal site and test the device connectivity with the SharePoint 2013 farm.
Test the iOS device connectivity with the SharePoint 2013 farm. Test the iOS device connectivity with the SharePoint 2013 farm.

The device is able to communicate with the personal OneDrive site. Now let’s configure OneDrive for Business 1.2.2 (iOS).
User name: ITECH\John.Smith
SharePoint Server URL: http://drive002.informationtechnology.ro/
Configure OneDrive for Business 1.2.2 (iOS). Configure OneDrive for Business 1.2.2 (iOS).

Configure OneDrive for Business 1.2.2 (iOS). Configure OneDrive for Business 1.2.2 (iOS).

Configure OneDrive for Business 1.2.2 (iOS).

OneDrive for Business 1.2.2 (iOS) is now configured.
OneDrive for Business 1.2.2 (iOS) is now configured.

If I look into the network traffic generated when I taped Sign In, I see many more HTTP requests.
I see many more HTTP requests compared with the previous capture - sign the OneDrive for Business 1.2.2 (iOS) is actually working.

 

I will try to open a support call with Microsoft related to this issue and keep this post updated with the status.

OneDrive for Business – get up-to-date fast as possible

I the last days I test more and more OneDrive for Business. I already have an opinion around the PC version (and is by far not a good one), but I haven’t yet tested the other versions (Windows Tablet, Android, iOS, Windows Phone, Xbox). Before “jumping” into my tests I searched the already news/articles/videos around these versions and I found two sessions from the SharePoint Conference 2014 (@SPConf) which will pretty much put you up to date with OneDrive for Business.

OneDrive for Business and Mobility: Access your files while on the go from any device or platform (speakers: Kate Dramstad, Kieran Gupta) | Slides

What’s new and what’s coming for OneDrive for Business (speakers: Kieran Gupta, Tejas Mehta)

Very good sessions! This year I will attend to TechEd Europe 2014 (@teched_europe). I hope the sessions will reach at least the same level.
Last year (2013) I was at European SharePoint Conference (@EuropeanSP) and I was not that impressed by the technical sessions.