Поделиться через

Управление доступом к интрасети

Глава 2: Методы управления доступом в интрасеть

Опубликовано 11 мая 2004 | Обновлено 26 июня 2006

Есть несколько способов улучшить управление доступом в интрасеть в пределах организации, которая использует технологии Майкрософт. Подход, который переводит платформы и приложения на использование общих служб безопасности, выполняющих проверку подлинности и авторизацию, может сделать возможной однократную идентификацию (SSO) пользователей, улучшить аудит безопасности, использовать преимущества существующих доверительных отношений, объединить вашу инфраструктуру, снизить расходы на управление и улучшить безопасность сети.

Однако не все подходы равноценны по эффективности, легкости реализации и безопасности. Эти подходы, в порядке предпочтения, следующие:

  • Интеграция приложений со службами безопасности Windows. Этот подход разрабатывает новые и переводит существующие приложения на использование служб безопасности платформы Microsoft® Windows®, включая проверку подлинности и авторизацию. Интеграция со службами безопасности Windows уменьшает затраты на разработку приложений и позволяет приложениям легко использовать однократную идентификацию, правила доверия и возможности аудита безопасности операционной системы Windows.

  • Интеграция платформ со службами каталогов и безопасности Windows . Этот подход настраивает другие платформы на использование служб каталогов и безопасности, которые поддерживаются службой каталогов Microsoft Active Directory®, что делает возможным взаимодействие между платформами и облегчает администрирование.

  • Интеграция приложений со службами каталогов Windows . Разработка и перевод приложений на использование стандартных протоколов каталогов, поддерживаемых службой Active Directory, в целях проверки подлинности и авторизации пользователей делают возможным создание хранилища идентификаторов.

  • Непрямая интеграция путем сопоставления учетных данных. Когда прямая интеграция приложения или платформы невозможна, метод сопоставления учетных данных (также известен как Enterprise Single Sign On, или ESSO) может предоставить пользователям возможности однократнoй идентификации.

  • Синхронизированные учетные записи и пароли. Когда ни один из других вариантов недоступен, и были приняты во внимание риски безопасности, использование общих учетных данных для различных приложений и платформ сможет уменьшить недовольство пользователей.

Менее предпочтительный подход может быть выбран из-за возможностей ведущей системы, возможностей замены приложения, или ожидаемого дохода на инвестиции (ROI), вложенные в осуществление решения.

На этой странице

Интеграция приложений со службами безопасности Windows Интеграция платформ со службами каталогов и безопасности Windows Интеграция приложений со службами безопасности Windows Непрямая интеграция путем сопоставления учетных данных. Синхронизированные учетные записи и пароли.

Интеграция приложений со службами безопасности Windows

Интеграция приложений со службами безопасности Windows (или, по-другому, приложения, интегрированные с Windows), обеспечивает следующие преимущества:

  • Однократная идентификация для клиентов Windows

  • Большая безопасность для данных прикладных программ, передаваемых по сети.

  • Более эффективное управление цифровыми удостоверениями в службе Active Directory.

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

  • Расширенный диапазон служб проверки подлинности и авторизации, через использование доверительных отношений, позволяющих ограничить расходы на управление.

  • Интегрированное ведение журнала событий системы безопасности.

Этот раздел описывает преимущества приложений, интегрированных с Windows, и рассматривает следующие темы:

  • Однократная идентификация в Windows и управление доступом.

  • Примеры приложений, интегрированных с Windows.

Примечание   Для получения дополнительной информации о разработке приложений для Microsoft ASP.NET, которые интегрируются со службами безопасности Windows, см. статью «Разработка приложений ASP.NET, способных к идентификации» (Developing Identity-Aware ASP.NET Applications) в данной серии.

Служба однократной идентификации в Windows и управление доступом

Компьютеры-клиенты, работающие под управлением операционных систем класса Microsoft Windows, таких как Microsoft® Windows® XP Professional и Windows® 2000 Professional (сюда также входит любой серверный продукт, например, Windows Server™ 2003 в качестве клиента), включают в себя встроенные функции, которые позволяют однократную идентификацию пользователей, когда клиент или сервер присоединяются к домену Windows или лесу. Междоменная однократная идентификация обеспечивается путем установления доверия между доменами или лесами, как описано в статье «Фундаментальные понятия» в этой серии.

Следующие функции, которые реализованы в службах безопасности Windows, обеспечивает возможность однократной идентификации:

  • Кэш учетных данных, управляемый службой Local Security Authority (LSA).

  • Набор программ проверки подлинности, интегрированных в LSA.

Понимание процесса входа в систему Windows является обязательным для понимания того, как службы безопасности Windows обеспечивают однократную идентификацию. В следующих разделах содержится краткий обзор того, как происходит этот процесс, и как обеспечивается возможность однократной идентификации.

Процесс входа в систему

В операционной системе Windows механизм входа пользователя в систему является неотъемлемой частью как для компьютера-клиента, так и для сети. Пользователь должен только один раз подтвердить свою подлинность при входе в сеть, введя свои учетные данные уровня домена. Эта однократная идентификация в системе позволяет пользователю войти в свою рабочую станцию и получить доступ к любым локальным или удаленным ресурсам, к которым ему был предоставлен доступ. Процесс входа в систему описан на Рис. 2.1.

Рисунок 2.1. Интегрированный в Windows процесс проверки подлинности при входе в систему настольного компьютера

Как часть процесса входа в систему, пользователь вызывает GINA DLL (Graphical Identification and Authentication), нажимая CTRL+ALT+DEL. Функция безопасной проверки подлинности (SAS) выдает пользователю диалоговое окно входа в систему Windows (шаг 1). Здесь пользователь вводит свои учетные данные в диалоговое окно.

После этого служба Local Security Authority (LSA) посылает запрос Ticket Granting Ticket (TGT) или TGT-REQ (шаг 2) на контроллер домена, где запущена служба Active Directory. Служба Key Distribution Center (KDC) протокола Kerberos V5, работающая в рамках службы LSA на контроллере домена подтверждает подлинность имени пользователя и пароля, вызывая службу Service Accounts Manager (SAM) (шаг 3) на контроллере домена. Если учетные данные правильны, и никакие другие элементы политики (например ограничения времени или рабочей станции) не препятствуют входу пользователя в систему, LSA на контроллере домена передает либо билеты протокола проверки подлинности Kerberos V5 (шаг 4), либо данные авторизации службы NT LAN Manager (NTLM) (не показано) назад в службу LSA на компьютере-клиенте.

Примечание В программах проверки подлинности (также известны как провайдеры проверки подлинности) на клиентах и серверах Windows реализованы и другие протоколы проверки подлинности, но эта статья рассматривает главным образом протокол проверки подлинности Kerberos версии 5 и упоминает протокол NTLM только по мере необходимости.

Создание контекста авторизации

Кроме другой информации, билет Kerberos содержит сертификат Privilege Attribute Certificate (PAC), который включает в себя идентификатор безопасности (SID) для пользователя и группы, членом которой он является. Эта структура показана на Рис. 2.2.

На основе билета Kerberos (шаг 5 на Рис. 2.1) или данных авторизации NTLM рабочая станция создает маркер доступа. (Иногда это называется контекстом безопасности, но понятие маркера доступа более применимо при обсуждении локальной авторизации в отличие от механизма проверки подлинности в сети.)

