locked
NAP DHCP issues RRS feed

  • Question

  • we have deployed NAP DHCP enforcement. Now every morning the Help Desk is swamped with user calls that they have no network access. I have looked into the issue and found that machines were quarantined by Non Nap- Capable policy. This was a month ago, and since then I am so puzzled over this issue that I have lost half of my hair. I contacted MS tech support on this and all they could say was NAP agent service isn't running. in fact when we looked we found the service to be running along with DHCP enforcement client and Security center.  However, many windows XP sp3 clients with the required services running, were quarentined as Non Nap-capable machines. 

    To recreate the problem on my test machine, I stopped the nap agent service and it gets quarantined as non Nap- capable. Similarly, when I only stop Security  Center Service the test machine is quarantined as non compliant. I beleieve that is by design and that also tells me my NPS server with the policies are setup correctly. 

    A typical scenario after deploying NAP in my network is that a Nap capable machine gets quarantined as non nap-capable and when I release/renew IP address or do a repair on the NIC card it  is allowed in with full access, and  renews IP address lease on its own throughout the day without any issues until it is restarted again. further, not all XP machines in our network are quarantined but about 30% of them. Rest of them are working just fine. 

     Any help would be really appreciated.  

     

    Tuesday, April 6, 2010 4:44 PM

Answers

  • Hi,

    To stop the help desk calls I suggest you change your non-NAP capable policy from restrict access to allow full network access for the time being. Then you can continue to troubleshoot the problem until you think you have a solution. Perhaps this isn't possible, but I thought I would suggest it.

    Assuming that all cases are clients that are evaluated as non NAP-capable, the problem can only be caused by one of three things:

    1. NAP agent has not yet started when the client first requests a DHCP address. In this case, the service may be starting later but the client is unable to acquire a new (unrestricted) IP address because your DHCP server is on a different subnet and you have not configured the gateway address.

    2. The DHCP enforcement client is not initialized when the client first requests a DHCP address. Again, the same problem might be happening as described in #1. The enforcement client might initialize late and then the client cannot renew its IP address because it is restricted.

    3. The DHCP server is functioning as an NPS proxy and is not marked as "NAP-capable" in the list of RADIUS clients on your primary NPS. I only provide this possibility because it is one of the possible causes. Since many of your clients are working correctly this is unlikely to be the cause.

    Is your DHCP server located on a different subnet from your clients? If so, have you configured the 003 Router option?

    See http://technet.microsoft.com/en-us/library/dd363563(WS.10).aspx for instructions.

    Let me know if this helps!

    -Greg 

    • Marked as answer by Miles Zhang Monday, April 12, 2010 8:51 AM
    Wednesday, April 7, 2010 1:47 AM

