{"id":1162,"date":"2008-08-21T08:00:57","date_gmt":"2008-08-21T08:00:57","guid":{"rendered":"http:\/\/www.markwilson.co.uk\/blog\/2008\/08\/microsoft-infrastructure-architecture-considerations-part-3-controlling-network-access.htm"},"modified":"2008-08-21T08:01:16","modified_gmt":"2008-08-21T08:01:16","slug":"microsoft-infrastructure-architecture-considerations-part-3-controlling-network-access","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2008\/08\/microsoft-infrastructure-architecture-considerations-part-3-controlling-network-access.htm","title":{"rendered":"Microsoft infrastructure architecture considerations: part 3 (controlling network access)"},"content":{"rendered":"

Continuing the series of posts on the architectural considerations for designing a predominantly-Microsoft IT infrastructure, based on the MCS Talks: Enterprise Infrastructure series<\/a>, in this post, I\u00e2\u20ac\u2122ll look at some of the considerations for controlling access to the network.<\/p>\n

Although network access control (NAC) has been around for a few years now, Microsoft’s network access protection (NAP)<\/a> is new in Windows Server 2008 (previous quarantine controls were limited to VPN connections<\/a>).<\/p>\n

It’s important to understand that NAC\/NAP are not security solutions but are concerned with network health – assessing an endpoint and comparing its state with a defined policy, then removing access for non-compliant devices until they have been remediated (i.e. until the policy has been enforced).<\/p>\n

The real question as to whether to implement NAC\/NAP is whether or not non-compliance represents a business problem.<\/p>\n

Assuming that NAP is to be implemented, then there may be different policies required for different groups of users – for example internal staff, contractors and visitors – and each of these might require a different level of enforcement; however, if the the policy is to be applied, enforcement options<\/a> are:<\/p>\n