Маркер доступа Windows содержит:

  • Первичный идентификатор безопасности (SID) пользователя

  • Глобальные и универсальные групповые идентификаторы SID из учетной записи пользователя, домена или леса.

  • Локальные SID домена из домена рабочей станции (если они отличаются от домена пользователя).

  • Привилегии, которые явно назначены пользователю или получены в результате членства в группе.

Последовательность входа в систему на компьютере-клиенте запускает команду оболочки (обычно это файл Explorer.exe) и прикрепляет маркер доступа пользователя к оболочке (шаг 6 на Рис.2.1).

Рисунок 2.2. Билет Kerberos содержит сертификат PAC, который, в свою очередь, содержит SID группы и пользователя

Доступ к локальным ресурсам

Все приложения, которые будут запущены на рабочей станции с данной операционной системой, унаследует маркер доступа из процесса операционной системы (оболочки). Поэтому, после того как пользователь вошел в систему, любая попытка обратиться к локальному ресурсу, например, команда открыть файл или распечатать документ, поданная из оболочки операционной системы или любого процесса, начатого оболочкой, заставляет рабочую станцию сравнивать маркер доступа пользователя со списком управления доступом (ACL) на объекте, к которому происходит доступ.

Доступ к удаленным ресурсам

Любая попытка пользователя выполнить операцию на удаленном ресурсе, например, открыть файл в разделяемом сетевом хранилище файлов или распечатать документ на сетевом принтере, заставляет клиента и сервер выполнить последовательность команд проверки подлинности. Последовательность команд проверки подлинности выполняется, по умолчанию, с теми же самыми учетными данными, которые использовались при входе в рабочую станцию. Интеграция провайдеров проверки подлинности протоколов Kerberos и NTLM со службой LSA на рабочей станции как раз и создает возможность однократной идентификации для пользователя Windows. Этот процесс описан на рисунке 2.3.

Рисунок 2.3. Процесс проверки подлинности при входе на удаленный ресурс

В этом примере предполагается, что вход в систему рабочей станции был выполнен при использовании протокола Kerberos, который является стандартным механизмом проверки подлинности в Microsoft Windows ® 2000 и Windows Server 2003. Если бы начальный вход в систему происходил через протокол NTLM, то последовательность была бы несколько иной.

Пользователь пытается обратиться к файлу на удаленном компьютере, который работает под управлением Windows Server 2003 (шаг 1). Сервер требует проверки подлинности и посылает пользователю "вызов" (шаг 2). После этого служба LSA на компьютере-клиенте запускает программу проверки подлинности протокола Kerberos и запрашивает у него необходимые учетные данные (шаг 3). Программа проверки подлинности Kerberos удовлетворяет запрос, извлекая предварительно выпущенный и правильный билет из кэша билетов (шаг 4) на компьютере-клиенте, или запрашивая у KDC новый билет (TKT) для сервера (не показано), и, наконец, клиент отвечает на вызов сервера, посылая серверу билет (шаг 5).

После того как билет проверен (шаг 6), провайдер проверки подлинности протокола Kerberos создает маркер доступа, как уже было описано выше (шаг 7). Используя этот маркер, сервер может олицетворить (шаг 8) пользователя на компьютере-клиенте. Олицетворение позволяет серверу положиться на операционную систему, чтобы она провела правильную авторизацию, сравнивая права пользователя, зафиксированные в маркере доступа, со списком ACL на ресурсе (шаг 9). После этого операционная система либо разрешает (как показано на Рис. 2.3), либо запрещает операцию, в зависимости от ситуации.

Аудит безопасности

Аудит безопасности может быть настроен как для проверки подлинности (включая вход в систему рабочей станции), так и авторизации. Аудит безопасности должен быть настроен так, чтобы выполнять официальную политику безопасности организации. Аудит проверки подлинности можно настроить так, чтобы проверять успешность или неуспешность входа в систему, или оба этих события.

Аудит авторизации настраивается на уровне объекта и может быть детализирован до уровня, определяемого операциями на объекте. Например, можно проверять неудачные или успешные операции чтения, записи или редактирования файла.

Расширение доступа путем использования доверительных отношений

Вы можете увеличить эффект интегрированной службы проверки подлинности Windows, используя доверительные отношения Windows. Доверительные отношения между двумя доменами Windows или между лесами в Windows Server 2003 дают возможность предоставить учетным записям пользователя в одном, доверяемом домене, права и разрешения в другом, доверяющем домене.

Доверительные отношения расширяют возможности SSO, так как пользователь не должен регистрироваться вновь, чтобы обратиться к ресурсам в доверяющем домене. Когда пользователь пытается соединиться с ресурсом в доверяющем домене, доверяющий домен соединяется с доверяемым доменом, используя доверительные отношения, и проверяет учетные данные пользователя. После этого к ресурсу в доверяющем домене предоставляется доступ, в зависимости от прав пользователя в доверяемом домене.

Междоменные доверительные отношения установлены по умолчанию для доменов Windows 2000 в одном лесу. В доменах Windows Server 2003 установление доверительных отношений между лесами позволяет всем доменам в одном лесу доверять доменам в другом лесу.

Когда доверительные отношения не могут быть установлены, можно использовать службу Windows Credential Manager, чтобы обеспечить возможность однократной идентификации для пользователя через приложение, которое использует службу Windows Integrated Authentication. Диспетчер учетных данных (Windows Credential Manager) будет рассмотрен более подробно далее в этой главе.

Для получения дополнительной информации о механизмах доверия в Windows, см. страницу What Are Domain and Forest Trusts?.

Для получения дополнительной информации о планировании и реализации доверительных отношений между лесами в системе Windows Server 2003, см. страницуPlanning and Implementing Federated Forests in Windows Server 2003.

Улучшение процесса доступа с помощью Диспетчера учетных данных Windows

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

  • Когда есть потребность получить доступ к ресурсу в недоверяемом домене.

  • Когда есть потребность получить доступ к ресурсу на автономном сервере.

  • Когда есть потребность использовать дополнительные учетные данные, чтобы обратиться к сетевому ресурсу.

Microsoft Windows® XP и Windows Server 2003 учитывает эти случаи через компонент, интегрированный в службу и известный как Сохраненные имена пользователей и пароли (обычно называемый Диспетчером учетных данных Windows), который обеспечивает функции управления учетными данными на стороне клиента.

Этот компонент можно настроить одним из двух способов: Потребовать, чтобы пользователь вручную вводил учетные данные каждый раз перед обращением к ресурсу, или автоматически сохранять учетные данные пользователя и использовать их для будущих случаев доступа.

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

Некоторые приложения и интерфейсы для разработчиков написаны так, чтобы использовать Диспетчер учетных данных Windows, когда это необходимо. От пользователя при этом потребуется следующее: при первой попытке обратиться к ресурсу, который требует проверки подлинности, приложение запросит пользователя ввести учетные данные. Если позволяет приложение, используемое для доступа к ресурсу, пользователь может сохранить свои учетные данные. Учетные данные теперь связаны с ресурсом, который их запросил. Когда пользователь обратится к ресурсу в будущем, программа проверки подлинности использует сохраненные учетные данные, уже не запрашивая о них пользователя. Однако, если приложение не позволяет пользователю сохранить учетные данные, пользователь должен вручную установить учетные данные для этого ресурса, войдя в компонент Сохраненные имена пользователей и пароли (Stored User Names and Passwords) Диспетчера учетных данных Windows. Диспетчер учетных данных Windows можно настроить так, чтобы передавать учетные данные в протоколы Kerberos и NTLM, протокол SSL (Secure Sockets Layer), протокол TLS, службы Microsoft Passport и обычной проверки подлинности.

