Nap windows server 2012 что это

The step by step guide to configure Network Access Protection (NAP), in Windows Server 2012 R2.. The NAP is a Microsoft technology for controlling network access of a computer, based on its health. With NAP, system administrators of an organization can define policies for system health requirements. For instance System health requirements are whether the computer has the most recent operating system updates installed. The computer host based firewall is installed and enabled etc.

The NAP is completely removed from Windows server 2016. It will be replace with Direct Access and new network policy feature Web Application Proxy. Also the DHCP servers are no longer capable of enforcing NAP policies.

The above screenshot is Network Policy Server in Windows Server 2016 without Network Access Protection. It shows that you must get ready to migrate from NAP to DirectAccess and Windows Web Application Proxy in Server 2016. I didn’t want to write this article, so it must be written for new admins in Windows Server 2008 and 2012 R2.

This post is going to configure network access protection. If you don’t know the installation, read the below article about installation of NAP in Windows server 2012 R2.

• Installing Network Policy Server (NPS) on Windows Server 2012 R2

1. To configure network access protection, open network policy server from server manager.
2. On the network policy server page, from right side select NPS (Local) then select Network Access Protection (NAP) from Standard Configuration section and click Configure NAP link.

3. On the network connection method for use with NAP page, select Dynamic Host Configuration Protocol (DHCP) from Network connection method section then click Next.

4. On the Specify NAP Enforcement Server Running DHCP Server page, just click Next. Then click Next on the Specify DHCP Scopes page. Do click Next on Configure Machine Group also.

5. On the Specify a NAP Remediation Server Group and URL click New Group and type a meaningful name for Group Name. Then click Add to specify a name for Freindly name and name or IP address of Remediation server.  When complete, click OK to close the pages.

6. Now type the help page url address on Troubleshooting URL and click Next.

The Remediation Server Groups are the servers that will be made accessible to non-compliant clients. These servers can be used to patch clients to a compliant status.

7. Click Next on Define NAP Health Policy page.

8. Finally click Finish to complete the NAP enforcement policy and RADIUS client configuration.

9. Navigate to Network Policies and Health Polices to check whether the polices are ready for serving NAP.

So, everything good.

Configure Group Policy and Services for NAP

After installing and configuration of NAP, you should enable DHCP Client enforcement from group policy management.

1. Type “gpmc.msc” on the run and press enter to open Group Policy Management.
2. Expand Forest, Domain, and domain name. Then create a new group policy object, and named NAP enforcement.
3. Now right click on the new created GPO and click Edit to edit it.
4. Navigate to NAP Client Configuration and select Enforcement Clients. Finally right click DHCP Quarantine Enforcement Client and enable it.  Do it like below screenshot.

5. Navigate to System Services and find Network Access Protection Agent then enable it.

6. Go to DHCP, right click IPv4 then select Properties. Now on the Network Access Protection tab, click Enable on all scopes.

That’s all, but don’t forget to configure the Windows Security Health Validator for clients. The default policy is require the Firewall and Auto Update should be enabled, Anti Virus, Spyware Protection must be installed on the client systems.

OK, hope you find this article helpful. Any question? Ask through comment sections. So have a nice and great time as system admin.

Уже месяц прошел с того момента, как была анонсирована Windows 10 Technical Preview и как был представлен Windows Server Technical Preview. Для того, чтобы увидеть произошедшие изменения, даже не нужно глубоко копаться в системах – интерфейс уже другой – вернулась кнопка пуск, нет стартового меню… На самом деле, в нашем блоге уже рассказывали об изменениях и в Windows 10, и в Windows Server Technical Preview, и даже в System Center. Я же сегодня хочу рассказать о тех изменениях, которые ожидают нас в работе с сетью. К сожалению, не все обещанные возможности можно проверить на работоспособность в технической версии – но на то это и Technical Preview. Заинтересовавшихся жду под катом.

Изменения и дополнения, которые появились в Windows Server Technical Preview и касаются работы с сетью, касаются следующих компонентов сервера:

1. DHCP
2. DNS
3. GRE Tunneling
4. IPAM
5. Network Controller

