Connecting a SSTP session takes longer than expected on German Windows installations


Action


You are running a Windows Active Directory Domain and you use access to your network from an outside and/or mobile client. You chose the Secure Socket Tunneling Protocol (SSTP) to facilitate the communication into your network. The setup is described here: http://technet.microsoft.com/en-us/library/cc731352(WS.10).aspx

You are using German language clients or with the German language pack with the system language set to German.

Result


When users of German workstations or notebooks connect the SSTP VPN, they encounter a delay of an additional 6-10 seconds compared to English language clients.

Cause


This is a known problem in Windows Vista and newer operating systems.

The SSTP service calls into LSASS to manage the certificates for the SSL session. It is doing these calls in its own context, and the SSL/TLS security provider uses Windows APIs to retrieve information about the user domain. In this case, the user name is "NT-Autorität\Lokaler Dienst" which in English is "NT Authority\LocalService".

TLS wants to retrieve the DNS domain name for the user, so the call is forwarded to a Domain Controller of the domain which in this case cannot work.

The German string "NT-Autorität" is accepted by Netlogon service as a NETBIOS domain name and it attempts to find DCs for the domain and of course fails after a time-out. For all other languages we have looked at, the name contains a space or other character that is invalid for NETBIOS, so Netlogon rejects the request immediately.

Resolution


Netlogon sends broadcasts to resolve the NETBIOS domain name and waits for responses which creates the delay. The delay is avoided if you set the NetBt Node Type to "2" which is "Point-to-Pont".

In this mode broadcasts are not allowed but only direct queries to NETBIOS name servers such as WINS servers. Typically, mobile clients don't have a NETBIOS name server in their home network or hotspot, so there is no delay. When the client is in the corporate network, it maybe does have a WINS server for NETBIOS name resolution so NETBIOS name resolution works.

You can find information about NETBIOS Node Type here: http://technet.microsoft.com/de-de/library/cc759557(WS.10).aspx

More Information


When you enable netlogon.log for the affected clients, you will see:

07/12 14:42:29 [MISC] DsGetDcName function called: Dom:NT-AUTORITÄT Acct:(null) Flags: DSP 
07/12 14:42:29 [MISC] DsIGetDcName: Ignore single label DNS domain name NT-AUTORITÄT
07/12 14:42:29 [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c01ffff1
07/12 14:42:29 [MAILSLOT] Sent 'Sam Logon' message to NT-AUTORITÄT[1C] on all transports.
...
07/12 14:42:35 [CRITICAL] NetpDcGetNameNetbios: NT-AUTORITÄT: Cannot NlBrowserSendDatagram. (1C) 53
07/12 14:42:35 [MISC] NetpDcGetName: NetpDcGetNameNetbios returned 1355
07/12 14:42:35 [CRITICAL] NetpDcGetName: NT-AUTORITÄT: IP and Netbios are both done.
07/12 14:42:35 [MISC] DsGetDcName function returns 1355: Dom:NT-AUTORITÄT Acct:(null) Flags: DSP

When the customer creates a SCHANNEL.ETL file for the client while connecting the SSTP, he will see:

[1]0258.0290::07/12/2011-12:42:29.057 [sslproto]New cred:00000000003A5410, Protocol:80000000
[0]0258.0290::07/12/2011-12:42:35.945 [sslproto]GetUserName FAILED: 0x54b
[0]0258.0290::07/12/2011-12:42:35.946 [release]==============================================

So the delay is introduced by the German Name for "NT Authority".

This is reported in:

http://bugcheck/bugs/Windows8Bugs/415353

http://bugcheck/bugs/WindowsSE/384979