Управление доступом в интрасетях
Глава 4: Разработка решения
Опубликовано 11 мая 2004 | Обновлено 26 июня 2006
В предыдущей главе рассмотрены организационные и технические вопросы, а также вопросы обеспечения безопасности для двух вариантов управления доступом в интрасетях. В ней перечислены требования к решению для каждого из вариантов. На следующей стадии осуществляется разработка соответствующего решения.
В данной главе приводятся принципы решения для каждого из вариантов управления доступом в интрасетях, а также рассматриваются необходимые условия для этого решения. В остальных главах статьи описываются особенности применения разработанного решения.
На этой странице
Интеграция рабочих станций UNIX со средствами Active Directory Идентификация пользователей на сервере приложений SAP R/3 с использованием средств Active Directory по протоколу Kerberos
Интеграция рабочих станций UNIX со средствами Active Directory
При интеграции рабочих станций UNIX с платформой управления идентификаторами и доступом компании Майкрософт с использованием протокола аутентификации Kerberos версии 5 необходимо перейти от среды сетевых информационных служб (NIS+) к среде, основанной на службе каталогов Microsoft® Active Directory®. Использование среды на основе Active Directory позволяет решить проблемы идентификации пользователей и предоставления им прав доступа на рабочих станциях UNIX, что отвечает требованиям компании Contoso по централизованному управлению учетными записями пользователей в каталоге интрасети.
Основные принципы решения
Анализ совместных возможностей средств Active Directory и рабочих станций Solaris 9 по обеспечению безопасности, выполненный в компании Contoso показал, что оптимальным протоколом интеграции рабочих станций компании с платформой управления идентификаторами и доступом компании Майкрософт является протокол Kerberos версии 5.
Данное решение реализуется путем выполнения следующих операций:
Внесение в файл pam.conf на рабочей станции UNIX указания о том, что вход пользователей в систему и их идентификацию с использованием таких стандартных средств UNIX, как telnet и FTP, следует преимущественно осуществлять по протоколу Kerberos.
Редактирование файла krb5.conf таким образом, чтобы рабочая станция UNIX использовала доменный центр распределения ключей (KDC) компании Contoso на основе ОС Windows®.
Схематическое изображение решения показано на рисунке 4.
.gif)
Рисунок 4.1. Основные принципы решения по интеграции рабочих станций UNIX со средствами Active Directory с использованием протокола Kerberos версии 5
Это решение реализуется путем задания конфигурации рабочих станций Solaris и средств Active Directory.
Необходимые условия для решения
В статье "Платформа и инфраструктура", входящей в данный комплект документации, описывается порядок использования Active Directory в интрасети компании Contoso.
Возможность использования этого решения обеспечивается путем изменения конфигурационных настроек UNIX, а существующая архитектура сети компании Contoso при этом не расширяется и не изменяется. Поэтому для этого варианта схема использующей данное решение архитектуры не приводится.
Процедура идентификации пользователя при использовании данного решения
После реализации решения и его проверки как описано в главе 5 "Реализация решения" и в главе 6 "Проверка решения" пользователи рабочей станции UNIX могут получить доступ к командной оболочке UNIX, введя свое имя пользователя и учетные данные, зарегистрированные в системе Active Directory. Запрос на вход в систему от командной оболочки передается в подключаемый модуль идентификации пользователей (PAM), а затем в библиотеку Kerberos, которая начинает обмен сообщениями между рабочей станцией и KDC на ОС Windows (этапы с 1 по 4 на рисунке 4.2). В результате этого обмена формируется мандат службы Kerberos, который может быть расшифрован библиотекой Kerberos на рабочей станции UNIX с использованием ее собственных ключей. Эта процедура показана на рисунке 4.2.
.gif)
Рисунок 4.2. Рабочая станция UNIX, использующая протокол Kerberos для идентификации пользователя, зарегистрированного в системе Active Directory
Библиотека Kerberos на машине UNIX расшифровывает этот мандат и определяет по нему имя этого пользователя в своей системе (имя UPN). После завершения идентификации пользователя процедура входа в систему получает сведения о его полномочиях при помощи стандартных интерфейсов прикладного программирования (API) системы UNIX. Запросы этих API направляются через коммутатор службы имен (NSS), подключающийся к Active Directory при помощи модуля nss_ldap и получающий запрашиваемые сведения (например, идентификатор пользователя (UID) и идентификатор группы (GID). На последнем этапе процедура входа в систему использует эти сведения для определения контекста безопасности для пользователя и запускает командную оболочку с этим контекстом.
Кроме того, библиотека Kerberos осуществляет обработку поступающих от KDC сообщений об ошибках и указаний, относящихся к учетной политике, например, сообщений пользователям о необходимости изменения пароля. Затем процедура входа выполняет (при помощи модуля PAM) действия, необходимые для обеспечения соответствия этим указаниям.
В результате проверки подлинности пользователя по базе данных KDC, использующего средства Active Directory, рабочая станция (при помощи модуля PAM и библиотеки Kerberos) запоминает в кэше мандаты Kerberos по данному пользователю. Этот кэш мандатов и позволяет пользователям в защищенном режиме получать сетевой доступ к приложениям с поддержкой протокола Kerberos, причем процедуру идентификации при этом необходимо проходить только один раз.
Если пользователь, зарегистрированный в Active Directory, ранее уже пользовался рабочей станцией UNIX, и на этой рабочей станции была создана учетная запись UNIX с тем же именем пользователя, что и в системе Active Directory, то в файле /etc/shadow могут остаться сведения об этом пользователе, в том числе и его пароль. Файл /etc/shadow можно отредактировать и удалить из него пароль пользователя, так как он больше не будет использоваться для входа на рабочую станцию UNIX.
Дополнительные сведения об осуществляемом во время входа пользователя обмене мандатом Kerberos приведены в статье "Изучение Kerberos - протокола распределенной безопасности в ОС Windows 2000", опубликованной в сети MSDN в журнале "Microsoft Systems Journal".
Расширение возможностей данного решения
Для наиболее полного удовлетворения функциональных требований, описанных в главе 3 "Проблемы и требования", параметры учетной записи пользователя UNIX, например, его uid и gid, следует хранить в Active Directory, а не на рабочей станции UNIX. Для удовлетворения этих требований компания Contoso устанавливает дополнение к схеме Active Directory, предоставляемое в составе пакета "Services for UNIX".
Для обеспечения возможности получения этих параметров идентификации пользователя на рабочей станции UNIX в конфигурации NSS на рабочей станции задается использование протокола LDAP и системы Active Directory.
Дополнительные сведения по установке дополнения к схеме Active Directory, входящего в пакет "Services for UNIX (SFU)" компании Майкрософт, и по заданию конфигурации NSS с использованием протокола LDAP приведены в Инструкции компании "Майкрософт по использованию службы каталогов Windows и службы безопасности в ОС UNIX.
Идентификация пользователей на сервере приложений SAP R/3 с использованием средств Active Directory по протоколу Kerberos
Решение компании Contoso по интеграции SAP с платформой управления идентификаторами и доступом компании Майкрософт заключается в изменении конфигурации сервера приложений SAP и графического интерфейса пользователя (GUI) клиента SAP с использованием протокола связи по защищенным сетям (SNC) и протокола Kerberos. Такой подход обеспечивает строгую проверку подлинности пользователя и безопасную передачу данных по сети.
Дополнительные сведения о возможностях SAP R/3 по защищенной передаче данных приведены на странице Интеграция и сертификация партнеров компании SAP: Варианты интеграции.
Основные принципы решения
Анализ совместных возможностей средств Active Directory и сервера приложений SAP по обеспечению безопасности показал, что оптимальным протоколом для осуществления интеграции и повышения безопасности является протокол Kerberos версии 5 по перечисленным ниже причинам.
Протокол Kerberos отвечает всем соответствующим стандартам и реализован в клиентских и серверных ОС Windows, в средствах Active Directory и в сервере приложений SAP R/3.
Протокол Kerberos позволяет передавать мандат, предоставляющий мандат, (мандат TGT), полученный во время входа в систему, на KDC с ОС Windows, формирующий мандат службы Kerberos. Впоследствии этот мандат предоставляет пользователю доступ к сетевым ресурсам и приложениям, например, к серверу приложений SAP R/3. Эта процедура прозрачна для пользователя и позволяет проходить идентификацию только один раз.
Протокол Kerberos обеспечивает создание и совместное использование ключей сессии связи между клиентом и сервером, которые позволяют осуществлять строгое шифрование данных, передаваемых впоследствии приложениями между клиентом и сервером.
Задание конфигурации сервера приложений SAP R/3 и GUI клиента SAP с использованием SNC и протокола Kerberos обеспечивает надежную идентификацию пользователя и защищает данные, передаваемые по сети приложениями SAP.
Кроме того, использование протокола Kerberos при входе на сервер приложений SAP позволяет пользователям SAP проходить процедуру идентификации только один раз благодаря их регистрации в сети Active Directory. Исключение необходимости ввода отдельного пароля на сервере SAP существенно сокращает затраты на управление паролями, в том числе затраты на системы поддержки пользователей. Основные принципы решения для этого варианта показаны на рисунке 4.3.
.gif)
Рисунок 4.3. Интеграция сервера приложений SAP R/3 со средствами Active Directory с использованием протокола Kerberos версии 5
Необходимые условия для решения
В статье "Платформа и инфраструктура", входящей в данный комплект документации, описывается порядок использования Active Directory в интрасети компании Contoso.
Возможность использования этого решения обеспечивается путем изменения конфигурационных настроек UNIX, а существующая архитектура сети компании Contoso при этом не расширяется и не изменяется. Поэтому для этого варианта схема использующей данное решение архитектуры не приводится.
Процедура идентификации пользователя при использовании данного решения
После реализации решения и его проверки как описано в главе 5 "Реализация решения" и в главе 6 "Проверка решения" пользователь сервера приложений SAP входит на свою рабочую станцию с ОС Windows, введя свои учетные данные, зарегистрированные в системе Active Directory. Затем пользователь запускает на рабочем столе графический интерфейс SAP и выбирает вариант входа по протоколу Kerberos. При помощи оболочки API для служб безопасности (GSS-API), разработанной для пакета идентификации пользователя по протоколу Kerberos, графический интерфейс SAP запрашивает мандат службы Kerberos (этап 1) для сервера приложений SAP R/3 с использованием конфигурационных данных, хранящихся в профиле графического интерфейса SAP. Пакет идентификации пользователя по протоколу Kerberos при необходимости запрашивает у контроллера домена новый мандат или получает имеющийся мандат из кэша мандатов (этап 2). Затем графический интерфейс SAP создает соединение с сервером приложений SAP R/3 и выдает соответствующий мандат в ответ на запросы (этап 3). На рисунке 4.4 показана эта последовательность операций.
.gif)
Рисунок 4.4. Идентификация пользователя клиентской машины с ОС Windows на сервере приложений SAP
Сервер приложений SAP R/3 получает мандат службы Kerberos и проверяет его подлинность путем вызова пакета идентификации пользователя по протоколу Kerberos при помощи оболочки GSS-API. В случае подтверждения подлинности мандата сервер приложений SAP R/3 извлекает UPN пользователя, а затем сопоставляет эти сведения с учетной записью, хранящейся на сервере приложений SAP R/3 (этап 5). После чего осуществляется вход пользователя на сервер приложений SAP с использованием учетной записи, хранящейся на сервере SAP, и между клиентом и сервером устанавливается сессия связи с шифрованием передаваемых приложениями данных (этап 6).
Идентификация пользователя на сервере приложений SAP R/3 осуществляется с использованием их стандартных учетных данных, передаваемых по протоколу Kerberos, поэтому процедура идентификации пользователя осуществляется только один раз.
Расширение возможностей данного решения
Это решение описывает способ ручного задания конфигурации каждой учетной записи на сервере SAP таким образом, чтобы при идентификации пользователя использовалась его учетная запись в системе Active Directory с использованием протокола Kerberos. Такое решение приемлемо для организаций с небольшим количеством прямых пользователей SAP, например, для отдела кадров со средним количеством персонала.
Для компаний с большим количеством пользователей SAP рекомендуется применять более автоматизированные средства создания и синхронизации для управления учетными записями SAP (в том числе сопоставление с учетными записями Active Directory). Такое решение можно подготовить с использованием сервера Microsoft Identity Integration Server 2003, версия для предприятий с пакетом обновлений 1 (MIIS 2003 с SP1).
Примечание При разработке данного решения можно предусмотреть и использование рабочих станций UNIX, осуществляющих идентификацию пользователей на сервере приложений SAP R/3 по протоколу Kerberos версии 5, но по ряду причин безотлагательное применение такого решения в компании Contoso оказалось затруднительным. Основная причина отказа компании Contoso от реализации такого решения в настоящее время заключается в том, что компания SAP одобряет использование для платформы UNIX лишь нескольких библиотек GSS-API. Когда перечень одобряемых SAP библиотек GSS-API расширится и будет включать уже используемую в Contoso версию, или когда компания начнет использовать другую, одобренную версию, можно будет приступить и к этому этапу проекта.
Скачать
Уведомления об изменениях
Подпишитесь на рассылку уведомлений о выпуске изменений и новых редакций этого документа
Обратная связь