Официальные источники (читай: блоги разработчиков и форумы) сообщают, что в Windows Server Technical Preview не работают новые возможности IPAM, а также нельзя полностью настроить и протестировать Network Controller. Зато об изменениях в работе DHCP, DNS и VPN туннелей можно не просто почитать, но еще и самостоятельно с этими службами поэкспериментировать (эксперименты лучше ставить в тестовой среде). Давайте посмотрим на все изменения по порядку.

1 DHCP

В новой версии сервера DHCP больше не поддерживает Network Access Protection (NAP). Поддержка NAP была реализована в Windows XP Service Pack 3, Windows Vista и Windows Server 2008, но уже в Windows Server 2012 R2 эта функция была отнесена к устаревшим, и вот в Windows Server Technical Preview удалена уже насовсем. Изменения мы можем увидеть в Group Policy Management:

Теперь, DHCP сервер не будет применять политики NAP, а защита доступа к сети для DHCP зон будет выключена. Как же будет происходить взаимодействие с другими версиями, которые NAP поддерживают? DHCP-клиент, поддерживающий NAP, будет отправлять сведения о состоянии работоспособности (Statement of Health, SoH). Если DHCP сервер будет запущен на сервере под управлением Windows Server Technical Preview, то эти запросы будут обрабатываться так, как будто сведений о состоянии работоспособности нет и в этом случае будет предоставляться нормальная аренда DHCP. Кроме того, Windows Server Technical Preview может быть установлен на сервер, выполняющий роль RADIUS прокси и перенаправляющий запросы об аутентификации на сервер политики сети (Network Policy Server, NPS). Если сервер политики сети будет поддерживать NAP, то в этом случае NAP-клиенты будут считаться NAP несовместимыми.

2 DNS

Изменения в работе DNS касаются как клиентской, так и серверной части. Изменения, касающиеся клиентской службы DNS, которые были заявлены в Windows 10 Technical Preview, также актуальны и для компьютеров с установленной Windows Server Technical Preview.
Что же изменилось в серверной части DNS? Тут нововведения делятся на две группы. Первая часть коснулась журнала событий и диагностики. Более того, с этими изменениями можно познакомиться и в Windows Server 2012 R2, если перед этим установить соответствующий hotfix. Но в Windows Server Technical Preview все возможности доступны без каких-либо дополнительных установок.

Для DNS сервера расширена функциональность записи событий в журнал событий и диагностики, а именно включены события аудита и аналитики. Для того, чтобы эту функциональность включить, необходимо открыть Event Viewer, в ней перейти в Application and Services LogsMicrosoftWindowsDNS—Server. Щёлкнув правой кнопкой мышки по DNS-Server, выберите View, а затем Show Analytic and Debug Logs. В результате будут отображен лог Analytical; щелкнув по нему, выбираем свойства. В появившемся окне необходимо выбрать пункт Do not overwrite events (Clear logs manually) в пункте When maximum event log size is reached, выбрать чекбокс Enable logging и нажать ОК.

В чем интересные особенности этого решения. Во-первых, расширение возможностей ведения журнала событий и диагностики мало сказываются на производительности, уменьшая нагрузку на сервер. Во-вторых, логи DNS совместимы с клиентскими приложениями ETW (logman, tracelog, message analyzer). Используя эти приложения, вы можете получать, например, трейсы всех аналитических и аудит-событий, и анализировать уже собранные логи с помощью журнала событий и диагностики
Ко второму глобальному нововведению в DNS сервере можно отнести новую функцию, получившую название «DNS политики» (DNS Policies). C помощью DNS политик у системного администратора появляется возможность сконфигурировать DNS сервера так, чтобы можно было контролировать ответы на DNS запросы. Ответы могут быть основаны на общем IP адресе DNS клиента, времени суток, и нескольких других параметрах. Кроме того, политики DNS позволяют определять местоположение DNS, управлять траффиком, балансировать нагрузки, а также обещают реализовывать некоторые другие сценарии. Однако более конкретной информации пока нет; надеемся, что она появится ближе к финальной версии.

3 GRE Tunneling