Чтобы получить дополнительную информацию о том, как приложения могут использовать компонент Сохраненные имена пользователей и пароли, см. раздел Using Credential Management in Windows XP and Windows Server 2003 на веб-узле Microsoft MSDN®.

Примеры приложений, интегрированных с Windows.

Приложения типа клиент/сервер могут использовать механизмы, описанные выше, чтобы обеспечить однократную идентификацию пользователей, интегрированный аудит безопасности и преимущества доверительных отношений. Хотя многие приложения Майкрософт и независимых разработчиков, как клиентские, так и серверные, используют интегрированные функции безопасности Windows для однократной идентификации, следующие приложения клиент/сервер представляют собой особый интерес:

  • Microsoft Internet Explorer и Internet Information Services (IIS).

  • Microsoft Office Outlook® и Exchange Server 5.5 или выше.

  • Microsoft SQL Server™ 7.0 или выше и SQL Server для клиентов.

В разделах ниже приведены примеры того, как служба Интегрированной проверки подлинности (Windows Integrated Authentication) работает в этих приложениях.

Internet Explorer и IIS

Обеспечение однократной идентификации в сети (Web SSO) для браузеров интрасети очень важно для пользователей, работающих с веб-приложениями. Internet Explorer — это интегрированное приложение Windows, которое обеспечивает механизм Web SSO в интрасети с использованием IIS 5.0 (входит в Windows 2000 Server) и IIS 6.0 (входит в Windows Server 2003). Рис. 2.4 показывает, как служба Интегрированной проверки подлинности Windows работает с Internet Explorer и IIS.

Рисунок 2,4. Проверка подлинности для IIS с использованием протокола Kerberos

Администратор IIS, который хочет позволить только уже зарегистрированным пользователям обращаться к веб-приложению интрасети, обычно будет настраивать сайт или виртуальный каталог так, чтобы использовать службу Windows Integrated Authentication. С включением такого параметра безопасности, клиентское приложение для Internet Explorer должно сначала подтвердить подлинность пользователя в веб-сервере IIS 6.0, используя либо протокол Kerberos, либо протокол проверки подлинности NTLM. Протокол Kerberos версии 5 предпочтителен в большинстве случаев, но есть такие настройки сети и безопасности в контроллере домена, сервере, где запущен веб-сервер IIS 6.0, и на уровне клиента Internet Explorer, которые администратор может использовать, чтобы применить проверку подлинности по протоколу NTLM.

Ниже приведен пример того, как проверка подлинности по протоколу Kerberos работает с Internet Explorer и IIS. Вначале клиент, где запущен Internet Explorer, делает запрос на получение страницы (шаг 1). Сервер, где работает веб-сервер IIS 6.0, выполняет проверку подлинности через протокол HTTP, посылая назад на браузер вызов с кодом 401 (шаг 2). Этот вызов включает в себя список заголовков HTTP WWW-Authenticate , которые указывают протоколы проверки подлинности, приемлемые для данного URL, на которые настроен сервер, где работает IIS 6.0.

Когда Internet Explorer получает вызов 401, он проверяет список заголовков и выбирает соответствующий протокол проверки подлинности, на основе настроек браузера. Internet Explorer вызывает программу проверки подлинности через LSA (шаг 3). На основе учетных данных пользователя, присутствующих в кэше учетных данных службы LSA рабочей станции, и возможности получить билет Kerberos для ресурса IIS (шаг 4), полученный билет затем возвращается из LSA в Internet Explorer (шаг 5). После того как Internet Explorer получает билет, он, в ответ на вызов 401, отсылает билет обратно на сервер, где работает IIS, и этот билет включает в себя заголовок HTTP WWW-Authenticate (шаг 6).

После того как клиент послал серверу ответ, сервер, где работает IIS 6.0, извлекает опознавательную информацию из заголовка HTTP и посылает эти данные провайдеру проверки подлинности, который указан клиентом (шаг 7). Если проверка подлинности прошла успешно, провайдер проверки подлинности создает маркер доступа, который представляет пользователя, и IIS 6.0 ассоциирует этот маркер с запросом клиента (шаг 8), используя механизм олицетворения. Рис. 2.4 показывает этот процесс в действии.

Важно понимать, что серверное приложение IIS 6.0 не проверяет подлинность пользователя в течение этого процесса. Серверное приложение поручает эту задачу операционной системе, через интерфейс провайдера проверки подлинности. Серверное приложение пользуется преимуществами этой схемы, позволяющей ему не запускать программу проверки подлинности на своей стороне.

Если будут выполнены следующие условия, то проверка подлинности и авторизация пройдут успешно, и пользователю не придется вводить дополнительные учетные данные:

  • Сервер, где работает IIS, является членом домена Windows.

  • Клиент, то есть рабочая станция под управлением Windows, является членом домена, с которым у домена, где находится сервер с IIS, установлены доверительные отношения.

  • Пользователь зарегистрировался на рабочей станции, используя свои учетные данные домена.

  • Пользователю предоставлен доступ к требуемому ресурсу, потому что выполнено одно из следующих условий.

    • Администратор IIS 6.0 настроил списки ACL для статического контента (файлы с расширениями .htm и .asp), который позволяет доступ пользователя.

    • Приложение Microsoft ASP.NET определяет роли Microsoft .NET или Диспетчера авторизации, которые разрешают доступ пользователя.

Для получения дополнительной информации о процессе проверки подлинности и авторизации см.:

Microsoft Office Outlook и Exchange Server

В этом примере пользователь входит в систему рабочей станции Windows со своей учетной записью. После этого пользователь запускает клиента электронной почты Outlook, который пытается соединиться с приложением Exchange Server, работающим на Windows Server 2003, используя интерфейсы Remote Procedure Call (RPC). Приложение Exchange Server требует проверки подлинности клиента, прежде чем подключение будет установлено, и клиент совместно сервером договариваются об опознавательных сообщениях в течение сеанса RPC

В случае с Outlook и Exchange вначале предпринимается попытка проверки подлинности по протоколу Kerberos (Kerberos является более привилегированным протоколом по сравнению с NTLM). Если попытка была успешной, для приложения Exchange Server генерируется маркер доступа, который указывает операционной системе произвести правильную авторизацию. Почтовый клиент Outlook пытается открыть почтовый ящик пользователя, но эта операция будет успешной только тогда, когда списки управления доступом (ACL) на почтовом ящике настроены так, чтобы предоставить доступ для пользователя, который пытается соединиться. Если процесс проверки подлинности прошел успешно, и правила авторизации, описанные в списке ACL почтового ящика, выполнены, пользователю предоставляется доступ к почтовому ящику в Outlook, без необходимости повторной регистрации.

SQL Server и клиенты SQL

Похожий процесс происходит и с базами данных SQL Server, которые настроены так, чтобы использовать либо режим проверки подлинности (Authentication Mode) Windows, либо смешанный режим (Mixed Mode). Режим проверки подлинности Windows в SQL Server эквивалентен службе Интегрированной проверки подлинности в Windows, как описано ранее для IIS 6.0, в то время как смешанный режим позволяет комбинацию проверки подлинности на базе Windows и на базе SQL Server.