All replies

  • Hi,

    To stop the help desk calls I suggest you change your non-NAP capable policy from restrict access to allow full network access for the time being. Then you can continue to troubleshoot the problem until you think you have a solution. Perhaps this isn't possible, but I thought I would suggest it.

    Assuming that all cases are clients that are evaluated as non NAP-capable, the problem can only be caused by one of three things:

    1. NAP agent has not yet started when the client first requests a DHCP address. In this case, the service may be starting later but the client is unable to acquire a new (unrestricted) IP address because your DHCP server is on a different subnet and you have not configured the gateway address.

    2. The DHCP enforcement client is not initialized when the client first requests a DHCP address. Again, the same problem might be happening as described in #1. The enforcement client might initialize late and then the client cannot renew its IP address because it is restricted.

    3. The DHCP server is functioning as an NPS proxy and is not marked as "NAP-capable" in the list of RADIUS clients on your primary NPS. I only provide this possibility because it is one of the possible causes. Since many of your clients are working correctly this is unlikely to be the cause.

    Is your DHCP server located on a different subnet from your clients? If so, have you configured the 003 Router option?

    See http://technet.microsoft.com/en-us/library/dd363563(WS.10).aspx for instructions.

    Let me know if this helps!

    -Greg 

    • Marked as answer by Miles Zhang Monday, April 12, 2010 8:51 AM
    Wednesday, April 7, 2010 1:47 AM
  • Hi Greg, 

    First of all I like to thank you very much for your reply.

    Just to give you a bit on the background of my project here,  NAP deployment runs fine without any glitches on my test environment. I did the testing for few months and then moved on to the production hoping to get the same result, but am spell bound with all these unforeseen issues. 

    On your suggestions above, 

    1. We do suspect NAP agent service not starting  when the client first requests a dhcp address. This suspicion also was raised right after I spend hours with MS tech. The MS support team found NAP agent service not running in the Nps related logs, reports and network monitor traps I sent them. However,when I looked into the services on a client the nap agent service is started automatically. This somewhat confirmed that the clients were requeting DHCP lease prior to NAp agent service starting. I know at some point you were going to test the "Dependency of dhcp on nap agent service" setup mitigate this issue. I wonder about the outcome of such test.

    2. After going over system event logs on many clients I have found that dhcp client enforcement does initialize few seconds after nap agent service is started.  I do not guess this to be an issue. 

    3. We strictly have the simplest form of NAP , that is the DHCP enforcement . I did not want to complicate the setup just so that we could start testing and get on par with newer extra layer of security added to our network. 

      I am glad you pointed out on the DHCP 003 Router option. yes, my DHCP server does reside on a seperate subnet, for example, say 192.168.A.0,

    And the clients machines are on three different floors. Each floor has its own subnet, for example, 192.168.B.0 and 192.168.C.0 and so on. I just checked on the DHCP scope options for subnet 192.168.B.0 and .C.0 and found that they were missing Default Network Class 003 router options. I have just added  that option with 192.168.B.1 and 192.168.C.1 now and crossing my fingers. However, this may mean all day today or may be tomorrow. 

     

    Can I please request to have this thread open so that I can update you on the status ? please

     

    Thank you.

    -Mo

     

    Wednesday, April 7, 2010 1:10 PM
  • Hi Mo,

    I will keep an eye on the thread to see if I can help! Good luck and hopefully the 003 Router option will resolve some problems.

    Adding the dependency on NAP agent to DHCP client service isn't commonly done, but it has worked for the dot3svc service when deploying 802.1X so I would guess this is a good way to proceed if you are still having trouble. Also please let me know if there is a case # for you with MS tech support so I can review it. You can email me at: greglin@online.microsoft.com <-- remove the "online" to actually email me (I added it to prevent spammers from scanning).

    Thanks,

    -Greg

    Wednesday, April 7, 2010 3:23 PM
  • Thanks Greg, I have emailed you as well

     

    I do not know how much of a difference the router option made since I see a very large number of our clients still being quarantied by non nap-capable policy.

    I have gone ahead and made dhcp client service dependent on NAP agent service and that did seem a bit promising. However, when I restarted the client after running the command, the event log on NPS server still showed the machine as Non Nap-Capable, as before. Only thing different now post-command on the client is that Nap agent service does start right after the eventlog service. 

    I am going to have to continue testing on this area. i will keep you updated. I know now i can email but it may also be better if i keep posting my findings here, so that people who come after me will benefit from these posts I make here.

     

    Thanks

    Thursday, April 8, 2010 8:23 PM
  • Hi Mo,

    Yes, please do post your findings here. I just wanted to provide my email so we can communicate directly if needed. From the status you gave in the email, it sounds like running "SC config dhcp depend= napagent" on one of the problem computers may have helped.

    -Greg

    Saturday, April 10, 2010 5:08 AM
  • Hi Greg, last friday I setup a new subnet with all the gateway configurations as needed for NAP. I have placed about 15 machines on that subnet. I restarted them and few had could not access the netwrok due to not having security center running. They were auto updated as is desinged in my deployment. then i proceeded to turn the machine off and left for the weekend.

    this morning i came back to work and first thing i did was deleted all and every record from DHCP from that specifig subnet, meaning i deleted all the ip address lease records. Then i restarted all clients one after another. Surprisingly they all came back up and connected to the network with full access and as NAP dhcp Compliant. 

    I looked at the event viewer and found out that, Each machine came up and was logged as Non Nap-capable and quarantied. After about 10 seconds the same clients were logged as DHCP Compliant and allwowed full access. This thing really puzzled me. I thought the machines would be blocked if they come in as non nap-capable. that is how i have my network policies setup. There are three policies, one for nap compliant, one non compliant and one no capable as was suggested by the step by step guide. 

    So the question is , do all the machines come in initially as non nap-capable and then become compliant ? Has anyone else had this issue? is this the normal behavior ?

    My superiors thought NAP was all waste of time, but I have insisted on its successful deployment and now they have given me until Thursday to prove. or I am not allowed to talk about NAP anymore. Its taken a lot of time and energy in the process. 

    Monday, April 12, 2010 3:57 PM
  • Below is one example of Event Logs I speak of above, Please note the Account Name of the machine. This same machine 


    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          4/12/2010 8:42:59 AM
    Event ID:      6276
    Task Category: Network Policy Server
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      ENVDC2
    Description:
    Network Policy Server quarantined a user.

    Contact the Network Policy Server administrator for more information.

    User:
    Security ID: NULL SID
    Account Name: -
    Account Domain: -
    Fully Qualified Account Name: -

    Client Machine:
    Security ID: NULL SID
    Account Name: en8s5znj1
    Fully Qualified Account Name: -
    OS-Version: -
    Called Station Identifier: 192.168.60.0
    Calling Station Identifier: 0023AE1E0C2C

    NAS:
    NAS IPv4 Address: 192.168.15.12
    NAS IPv6 Address: -
    NAS Identifier: ENVDC2
    NAS Port-Type: Ethernet 
    NAS Port: -

    RADIUS Client:
    Client Friendly Name: -
    Client IP Address: -

    Authentication Details:
    Proxy Policy Name: NAP DHCP
    Network Policy Name: NAP DHCP Non NAP-Capable
    Authentication Provider: Windows 
    Authentication Server: ENVDC2
    Authentication Type: Unauthenticated 
    EAP Type: -
    Account Session Identifier: 32393338373339313039

    Quarantine Information:
    Result: Quarantined 
    Extended-Result: -
    Session Identifier: -
    Help URL: -
    System Health Validator Result(s): -

    Few Seconds Later

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          4/12/2010 8:43:15 AM
    Event ID:      6272
    Task Category: Network Policy Server
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      ENVDC2
    Description:
    Network Policy Server granted access to a user.

    User:
    Security ID: NULL SID
    Account Name: -
    Account Domain: -
    Fully Qualified Account Name: -

    Client Machine:
    Security ID: \EN8S5ZNJ1$
    Account Name: en8s5znj1..com
    Fully Qualified Account Name: \EN8S5ZNJ1$
    OS-Version: 5.1.2600 3.0 x86 Workstation 
    Called Station Identifier: 192.168.60.0
    Calling Station Identifier: 0023AE1E0C2C

    NAS:
    NAS IPv4 Address: 192.168.15.12
    NAS IPv6 Address: -
    NAS Identifier: ENVDC2
    NAS Port-Type: Ethernet 
    NAS Port: -

    RADIUS Client:
    Client Friendly Name: -
    Client IP Address: -

    Authentication Details:
    Proxy Policy Name: NAP DHCP
    Network Policy Name: NAP DHCP Compliant
    Authentication Provider: Windows 
    Authentication Server: ENVDC2..com
    Authentication Type: Unauthenticated 
    EAP Type: -
    Account Session Identifier: 31323631383338363936

    Quarantine Information:
    Result: Full Access 
    Session Identifier: {81DFE51C-BE8A-4A5F-8352-D5D81C8FC469} - 2010-04-12 12:42:16.125Z

    Thanks for all you help.
    Monday, April 12, 2010 4:17 PM
  • Hi Mo,

    The behavior you describe isn't unusual. You said that initially they matched the non NAP-capable policy and were quarantined. This is probably because NAP agent service was still in the process of starting when they made the first DHCP request. When NAP agent starts, this will trigger the enforcement client to send a new network access request. For DHCP enforcement, this will be a DHCP renewal request. If the computer is compliant then it will be granted full access.

    This seems to be working correctly. Is there a problem?

    -Greg

    Monday, April 12, 2010 6:03 PM
  • Greg, I will post a reply after  I turn it on the production. I am hoping that the dchp scope option you pointed out the other day helps in fixing my problem. 

    Making dhcp service dependent on Nap agent does one thing and that it reduces the time between non nap- capable to nap compliant. Initially, the event logs were 10-16 seconds apart for the two status messages. After running the "sc config dhcp depend= napagent" command, the time was reduced to 2-3 seconds. 

    Tuesday, April 13, 2010 2:48 PM
  • Good morning Greg,

     

    I believe all my NAP woes are fixed. The credit is all yours. I like to copy and paste what you said that fixed my issue from above,

     1. NAP agent has not yet started when the client first requests a DHCP address. In this case, the service may be starting later but the client is unable to acquire a new (unrestricted) IP address because your DHCP server is on a different subnet and you have not configured the gateway address.

    Is your DHCP server located on a different subnet from your clients? If so, have you configured the 003 Router option?

     

    As I have noted before, two of my subnets were missing that router option and now this morning I have turned NAP back on again on those subnets with the Router Option 003 configured. Everything seems to be fine. 

    Thank you Greg. 

    Also I found a great blog by Jeff Sigman and i am going to post the link for all that are interested. http://blogs.technet.com/nap/archive/2008/02/19/debugging-nap-errors-part-1.aspx

     

    Thanks again 


    Wednesday, April 14, 2010 2:47 PM