В Windows Server Technical Preview представлено дополнение, которое позволяет использовать возможности протокола GRE (Generic Routing Encapsulation) для Windows Server Gateway. Теперь GRE можно использовать в интерфейсе S2S (site-to-site). Данный интерфейс используется для установки соединения между вашей локальной и виртуальной сетью. В предыдущих версиях, при создании соединения S2S можно было установить безопасное соединение. Не всегда это решение было самым удобным – необходимость создания отдельных туннелей для подсетей, невозможность создания маршрутизируемых интерфейсов, и т.д.
Использование протокола GRE позволяет эти проблемы решить. С одной стороны, GRE менее безопасен, но его можно использовать совместно с защищенным протоколом. С другой стороны, при использовании GRE туннеля, вы не ограничены типом трафика, который может быть по туннелю передан. Также GRE позволяет маршрутизировать несколько сетей, не требуя при этом создавать несколько туннелей.
Для GRE протокола были дополнены командлеты Windows PowerShell, работающие с протоколом S2S (Add-VpnS2SInterface, Set-VpnS2SInterface и Get-VpnS2SInterface. Далее приведу примеры использования этих командлетов.

Шлюз на стороне облака

Создание нового туннеля

Add-VpnS2SInterface –Name GreCloudToEnt1 –Destination <Destination IP> -IPv4Subnet “10.1.1.0/24:1000” –GRETunnel –GREKey “12345” –SourceIP: <public interface IP> -RoutingDomain Rd1

Изменение существующего туннеля

Get-VpnS2SInterface –Name GreCloudToEnt1 | Set-VpnS2SInterface –EnableQos Disabled –GRETunnel –RoutingDomain Rd1

Удаление GRE туннеля

Get-VpnS2SInterface –Name GreCloudToEnt1 | Set-VpnS2SInterface –AdminStatus $false – GRETunnel –RoutingDomain Rd1

Шлюз на стороне предприятия

Создание нового туннеля

Add-VpnS2SInterface –Name GreEnt1ToCloud –Destination <Destination IP> -IPv4Subnet “10.1.2.0/24:1000” –GRETunnel –GREKey “12345” –SourceIP: <Enterprise_IP>

Изменение существующего туннеля

Get-VpnS2SInterface –Name GreEnt1ToCloud | Set-VpnS2SInterface –EnableQos Disabled – GRETunnel

Удаление GRE туннеля

Get-VpnS2SInterface –Name GreEnt1ToCloud | Set-VpnS2SInterface –AdminStatus $false -GRETunnel

Вот тут конкретика более или менее заканчивается. К сожалению, возможности IPAM и новой роли Network Controller пока не протестируешь. Превращать этот пост в еще больший обзор я не хочу, поэтому очень поверхностную информацию про IPAM и Network Controller я спрячу под спойлеры ниже – кому интересно, посмотрите:

Что ж, надеюсь, что вы нашли в этой статье для себя что-то полезное. Я продолжаю ждать новой информации о Windows Server Technical Preview (хочется уже конкретики и, желательно, целиком и полностью, работающей) и желаю вам удачных экспериментов, в которых вам помогут уже имеющиеся материалы на Хабре:

1. Первый взгляд на Windows Server Technical Preview
2. Как попробовать новый Windows Server Technical Preview без установки
3. Первый взгляд на System Center Virtual Machine Manager Technical Preview

Полезные ссылки

• Попробовать Azure бесплатно на 30 дней!
  • Центр разработки Microsoft Azure (azurehub.ru) – сценарии, руководства, примеры, рекомендации по разработке
  • Twitter.com/windowsazure_ru — последние новости Microsoft Azure
  • Сообществе Microsoft Azure на Facebook – эксперты, вопросы

• Изучить курсы виртуальной академии Microsoft по облачным и другим технологиям
  • Бизнес и облако: лучшие практики решений
  • Windows 8.1 Update для крупных организаций. Начало работы
  • Гибридное облако Microsoft: Руководство по типовым решениям
  • Набор средств для подготовки пользователей к Windows 8.1
  • Введение в графическую библиотеку Win2D

• Загрузить бесплатную или пробную Visual Studio
• Стать разработчиком универсальных приложений Windows

As promised, today lets go through my Part 1 of 7, step by step on how to deploy Network Access Protection in Windows Server 2012 R2.

I can promise you this deployment will be major, so many step to go through, and for that reason, i prepare 7 parts of the Step by Step so that you as a IT Administrator can understand the flow of the deployment and please take time to read more on the NAP.

a little bit of information about NAP :

NAP is a policy-enforcement platform that is built into all Windows client computers beginning with the WinXP SP3, and all server-based operating systems beginning with the Windows Server 2008.

You can use NAP to protect network assets more strongly by enforcing compliance with system-health requirements. NAP provides the necessary software components to help ensure that computers connected or connecting to your network remain
manageable, and so that they do not become a security risk to your enterprise’s network and other attached computers.

Understanding the functionality and limitations of NAP will help you protect your network from the security risks posed by noncompliant computers.

For more information on the NAP : http://technet.microsoft.com/en-us/network/bb545879.aspx

In this Part 1, lets go through how to configure Server and Client Certificate Requirements / Health Policies before we jump into NAP deployment…

1 – On OSI-ADDS01 server, open Server Manager, click Tools, and then click Certification Authority…

** in case you do not have Certificate Authority installed, please log in to my previous post : Installing Certificate Authority on Windows Server 2012 R2 (https://mizitechinfo.wordpress.com/2014/07/19/step-by-step-installing-certificate-authority-on-windows-server-2012-r2/)

2 – In the certsrv management console, double click osi-ADDS01-CA, right-click Certificate Templates, and then
select Manage on the context menu…

3 – In the Certificate Templates Console, right-click Computer, and then click Properties…

4 – In the Computer Properties box, click the Security tab,  select Authenticated Users, an then in the Permissions for Authenticated Users, tick Allow check box for the Enroll permission, and then click OK.

5 – Next, in certsrv – [Certification Authority (Local)] console, right-click osi-ADDS01-CA, point to All Tasks, and then click Stop Service…

6 – Next, right-click  osi-ADDS01-CA again, point to All Tasks, and then click Start Service…

7 – Next, log in to another server (OSI-NPS), in this new server we are going to enroll new certificate from AD into this OSI-NPS Server :

– On the OSI-NPS Server, open MMC…

8 – On the OSI-NPS Server, click File menu, click Add/Remove Snap-in…

9 – Next, in the Add or Remove Snap-ins dialog box, click Certificates, click Add, select Computer account, click Next, and then click Finish…

10 – In the Add or Remove Snap-ins dialog box, click OK…

11 – In the console1 tree, expand Certificates, right-click Personal, point to All Tasks, and then click Request New Certificate…

12 – In the Certificate Enrollment dialog box, click Next to proceed…

13 – Next on the Select Certificate Enrollment Policy interface, click Active Directory Enrollment Policy, and then click Next…

14 – Next, select the Computer check box, and then click Enroll…

15 – Verify the status of certificate installation as Succeeded, and then click Finish…

Технология NAP предлагает различные варианты реализации: выдача IP-адресов из различных диапазонов для «хороших» и «плохих» компьютеров; установление соединения IPSec с «хорошими» компьютерами, в то время как «плохим» компьютерам в соединении будет отказано. И самый интересный и наиболее правильный для использования в локальной сети вариант — авторизация сетевых устройств по протоколу IEEE 802.1x на коммутаторах локальной сети. Далее я расскажу, как настроить роль Network Policy Server в  Windows Server 2008, а также сетевые коммутаторы для реализации NAP в сети.

Для изучения и демонстрации технологии NAP у нас в компании был собран стенд «Поликом Про», состав оборудования которого был максимально приближен к реальным условиям. В нашей лабораторной сети установлен L3-коммутатор Cisco Catalyst 3550 и L2-коммутаторы Cisco Catalyst 2950. Данные модели наиболее распространены в сетях российских предприятий. Схема собранного стенда показана на рисунке.

Как мы видим, в качестве контроллера домена используется компьютер под управлением Windows Server 2003, центр сертификации также развернут на компьютере под управлением Windows Server 2003. На компьютере под Windows Server 2008 развернута только одна роль — Network Policy Server, которая необходима для реализации технологии NAP. Такая конфигурация стенда была выбрана специально, чтобы показать, что для использования технологии NAP администраторам не придется перестраивать всю существующую инфраструктуру, а при желании достаточно лишь добавить один сервер под управлением Windows Server 2008, и можно использовать новые технологии, реализованные в новой серверной операционной системе. В качестве клиентов использовались компьютеры под управлением Windows Vista и Windows XP SP2 плюс специальный программный модуль или Windows XP SP3.

Итак, я описал собранный стенд, теперь расскажу о том, как все это будет работать. Как сказано выше, у нас есть два коммутатора и клиентский компьютер под управлением Windows Vista. Сетевые политики нашей сети требуют, чтобы на клиентском компьютере на всех сетевых интерфейсах был включен брандмауэр Windows. Изначально на нашем компьютере-клиенте брандмауэр включен. Подключим наш компьютер по сети к коммутатору 2950, и, так как наш компьютер соответствует политикам сети (брандмауэр включен), получим полный доступ к ресурсам локальной сети. Если во время работы брандмауэр выключен, то доступ к сети будет немедленно заблокирован. Давайте теперь переключимся на коммутатор 3550. Пусть брандмауэр на нашем компьютере будет выключен. После подключения к сети мы получили доступ в сеть, однако коммутатор перенаправил порт, к которому мы подключились, в карантинную сеть, не имеющую доступа к основной сети. После того как мы включим брандмауэр и наш компьютер будет соответствовать политикам сети, коммутатор перенаправит нас в основную сеть. Данная несложная демонстрация показывает, как можно защитить локальную сеть на самом первом этапе подключения к сети.

Предварительная настройка Windows Server 2008

На рисунке мы видим, что у нас есть сервер с именем DC, который работает под управлением операционной системы Windows Server 2003. Данный сервер является контроллером домена nap.demo. Также на данном сервере развернут центр сертификации Microsoft Certification Authority. Никаких других настроек не производилось.

Второй сервер, NPS, работает под управлением операционной системы Windows Server 2008. Этот сервер входит в домен nap.demo, т. е. является членом домена. Первое, что необходимо сделать при его настройке, это запросить сертификат компьютера для данного сервера. Для этого открываем консоль mmc, в меню File выбираем Add/Remove Snap-in, в появившемся окне из списка предложенных оснасток выбираем оснастку Certificates, далее нажимаем кнопку Add, в следующем окне Certificates snap-in выбираем пункт Computer Account и нажимаем Next. В новом окне выбираем пункт Local computer (the computer this console is running on) и нажимаем кнопку Finish. В окне удаления/добавления оснасток нажимаем Ok.

В оснастке Certificates щелкаем правой кнопкой мыши на пункте Personal и из контекстного меню выбираем All Tasks, Request New Certificate, после чего появится мастер запроса сертификатов. В окне Before you begin нажимаем Next. Далее из списка предложенных шаблонов нужно выбрать шаблон Computer и Enroll. После получения сообщения об успешном завершении операции нажимаем Finish.

Чтобы удостовериться, что теперь на нашем компьютере есть сертификат, открываем Certificates(Local Computer), Personal, Certificates и видим в правой панели экрана выданный нам сертификат.

Следующим шагом будет установка роли Network Policy Server. Для этого необходимо открыть Server Manager, в разделе Roles Summary выбрать пункт Add Roles и далее в окне Before You Begin нажать Next. Из списка предложенных ролей выбираем роль Network Policy and Access Services и опять нажимаем Next. В окне Network Policy and Access Services нажимаем Next. Далее, в окне Role Services следует выбрать пункт Network Policy Server и щелкнуть Next. Для запуска установки роли нажимаем кнопку Install и после завершения установки — Close.

Настройка Network Policy Server

Все предварительные действия выполнены, теперь можно приступать к настройке самого Network Policy Server. Для этого открываем Start, Programs, Administrative Tools, Network Policy Server.

На первом этапе создадим в NPS записи для наших коммутаторов Cisco Catalyst 2950 и Cisco Catalyst 3550. Разворачиваем контейнер RADIUS Clients and Servers и щелкаем правой кнопкой мыши на RADIUS Clients. Из контекстного меню выбираем пункт New RADUIS Client и в появившемся окне указываем имя клиента — Cisco Catalyst 2950. Это имя будет отображаться в окне Network Policy Server. Указываем IP-адрес клиента — 192.168.200.10 — это IP-адрес коммутатора Cisco Catalyst 2950 (см. рисунок). Далее указываем ключ — выбираем Manual и в поле Shared Secret пишем cisco (данный пароль будет ниже использоваться при настройке коммутатора). Повторяем наш пароль в поле Confirm Shared Secret и последним шагом устанавливаем флажок у параметра Access-Request. Повторяем аналогичные действия для Cisco Catalyst 3550, только имя будет, соответственно, Cisco Catalyst 3550, а IP-адрес — 192.168.200.20. В качестве Shared Secret также указываем cisco. В результате этой процедуры у нас в Network Policy Server будут зарегистрированы оба коммутатора.

Подключение — по запросу

Теперь необходимо создать политики запроса подключения, для чего переходим в раздел Policies и, щелкнув правой кнопкой мыши на пункте Connection Request Policies, из контекстного меню выбираем New. В открывшемся окне вводим имя политики — Request Policy for 2950 и нажимаем Next. В окне Specify Conditions нажимаем кнопку Add, и в разделе RADIUS Client выбираем пункт Client IPv4 Address. Нажимаем Add и в появившемся окне вводим адрес коммутатора 192.168.200.10, после чего нажимаем Ok.

Далее нажимаем Next до тех пор, пока не появится окно Specify Authentication Methods. В этом окне устанавливаем флажок Override network policy authentication settings, нажимаем кнопку Add и из появившегося списка выбираем пункт Microsoft: Protected EAP (PEAP). В окне Specify Authentication Methods нужно указать только что добавленный метод аутентификации, нажать кнопку Edit и в окне Configure Protected EAP Properties убедиться, что в Certificate issued отображается сертификат нашего компьютера NPS.nap.demo. После этого нажимаем Ok, затем дважды Next, и в окне Completing Connection Request Policy Wizard нажимаем кнопку Finish (см. экран 1).

Создаем аналогичную политику для Cisco Catalyst 3550. При создании указываем имя политики Request Policy for 3550 и в окне Specify Conditions при указании IP-адреса клиента RADIUS вводим 192.168.200.20. Остальные действия аналогичны созданию политики для Cisco Catalyst 2950.

В итоге получаем две политики Connection Request Policies.

Проверка статуса

Следующий шаг — настройка проверки состояния компьютера для определения его статуса. Сначала укажем, какие параметры должны проверяться на компьютере, — открываем контейнер Network Access Protection и выбираем System Health Validators. В панели справа выбираем Windows Security Health Validator, щелкаем на нем правой кнопкой мыши и в контекстном меню выбираем пункт Properties. В открывшемся окне нажимаем кнопку Configure. Так как на нашем стенде клиентский компьютер работает под управлением операционной системы Windows Vista, на вкладке Windows Vista выбираем те параметры, которые нам необходимы. В нашем случае для стенда мы оставим включенной только проверку состояния брандмауэра. Проверку остальных параметров проводить не будем.

Теперь необходимо создать политики проверки состояния компьютеров, которые описывают, какой компьютер и с какими параметрами считать соответствующим политикам сети, а какой — нет. Для этого перейдем в контейнер Policies и, щелкнув правой кнопкой мыши на пункте Health Policies, из контекстного меню выберем пункт New.

В окне Create New Health Policy заполняем поле Policy Name — Compliant, убеждаемся, что в поле Client SHV Checks установлен переключатель Client passes all SHV checks, и ниже устанавливаем флажок напротив Windows Security Health Validator, после чего нажимаем Ok.

Аналогичным образом создаем политику для определения компьютеров, которые не соответствуют требованиям сети. Для Client SHV Checks выбираем значение Client fails one or more SHV checks.

Политики сети

Остался последний шаг — настройка сетевых политик. На пункте Network Policies щелкаем правой кнопкой мыши и из контекстного меню выбираем пункт New. В окне Specify Network Policy Name and Connection Type указываем имя политики Full Access for 2950 и нажимаем Next. В окне Specify Conditions нажимаем кнопку Add. Из открывшегося списка выбираем пункт Health Policies из раздела Network Access. Нажимаем кнопку Add, в появившемся окне выбираем из списка значение Compliant и нажимаем Ok.

В окне Specify Conditions опять нажимаем кнопку Add. Из появившегося списка следует выбрать пункт Client IPv4 Address из раздела RADIUS Client и нажать Add. В поле запроса IP-адреса вводим значение 192.168.200.10 и нажимаем Ok. Далее в окне Specify Conditions нажимаем Next. В следующем окне Specify Access Permission выбираем пункт Access granted и нажимаем Next до тех пор, пока не увидим окно Configure Settings (см. экран 2).

В левой части окна в разделе RADIUS Attributes выбираем пункт Standard, затем в рабочей области справа нажимаем кнопку Add и из списка параметров выбираем Termination-Action, после чего нажимаем кнопку Add. В окне Attribute Information в поле Attribute Value указываем значение RADIUS-Request и затем нажимаем Ok.

Таким же образом добавляем параметр Tunnel-Medium-Type со значением параметра 802 (includes all 802 media plus Ethernet canonical format). Затем закрываем окно Add Standard RADIUS Attribute.

В окне Configure Settings в левой части окна нужно выбрать пункт NAP Enforcement из раздела Network Access Protection. В правой части окна выбираем пункт Allow full network access и нажимаем Next.

В окне Completing New Network Policy нажимаем Finish. Все, сетевая политики для доступа «правильных» компьютеров создана.

Теперь создадим политику ограниченного доступа, для компьютеров, не соответствующих политикам сети. Для этого нужно щелкнуть правой кнопкой мыши на только что созданной политике и из контекстного меню выбрать пункт Duplicate Policy. На сдублированной политике Copy Of Full Access for 2950 щелкаем правой кнопкой мыши и из контекстного меню выбираем свойства. В открывшемся окне следует заменить значения полей Policy name на значение Limited Access for 2950, затем установить флажок Policy enabled, а в разделе Access Permission выбрать значение Deny Access. Переходим на вкладку Conditions. Выбираем пункт Health Policy и нажимаем кнопку Edit. В открывшемся окне меняем значение поля Health Policies на NonCompliant, нажимаем Ok и затем нажимаем кнопку Apply. Правила для Cisco Catalyst 2950 созданы: первое правило разрешает коммутатору открывать доступ компьютера в сеть, если у него включен брандмауэр. Второе правило предписывает коммутатору заблокировать порт, к которому подключен компьютер, если на нем брандмауэр выключен.

По аналогии создаем правила для Cisco Catalyst 3550. Для ускорения создания правил будем использовать правила, определенные на предыдущих этапах. Выбираем правило Full Access for 2950, щелкаем на нем правой кнопкой мыши и из контекстного меню выбираем Duplicate Policy. Открываем свойства вновь созданного правила и исправляем значения параметров следующим образом: в поле Policy name вводим Full Access for 3550, устанавливаем флажок Policy enabled. Переходим на вкладку Conditions, выбираем пункт Client IPv4 Address, нажимаем кнопку Edit и вводим IP-адрес 192.168.200.20. Переходим на вкладку Settings, в панели справа нажимаем кнопку Add и добавляем следующие параметры: Tunnel-Pvt-Group-ID со значением Healthy и Tunnel-Type со значением Viltual LANs (VLAN). Нажимаем Ok.

Повторяя шаги, необходимые для задания политик для 2950, создаем копию правила Full Access for 3550. Открываем свойства вновь созданного правила и редактируем следующим образом: в Policy name вводим Limited Access for 3550, устанавливаем флажок Policy enabled, переходим на вкладку Conditions, выбираем пункт Health Policy и изменяем значение этого параметра на NonCompliant. Далее переходим на вкладку Settings, в рабочей области экрана в разделе Attributes изменяем значение параметра Tunnel-Pvt-Group-ID на Quarantine и нажимаем Ok. Результат представлен на экране 3. На этом настройка Network Policy Server завершена.

Финал — настройка оборудования Cisco

Теперь приступим к настройке оборудования Cisco. Список необходимых команд приведен в листинге, я лишь вкратце поясню последовательность действий. Через терминальный кабель следует подключиться к Cisco Catalyst 2950 и для начала изменить имя коммутатора, чтобы потом не запутаться, поскольку предстоит повторить такую же последовательность для модели 3550. Далее настраиваем аутентификацию и авторизацию через службу RADIUS: прежде всего, задаем настройки сервера RADIUS; он должен быть доступен через первый порт коммутатора. Далее настраиваем параметры Default VLAN (Vlan 1). Следующий шаг — настроить порты коммутатора, к которым будут подключаться клиенты. Порт 9 в листинге выбран для примера, аналогичная настройка должна выполняться для всех портов, к которым будут подключаться клиенты. На последнем шаге останется только сохранить конфигурацию.

Настройки Cisco Catalyst 3550 аналогичны настройке Cisco Catalyst 2950, только в качестве клиентского порта на нашем стенде был настроен 13-й порт коммутатора.

Роман Совалов (RSovalov@polikom.ru) — ведущий инженер компании «Поликом Про»