Reset Search
 

 

Article

KB21745 - Windows 7 Network Location Awareness is not correctly assigning the Network Connect / Pulse Secure Desktop adapter firewall policy

« Go Back

Information

 
Last Modified Date8/6/2015 8:09 PM
Synopsis
This article describes the issue of Windows Network Location Awareness not being able to correctly assign the Network Connect / Pulse Secure Desktop adapter firewall policy.
Problem or Goal
Windows 7 can use NLA (Network Location Awareness) to dynamically set firewall policies. When setting up a connection with Network Connect or Pulse, the system is unable to set the correct firewall policies on the Network Connect / Pulse Secure Desktop interface.

In the case of an Active Directory facing network with a domain controller behind the PCS, NLA should tag the interface as a Domain Network. As such, the firewall is closed and the user cannot continue. After restarting the NLA service in Windows, the adapter is correctly registered in NLA and the firewall policies get correctly configured.
Cause
In most cases, this functionality should work correctly between the Windows 7 client, its Domain Controller, and the Pulse Secure Desktop device.

Communication delays between the client and DC during Netlogon can place the client firewall in a state where it does not follow up with the controller, after delays in the Netlogon process. An example of what can cause this is the NetBios drive mounts occurring after the VPN client IP is brought up on the client machine.

Reconstruction of the issue:
  1. A user logs on to Windows with cached credentials.
  2. The user opens a PCS connection.
  3. At this point, NLA domain determination would have started.
  4. The VPN client queries the DC (Note: The user cannot reach the DC; only the VPN client itself has access at this point). In fact there is a moment in time when there is yet no domain connectivity after VPN establishment.
  5. The connection is authenticated and the user is allowed on the network.
  6. Domain Connectivity is now up; but NLA has already timed out since step 3. If there is a delay between network interface startup and communication with the DC, the client machine places the controller in a negative cache state, between steps 4 and 5.

 
Solution
This is not a bug, but a time sensitive function easily disrupted by network traffic such as NetBios drive mounts. By default, Windows 7 does not attempt to automatically recover, though two workarounds are available based on suggestions from Microsoft.
  1. Reducing the negative cache period via a client-side registry change. The relevant registry key is:
  • Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters.
  1. Value: NegativeCachePeriod
  • Type: REG_DWORD

The NegativeCachePeriod specifies the amount of time that DsGetDcName recalls a DC could not be found in a domain. If a subsequent attempt is made within this time, the DsGetDcName call does not work and does not try to find a DC again. If this number is too large, a client never tries to find a DC again if the DC is initially unavailable.

By default, the key does not exist; so it must be created manually and will be subsequently referenced by Windows 7. The Microsoft recommendation for a value to set:
 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\NegativeCachePeriod = 0

Re-triggering the DC list population using a network restart, also corrects the situation. This can be done via the NetConnect post-startup script. Here we can use the addition of a dummy network route or ipconfig with a sleep delay to trigger the restart.
 
sleep 50
ipconfig /renew
Related Links
Attachment 1 
Created ByData Deployment

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255