Сервер сетевой политики — Network Policy Server
Службы сетевой политики и доступа (NPAS) — это компонент Windows Server 2008 . Он заменяет службу проверки подлинности в Интернете (IAS) из Windows Server 2003 . NPAS помогает защитить работоспособность и безопасность сети. Роль сервера NPAS включает в себя сервер политики сети (NPS), центр регистрации работоспособности (HRA) и протокол авторизации учетных данных узла (HCAP). В Windows Server 2003 IAS — это реализация Microsoft сервера службы удаленной аутентификации пользователей с телефонным подключением (RADIUS) . В операционных системах Windows Server более поздних версий, чем Windows Server 2003, IAS переименовывается в NPS.
Содержание
Обзор
NPAS — это служба ролей в Windows Server 2008, которая может выполнять следующие функции:
- RADIUS сервер
- Прокси RADIUS
- Сервер политик защиты доступа к сети
Характеристики
NPSEE позволяет использовать разнородный набор оборудования для беспроводной связи, коммутатора, удаленного доступа или VPN. Можно использовать NPS со службой маршрутизации и удаленного доступа, которая доступна в Microsoft Windows 2000, Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; и Windows Server 2003, Datacenter Edition.
Когда сервер, на котором работает NPS, является членом домена доменных служб Active Directory (AD DS), NPS использует службу каталогов в качестве своей базы данных учетных записей пользователей и является частью решения для единого входа. Один и тот же набор учетных данных используется для управления доступом к сети (проверка подлинности и авторизация доступа к сети) и для входа в домен AD DS.
Настройка Windows Server с помощью групповых политик
Цель данной статьи — тонкая настройка терминального сервера. Все скриншоты будут соответствовать версии Windows Server 2016. В результате такой настройки вы сможете повысить безопасность сервера и ограничить права терминальных пользователей.
Удаляем лишние команды из Проводника
Откройте редактор групповой политики (команда gpedit.msc) и перейдите в раздел Конфигурация пользователя, Административные шаблоны, Компоненты Windows, Проводник (рис. 1.).
Рис. 1. Параметры Проводника
Как видите, есть много полезных и не очень групповых политик в Windows Server 2016. Рассмотрим несколько полезных. Так, Скрыть выбранные диски из окна Мой компьютер (рис. 2) позволяет удалить значки выбранных дисков из окна Этот компьютер (в последних версиях Windows это окно называется именно так).
Рис. 2. Ограничиваем доступ пользователей в Windows Server 2016 к определенным дискам
Впрочем, если пользователь окажется умным и введет путь диска (например, D:\) в окне Проводника, он сможет получить доступ к нему. Для таких умных пользователей предназначена групповая политика Запретить доступ к дискам через «Мой компьютер» (рис. 3).
Рис. 3. Запретить доступ к дискам
Неплохо было бы еще и запретить пользователю использовать окно Выполнить (открывается при нажатии Win + R). Для этого нужно включить групповую политику Отключить сочетания клавиш Windows + X. Правда, такая настройка «убьет» все сочетания, в том числе и Win + R, но отдельной групповой политики, которая бы отключала отдельные команды, в современных версиях Windows Server нет (хотя раньше была опция, скрывающая команду Выполнить)
Запрещаем доступ к командной строке и PowerShell
Окно Выполнить используют самые начинающие пользователи. Продвинутые пользователи используют или командную строку, или PowerShell. Запретить пользователям использовать командную строку можно, проведя настройку групповой политики Конфигурация пользователя, Административные шаблоны, Система, Запретить использование командной строки (рис. 4). Также включите опцию Запретить также обработку сценариев в командной строке, чтобы нельзя было запускать сценарии командной строки.
Рис. 4. Запрещаем использование командной строки в Windows Server
Отдельной групповой политики, запрещающей запуск PowerShell, нет, но есть групповая политика, запрещающая запуск определенных приложений. Она называется Не запускать указанные приложения Windows и находится все в том же разделе Система. Включите ее и запретите запуск powershell.exe and powershell_ise.exe (рис. 5).
Рис. 5. Запрет запуска PowerShell
Также, пока вы еще не «ушли» из раздела Система, неплохо было бы запретить запуск редактора реестра. Для этого включите Запретить доступ к средствам редактирования реестра.
Максимальное время работы пользователя
Групповая политика Конфигурация пользователя, Административные шаблоны, Компоненты Windows, Службы удаленных рабочих столов, Узел сеансов удаленных рабочих столов, Ограничение сеансов по времени, Задать ограничение по времени для активных сеансов служб удаленных рабочих столов позволяет задать максимальную продолжительность сеанса. Ее можно установить, например, в 8 часов.
Рис. 6. Ограничиваем время сеанса
К сожалению, эта настройка не помешает пользователю снова залогиниться на сервере. Ограничить время входа на сервер можно только с помощью оснастки Пользователи и компьютеры Active Directory, но далеко не все терминальные серверы являются контроллерами домена, к сожалению. Разворачивать контроллер домена только ради этой функции не хочется (например, если терминальный сервер у вас используется только ради совместного доступа к 1С, нет смысла проводить настройку контроллера домена).
Рис. 7. Установка времени входа учетной записи в Windows Server
Отключение элементов панели управления
С помощью групповых политик можно отключить некоторые элементы панели управления. В разделе Конфигурация пользователя, Административные шаблоны, Панель управления находятся две замечательных групповые политики — Скрыть указанные элементы панели управления и Запретить доступ к панели управления и параметрам компьютера. Первая позволяет запретить выбранные элементы панели управления, а вторая вообще запрещает доступ к панели управления и к параметрам компьютера.
Надеюсь, прочитав эту статью, администратору будет немного спокойнее — ведь теперь пользователи смогут сделать гораздо меньше, чего стоит только отключение командной строки и PowerShell.
Настраиваем доменную аутентификацию на сетевом оборудовании
22.01.2015
itpro
Windows Server 2012 R2
комментариев 7
При обслуживании больших сетей системные администраторы часто сталкиваются с проблемами аутентификации на сетевом оборудовании. В частности, довольно сложно организовать нормальную работу нескольких сетевых администраторов под индивидуальными учетными записями на большом количестве оборудования (приходится вести и поддерживать в актуальном состоянии базу локальных учетных записей на каждом устройстве). Логичным решение было бы использовать для авторизации уже существующей базы учетных записей — Active Directory. В этой статье мы разберемся, как настроить доменную (Active Directory) аутентификацию на активном сетевом оборудовании (коммутаторы, маршрутизаторы).
Не все сетевое оборудование популярных вендоров (CISCO, HP, Huawei) поддерживает функционал для непосредственного обращения к каталогу LDAP, и такое решение не будет универсальным. Для решения нашей задачи подойдет протокол AAA (Authentication Authorization and Accounting), фактически ставший стандартом де-факто для сетевого оборудования. Клиент AAA (сетевое устройство) отправляет данные авторизующегося пользователя на сервер RADIUS и на основе его ответа принимает решение о предоставлении / отказе доступа.
Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2012 R2 включен в роль NPS (Network Policy Server). В первой части статьи мы установим и настроим роль Network Policy Server, а во второй покажем типовые конфигурации сетевого устройств с поддержкой RADUIS на примере коммутаторов HP Procurve и оборудования Cisco.
Установка и настройка сервера с ролью Network Policy Server
Как правило, сервер с ролью NPS рекомендуется устанавливать на выделенном сервере (не рекомендуется размещать эту роль на контроллере домена). В данном примере роль NPS мы будем устанавливать на сервере с Windows Server 2012 R2.
Откройте консоль Server Manager и установите роль Network Policy Server (находится в разделе Network Policy and Access Services).

