locked
NAP Conditions - Operating System RRS feed

  • Question

  • I am trying to allow all operating systems other than Windows operating systems full access to the network with no NAP enforcement.  There is an option under the conditions tab that will let me specify operating system, but the values I am able to set are numeric, and I can't seem to find a list that maps the numeric values to the different operating systems.  The only documentation I have found relating to NAP conditions was on technet, under one of the RADIUS options, which I don't want to use.
    Is there just one value for each vendor?  Will have have to specify every OS version that exists besides Microsoft to accomplish my goal? 

    I understand there was another thread on this addressing the same issue.  Two different scopes will not work in this case my case either.  I did not notice a question about specifying conditions for the OS.  However, it does seem that if those conditions were specified, that it is possible the client must first be NAP-capable before that condition can be evaluated.  If that is the case, am I just at a loss for trying to implement NAP on windows clients, while letting all other OS's and mobile devices be granted full network access? 

    Maybe there is a different way of implementing this that I haven't thought of.  Any help that can be provided would be greatly apperciated.


    -JC

    Thursday, August 27, 2009 11:31 AM

Answers

  • Hi JC,

    You can try the same testing I've been planning to do. First, I want to see if the operating system condition can match a non-Windows system. So, I would take a policy that the Ubuntu system is matching and modifiy it to add the operating system condition. Add something like the x86 or x64 condition - whatever architecture the Ubuntu machine is using. If you can get it to match the policy with this condition, I would try some other conditions also, such as client or OS version.

    The other test I wish to run is to determine if a non-NAP capable Windows system can match the operating system condition. I would take a computer with napagent OFF and test it using x86 or x64, and operating system version.

    When we have these results, we can decide the best way to configure the exemptions. The second test (whether a machine must be nap-capable to use the operating system condition) affects things the most.

    -Greg
    • Marked as answer by Miles Zhang Wednesday, September 2, 2009 1:33 AM
    Saturday, August 29, 2009 4:29 PM
  • Hi JC,

    I've tested this and confirmed that you can't use the condition unless NAP agent (or another service that provides SoH) is running on the access client. I also see that in Server 2008 R2 this is more clearly stated. The category of conditions is renamed from "Network Access" to "Network Access Protection."

    That means it (the operating system condition) will not be useful to provide exemptions to systems running Ubuntu. You also can't use it for Windows clients that have NAP agent off. We are left with the problem of differentiating Windows vs. non-Windows clients using only the DHCP request. I'll have to think about this further and see what options are available.

    -Greg

    • Marked as answer by Miles Zhang Wednesday, September 2, 2009 1:33 AM
    Monday, August 31, 2009 9:00 PM

