locked
NAP notification does not occur on some Windows XP clients RRS feed

  • Question

  • Server configuration:

    Windows 2008 RTM NPS Server using EAP/802.1x

    802.1x-configured Cisco switch

    Client configuration:

    "netsh nap client show grouppolicy" output looks good - EAP agent enabled

    napagent service and security center services start automatically

    I have two XP clients; on the older one, napstat doesn't start automatically, which means that the user doesn't get a notification; on the newer client, it does, and notification works fine.

    Looking through all the other NAP notification and napstat related articles here, I didn't find one that resolved my issue.  I compared the security parameters of the napagent service on the two clients using sc, and they are identical.  File permissions on napstat.exe appear identical.  Logging in as administrator doesn't help.  There are no DCOM errors in the event log.

    What is responsible for starting napstat.exe at login?  What can prevent it from doing so normally?

    Thanks!

    Thursday, January 13, 2011 11:34 PM

Answers

  • Hi Amber,

    Your switch may have a periodic reauthentication timer set. This is quite common. Perhaps that is why the client was given another chance after 10 minutes.

    If you have three VLANs where the client can potentially be placed: 1) Compliant VLAN, 2) Noncompliant VLAN, and 3) Non-NAP capable VLAN then it does make sense that a client might be put in Non-NAP capable if NAP agent wasn't fully started before 802.1X authentication completed. If the Non-NAP capable VLAN has no DHCP server available, this would explain the 169.x.x.x address.

    It is also possible to configure a workaround where the wired autoconfig service depends on napagent. That way, the client will never attempt 802.1X auth until after NAP agent is running. That solution is described here: http://technet.microsoft.com/en-us/library/dd348450(WS.10).aspx

    The sequence of events should tell you a lot. Let me know what you find out!

    -Greg

    Thursday, January 27, 2011 10:40 PM

