locked
NAP-DHCP Issue in Wireless Access Point RRS feed

  • Question

  • When we deploy NAP-DHCP into wireless access point, we found NAP-DHCP works when the AP is configured with WPA/WPA2-Personal, but it would fail when the specific security mode is not. After inspection the package over the air and wire side, we're wondering if MS Vista has some mechanism to adjust the NAP behavior in wireless. Is the security mode of wireless a prerequisite to NAP?
    Wednesday, July 1, 2009 1:18 AM

Answers

  • Do you mean that you are trying to hand a different set of IPs to compliant vs. non-compliant clients?

    If so, then I believe you misunderstand how DHCP NAP enforcement works.
    It does not (can not) work by handing out addresses from different scopes/subnets to clients on the same physical subnet.  (that would be a routing nightmare)

    Instead, it follows the same address-selection logic, but plumbs a different set of options onto the client to 'lock down' networking.  It provides a 0.0.0.0 value for default gateway, along with a 255.255.255.255 (32bit) mask, effectively configuring the client's stack such that it cannot talk to other machines (it has no routing ability at all) on that interface.  You can then specify a set of remediation servers at the NAP Server/NPS which are then used by the DHCP Server in conjunction with the scope's default gateway option to plumb a set of host-to-host-only routes to the client to allow access only to specified resources.

    Please read this walk-through for more details:
    http://www.microsoft.com/downloads/details.aspx?FamilyID=ac38e5bb-18ce-40cb-8e59-188f7a198897&displaylang=en

    -Chris


    Chris.Edson@online.microsoft.com * SDET II, Network Access Protection * Remove the "online" make the address valid. ** This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, July 31, 2009 5:31 PM
  • Hi Matt,
        If your Access point is configured as "unsecured", Windows VISTA will not send its NAP Specific information to the NPS server. So, NAP Server (NPS) will treat that VISTA as non- NAP Capable machine. Sending such information on the unsecure wireless might expose a change for hacker to know the information about the computer, so it is blocked by design. Hope this answers your question.

     Feel free to ask if you have more questions.

    Thanks
    -RamaSubbu SK
    Sorry! Microsoft doesn't own any liability & responsibility for any of my posting.
    Monday, August 3, 2009 6:56 PM

All replies

  • Hi,

    You said NAP-DHCP "would fail when the specific security mode is not."

    What do you mean by fail? Does the client fail to get an IP address? What security settings are you trying in addition to WPA/WPA2? Are you using VLANs on the AP?

    If you are having problems with clients in a restricted state, check the routing table and verify that a route is configured to any required remediation servers (AD, DNS, etc).

    -Greg

    Friday, July 3, 2009 5:20 AM
  • Hi Greg,

    First, thank you to reply my question. And, here is what did we run the test.

    I set the AP in "Open system" mode without any encryption, and I got the following result:

    1. The Vista PC in wireless always got restricted IP address even if the PC is a compliant NAP client.

    2. On the same PC with the same configuration and test procedure, the LAN port can have correct behavior.

    3. I checked the captured packet, and compare wired and wireless, the there is one different in DHCP Request packet.  The wired packet, in DHCP Request, there is one more option field (option 43, length = 135).

    4. When tested in wireless, there is no NAP message when I turn on or turn off the firewall, but the NAP message will appear in wired

    Then, I try to set the AP in WPA2-PAK mode to test it again, it works.  The Vista PC can got correct NAP behavior, the DHCP Request have option 43 field, and the NAP message will appear. I also tested in WPA-PSK mode, also can get work. 
     
    So, I wonder the Vista have some mechanism to adjust the NAP behavior in wireless, the NAP will only work if the wireless work in security mode.  Rite?

    Monday, July 6, 2009 10:29 AM
  • Wow - this is an interesting case... I'd like to get some more clarifications.

    First off, I'll say that I know of no such mechanism around NAP bahavior, wireless, and turning on/off NAP for DHCP enforcement.

    When you say 'always got restricted IP address' - what do you mean?

    Did it end up with AutoNet addresses (169.254.x.x)?  If so, this is not a NAP restricted address; instead, this reflects the fact that the adapter was unable to reach a DHCP Server, and instead auto-selected its IP.  This means that the AP association is not connecting the client to any network where it can find a DHCP Server - most likely that the AP is misconfigured.

    For reference:
    When the DHCP client sends its Discover packet, it also sends an option that an MS DHCP Server will interpret as indicating that the client is NAP capable.  The server will then send a value back to the client in the Offer packet that indicates that the DHCP Server is NAP capable, effectively 'asking' the client send its SOH data.  The client will then respond with its REQUEST packet, which will contain the encapsulated SOH.  The DHCP Server relays the SOH to the NAP Server, get it evaluated, and create the final lease options based upon the results.  These lease options are then given to the client via the ACKnowledgement packet.

    This all occurs once the IP layer (layer 3) connectivity is available - and is not related to the Association process in any way.

    -Chris

    Chris.Edson@online.microsoft.com *
    SDET II, Network Access Protection
    * Remove the "online" make the address valid.
    ** This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, July 10, 2009 10:15 PM
  • Hi Chris,
    "Always got restricted IP address" means even the wirelss client be validated as the "health" by NPS (Network policy server), it failed to receive the IP from the DHCP server at specific range which we specified for NAP compliant client.
    Thursday, July 30, 2009 9:19 PM
  • Do you mean that you are trying to hand a different set of IPs to compliant vs. non-compliant clients?

    If so, then I believe you misunderstand how DHCP NAP enforcement works.
    It does not (can not) work by handing out addresses from different scopes/subnets to clients on the same physical subnet.  (that would be a routing nightmare)

    Instead, it follows the same address-selection logic, but plumbs a different set of options onto the client to 'lock down' networking.  It provides a 0.0.0.0 value for default gateway, along with a 255.255.255.255 (32bit) mask, effectively configuring the client's stack such that it cannot talk to other machines (it has no routing ability at all) on that interface.  You can then specify a set of remediation servers at the NAP Server/NPS which are then used by the DHCP Server in conjunction with the scope's default gateway option to plumb a set of host-to-host-only routes to the client to allow access only to specified resources.

    Please read this walk-through for more details:
    http://www.microsoft.com/downloads/details.aspx?FamilyID=ac38e5bb-18ce-40cb-8e59-188f7a198897&displaylang=en

    -Chris


    Chris.Edson@online.microsoft.com * SDET II, Network Access Protection * Remove the "online" make the address valid. ** This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, July 31, 2009 5:31 PM
  • Hi Matt,
        If your Access point is configured as "unsecured", Windows VISTA will not send its NAP Specific information to the NPS server. So, NAP Server (NPS) will treat that VISTA as non- NAP Capable machine. Sending such information on the unsecure wireless might expose a change for hacker to know the information about the computer, so it is blocked by design. Hope this answers your question.

     Feel free to ask if you have more questions.

    Thanks
    -RamaSubbu SK
    Sorry! Microsoft doesn't own any liability & responsibility for any of my posting.
    Monday, August 3, 2009 6:56 PM