Администратор базы данных SQL Server может определить доступ пользователей или групп, занесенных в каталог Active Directory, на уровне таблицы или базы данных. Когда приложение-клиент, например SQL Query Analyzer, или другое прикладная программа, которая использует Open Database Connectivity (ODBC) или Microsoft ADO.NET, соединяется с базой данных, SQL Server проверяет подлинность пользователя и затем определяет, должны ли требуемые данные быть возвращены клиенту. Проверка доступа сравнивает разрешения пользователя либо на уровне всей базы данных, либо, более точно, на уровне таблицы, основываясь на списках ACL, сохраненных операционной системой SQL Server, и на маркере доступа пользователя. Если проверка подлинности и доступа прошла успешно, то пользователь получает доступ к данным SQL Server, без необходимости регистрироваться отдельно на приложении SQL Server.

Для получения дополнительной информации о том, как настроить и использовать Windows Integrated Authentication с SQL Server, см. страницу Administering SQL Server: Authentication Modes.

К началу страницы

Интеграция платформ со службами каталогов и безопасности Windows

В системе Windows имеется ряд служб для интеграции Windows с другими платформами. Эти службы предоставляют организациям несколько вариантов для интеграции (на определенном уровне) других платформ со службами безопасности и каталогов Windows. Интеграция через эти службы обычно не влечет за собой изменения приложений или перенастройки рабочих станций и серверов. Однако они вводят дополнительные "подвижные части" в сеть и имеют отдельные требования к управляемости. Обычно эти службы не предлагают всех возможностей и функций, которые можно достигнуть через прямую интеграцию со службами безопасности Windows.

Интеграция с UNIX и Linux

Интеграция этих платформ со службами безопасности Windows использует протокол Kerberos V5. Протокол Kerberos является превосходным выбором для интеграции платформ UNIX и Linux с операционной системой Windows, потому что все они поддерживают этот протокол (иногда с помощью продуктов независимых производителей).

Преимущества использования протокола Kerberos V5 для интеграции следующие:

  • Kerberos является протоколом, основанным на стандартах (Internet Engineering Task Force (IETF) RFC 1510), которые используются в продуктах типа клиент и сервер для Microsoft Windows, в службе Active Directory и почти во всех версиях UNIX и Linux.

  • Протокол Kerberos поддерживает безопасный вход в систему.

  • Регистрация в системе с использованием протокола Kerberos может обеспечить контекст авторизации (включая группы) и информацию о профиле через следующие механизмы.

    • Обработка информации сертификата PAC Windows в билетах Kerberos, выпущенных контроллерами домена Windows. Не все производители платформ изменили свои реализации протокола Kerberos V5 так, чтобы он запрашивал PAC Windows во время запросов билетов. Это ограничение включает в себя текущую версию библиотек протокола Kerberos, которые поставляются вместе с операционной системой SUN Solaris 9.

      Для получения дополнительной информации о PAC Windows прочтите статью "Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources" на портале MSDN.

    • Настройка диспетчера службы имен (NSS) рабочей станции UNIX для использования протокола LDAP с модулем с nss_ldap: Модуль nss_ldap модуль обеспечивает средства для рабочих станций UNIX для извлечения данных авторизации из каталога LDAP, на основе главного имени в билетах Kerberos, выпущенных службой Windows Key Distribution Center (KDC). Этот подход к авторизации обычно требует расширения схемы и использования службы Active Directory, которая добавляет группу типа UNIX и данные авторизации. Служба Microsoft Services for UNIX (SFU) обеспечивают расширение схемы, которое отвечает этому требованию.

    • Настройка диспетчера службы имен NSS рабочей станции UNIX для использования службы NIS (Network Information Service) с модулем nss_nis: Вы можете установить службу SFU, чтобы обеспечить "понимание" NIS для службы Active Directory. При использовании SFU, служба Active Directory будет работать как сервер NIS, а также осуществит расширение схемы в Active Directory, чтобы ввести в нее данные об общем профиле UNIX и авторизации, идентификаторы пользователя (UID), идентификаторы группы (GID), и информацию об оболочке операционной системы.

  • Протокол Kerberos в службе Active Directory полностью интегрирован со строгой политикой безопасности, которая выполняется контроллерами домена, где запущен Windows Server 2003. Перед обработкой запроса на вход в систему от Kerberos, контроллер домена сравнивает все уместные настройки политик со статусом текущей учетной записи. Если какое-нибудь требование политики не выполняется, контроллер домена отвергает запрос.

  • Протокол Kerberos указывает, что билет TGT (Ticket Granting Ticket), полученный при входе в систему, может быть передан службе KDC, для генерации билета службы. Билет службы затем используется, чтобы получить доступ к сетевым ресурсам и приложениям, например к SAP R/3 Application Server. Этот процесс прозрачен для пользователя и позволяет реализовать однократную идентификацию пользователя в системе.

  • Протокол проверки подлинности Kerberos включает в себя создание и совместное использование ключей сеанса клиент-сервер, которые обеспечивают надежное кодирование данных прикладной программы, впоследствии передаваемых между клиентом и сервером.

Обычные пользователи UNIX и Linux регистрируются на своих компьютерах, вводя уникальное имя пользователя и пароль. Имя пользователя и пароль сравниваются с теми, которые сохранены в файлах /etc/password и /etc/shadow. Служба Pluggable Authentication Module (PAM) расширяет возможности проверки подлинности и авторизации в UNIX и Linux, позволяя сохранять учетные данные в различных местах. PAM также позволяет использовать различные механизмы для проверки учетных данных пользователя.

На системах, которые используют PAM, процесс входа в систему и все утилиты, которые требуют опознавания пользователя, должен быть скомпилированы так, чтобы использовать PAM для проверки подлинности и авторизации.

Большинство версий UNIX и многие версии Linux включают в себя поддержку протокола Kerberos V5 через файл конфигурации PAM, который называется pam.conf. Многие из этих версий операционных систем также предоставляют библиотеки, которые реализуют клиент-серверную часть протокола Kerberos. Поддержка протокола Kerberos в UNIX и Linux обеспечивает возможность плавной интеграции приложений на компьютерах под управлением UNIX и Linux со службами безопасности Windows.

Главы 3 - 7 этой статьи описывают подробный сценарий настройки проверки подлинности по протоколу Kerberos на рабочей станции UNIX Sun Solaris, с целью интеграции со службой Active Directory для опознавания пользователя и авторизации.

Службы для UNIX 3.5

Служба Microsoft Windows Services for UNIX (SFU), дает возможность клиентам Windows, клиентам UNIX и серверам совместно использовать сетевые ресурсы, интегрирует управление учетными записями, упрощает управление взаимодействием между платформами и обеспечивает полноценное окружение для выполнения программ UNIX и приложений, которое одновременно является родным для операционной системы Windows. Для получения дополнительной информации о SFU см. веб-сайт Windows Services for UNIX.

Взаимодействие между Windows Server 2003 R2 и UNIX

Windows Server 2003 R2 включает в себя компоненты взаимодействия с UNIX, которые представляют собой часть операционной системы. В эти компоненты входят:

  • Подсистема для приложений UNIX, которая обеспечивает компиляцию и запуск приложений UNIX на Windows Server 2003 R2.

  • Служба Identity Management for UNIX (IDMU), которая обеспечивает интеграцию служб безопасности и каталогов UNIX. IDMU включает в себя дополнительное обновление схемы Active Directory, которое импортирует NIS и расширения схемы Kerberos.

  • Службы Майкрософт для протокола Network File System, который включает в себя ряд компонентов для совместного использования файлов, обеспечивает безопасность файлов и управляет совместным использованием файлов и печати между системами Windows и UNIX.

