W ramach roli NPS - a właściwie Network Policy and Access Services (jak zresztą wskazuje nazwa) - konfigurujemy zasady polityki. Możemy tu uwzględnić różne stany stacji klienckiej i dla każdego z nich przypisać określone działania. Zanim to jednak nastąpi, trzeba skonfigurować samą usługę NPS. Musimy ustawić: SHV (wymagania konfiguracji klienta), reguły polityki zgodności (przyjmujące wartości "zgodny", "niezgodny"), zasady polityki dostępu do sieci (np. przypisanie do VLAN-u kwarantanny), politykę połączenia (np. z wykorzystaniem uwierzytelniania EAP), przypisanie klientów RADIUS oraz wskazanie serwerów naprawczych ("remediation server group").

Przygotowanie samych reguł polityki nie nastręcza zbyt wielu problemów, co częściowo spowodowane jest niezbyt szerokim wachlarzem dostępnych sprawdzeń. Jak wspomnieliśmy, po instalacji NPS mamy jeden zestaw sprawdzeń - WSHVW. W jego ramach otrzymujemy tylko pięć opcji do wyboru:

obecność i aktualność oprogramowania antywirusowego

obecność oprogramowania antyspyware (tylko w przypadku Visty/Windows 7)

stan zapory ogniowej

włączone/wyłączone automatyczne aktualizacje

zainstalowane aktualizacje określonej ważności/ brak aktualizacji określonej ważności.

Liczba dostępnych "z pudełka" sprawdzeń to nie jedyne ograniczenie NAP-a, sporo do życzenia pozostawia też raportowanie. Brakuje dedykowanych narzędzi, które pozwoliłyby na szybkie uzyskanie szczegółowego obrazu bezpieczeństwa stacji roboczych.

Sam NAP zatem nie wystarczy (przynajmniej na razie) jako samodzielne rozwiązanie NAC w zróżnicowanym środowisku. Dopiero integracja z innymi produktami, np. Cisco lub zgodnymi z TCG-TNC, pozwoli na rozwinięcie skrzydeł. A skoro mowa o Cisco..., swego czasu głośno było o integracji Cisco NAC z Microsoft NAP. Współpraca ta, choć możliwa, nie przebiega wprost. Ani klient NAP nie jest w stanie bezpośrednio porozumieć się z serwerem Cisco, ani agent Cisco nie rozmawia wprost z NPS. Możliwa jest jednak wymiana informacji. Agent MS NAP przekazuje informacje o stanie klienta do serwera Cisco ACS, a ten dalej do NPS. Wreszcie NPS przekazuje rezultaty sprawdzenia do Cisco ACS, który odpowiada za właściwe wymuszenie polityki. Wymiana danych między ACS a NPS jest możliwa dzięki protokołowi HCAP (Host Credentials Authorization Protocol), którego obsługę możemy włączyć już na etapie konfiguracji roli serwera NPS.

Inni konkurenci MS NAP również uznają jego potencjał i zawczasu starają się uczynić swoje rozwiązania "NAP compliant". Dzięki temu, w bardzo krótkim czasie liczba partnerów Microsoft NAP przekroczyła sto. Wśród nich znajdują się zarówno firmy tradycyjnie kojarzone z bezpieczeństwem desktopów (McAfee, Kaspersky, Symantec), jak i te z branży sieciowej (np. Extreme Networks, Enterasys). Są też firmy, które wyraźnie stawiają na komponenty MS NAP, tu przykład stanowi chociażby Napera z rozwiązaniem N24, które jest połączeniem funkcjonalności przełącznika Gigabit Ethernet z 802.1x, protokołów stosowanych przez NAP oraz komponentów zastępujących usługi NAP realizowane przez Windows 2008. N24 znacznie rozszerza możliwości budowania reguł polityki dostępnych natywnie w MS NAP, chociażby o powiązanie ich z tożsamością użytkownika czy portem.

Myśląc więc o wdrożeniu NAC, należy przede wszystkim przeprowadzić inwentaryzację produktów wykorzystywanych w naszej organizacji oraz plany ich migracji. Może się okazać, że mamy już sporo elementów, które będą nadawały się do zbudowania układanki NAC, a to pozwoli nam uniknąć kosztownych i niepotrzebnych zakupów u jednego producenta.