All replies

  • Hi JC,

    There are several ways to specify exemptions. Some methods require that you use NPS policies, and others do not. It depends largely on what enforcement mechanism you use. For example, if you use DHCP enforcement then any system with a static IP configuration is automatically exempt.

    If you use policies, this requires that the systems send network access requests for processing by NPS. If the devices are members of an Active Directory domain, or if the user logging on the device is a domain user, then you can establish exemptions by using a security group condition. Other possibilities include configuring exemptions based on MAC address, IP address, DHCP scope, network access device, and several others. The type of exemption you use depends on how the device accesses the network.

    In regard to the operating system condition, I will need to ask the NPS team how various client systems report this in the access request packet and whether it is useful for non-Windows systems.

    -Greg
    Friday, August 28, 2009 5:48 AM
  • Hi Greg,

    Thank you for the response.  I should have clarified my original question by letting you know my environment.  I'm trying to use DHCP enforcement in a workgroup environment.  Clients will connect to a WAP and login through a Bluecoat SG (have not determined authentication method yet) and then they will be give access to the internet.  The idea is to apply NAP enforcement before they login through the SG.  So any windows XP SP3 or Vista clients will have to meet the SHV requirements, while all other clients will get an IP in the default DHCP class and be given full access after authenticating to the SG.  Clients could range from linux, mac, and mobile devices.  While using NAP is not a requirement, we would like to at least get the windows clients enforced using NAP, as the majority of clients will be windows.  I am not set on using DHCP as the enforcement mechanism, it is just the only one I know well, and from the surface seemed like it might work.

    -JC
    Friday, August 28, 2009 2:24 PM
  • Hi JC,

    If you want to catch the computers that are NAP-capable and evaluate their health, but let everything else through this is fairly simple. You could do this by creating a noncompliant policy, a compliant policy, and a "everything else" policy. The "everything else" policy must be last in the processing order, and could use "Computer is not NAP-capable" as a condition or something as simple as Time of Day with all times being allowed.

    The disadvantage to this type of configuration is that Windows computers with NAP agent turned off will be allowed full access just like the linux, mac, and mobile devices. If that is a concern, you could create another policy that combines "Computer is not NAP-capable" with the Operating system condition. I'm checking right now as to whether or not the Operating System condition can match non-Windows systems.

    -Greg
    Friday, August 28, 2009 8:13 PM
  • Hi Greg,

    That is one thing I wanted to avoid, allowing clients to get full access because of the agent not running, which is why I started looking at the conditions in order to allow all devices full access except those running a Windows OS.  The idea would be for the operating system condition(s) to be set to only windows OS values, and anything that doesn't meet one of those will be considered NAP in-capable and allowed access. 

    -JC
    Saturday, August 29, 2009 5:52 AM
  • Hi JC,

    I wish I had tested this previously, but I suspect that OS version means Windows OS version (output of "ver" at a command line). If that is true, then a Mac or Linux computer would be "null" and you can use this condition to evaluate only Windows computers. I am still waiting for clarification on this. One thing I've been told leads me to believe you can't use this condition at all for non-NAP capable computers, but I'm not positive. Sorry I don't have an answer right now for you. I hope to get time to set up a non-Windows client and add it to my NAP test lab so I can verify the behavior. Please let me know anything you find out in the meanwhile.

    -Greg

    Saturday, August 29, 2009 6:05 AM
  • Hi Greg,

    Thanks for the quick response.  I did setup an Ubuntu machine in my environement, and it has been treated as non-capable for NAP, but gets onto to the restricted network since that is what the non-capable NAP policy is set to.  I came across the operating system condition and that is when I stopped to find out more.  I would be more than willing to try any suggestions you might have.  Thanks for your time, I apperciate it.

    -JC
    Saturday, August 29, 2009 7:19 AM
  • Hi JC,

    You can try the same testing I've been planning to do. First, I want to see if the operating system condition can match a non-Windows system. So, I would take a policy that the Ubuntu system is matching and modifiy it to add the operating system condition. Add something like the x86 or x64 condition - whatever architecture the Ubuntu machine is using. If you can get it to match the policy with this condition, I would try some other conditions also, such as client or OS version.

    The other test I wish to run is to determine if a non-NAP capable Windows system can match the operating system condition. I would take a computer with napagent OFF and test it using x86 or x64, and operating system version.

    When we have these results, we can decide the best way to configure the exemptions. The second test (whether a machine must be nap-capable to use the operating system condition) affects things the most.

    -Greg
    • Marked as answer by Miles Zhang Wednesday, September 2, 2009 1:33 AM
    Saturday, August 29, 2009 4:29 PM
  • Hi Greg,

    Those are good suggestions, unfortuantely I won't be back in the office until Wednesday.  I have set up an ESX whitebox at home, but I just moved and it isn't setup yet.  If I can, I will set it up  and try those things out.  If not, I will try it on Wednesday and let you know the results.

    -JC
    Saturday, August 29, 2009 7:58 PM
  • Hi JC,

    I've tested this and confirmed that you can't use the condition unless NAP agent (or another service that provides SoH) is running on the access client. I also see that in Server 2008 R2 this is more clearly stated. The category of conditions is renamed from "Network Access" to "Network Access Protection."

    That means it (the operating system condition) will not be useful to provide exemptions to systems running Ubuntu. You also can't use it for Windows clients that have NAP agent off. We are left with the problem of differentiating Windows vs. non-Windows clients using only the DHCP request. I'll have to think about this further and see what options are available.

    -Greg

    • Marked as answer by Miles Zhang Wednesday, September 2, 2009 1:33 AM
    Monday, August 31, 2009 9:00 PM
  • Hi Greg,

    Well those results are unfortunate.  I apperciate you taking the time to test it out though.  Are there ways of accomplishing my goals through other NAP implementations?  Possibly at the hardware layers?  I haven't looked at the 802.1x implementation yet and am not sure of its capabilities.  Thanks again Greg.

    -JC
    Wednesday, September 2, 2009 2:02 PM
  • I am currently trying to do the same thing, but I've been going about it a backwards.  I am trying to set an OS condition that only Windows will match and Ubuntu/Fedora clients will move on to the next enabled policy (in processing order).  I'm not having much luck either.

    I tried setting something like OS Version >= 5.1, but linux still matched it.  I tried OS Version = 5.1 OR 6.0 OR 6.1, but linux still matched it.

    I'm doing this on an 802.1x network, not using DHCP enforcement.
    Thursday, October 15, 2009 8:21 PM
  • I am throughly confused here.

    OS Version = 5.1 OR 6.0 OR 6.1 Fails, Ubuntu matches this rule for whatever reason.
    OS Version = 5.1 OR OR 6.1 WORKS!  Ubuntu does not match and moves on to the next policy.

    But, I do have Vista machines so it still is not a solution.
    Joe
    Friday, October 16, 2009 4:39 PM