Для получения дополнительной информации, см. статью: "UNIX Interoperability in Microsoft Windows Server 2003 R2".

Служба Vintela Authentication Services

Компания Vintela Inc. (теперь входит в Quest Software) — партнер Майкрософт и независимый разработчик ПО, который сосредоточил свои усилия на интеграции UNIX с платформой Майкрософт. Vintela Authentication Services (VAS) интегрирует версии операционных систем UNIX/Linux со службой Active Directory, путем интеграции родных интерфейсов UNIX с Active Directory, на основе протоколов Kerberos и LDAP.

Для получения дополнительной информации о VAS, см. веб-сайт компании Vintela.

Интеграция с Novell NetWare

Служба Microsoft Windows Services for Netware (SFN) 5.02 обеспечивает ряд утилит взаимодействия, которые упрощают интеграцию Windows Server 2003 и Active Directory с сетевым окружением Novell Netware и его службой Novell Directory Service (NDS).

Для получения дополнительной информации о SFN см. Microsoft Windows Services for Netware 5.03.

Интеграция с Apple Macintosh

Служба Services For Macintosh (SFM), входящая в Microsoft Windows Server 2003 — это полностью интегрированный компонент Windows Server 2003, позволяющий компьютерам, работающим под управлением ОС Windows и Macintosh, совместно использовать файлы и принтеры. После установки SFM эти компьютеры могут выполнять функции файлового сервера, сервера удаленного доступа и сервера печати для компьютеров, работающих под управлением ОC Macintosh. Кроме того, Windows Server 2003 со службой SFM может выполнять функции маршрутизатора AppleTalk.

Для получения дополнительной информации о SFM, см. страницуWindows 2000 SFM на портале Mactopia Web.

Интеграция с мэйнфреймами

Интеграция операционных систем мэйнфреймов, например ОС/390 и z/ОС от IBM, со службами безопасности и каталогов Windows может быть выполнена несколькими способами:

  • Сопоставление учетных данных через службу Microsoft Host Integration Server (HIS).

  • Интеграция платформ через протокол Kerberos.

  • Подходы к интеграции приложений, которые используют LDAP и GSS-API.

Служба HIS обеспечивает подход сопоставления учетных данных (или ESSO) для косвенной интеграции Active Directory с хранилищами каталогов мэйнфреймов. Для получения дополнительной информации по этой теме, см. раздел «Косвенная интеграция через сопоставление учетных данных» ниже в этой статье.

Мэйнфреймы IBM с обновленными версиями IBM SecureWay Security Server (куда входит служба Resource Access Control Facility (RACF)), поддерживают протокол Kerberos, LDAP, SSL, GSS-API и другие стандарты, связанные с управлением доступом, которые описаны в статье «Фундаментальные понятия» в этой серии. Использование стандартных протоколов, таких как Kerberos, делает теоретически возможной конфигурацию RACF на мэйнфрейме, с целью взаимодействия с протоколом Kerberos KDC, разработанным в Майкрософт.

Также, теоретически можно настроить или перенести приложения на мэйнфреймах, которые используют такие стандарты как LDAP и GSS-API, на использование служб безопасности и каталогов Windows.

Для получения дополнительной информации о том, как использовать стандарты RACF, которые поддерживают интеграцию со службами безопасности и каталогов Windows, см. следующие ресурсы.

Интеграция с J2EE

J2EE являетcя платформой разработки приложений, которую многие клиенты рассматривают вместо, или в дополнение к платформе Microsoft .NET Framework для разработки приложений. Интеграция приложений J2EE со службами безопасности и каталогов Windows возможна при использовании одной или более из следующих технологий:

  • Браузер — веб-сервер Серверы приложений J2EE, такие как Apache и BEA WebLogic, поддерживают протокол Kerberos через подключаемые модули идентификации, поставляемые разработчиком ПО в виде открытого кода или независимыми разработчиками ПО (ISV).

  • Протокол LDAP. Любое приложение J2EE, которое выполняет основную проверку подлинности на основе форм, может проверить учетные данные пользователя на соответствие с Active Directory, используя протокол LDAP.

  • Веб-службы — безопасность. Технология WS-Security определяет несколько типов маркеров, включая маркеры для протокола Kerberos и X.509, которые обеспечивают интеграцию между приложениями J2EE и службами безопасности Windows.

Vintela

Компания Vintela (теперь входит в Quest Software) интегрировала JCSI Kerberos от Wedgetail в решение Vintela Single Sign-on for Java (VSJ). VSJ — это серверное решение, которое позволяет использовать службу Windows Integrated Authentication серверами приложений Java. Для получения дополнительной информации о продуктах Vintela, см. веб-сайт компании Vintela.

К началу страницы

Интеграция приложений со службами безопасности Windows

Когда естественная интеграция между приложениями и службами безопасности Windows невозможна, вы можете интегрировать приложения в среду Windows через службы каталогов Windows, или через программу, которая расширяет функциональные возможности Active Directory. Это решение, возможно, не столь элегантно, как полностью интегрированный подход, описанный ранее, но оно может оказаться необходимым для различных платформ и приложений, которые не поддерживают прямую интеграцию с Windows.

Интеграция со службами каталогов может просто требовать такой настройки приложений, серверов или рабочих станций, которая позволяет использовать службу Active Directory, например LDAP. В некоторых случаях, приложениям, возможно, потребуется модификация, чтобы их можно было полностью интегрировать со службами каталогов Windows, или может потребоваться каталог приложений, такой как Active Directory Application Mode (ADAM).

В следующих разделах приведены примеры того, как интегрировать приложения со службами каталогов Windows, используя LDAP и ADAM.

Интеграция с LDAP

Служба Active Directory соответствует протоколу LDAP 3.0, который определен стандартом RFC 3377 и другими стандартами RFC. Так как многие другие доступные в продаже службы каталогов поддерживают LDAP, и многие приложения используют LDAP для обращения к этим службам каталогов, стандартизированный протокол, такой как LDAP, может обеспечить взаимодействие при управлении доступом между существующими приложениями, как родными, так и выполненными независимых разработчиков, и службой Active Directory.

Для получения дополнительной информации о поддержке Active Directory LDAP, см. статью Active Directory LDAP Compliance.

Протокол LDAP может обеспечить интеграцию функций проверки подлинности и авторизации между Active Directory и приложениями, работающими на любой клиентской или серверной операционной системе, которая поддерживает LDAP. В этой роли Active Directory становится хранилищем идентификаторов для приложения. Вообще, приложения могут использовать LDAP напрямую, через интерфейсы прикладных программ (API) стандарта RFC 1823, которые предоставляются операционной системой, где запущено приложение, или дополнительными модулями, например, Open LDAP, который является библиотекой LDAP с открытым кодом для операционных систем UNIX и Linux.

Разработка приложений для применения протокола LDAP

Разработка приложений не является главной темой этой статьи, но важно отметить, что интеграция с Active Directory через протокол LDAP может потребовать внесения некоторых изменений в существующие приложения. Некоторые из этих изменений могут потребоваться из-за:

  • Тонких различий в реализациях LDAP.

  • Более сложной структуры каталога, основанной на доменах Active Directory и лесах.

  • Требований использовать преимущества функций безопасности LDAP в платформе Windows.