После окончания установки запустите mmc-консоль управления Network Policy Server. Нас интересуют три следующих раздела консоли:
- RADIUS Clients — содержит список устройств, которые могут аутентифицироваться на сервере
- Connection Request Policies – определяет типы устройств, которые могут аутентифицироваться
- Network Polices – правила аутентификации

Добавим нового клиента RADIUS (это будет коммутатор HP ProCurve Switch 5400zl), щелкнув ПКМ по разделу RADIUS Clients и выбрав New. Укажем:
- Friendly Name:sw-HP-5400-1
- Address (IP or DNS): 10.10.10.2
- Shared secret (пароль/секретный ключ): пароль можно указать вручную (он должен быть достаточно сложным), либо сгенерировать с помощью специальной кнопки (сгенерированный пароль необходимо скопировать, т.к. в дальнейшем его придется указать на сетевом устройстве).

Отключим стандартную политику (Use Windows authentication for all users) в разделе Connection Request Policies, щелкнув по ней ПКМ и выбрав Disable.
Создадим новую политику с именем Network-Switches-AAA и нажимаем далее. В разделе Сondition создадим новое условие. Ищем раздел RADIUS Client Properites и выбираем Client Friendly Name.

В качестве значения укажем sw-?. Т.е. условие будет применяться для всех клиентов RADIUS, начинающийся с символов :”sw-“. Жмем Next->Next-> Next, соглашаясь со всеми стандартными настройками.
Далее в разделе Network Policies создадим новую политику аутентификации. Укажите ее имя, например Network Switch Auth Policy for Network Admins. Создадим два условия: в первом условии Windows Groups, укажем доменную группу, члены которой могут аутентифицироваться (учетные записи сетевых администраторов в нашем примере включены в группу AD Network Admins) Второе условие Authentication Type, выбрав в качестве протокола аутентификации PAP.

Далее в окне Configure Authentication Methods снимаем галки со всех типов аутентификации, кроме Unencrypted authentication (PAP. SPAP).
В окне Configure Settings изменим значение атрибута Service-Type на Administrative.

В остальных случаях соглашаемся со стандартными настройками и завершаем работу с мастером.
И, напоследок, переместим новую политику на первое место в списке политик.