All replies

  • Hi,

    Thank you for your post here.

    First of all, please double check whether the problematic client computer get the NAP group policies applied perperly. You can run GPMC.msc on the server and garther the GP result report from the problematic client computer.

    A similar post for your reference:

    http://social.technet.microsoft.com/Forums/en-US/winserverNAP/thread/b2d72b80-28d1-4786-ac02-074ed2c78b52

    Friday, January 14, 2011 8:08 AM
  • Thank you, that thread was my starting place. I have two XP SP3 clients that are both getting the same GPOs successfully.  One works and the other doesn't.  The one that works is running napstat automatically, and it doesn't launch on the non-working one.  What else could cause this?  Thanks, and let me know if you need to see the GP result report.
    Friday, January 14, 2011 7:18 PM
  • What does it say if you run the command "napstat /s"? What is the different result you have seen when running this command in these two client machines?

    Besides that, please also double check the configuration on the client side. Make sure you configure it correctly, go to the "Local area connection", properties, and then go to authentication tab... make sure the configuration there is correct.

    Regards

    Qunshu


    Clarification: Microsoft doesn't own any liability & responsibility for any of my posting.
    Saturday, January 15, 2011 9:30 AM
  • On both computers, when calling napstat /s, we get the popup saying the computer is compliant.  There is not difference in what shows there.

    Thanks

    Tuesday, January 18, 2011 11:41 PM
  • Hi, does anyone have information about what causes napstat to launch automatically or not?

    Thanks!

    Monday, January 24, 2011 5:17 PM
  • Hi,

    If the computer is noncompliant, you should always see the napstat notification. However, if the computer is compliant you might not see this. In my experience, this is just a timing issue. Since there is nothing for the user to do when the client is compliant, napstat launches and then is immediately killed. If the UI does not pop up quickly enough before napstat is killed, you will not see it. This is not considered a problem because it isn't terribly important to tell the user everything is fine. 

    On the affected computer, is there a problem seeing the message when the computer is noncompliant? 

    -Greg

    Monday, January 24, 2011 7:03 PM
  • Greg,

    Thanks for your response.  The computer does not get the notification from napstat even when non-compliant. 

    What we do see is that the Windows Security Center notifies about the AV definitions being out of date (this is on purpose to test the non-compliant state), and the network notification icon shows fully connected at 100Mbps.  However, the computer has an auto-configuration IP.  It is not even properly put onto the remediation network.

    Thanks,

    Amber

    Tuesday, January 25, 2011 10:07 PM
  • Hi Amber,

    I think we have a different problem than originally thought. If the computer is getting a 169.x.x.x address this indicates a problem with DHCP services on the restricted network. It also may mean that the client computer is having trouble authenticating, but since it is receiving Group Policy it must have made it through at least one successful authentication attempt.

    1. You said that you are using the EAP agent and you see this enabled when you issue a netsh nap client show group. Keep in mind that this only tells you that the client computer has been given this setting by GP. It doesn't tell you that the EAP agent is actually initialized or that NAP agent is running. To verify this, please issue a "netsh nap client show state."

    2. Are you using VLANs or ACLs to separate compliant and noncompliant computers? How is this configured? Please verify that there is a DHCP server on the restricted network.

    3. When the client computer goes from compliant to noncompliant, do you see that your expected network policies are matched on NPS? Review the NPS events and find those that show the name of this client computer together with the policies that are matched. You should see two events for each authentication attempt - the first should always say that access was granted, the second should say that the user was either quarantined or granted full access. There will be a new 802.1X authentication attempt with two new events each time the computer changes from compliant to noncompliant and vice-versa.

    Below is a summary of the events you should see on the server side, taken from the NAP troubleshooting guide.

    ---------------------------------------------------------------------------------------------------------------------------------------------------

    The following events on servers running NPS display detailed information about NAP client access request processing:

    • Event ID 6272: Network Policy Server granted access to a user.

      This event occurs when a NAP client computer is successfully authenticated and, depending on its health state, obtains full or restricted access to the network.
    • Event ID 6273: Network Policy Server denied access to a user.

      This event occurs when there is a problem with authentication or authorization and is associated with a reason code. For more information, see NPS Reason Codes (http://go.microsoft.com/fwlink/?LinkId=136640).
    • Event ID 6274: Network Policy Server discarded the request for a user.

      This event occurs if there is a configuration problem. It can occur if RADIUS client settings are incorrect or if NPS cannot create accounting logs.
    • Event ID 6276: Network Policy Server quarantined a user.

      This event occurs when the client access request matches a network policy that is configured with a NAP enforcement setting of Allow limited access. It can also occur if you have configured a setting of Allow full network access for a limited time and the specified date is in the past.
    • Event ID 6277: Network Policy Server granted access to a user but put it on probation because the host did not meet the defined health policy.

      This event occurs when the client access request matches a network policy that is configured with a NAP enforcement setting of Allow full network access for a limited time when the date specified in the policy has passed.
    • Event ID 6278: Network Policy Server granted full access to a user because the host met the defined health policy.

      This event occurs when the client access request matches a network policy that is configured with a NAP enforcement setting of Allow full network access.
    Tuesday, January 25, 2011 10:42 PM
  • OK, I think we might have found the problem, but we need to compare the sequence of event IDs to see where the process is breaking.  After walking away from the station for over 10 minutes, the napstat notification finally came up.  My theory is that it exceeded a timeout somewhere, probably with the switch communication with the DHCP server.  I think that the client was slow and didn't report its health in time to get put in the remediation VLAN.  After a certain period of time, maybe 10 minutes, it was ready to report its health, it was given a chance to authenticate.

    What do you think of this theory?  On my side, we'll be looking at the sequence of events in the event log to see if we can confirm this.

    Thanks!

    Thursday, January 27, 2011 10:28 PM
  • Hi Amber,

    Your switch may have a periodic reauthentication timer set. This is quite common. Perhaps that is why the client was given another chance after 10 minutes.

    If you have three VLANs where the client can potentially be placed: 1) Compliant VLAN, 2) Noncompliant VLAN, and 3) Non-NAP capable VLAN then it does make sense that a client might be put in Non-NAP capable if NAP agent wasn't fully started before 802.1X authentication completed. If the Non-NAP capable VLAN has no DHCP server available, this would explain the 169.x.x.x address.

    It is also possible to configure a workaround where the wired autoconfig service depends on napagent. That way, the client will never attempt 802.1X auth until after NAP agent is running. That solution is described here: http://technet.microsoft.com/en-us/library/dd348450(WS.10).aspx

    The sequence of events should tell you a lot. Let me know what you find out!

    -Greg

    Thursday, January 27, 2011 10:40 PM