Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.
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.
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.
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
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ÄT07/12 14:42:29 [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c01ffff107/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) 5307/12 14:42:35 [MISC] NetpDcGetName: NetpDcGetNameNetbios returned 135507/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: DSPWhen 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:
Keywords: vkball, kb