Планирование сервера политики сети в качестве RADIUS-сервера
При развертывании сервера политики сети (NPS) в качестве сервера службы удаленной проверки подлинности (RADIUS), NPS выполняет проверку подлинности, авторизацию и учет запросов на подключение для локального домена и доменов, которые доверяют локальному домену. Эти рекомендации по планированию можно использовать для упрощения развертывания RADIUS.
Эти рекомендации по планированию не включают обстоятельства, в которых требуется развернуть NPS в качестве прокси-сервера RADIUS. При развертывании NPS в качестве прокси-сервера RADIUS NPS пересылает запросы на подключение к серверу под управлением NPS или других серверов RADIUS в удаленных доменах, ненадежных доменах или обоих.
Перед развертыванием NPS в качестве сервера RADIUS в сети используйте следующие рекомендации для планирования развертывания.
Планирование конфигурации NPS.
Планирование клиентов RADIUS.
Планирование использования методов проверки подлинности.
Планирование политик сети.
Планирование учета NPS.
Планирование конфигурации NPS
Необходимо решить, в каком домене NPS является членом. Для сред с несколькими доменами NPS может проходить проверку подлинности учетных данных для учетных записей пользователей в домене, в котором он является членом, и для всех доменов, которые доверяют локальному домену NPS. Чтобы разрешить NPS считывать свойства учетных записей пользователей в процессе авторизации, необходимо добавить учетную запись компьютера NPS в группу RAS и NPSs для каждого домена.
После определения членства в домене NPS сервер должен быть настроен для связи с клиентами RADIUS, также называемыми серверами сетевого доступа, с помощью протокола RADIUS. Кроме того, можно настроить типы событий, записывающих NPS в журнале событий, и ввести описание сервера.
Ключевые шаги
Во время планирования конфигурации NPS можно выполнить следующие действия.
Определите порты RADIUS, используемые NPS для получения сообщений RADIUS от клиентов RADIUS. Порты по умолчанию — это порты UDP 1812 и 1645 для сообщений проверки подлинности RADIUS и портов 1813 и 1646 для сообщений учета RADIUS.
Если NPS настроен с несколькими сетевыми адаптерами, определите адаптеры, для которых требуется разрешить трафик RADIUS.
Определите типы событий, которые требуется записать ВП в журнале событий. Вы можете записывать отклоненные запросы проверки подлинности, успешные запросы проверки подлинности или оба типа запросов.
Определите, развертывается ли развертывание нескольких NPS. Чтобы обеспечить отказоустойчивость для проверки подлинности и учета на основе RADIUS, используйте по крайней мере два NPS. Один NPS используется в качестве основного сервера RADIUS, а другой используется в качестве резервной копии. Затем каждый клиент RADIUS настраивается в обоих NPS. Если основной NPS становится недоступным, клиенты RADIUS отправляют сообщения Access-Request в альтернативные NPS.
Запланируйте сценарий, используемый для копирования одной конфигурации NPS в другие NPS, чтобы сэкономить на административных затратах и предотвратить неправильную конфигурацию сервера. NPS предоставляет команды Netsh, которые позволяют копировать все или часть конфигурации NPS для импорта в другой NPS. Команды можно выполнять вручную в строке Netsh. Однако при сохранении последовательности команд в качестве скрипта можно запустить сценарий позже, если вы решите изменить конфигурации сервера.
Планирование клиентов RADIUS
Клиенты RADIUS — это серверы доступа к сети, такие как беспроводные точки доступа, серверы виртуальной частной сети (VPN), коммутаторы с поддержкой 802.1X и серверы с поддержкой телефонного подключения. Прокси-серверы RADIUS, которые пересылают сообщения о подключении к серверам RADIUS, также являются клиентами RADIUS. NPS поддерживает все серверы доступа к сети и прокси-серверы RADIUS, соответствующие протоколу RADIUS, как описано в RFC 2865, "Служба пользователей с удаленной проверкой подлинности (RADIUS)" и RFC 2866, "Учет RADIUS".
Внимание
Доступ к клиентам, таким как клиентские компьютеры, не являются клиентами RADIUS. Только серверы доступа к сети и прокси-серверы, поддерживающие протокол RADIUS, являются клиентами RADIUS.
Кроме того, точки беспроводного доступа и коммутаторы должны иметь возможность проверки подлинности 802.1X. Если вы хотите развернуть расширяемый протокол проверки подлинности (EAP) или защищенный протокол расширенной проверки подлинности (PEAP), точки доступа и коммутаторы должны поддерживать использование EAP.
Чтобы проверить базовое взаимодействие подключений PPP для беспроводных точек доступа, настройте точку доступа и клиент доступа для использования протокола проверки подлинности паролей (PAP). Используйте дополнительные протоколы проверки подлинности на основе PPP, такие как PEAP, пока вы не протестируете те, которые вы планируете использовать для сетевого доступа.
Ключевые шаги
Во время планирования клиентов RADIUS можно выполнить следующие действия.
Задокументируйте атрибуты, относящиеся к поставщику (VSAs), необходимо настроить в NPS. Если для серверов доступа к сети требуются VSA, зайдите в журнал сведения VSA для последующего использования при настройке политик сети в NPS.
Задокументируйте IP-адреса клиентов RADIUS и NPS, чтобы упростить настройку всех устройств. При развертывании клиентов RADIUS необходимо настроить их для использования протокола RADIUS с IP-адресом NPS, введенным в качестве сервера проверки подлинности. При настройке NPS для взаимодействия с клиентами RADIUS необходимо ввести IP-адреса клиента RADIUS в оснастку NPS.
Создайте общие секреты для настройки клиентов RADIUS и в оснастке NPS. Необходимо настроить клиенты RADIUS с общим секретом или паролем, которые также будут входить в оснастку NPS при настройке клиентов RADIUS в NPS.
Планирование использования методов проверки подлинности
NPS поддерживает как методы проверки подлинности на основе паролей, так и на основе сертификатов. Однако не все серверы доступа к сети поддерживают одни и те же методы проверки подлинности. В некоторых случаях может потребоваться развернуть другой метод проверки подлинности на основе типа сетевого доступа.
Например, может потребоваться развернуть беспроводной и VPN-доступ для вашей организации, но использовать другой метод проверки подлинности для каждого типа доступа: EAP-TLS для VPN-подключений, из-за строгой безопасности EAP с помощью протокола EAP-TLS (EAP-TLS) и PEAP-MS-CHAP версии 2 для беспроводных подключений 802.1X.
PEAP с протоколом проверки подлинности Microsoft Challenge Handshake 2 (PEAP-MS-CHAP версии 2) предоставляет функцию быстрого повторного подключения, которая специально предназначена для использования с переносимыми компьютерами и другими беспроводными устройствами. Быстрое повторное подключение позволяет беспроводным клиентам перемещаться между точками беспроводного доступа в одной сети без повторной проверки подлинности при каждом связывании с новой точкой доступа. Это обеспечивает лучший интерфейс для беспроводных пользователей и позволяет им перемещаться между точками доступа без необходимости повторно вводить свои учетные данные. Из-за быстрого повторного подключения и безопасности, которую предоставляет PEAP-MS-CHAP версии 2, PEAP-MS-CHAP версии 2 является логическим выбором в качестве метода проверки подлинности для беспроводных подключений.
Для VPN-подключений EAP-TLS — это метод проверки подлинности на основе сертификатов, обеспечивающий надежную безопасность, которая защищает сетевой трафик, даже если он передается через Интернет с домашних или мобильных компьютеров на VPN-серверы организации.
Методы проверки подлинности на основе сертификатов
Методы проверки подлинности на основе сертификатов имеют преимущество обеспечения надежной безопасности; и у них есть недостаток, который будет сложнее развертывать, чем методы проверки подлинности на основе паролей.
Как PEAP-MS-CHAP версии 2, так и EAP-TLS являются методами проверки подлинности на основе сертификатов, но между ними и способом их развертывания существует множество различий.
Протокол EAP-TLS
EAP-TLS использует сертификаты для проверки подлинности клиента и сервера и требует развертывания инфраструктуры открытых ключей (PKI) в организации. Развертывание PKI может быть сложным и требует этапа планирования, независимо от планирования использования NPS в качестве сервера RADIUS.
При использовании EAP-TLS NPS регистрирует сертификат сервера из центра сертификации (ЦС), а сертификат сохраняется на локальном компьютере в хранилище сертификатов. Во время процесса проверки подлинности серверная проверка подлинности возникает, когда NPS отправляет сертификат сервера клиенту доступа, чтобы подтвердить его удостоверение клиенту доступа. Клиент доступа проверяет различные свойства сертификата, чтобы определить, является ли сертификат допустимым и подходит для использования во время проверки подлинности сервера. Если сертификат сервера соответствует минимальным требованиям к сертификату сервера и выдан ЦС, которому доверяет клиент, он успешно проходит проверку подлинности клиента.
Аналогичным образом проверка подлинности клиента происходит во время процесса проверки подлинности, когда клиент отправляет сертификат клиента в NPS, чтобы подтвердить его удостоверение в NPS. NPS проверяет сертификат, и если сертификат клиента соответствует минимальным требованиям к сертификату клиента и выдан ЦС, которому доверяет NPS, клиент доступа успешно проходит проверку подлинности с помощью NPS.
Хотя требуется, чтобы сертификат сервера хранится в хранилище сертификатов на NPS, клиент или сертификат пользователя можно хранить в хранилище сертификатов клиента или на смарт-карте.
Для успешного выполнения этого процесса проверки подлинности необходимо, чтобы все компьютеры имели сертификат ЦС вашей организации в хранилище сертификатов доверенных корневых центров сертификации для локального компьютера и текущего пользователя.
PEAP-MS-CHAP версии 2
PEAP-MS-CHAP версии 2 использует сертификат для проверки подлинности сервера и учетных данных на основе паролей для проверки подлинности пользователей. Так как сертификаты используются только для проверки подлинности сервера, для развертывания PKI не требуется для использования PEAP-MS-CHAP версии 2. При развертывании PEAP-MS-CHAP версии 2 можно получить сертификат сервера для NPS одним из следующих двух способов:
Вы можете установить службы сертификатов Active Directory (AD CS), а затем автоматически зарегистрировать сертификаты в NPS. При использовании этого метода необходимо также зарегистрировать сертификат ЦС на клиентских компьютерах, подключающихся к сети, чтобы они доверяли сертификату, выданному NPS.
Вы можете приобрести сертификат сервера из общедоступного ЦС, например VeriSign. Если вы используете этот метод, убедитесь, что выбран ЦС, который уже доверяется клиентским компьютерам. Чтобы определить, доверяют ли клиентские компьютеры ЦС, откройте оснастку консоли управления Майкрософт (MMC) на клиентском компьютере, а затем просмотрите хранилище доверенных корневых центров сертификации для локального компьютера и текущего пользователя. Если в этих хранилищах сертификатов есть сертификат из ЦС, клиентский компьютер доверяет ЦС и поэтому будет доверять любому сертификату, выданному ЦС.
Во время процесса проверки подлинности с помощью PEAP-MS-CHAP версии 2 проверка подлинности сервера возникает, когда NPS отправляет сертификат сервера на клиентский компьютер. Клиент доступа проверяет различные свойства сертификата, чтобы определить, является ли сертификат допустимым и подходит для использования во время проверки подлинности сервера. Если сертификат сервера соответствует минимальным требованиям к сертификату сервера и выдан ЦС, которому доверяет клиент, он успешно проходит проверку подлинности клиента.
Проверка подлинности пользователей возникает, когда пользователь пытается подключиться к учетным данным на основе паролей сетевых типов и пытается войти в систему. NPS получает учетные данные и выполняет проверку подлинности и авторизацию. Если пользователь прошел проверку подлинности и авторизован, и если клиентский компьютер успешно прошел проверку подлинности NPS, запрос на подключение предоставляется.
Ключевые шаги
Во время планирования использования методов проверки подлинности можно выполнить следующие действия.
Определите типы сетевого доступа, которые вы планируете предложить, например беспроводной, VPN, 802.1X-коммутатор и доступ к телефону.
Определите метод проверки подлинности или методы, которые необходимо использовать для каждого типа доступа. Рекомендуется использовать методы проверки подлинности на основе сертификатов, обеспечивающие надежную безопасность; однако для развертывания PKI может оказаться нецелесообразным, поэтому другие методы проверки подлинности могут обеспечить лучший баланс необходимых для вашей сети способов.
При развертывании EAP-TLS запланируйте развертывание PKI. Это включает планирование шаблонов сертификатов, которые будут использоваться для сертификатов сервера и сертификатов клиентского компьютера. Он также включает определение способа регистрации сертификатов на компьютерах-членах домена и компьютерах-членах, отличных от домена, и определение того, следует ли использовать смарт-карты.
Если вы развертываете PEAP-MS-CHAP версии 2, определите, нужно ли установить AD CS для выдачи сертификатов сервера на NPS или приобрести сертификаты сервера из общедоступного ЦС, например VeriSign.
Планирование политик сети
Политики сети используются NPS для определения того, разрешены ли запросы на подключение, полученные от клиентов RADIUS. NPS также использует свойства учетной записи пользователя для определения авторизации.
Так как политики сети обрабатываются в том порядке, в котором они отображаются в оснастке NPS, планируйте размещение наиболее строгих политик в списке политик. Для каждого запроса подключения NPS пытается соответствовать условиям политики со свойствами запроса подключения. NPS проверяет каждую сетевую политику в порядке, пока не обнаружит совпадение. Если он не находит совпадения, запрос на подключение отклоняется.
Ключевые шаги
Во время планирования политик сети можно выполнить следующие действия.
Определите предпочтительный порядок обработки политик сети по протоколу NPS, от наиболее строгих до наименьших ограничений.
Определите состояние политики. Состояние политики может иметь значение включено или отключено. Если политика включена, NPS оценивает политику при выполнении авторизации. Если политика не включена, она не вычисляется.
Определите тип политики. Необходимо определить, предназначена ли политика для предоставления доступа, если условия политики соответствуют запросу подключения или если политика предназначена для запрета доступа, если условия политики соответствуют запросу подключения. Например, если вы хотите явно запретить беспроводной доступ членам группы Windows, можно создать сетевую политику, указывающую группу, метод беспроводного подключения и параметр типа политики запрета доступа.
Определите, следует ли NPS игнорировать свойства учетных записей пользователей, являющихся членами группы, на которой основана политика. Если этот параметр не включен, свойства учетных записей пользователей переопределяют параметры, настроенные в политиках сети. Например, если настроена сетевая политика, которая предоставляет доступ пользователю, но свойства учетной записи пользователя с телефонным подключением для этого пользователя настроены для запрета доступа, пользователю запрещен доступ. Но если включить параметр типа политики Игнорировать свойства абонентской записи пользователя, то тот же пользователь получает доступ к сети.
Определите, использует ли политика параметр источника политики. Этот параметр позволяет легко указать источник для всех запросов доступа. Возможные источники — это шлюз служб терминалов (шлюз TS), сервер удаленного доступа (VPN или подключение), DHCP-сервер, точка беспроводного доступа и сервер центра регистрации работоспособности. Кроме того, можно указать источник для конкретного поставщика.
Определите условия, которые должны соответствовать для применения политики сети.
Определите параметры, применяемые, если условия политики сети соответствуют запросу подключения.
Определите, хотите ли вы использовать, изменять или удалять политики сети по умолчанию.
Планирование учета NPS
NPS предоставляет возможность регистрировать данные учета RADIUS, такие как запросы проверки подлинности пользователей и учета, в трех форматах: формат IAS, формат, совместимый с базой данных, и ведение журнала Microsoft SQL Server.
Формат IAS и формат, совместимый с базами данных, создают файлы журналов в локальном NPS в текстовом формате.
Ведение журнала SQL Server позволяет выполнять вход в базу данных, совместимую с SQL Server 2000 или SQL Server 2005 XML, расширяя учет RADIUS для использования преимуществ ведения журнала в реляционной базе данных.
Ключевые шаги
Во время планирования учета NPS можно выполнить следующие действия.
- Определите, следует ли хранить данные учета NPS в файлах журналов или в базе данных SQL Server.
Учет NPS с использованием локальных файлов журнала
Запись запросов проверки подлинности и учета пользователей в файлах журналов используется в основном для анализа подключений и выставления счетов, а также полезно в качестве средства исследования безопасности, предоставляя метод отслеживания активности вредоносного пользователя после атаки.
Ключевые шаги
Во время планирования учета NPS с помощью локальных файлов журнала можно выполнить следующие действия.
Определите формат текстового файла, который вы хотите использовать для файлов журналов NPS.
Выберите тип сведений, которые требуется регистрировать. Вы можете записывать запросы на учет, запросы проверки подлинности и периодическое состояние.
Определите расположение жесткого диска, в котором нужно хранить файлы журнала.
Создайте решение резервного копирования файлов журнала. Расположение жесткого диска, в котором хранятся файлы журнала, должно быть расположением, которое позволяет легко создавать резервные копии данных. Кроме того, необходимо защитить расположение жесткого диска, настроив список управления доступом (ACL) для папки, в которой хранятся файлы журнала.
Определите частоту создания новых файлов журнала. Если вы хотите создать файлы журналов на основе размера файла, определите максимальный размер файла, разрешенный перед созданием нового файла журнала NPS.
Определите, нужно ли удалять старые файлы журналов, если жесткий диск выходит из дискового пространства.
Определите приложение или приложения, которые вы хотите использовать для просмотра данных учета и создания отчетов.
Ведение журнала SQL Server NPS
Ведение журнала SQL Server NPS используется при необходимости сведений о состоянии сеанса, для создания отчетов и анализа данных, а также для централизованного управления и упрощения управления данными учета.
NPS предоставляет возможность использовать ведение журнала SQL Server для записи запросов проверки подлинности и учета пользователей, полученных от одного или нескольких серверов доступа к сети к источнику данных на компьютере под управлением ядра настольных компьютеров Microsoft SQL Server (MSDE 2000) или любой версии SQL Server более поздней, чем SQL Server 2000.
Данные учета передаются из NPS в формате XML в хранимую процедуру в базе данных, которая поддерживает язык структурированных запросов (SQL) и XML (SQLXML). Запись запросов проверки подлинности и учета пользователей в базе данных SQL Server, совместимой с XML, позволяет нескольким NPS иметь один источник данных.
Ключевые шаги
Во время планирования учета NPS с помощью ведения журнала SQL Server NPS можно выполнить следующие действия.
Определите, имеет ли вы или другой член вашей организации SQL Server 2000 или SQL Server 2005 возможности разработки реляционных баз данных, и вы понимаете, как использовать эти продукты для создания, изменения, администрирования и управления базами данных SQL Server.
Определите, установлен ли SQL Server на NPS или на удаленном компьютере.
Создайте хранимую процедуру, которая будет использоваться в базе данных SQL Server для обработки входящих XML-файлов, содержащих данные учета NPS.
Проектирование структуры репликации и потока репликации базы данных SQL Server.
Определите приложение или приложения, которые вы хотите использовать для просмотра данных учета и создания отчетов.
Планируйте использовать серверы доступа к сети, отправляющие атрибут класса во всех запросах на учет. Атрибут класса отправляется клиенту RADIUS в сообщении Access-Accept и полезен для сопоставления сообщений "Учет-запрос" с сеансами проверки подлинности. Если атрибут класса отправляется сервером сетевого доступа в сообщениях запроса на учет, его можно использовать для сопоставления записей учета и проверки подлинности. Сочетание атрибутов Unique-Serial-Number, Service-Reboot-Time и Server-Address должно быть уникальным идентификатором для каждой проверки подлинности, которую принимает сервер.
Планируйте использовать серверы доступа к сети, поддерживающие промежуточный учет.
Планируйте использовать серверы доступа к сети, отправляющие сообщения об учете и учете.
Планируйте использовать серверы доступа к сети, поддерживающие хранение и пересылку данных учета. Серверы доступа к сети, поддерживающие эту функцию, могут хранить данные учета, если сервер доступа к сети не может взаимодействовать с NPS. Когда NPS доступен, сервер доступа к сети перенаправит сохраненные записи в NPS, обеспечивая повышенную надежность в учете на серверах доступа к сети, которые не предоставляют эту функцию.
Планируйте всегда настраивать атрибут Acct-Промежуточный интервал в политиках сети. Атрибут Acct-Interim-Interval задает интервал (в секундах) между каждым промежуточным обновлением, которое отправляет сервер доступа к сети. В соответствии с RFC 2869 значение атрибута Acct-Interim-Interval не должно быть меньше 60 секунд (1 минуты) и не должно быть меньше 600 секунд (10 минут), что означает, что значения более 600 секунд будут уменьшать частоту обновлений, полученных сервером RADIUS. Дополнительные сведения см. в статье RFC 2869.
Убедитесь, что ведение журнала периодического состояния включено в NPS.