Для приложений на клиентах и серверах Windows, которые не интегрируются со службами безопасности Windows, есть выбор среди интерфейсов API, которые можно использовать для интеграции со службами каталогов Windows. Служба Active Directory поддерживает следующие интерфейсы.

  • Набор интерфейсов LDAP Win32 API, соответствующий стандарту RFC 1823, для приложений на C и C++.

  • Active Directory Service Interfaces (ADSI) для приложений Microsoft Visual Basic® и сценариев VB.

  • System.DirectoryServices для приложений с управляемым кодом, написанным в среде Microsoft Visual Studio .NET.  

Для получения дополнительной информации о том, как использовать эти программные интерфейсы для Active Directory, см. страницу Using Active Directory в разделе Platform SDK: Active Directory на портале MSDN.

Проверка подлинности через LDAP

Сеансы LDAP обычно начинаются с операции "привязки". Операция привязки может быть либо анонимной, либо может опционально включать учетные данные пользователя, желающего соединиться со службой каталогов. Так как этот раздел посвящен проверке подлинности пользователей, мы сосредоточимся на операции санкционированной привязки.

Имеется два типа операций санкционированной привязки: "простые" и "непростые", которые используют протокол проверки подлинности, поддерживаемый службой каталогов. Простая привязка использует учетные данные в виде открытого текста, чтобы санкционировать привязку, и по этой причине должна использоваться с осторожностью. LDAP поддерживает протокол SSL, который должен считаться обязательным для приложений, использующих простую привязку. Функцией LDAP, которая включает SSL, является ldap_set_option() с установленным флажком LDAP_OPT_SSL.

Для получения дополнительной информации о том, как использовать SSL для защиты сеансов LDAP, см. страницу Example Code for Establishing a Session over SSL в разделе Platform SDK: Lightweight Directory Access Protocol на портале MSDN.

Есть определенные случаи, когда простая связка LDAP является наилучшим вариантом. Примером этого могут служить серверные приложения, запрашивающие имя пользователя и пароль для санкционирования доступа, например, веб-приложение, использующее проверку подлинности на основе форм, где проверяется пароль пользователя в виде открытого текста. Если приложение требует, чтобы этот процесс был как можно более независим от платформы и каталогов, то простая связка LDAP является наиболее правильным подходом.

Для серверных приложений, которые должны выполнить связку с Active Directory, используя свои собственные учетные данные, чтобы извлечь определенную информацию из службы каталогов, Майкрософт рекомендует настраивать сервер так, чтобы использовать одну из опций механизма проверки подлинности, которые перечислены в документации для API ldap_bind_s().

Примечание Интерфейсы LDAP API, которые оканчиваются на 's', например, ldap_bind_s, являются синхронными. Буква 'S 'означает, что во время сеанса не обеспечивается никакой безопасности. Это может вызвать недопонимание, потому что только синхронные связки, или ldap_bind_s, поддерживает и другие механизмы проверки подлинности, помимо простой связки.

Непростые связки LDAP выполняются через механизм, известный как Simple Authentication and Security Layer (SASL). Механизмы SASL, поддерживаемые службой Active Directory, включают в себя те же самые протоколы проверки подлинности, которые уже были описаны: Kerberos V5 и NTLM (через пакет обеспечения безопасности Negotiate), а также механизм Digest Authentication. Связки LDAP, основанные на этих механизмах, используют стандартные учетные данные серверных приложений и устраняют необходимость сохранять в памяти пароль приложения в виде открытого текста. Чтобы использовать эти механизмы, приложение должно вызвать ldap_bind_s() с флажком LDAP_AUTH_NEGOTIATE или LDAP_AUTH_DIGEST.

Когда приложение использует любой из механизмов SASL, чтобы установить сеанс связи с Active Directory, оно может также указать, что все данные, которыми обмениваются между собой клиент и сервер LDAP, будут иметь цифровую подпись или будут зашифрованы. Приложение использует API ldap_set_option() либо с опцией LDAP_OPT_SIGN, либо с LDAP_OPT_ENCRYPT. Майкрософт рекомендует, чтобы все сеансы, по которым передаются чувствительные данные о каталогах или любые данные, которые будут использоваться для авторизации, должны быть защищены кодированием сеанса.

Авторизация через LDAP

Кроме проверки подлинности, приложения часто посылают запросы в службы каталогов, чтобы извлечь данные о пользователях, которые будут использоваться для авторизации. Атрибуты и данные каталогов, которые обычно используются для авторизации, включают в себя:

  • Группы безопасности.

  • Атрибуты пользователя, такие как расположение, должность, или менеджер.

  • Иерархическая информация, например, название подразделения организации или отдела.

  • Специальные атрибуты, сохраненные в каталоге, которые могут зависеть от приложения, например, «платиновый клиент».

Приложения, которые используют службы каталогов для авторизации, имеют много вариантов доступа к информации каталога, и иногда разработчики делают не лучший выбор при создании приложения. Общая проблема состоит в том, что приложения не в состоянии кэшировать результаты запроса, и в результате одно единственное приложение может значительно загрузить каталог. Разработчики должны обращать специальное внимание на кэширование результатов запроса каталога, если есть вероятность, что эта информация сможет потребоваться снова.

Примечание   Одним из самых больших преимуществ интеграции приложений со службами безопасности Windows является то, что механизмы проверки подлинности Windows извлекают и кэшируют данные авторизации, например, группы безопасности, во время процесса проверки подлинности. Диспетчер авторизации Windows также кэширует и другие данные авторизации, связанные с ролью пользователя, когда впервые создается контекст авторизации. После кэширования данные авторизации будут доступны локально в течение сеанса санкционированного доступа. Встроенные механизмы кэширования значительно упрощают разработку эффективных приложений.

Другая общая проблема состоит в том, что разработчики, возможно, не понимают, как осуществить эффективный поиск. Плохо организованный поиск, при частом повторении, может занять ресурсы и снизить производительность и доступность службы каталога. Для получения дополнительной информации, см. страницу Creating More Efficient Microsoft Active Directory-Enabled Applications на MSDN.

Интеграция со службами каталогов Windows, используя ADAM

Протокол Active Directory-Application Mode (ADAM) обеспечивает дополнительную возможность интеграции со службами каталогов Windows. ADAM является автономной версией службы Active Directory, которая выполняется как пользовательская служба на компьютерах с Windows XP или Windows Server 2003.

Чтобы удовлетворить требованиям по уменьшению числа хранилищ идентификаторов в системе, Майкрософт обычно рекомендует использовать службу Active Directory, когда это возможно. Некоторые из преимуществ Active Directory перед ADAM включают в себя:

  • Более богатые функции проверки подлинности, включая интеграцию с протоколом Kerberos V5 (включая более строгую реализацию протокола Kerberos для серверов с n слоями), Инфраструктура открытого ключа (PKI), и служба Microsoft Passport.

  • Одно место хранения для всех учетных записей упрощает управление идентификаторами.

  • Обеспечение связи со многими приложениями Майкрософт, например Microsoft SharePoint™ Portal Server и Microsoft Exchange Server, которые требуют, чтобы пользователи имели учетную запись в Active Directory.