Настройка сетевого оборудования для работы с сервером RADUIS
Осталось настроить наше сетевое оборудование для работы с сервером Radius. Подключимся к нашему коммутатору HP ProCurve Switch 5400 и внесем следующе изменение в его конфигурацию (измените ip адрес сервера Raduis и пароль на свои).
Совет. Если в целях безопасности вы запретили подключаться к сетевому оборудованию через telnet, эти строки нужно удалить из конфига:
Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!

Для коммутатора Cisco конфигурация, предполагающая использование доменных учетных записей для аутентификации и авторизации, может выглядеть так:
Для Cisco ASA конфигурация будет выглядеть так:
Совет. Если что то-не работает, проверьте:
- Совпадают ли секретные ключи на сервере NPS и коммутаторе (для теста можно использоваться простой пароль).
- Указан ли правильный адрес NPS сервера в конфигурации. Пингуется ли он?
- Не блокируют ли межсетевые экраны порты 1645 и 1646 между коммутатором и сервером?
- Внимательно изучите логи NPS сервера
Предыдущая статья Следующая статья
Авторизация через Network Policy Server (NPS) для MikroTik
Как быстро и просто настроить авторизацию через RADIUS от Microsoft? Думаю, это поможет тем, кто захочет иметь возможность заходить на устройства MikroTik через дружелюбный WinBox и простой SSH.
Установка роли NPS
Имеем Windows Server 2016 Datacenter с уже установленным доменом.

Выбираем сервер, на котором будет разворачиваться роль. Microsoft не рекомендует делать это на контроллере домена, но в некоторых best practices для уменьшения задержек дают совет ставить именно на него. Добавляем роль Network Policy and Access Server вместе с management tools для настройки.




Запускаем любым удобным способом админку NPS. Например, через менеджер серверов.

Регистрируем сервер NPS в AD.

Добавление RADIUS клиента
Для того, чтобы сервер знал с какими устройствами налаживать общение нужно добавить их в RADIUS Clients.

Для примера, добавляю свой MikroTik wAP. Friendly name установил как Identity на устройстве и IP заданный на его единственном проводном интерфейсе. Для того, чтобы устройство смогло авторизоваться на сервере нужно ввести ключ. Он создается на сервере либо вручную, либо генерируется автоматически. Я предпочел второй вариант.

Vendor name остановим на стандартном RADIUS.

Создание политики подключения

Подбираем подходящее название для политики.

Определяем наше устройство с которым будет работать сервер.

Я выбрал только Client Friendly Name со значением Router01. Это четко привязывает данный пункт политики к устройству через созданного клиента. Можно идентифицировать устройство Mikrotik по Identity выбрав NAS Identifier.

Без предварительной конфигурации устройства Identity = MikroTik.

Дальнейшая настройка политики.

На этапе выбора протокола аутентификации достаточно выбрать нешифрованный (о чем получите предупреждение) PAP для SSH или шифрованный CHAP для WinBox. Я выбрал оба. Если есть необходимость использовать web версию, то достаточно включить MS-CHAPv2, в остальном всё аналогично.

Собственно, предупреждение о выборе небезопасного способа. Предлагают почитать пошаговый справочный материал.

На данном этапе я не стал ничего трогать.

Итоговые установки политики.
У меня не получилось воспроизвести это через PowerShell, даже стандартный example с technet’а. Буду признателен, если подскажете почему.

Выбираем нужный приоритет двигая выше или ниже пункт политики.
Создание политики сети

Назовем её Routers.

Как и прежде, нужно определить условия.

В AD у меня создан дополнительный пользователь состоящий в группе Domain Admins. Выбираю условие Windows Group исходя из того, чтобы все администраторы домена смогли получать доступ к MikroTik.


Разрешительное или запретительное правило. Мы будем разрешать всем, кто попал под условие.

Способ аутенификации выбираем аналогичный прошлой политике.

Исходя из необходимости можно настроить дополнительные настройки. Я оставил без изменений.

Далее необходимо выбрать что будет отправляться на сервер.

Итоговые настройки политики сети.

Выбираем необходимый приоритет среди других политик, если необходимо.

Чтобы учетная запись проверялась через NPS в AD у этого пользователя на вкладке Dial-in в разделе Network Access Permission должен быть отмечен пункт Control access through NPS Network Policy.

Для возможности авторизовываться через WinBox нужно включить обратимое шифрование в профиле пользователя.

Добавление сервера авторизации на MikroTik
Первым делом присвоим System/Identity равным router01 и IP с маской для интерфейса.

В System/Users и на вкладке Users включаем пункт Use RADIUS. По умолчанию выбран доступ только для чтения.

Открываем настройки Radius и добавляем новый сервер. Сервис выбирается исходя из назначения. Лучше, конечно же, делить доступ между ними. Address — адрес сервера на котором установлен NPS.
Secret — ключ, который был сгенерирован на стадии добавления клиента на сервере.

Проверка через SSH и WinBox
Проверка подключения через SSH и экспорт конфигурации.

И проверяем авторизацию в Winbox.

Как видим, в активных пользователях висят системный admin и оба подключения доменного юзера с доступом для чтения через SSH и Winbox.