Network Access Protection, Revisited (Part 1)

If you would like to read other parts to the article series please read:

  • Network Access Protection, Revisited (Part 2)
  • Network Access Protection, Revisited (Part 3)
  • Network Access Protection, Revisited (Part 4)
  • Network Access Protection, Revisited (Part 5)
  • Network Access Protection, Revisited (Part 6)
  • Network Access Protection, Revisited (Part 7)
  • Network Access Protection, Revisited (Part 8)
  • Network Access Protection, Revisited (Part 9)
  • Back in 2006, I wrote a series of articles called Introduction to Network Access Protection. As you might have heard, Network Access Protection is a feature that is going to be built into Windows Server 2008 (formerly known as Longhorn Server). When I wrote that original article back in 2006, Windows Server 2008 was still in early beta testing. I went ahead and wrote the piece, because Network Access Protection seemed like such an important security feature that I wanted to help administrators understand what it was and how it worked, so that when Windows Server 2008 was eventually released, anyone who had read my article would be ready to implement Network Access Protection.

    Now that Windows Server 2008 has finally been released to manufacturing, I decided to take a look back at my article series on Network Access Protection. Although most of the concepts discussed in the article are still valid, some of the steps involved in the implementation process have changed rather drastically.

    My goal in writing this article is to update my original Network Access Protection series. In this first article in the series, I will introduce you to Network Access Protection, and explain how it works. From there, I will walk you step by step through the implementation process.

     What is Network Access Protection?

    Network Access Protection, or NAP as it is sometimes called, was created to address one of the major frustrations that network administrators often experience. As a network administrator, I’m sure that you have probably put a lot of time and effort into making your network is secure as possible. The problem is that some of the machines on your network are outside of your direct control, and have previously been difficult or impossible to secure.

    I am talking, of course, about remote users. It is easy to secure desktop workstations that reside on premise, and you can probably even get away with securing user’s laptops, so long as those laptops are company property. However, in many organizations, users like to logon from their home computer using a VPN connection so that they can do some work after hours without having to travel to the office. Because the company does not own these machines, the administrator staff has no direct control over them.

    Prior to the creation of Network Access Protection, I have always fought to keep machines outside of the direct control of the administrative staff from connecting to the network. My reason for this is that over the years I have run into some really scary home machines. It is not at all uncommon to find home machines that are completely infested with viruses and spyware, or that are still running outdated operating systems. From time to time, I still have people asking me about problems that they are having with Windows 98.

    Network Access Protection is designed to alleviate these concerns. When a user connects to your network, the user’s machine can be compared against a health policy that you have established. The actual contents of this health policy will likely vary from one organization to another, that you can require that the user’s operating system have the latest security patches, and that the machine be running up-to-date antivirus software, and things like that. If the machine meets the criteria that you have established in the policy that the machine is free to connect to the network in the usual manner.  If the machine does not comply with your policy, then you can choose to deny network access to the user, fix the problem on the spot, or go ahead and let the user have access but make a note of the state of the user’s machine.

    Some Terminology to Know

    Before I can really get started in explaining how Network Access Protection works, you need to be familiar with the terminology that Microsoft uses in regard to Network Access Protection.

    The first-term that you need to be familiar with is Enforcement Client, sometimes abbreviated as EC. An Enforcement Client is nothing more than the client machine that is attempting to connect to your network. Keep in mind that not all workstations are compatible with Network Access Protection. In order to be considered an Enforcement Client, the workstation must be able to run the System Health Agent component, which I will talk about a little bit later on. Only Windows Vista and Windows XP SP3 are capable of running the System Health Agent, and therefore these are the only workstation operating systems that are compatible with Network Access Protection.

    The next term that you need to be familiar with is System Health Agent, or SHA. The System Health Agent is an agent that runs as a service on the workstation, and monitors the Windows Security Center. The agent is responsible for reporting system health information to the Enforcement Server upon connection.

    As you might have guessed, the next term that I want to talk about is Enforcement Server. The Enforcement Server is a server that enforces the policies that are defined by Network Access Protection.

    Another term to know is System Health Validator, or SHV. The System Health Validator takes the information that has received from the System Health Agent, and compares that information against the health policy that has been defined.

    The last term that I want to talk about is Remediation Server. A remediation server is a server that is made accessible to enforcement clients that are found not to comply with the network access policies that have been established. Typically, a remediation server will contain all the mechanisms that are necessary for making the enforcement client compliant with the policies. For example, a remediation server might apply security patches to the enforcement client.

    Network Access Protection’s Limitations

    One last thing I want to be sure to mention about Network Access Protection is that Network Access Protection offers you a way of enhancing your organization’s security, but it does not replace the other security mechanisms that you are already using. Network Access Protection does a great job of ensuring that remote clients comply with your network security policy. In fact, it will probably do an even better job of enforcing this policy as time goes on, because the policy is based on open standards. This means that third-party software vendors will be able to write their own policy modules, which will allow you to create security policies that apply to third party software running on the enforcement client.

    What Network Access Protection does not do is that it will not keep intruders off of your network. Network Access Protection only ensures that workstations being used for remote access to the network meets certain criteria. Therefore, Network Access Protection will only stop a hacker if their machine does not comply with your security policy. If a hacker’s machine is compliant, then it will be up to your other security mechanisms to make sure that the hacker is denied access.

    Conclusion

    In this article, I have explained that Network Access Protection provides you with a way of ensuring that any workstation that establishes a connection to your network conforms to your network’s security policy. In the next article in this series, I will continue the discussion by showing you how to implement the Network Access Protection feature.

    If you would like to read other parts to the article series please read:

    • Network Access Protection, Revisited (Part 2)
    • Network Access Protection, Revisited (Part 3)
    • Network Access Protection, Revisited (Part 4)
    • Network Access Protection, Revisited (Part 5)
    • Network Access Protection, Revisited (Part 6)
    • Network Access Protection, Revisited (Part 7)
    • Network Access Protection, Revisited (Part 8)
    • Network Access Protection, Revisited (Part 9)
    • About The Author

      Leave a Comment

      Your email address will not be published. Required fields are marked *

      This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

      Scroll to Top