Однако, есть несколько веских причин для выбора режима ADAM, включая следующие соображения:

  • Миграция приложений. Перенос на новую систему уже существующих приложений, которые используют систему наименований объектов X.500.

  • Настройки и управление. ADAM более прост для разработчиков в смысле настройки и управления.

  • Безопасность и изоляция идентификаторов. Пользователи, санкционированные в режиме ADAM, не смогут получить доступ к рабочей станции, серверу, или другому сетевому ресурсу, который не является тем самым приложением, которое использует ADAM.

  • Данные персонализации и производительность. ADAM подходит для данных персонализации низкого уровня, которые не представляют глобального интереса. Данные и атрибуты, которые часто изменяются, могут также неблагоприятно повлиять на производительность службы Active Directory.

Для получения дополнительной информации об ADAM, см. страницу Windows Server 2003 Active Directory Application Mode.

Миграция приложений.

Одним из случаев, когда проверка подлинности по протоколу LDAP к Active Directory особенно полезна, является миграция приложений из другой службы каталогов, которая поддерживает контекст наименований объектов X.500 Поскольку Active Directory не поддерживает наименования X.500, ADAM может быть очень полезным для миграции приложений без написания кода на формат службы каталогов Майкрософт.

ADAM имеет функцию под названием LDAP Bind Redirection (иногда называется Bind Proxy), которая очень полезна в данном сценарии. Bind Redirection позволяет "теневой" учетной записи ADAM для пользователя, сохраненного в Active Directory, содержать любые атрибуты пользователя, которые нужны приложению, но при этом эта учетная запись не содержит пароль пользователя. Приложение будет пытаться проверить подлинность пользователя по ADAM через связку LDAP, но ADAM направит запрос на опознавание службе Active Directory. Active Directory затем проверяет подлинность пользователя и передает результат назад в ADAM. Эта функция позволяет перемещать один важный аспект пользователя, данные учетной записи, в централизованное хранилище идентификаторов в Active Directory, при этом оставляя связанные с приложением данные каталога в ADAM.

Настройка и управление.

При разработке приложений с поддержкой служб каталогов, программистам, возможно, потребуется изменить схему каталога. Разработчики вряд ли будут членами группы Active Directory Schema Admins, и поэтому не могут изменить саму схему. ADAM может быть полезным для разработчика как средство моделирования нужных модификаций схемы, без необходимости вносить изменения в схему Active Directory организации.

Безопасность и изоляция идентификаторов.

Также ADAM может быть выбран как хранилище идентификаторов для определенных типов пользователей из соображений безопасности. Для приложений внешней сети, которые предоставляют услуги клиентам, служащим и партнерам, организация может потребовать, чтобы учетные записи, предоставленные клиентам, не использовались для доступа к любым другим приложениям или ресурсам во внешней сети. Если бы учетные записи создавались в Active Directory, то это требование могло бы быть трудно выполнимым, потому что учетные записи в Active Directory обычно могут использоваться для соединения со службами и ресурсами во внешнем домене. Учетными записями клиента можно очень эффективно управлять через объекты групповой политики (GPO) и другие настройки политик, но некоторые организации пожелают иметь явное разделение учетных записей. Организации с этим требованием могут выбрать ADAM в качестве хранилища идентификаторов для клиента.

Данные персонализации и производительность.

В определенных сценариях организация может быть озабочена тем, что миграция приложения на Active Directory будет иметь неблагоприятное воздействие на центральную службу каталогов организации. Это может произойти из-за потребности хранить большое количество связанных с приложением данных "персонализации", которые не относятся к любому другому приложению, из-за того, что данные, связанные с приложение, очень часто изменяются, или даже потому, что приложение использует службы каталогов неэффективным образом. В этих случаях может быть уместным использовать ADAM для связанных с приложением данных каталога.

К началу страницы

Непрямая интеграция путем сопоставления учетных данных.

Когда прямая интеграция платформ и приложений со службами безопасности и каталогов Windows невозможна, служба однократной идентификации уровня предприятия (ESSO) может реализовать косвенную интеграцию между Active Directory и другими хранилищами идентификаторов, а также обеспечить проверку подлинности и однократную идентификацию через службы сопоставления учетных данных.

Многие межплатформные приложения для порталов и бизнеса извлекает данные из внутренних серверных баз данных от имени пользователей прикладных программ. Внутренние системы обычно реализуют собственные средства безопасности и имеют собственные хранилища идентификаторов. Обычно механизмы безопасности на внутренних системах не являются полностью интегрированными со службами безопасности Windows, и таким образом, невозможно делегировать проверку подлинности из межплатформного серверного приложения портала на внутреннюю систему.

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

Чтобы представить на примере, как работает сопоставление учетных данных, давайте предположим, что есть типичное серверное приложение среднего слоя, которое извлекает данные из внутренней системы. Внутренняя система не интегрирована со службами безопасности Windows или все еще поддерживает собственное хранилище идентификаторов. Чтобы обратиться к внутренней системе, не запрашивая при этом учетных данных у пользователя, серверное приложение запрашивает определенные учетные данные для внутренней системы у службы ESSO. В этом примере учетные данные локального пользователя, Мэри, ставятся в соответствие пользователю по имени M2231 на внутренней системе. В результате Мэри предоставляется доступ к определенному ресурсу, как показано на Рис. 2.5.

Может иметь место вариант прямого сопоставления, когда учетные данные используются для сопоставления типа "многие к одному". В этом случае многие пользователи сопоставляются с единственными учетными данными, которые распознаются внутренним ресурсом. На Рис. 2.5 Боб отображен на общего пользователя приложения на внутренней системе.

Рисунок 2.5. Пример сопоставления учетных данных

Преимущества и недостатки сопоставления учетных данных

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

  • Гетерогенные модели безопасности. Ваши приложения работают на операционной системе Windows, в качестве серверного приложения работает IIS 6.0, а внутренние системы используют как SQL Server 2000 или выше, так и Exchange 5.5 или выше. Протокол Kerberos V5 работает прекрасно, пока вы не решаете применить третью внутреннюю систему, например DB2 на ОС/390. В этом случае, вы должны отобразить учетные данные Windows на учетные данные Resource Access Control Facility (RACF), чтобы получить доступ к внутреннему ресурсу.

  • Отложенное использование учетных данных. Иногда вам нужно задержать использование учетных данных для проверки подлинности до того, как они асинхронно пройдут через очереди сообщений, брокеры сервисов или механизмы интеграции.

Однако вы должны сравнить эти преимущества со следующими недостатками.

  • Риск хранения имен пользователя и паролей. Чтобы такие системы сопоставления учетных данных работали, вам нужна база данных, которая будет содержать имена пользователя и пароли, которые могут быть расшифрованы перед использованием. Такие базы данных можно защитить разными способами, но хранение паролей, даже зашифрованных, представляет собой риск. Например, если используются настройки по умолчанию, Active Directory никогда не хранит фактический пароль. Этот риск должен быть оценен и учтен.

  • Синхронизация паролей. База данных, где хранятся сопоставленные учетные данные, означает, что некоторые учетные данные должны либо должны поддерживаться в двух местах, либо синхронизироваться через некий автоматизированный процесс. Этот фактор может привести к увеличению сложности архитектуры вашей системы или к увеличению накладных расходов. См. статью «Управление паролями» в данной серии для получения дополнительной информации.

Модель сопоставления учетных данных в продуктах Майкрософт

Продукты интеграции бизнеса от Майкрософт включают в себя службу ESSO, которая обеспечивает хранение и сопоставление учетных данных, с тем чтобы приложения могли извлечь информацию из систем планирования ресурсов предприятия (ERP), систем управления отношениями с клиентами (CRM) и приложений для мэйнфрейма.

