Omawiając część serwerową, warto wspomnieć o usprawnieniach, które wprowadzono w stosunku do NAP wraz z wersją R2 dla Windows Server 2008. W poprzednich wersjach zbudowanie platformy NAP wymagało dodatkowej i żmudnej konfiguracji przynajmniej kilku baz danych SQL. W R2 zautomatyzowano ten proces, dzięki czemu skrócono czas etapu przygotowawczego. Poprawek dokonano także w module logowania, m.in. możliwe stało się uruchomienie logowania zarówno do serwera SQL, jak i do pliku płaskiego. Dodano również funkcję przełączania logowania z bazy do pliku płaskiego w razie awarii tej pierwszej.

Przed pojawieniem się R2 administrator miał do dyspozycji tylko jedną konfigurację dla SHV (System Health Validator). Wszelkie zmiany w konfiguracji agentów można było więc traktować jedynie całościowo. W R2 mamy już możliwość rozdzielenia reguł polityki przypisywanych poszczególnym układom konfiguracji. Dzięki takiemu zabiegowi będziemy w stanie przygotować znacznie bardziej granularne polityki bezpieczeństwa, oparte na większej liczbie zmiennych. Na przykład możliwe jest wprowadzenie rozdziału między wymaganiami dla stacji znajdujących się w sieci LAN (np. wymóg obecności tylko aktualnego oprogramowania AV) i dla użytkowników połączonych VPN-em (np. dodatkowo uruchomiona zapora ogniowa).

Kolejna zmiana polega na wprowadzeniu szablonów do usługi NPS. Pozwala to na budowanie elementów konfiguracyjnych serwera NPS (takich jak przypisanie klientów RADIUS, filtry IP) w taki sposób, że nadają się one do zastosowania na innym serwerze NPS. Jakakolwiek zmiana w szablonie powoduje, że automatycznie jest ona odwzorowywana wszędzie tam, gdzie aktywny jest dany szablon. Dobrym przykładem wykorzystania szablonów jest zmiana hasła współdzielonego (shared secret) dla klientów RADIUS. Pojawia się również możliwość przeprowadzenia migracji usługi IAS (Internet Authentication Services), pracującej pod kontrolą Windows Server 2003 do postaci, która jest akceptowana przez NPS.

Punkt kontrolny

Poza częścią czysto serwerową i klientem jest jeszcze jeden element architektury NAP - punkt wymuszania zgodności z polityką, czyli tzw. enforcement point. Co zatem może być wykorzystane jako taki punkt wymuszania? Przede wszystkim, jak w większości rozwiązań NAC, korzysta się z protokołu 802.1X i możliwości dynamicznego przydzielania VLAN-ów. Jest to najczęstszy scenariusz wymuszania dla sieci lokalnych. Konfiguracja tego trybu jest dosyć czasochłonna - wymagana jest parametryzacja samego serwera RADIUS, rekonfiguracja przełączników itp. W związku z tym, jeżeli projekt NAP ma zostać zrealizowany "na wczoraj" i nie ma czasu na te wszystkie zabiegi, możemy skorzystać ze znacznie prostszego mechanizmu. Jest on znany z niektórych produktów NAC innych producentów (np. Symantec NAC). Mowa tutaj o włączeniu w łańcuch wymuszania serwera DHCP. Jeżeli klient nie będzie zgodny z polityką, otrzyma adres z innej puli adresacyjnej, np. kwarantanny. W ten sposób zostanie mu ograniczony dostęp do zasobów. Jest to jednak bardzo proste i łatwe do obejścia zabezpieczenie. Wystarczy, że znamy pule adresacyjne i jesteśmy w stanie ręcznie przypisać stacji adres. Jeśli w ogóle bierzemy pod uwagę takie podejście, to powinno ono mieć wyłącznie charakter tymczasowy.

Wśród specjalistów panuje zgodność, co do tego, że prawdziwy NAC powinien opierać się przede wszystkim na infrastrukturze sieciowej, począwszy od warstwy drugiej, a dopiero potem poddawać inspekcji obszary położone wyżej w modelu OSI. Na 802.1x i DHCP możliwości NAP jednak się nie kończą. Kolejnym scenariuszem może być wykorzystanie w roli punktu wymuszania koncentratora VPN RRAS pracującego na serwerze W2K8. Zastosowano tutaj protokoły EAP-RADIUS i PEAP-TLV, które pozwalają na przenoszenie informacji o stanie klienta między serwerem a klientem NAP.