locked
Restricted access how to? (SDK) RRS feed

  • Question

  • I am developing an custom NAP solution for both SHV and SHA using the existing SDK that is out there, and modifying it.
    I have got to the point where the client returns back to the server a value, and depending on this value the SHV logic is to say if the system is healthy or not healthy.

    this is all fine.

    But now, if the system is not healthy.... what do we do next? I mean, ideally the client computer should be disconnected or connected to a restricted network or something..... but is this "rule" configured in NPS? Or do we have to develop it ourselves in the SHV SDK?

    the compliant result setting is there in the code as it was (patches/not patched) and is being set correctly, but still unable to see that the client is connected to a restricted network.

    In the NPS itself, a health policy is set for compliant and non compliant. the non compliant states that if the "SDK" fails one or more client checks, then its a fail.
    but what exactly are the "checks"? how does it know what is a pass/fail? is this being set/passed from the plugin/SHV?
    Need 2 be back @ MS - MS All the way! Follower since 1995 MS Super Evangelist| MSDN Forums Moderator
    • Edited by ahmedilyas Monday, August 17, 2009 3:02 PM
    Monday, August 17, 2009 2:47 PM

Answers

  • Ahmed,

    To set up a working NAP DHCP end to end, please refer to the "Stepy-by-Step Guide: NAP DHCP": http://www.microsoft.com/downloads/details.aspx?FamilyID=ac38e5bb-18ce-40cb-8e59-188f7a198897&displaylang=en

    By following the steps in this doc, you should be able to put the client in restricted state.  Try first putting the client in restricted state using only Windows SHA/SHV but without SDK SHA/SHV.  This is so that you flush out issues you might have with your end-to-end setup.  After that's successful, then you try putting the client in restricted state using the SDK SHA/SHV. 

    Let us know how it goes.


    Howard Lee - Microsoft
    Tuesday, August 18, 2009 7:38 PM
  • Ahmed,

    Sounds like you've modified the code a bit.  Could you send me your changes, so that I can debug?  Also, have you tried the original NAP SDK SHA/SHV to see whether you're able to put the client into restricted state?

    Howard
    Howard Lee - Microsoft
    Tuesday, August 18, 2009 11:13 PM

All replies

  • Ahmed,

    I'm glad to hear your progress.  You don't have to develop this rule in your SHV SDK. 

    Putting your client in a restricted network is done by your NAP enforcement and has nothing to do with your SHA/SHV.  Say if you've deployed NAP with IPsec enforcement, when your client's deemed non-compliant, the client's NAP health cert will be deleted so that it will only be able to access limited network resources.  Say if you've deployed NAP with 802.1x enforcement, when the client's deemed non-compliant, the client will be put into a different VLAN that gives it access to only limited resources.  Similarly for other enforcements.

    Those checks on the client correspond to the values you put inside the Compliance Result Code List attribute you put in the SHV response, like QUAR_E_COMPLIANT, QUAR_E_NOTPATCHED, etc.  The non compliant states that if the "SDK" fails one or more client checks, then its a fail.  This means that if one or more of the Compliance Result Codes are non-compliance, then it's a fail.  So, yes these values are set by SHV.

    Hope this makes sense.
    Howard Lee - Microsoft
    Tuesday, August 18, 2009 1:21 AM
  • Thank-you, I appreciate that Mr.Lee!

    I'm just using the SDK as it is, and modifying the small bits I need to modify. The QUAR_E_COMPLIANT/NOTPATCHED etc... values are as is currently in the SHV SDK but placed a simple if condition around them to indicate what is considered healthy from the client response, and what isn't. This does work logically, but cannot see the client go into restricted mode access. Maybe my NPS policy for this SDK is not setup correctly? (using the DHCP approach here).

    I added the "if client passes all checks" and the "if client fails one or more checks" health policy on the SDK/SHV plugin and created a network policy for full and limited access.... but the client still (when reports unhealthy to the SHV) has the full network access, even though in the SHV the complianceResult = QUAR_E_NOTPATCHED; value is set in the CheckRequestSoHHealth method on the SHV code.

    Need 2 be back @ MS - MS All the way! Follower since 1995 MS Super Evangelist| MSDN Forums Moderator
    Tuesday, August 18, 2009 11:15 AM
  • Ahmed,

    To set up a working NAP DHCP end to end, please refer to the "Stepy-by-Step Guide: NAP DHCP": http://www.microsoft.com/downloads/details.aspx?FamilyID=ac38e5bb-18ce-40cb-8e59-188f7a198897&displaylang=en

    By following the steps in this doc, you should be able to put the client in restricted state.  Try first putting the client in restricted state using only Windows SHA/SHV but without SDK SHA/SHV.  This is so that you flush out issues you might have with your end-to-end setup.  After that's successful, then you try putting the client in restricted state using the SDK SHA/SHV. 

    Let us know how it goes.


    Howard Lee - Microsoft
    Tuesday, August 18, 2009 7:38 PM
  • it does work with the Windows SHA/SHV as say if I turn off the firewall, i can see it being in the restricted.contoso.com region.... then when the firewall is automatically enabled.... it goes back to the unrestricted region.

    Need 2 be back @ MS - MS All the way! Follower since 1995 MS Super Evangelist| MSDN Forums Moderator
    Tuesday, August 18, 2009 8:26 PM
  • Ahmed,

    Sounds like you've modified the code a bit.  Could you send me your changes, so that I can debug?  Also, have you tried the original NAP SDK SHA/SHV to see whether you're able to put the client into restricted state?

    Howard
    Howard Lee - Microsoft
    Tuesday, August 18, 2009 11:13 PM
  • Hi Ahmed,

    It appears you are working with Howard, so I will mark your question as answered. If you still have questions, un-mark it and let us know what further information you need.

    Thanks,
    -Greg
    Saturday, August 22, 2009 6:16 PM