Все эти приложения используют защищенную базу данных, чтобы хранить как учетные данные пользователей, так и данные об отображении учетных записей, которые связывают учетные записи Active Directory с учетными записями, используемыми для внутренних серверных приложений предприятия. Служба ESSO также реализует защищенный механизм выпуска и обмена билетами, который используется всякий раз, когда приложение интеграции бизнеса должно извлечь данные из внутреннего приложения. Так как пользователь обращается к различным приложениям, используя только свои учетные данные, сохраненные в Active Directory, пользователям обеспечивается однократная идентификация.

Приложения, которые используют служба Microsoft ESSO, включают в себя:

  • SharePoint Portal Server (SPS 2003)

  • Microsoft BizTalk® Server 2004

  • Host Integration Server 2004

Использование SharePoint Portal Server ESSO

SharePoint Portal Server (SPS 2003) дает возможность организациям разработать интеллектуальный портал, который соединяет пользователей, команды и знание, что позволяет людям использовать полученную информацию в своих бизнес-процессах и работать более эффективно.

SPS 2003 обеспечивает бизнес-решение для предприятия, которое объединяет информацию из различных систем в единое сетевое решение в виде портала. Это решение использует однократную идентификацию и возможности интеграции приложений предприятия, наряду с гибкими вариантами развертывания приложений и средствами управления. SPS 2003 также помогает защитить приложения предприятия, храня и отображая назначенные им учетные данные, что позволяет клиентам взаимодействовать с приложениями предприятия непосредственно из портала, используя только свои учетные данные, сохраненные в Active Directory.

Использование BizTalk Server ESSO

BizTalk Server 2004 соединяет системы, людей и торговых партнеров через управляемые бизнес-процессы. Он обеспечивает интеграцию между продуктами ERP, позволяя организациям объединить свои деловые операции и свести вместе поставщиков и потребителей. Также он предоставляет ряд механизмов взаимодействия, особенно веб-сервисы, работающие с языком Extensible Markup Language (XML).

BizTalk Server использует базу данных сопоставления учетных данных ESSO, похожую с SPS 2003. В этом случае BizTalk 2004 может обеспечить детали проверки подлинности для любого подключения, определенного инструментальным механизмом BizTalk Server.

Сценарий однократной идентификации пакета BizTalk Server 2004 похож на сценарий SPS, хотя он, возможно, может и не работать с порталом. Пользователь вводит свои учетные данные в операционную систему Windows, а BizTalk Server 2004 после этого связывает эти данные со своей внутренней базой данных, где хранятся учетные данные. Когда пользователю нужно обратиться к информации, которой владеет его деловой партнер, например, об к информации об уровне запасов, BizTalk Server 2004 извлекает сохраненные учетные данные и представляет их внешней системе.

Что касается интеграции SPS 2003 с BizTalk Server и однократной идентификации, рекомендованный подход состоит в том, чтобы использовать версию однократной идентификации от BizTalk Server, а не от SPS. Это означает, что сетевые части SPS вызывают адаптер веб-служб в BizTalk Server, и что эти сетевые части должны обеспечить то, что когда адаптер веб-службы BizTalk получает запрос, этот запрос будет совпадать с контекстом конечного пользователя, которые его инициировал. Поэтому адаптер веб-службы должен постоянно находиться на одном и том же компьютере, как сетевая часть, или же, можно установить принудительное перенаправление в сценариях с удаленными компьютерами. Адаптер веб-службы использует запрос IssueTicket с Enterprise SSO, а внутренний адаптер использует запрос ValidateAndRedeemTicket.

Использование Host Integration Server для ESSO

В программной среде клиентов, мэйнфрейм и другие системы на основе главного компьютера почти никогда не взаимодействуют с учетными данными пользователя, сохраненными в Active Directory. Хотя многие организации имеют долгосрочные планы интеграции систем на основе главного компьютера со службой Active Directory, используя стандартные протоколы, такие как протокол Kerberos V5, реализация этих планов требует времени. Как более скорое решение, Host Integration Server 2004 предоставляет возможности управления учетными данными, что обеспечивает пользователям однократную идентификацию.

Host Integration Server 2004 обеспечивает следующую версию базы данных для сопоставленных учетных данных ESSO, по сравнению с BizTalk Server 2004. Эта база данных обеспечивает однократную идентификацию в Host Integration Server, используя эмуляторы 3270 и 5250, и разрешает уже вошедшим в систему пользователям Windows автоматически входить на мэйнфрейм или систему AS/400 без необходимости повторно вводить свои учетные данные. Кроме того, функции интеграции приложений и данных в Host Integration Server позволяют уже вошедшим в систему пользователям Windows обращаться к подсистемам Customer Information Control System (CICS) и Information Management System (IMS) или к DB2, также не требуя от пользователей повторного ввода своих учетных данных.

Сценарий, использующий Host Integration Server, может включать в себя брокера в коммерческом банке. Брокер входит в операционную систему Windows и запускает приложение для торговли, основанное на платформе Microsoft .NET Framework. Чтобы осуществлять торговлю, он должен получить текущий торговый баланс своего клиента, который хранится на мэйнфрейме банка. Host Integration Server 2004 посылает данные учетной записи пользователя на мэйнфрейм, используя его базу данных, где хранятся сопоставленные учетные данные, что дает возможность брокеру выполнить запрос по своему клиенту.

Продукты ESSO, предоставленные независимыми разработчиками

Сфера однократной идентификации на уровне предприятия (ESSO) представляет собой еще одну область технологии, которая испытала бурный рост рынка для независимых разработчиков ПО. В отличие от технологии ESSO корпорации Майкрософт, эти продукты независимых разработчиков обычно обеспечивают централизованный механизм хранения, основанный на службе Active Directory для учетных данных и их сопоставлений, и также обеспечивают набор API-интерфейсов, который приложения могут использовать для реализации функций ESSO. Ниже перечислены разработчики продуктов ESSO (в алфавитном порядке)

К началу страницы

Синхронизированные учетные записи и пароли.

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

Синхронизация учетных записей и паролей является резервной методикой, позволяющей сократить количество регистраций, или может использоваться тогда, когда все другие методы не подходят, являются слишком трудными или слишком дорогими для реализации на практике. Этот подход не обеспечивает истинной однократной идентификации, но он позволяет уменьшить количество имен и паролей, которые пользователи должны помнить

Синхронизация паролей обычно подразумевает, что несколько хранилищ идентификаторов включают в себя идентичные учетные записи и пароли пользователей. Каждый пользователь регистрируется в компьютере-клиенте, других платформах, приложениях и веб-сайтах интрасети, используя одну и ту же комбинацию имени пользователя и пароля.

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

Статья «Identity Aggregation and Synchronization» в этой серии содержит дополнительную информацию о том, как синхронизировать цифровые удостоверения в нескольких хранилищах идентификаторов.

Статья «Управление паролями» в этой серии более подробно рассматривает подходы и проблемы, связанные с синхронизацией паролей при управлении доступом в интрасеть, а также демонстрирует, как осуществить распространение пароля от одного леса Active Directory на другие леса Active Directory, хранилища идентификаторов приложений и службы каталогов других платформ.

Загрузить

Скачайте комплект документации Майкрософт по управлению идентификаторами и доступом

Уведомления об изменениях

Подпишитесь на рассылку уведомлений о выпуске изменений и новых редакций этого документа

Обратная связь

Пришлите нам свои комментарии или предложения

К началу страницы