Знакомство с проверкой подлинности прокси в службах облегченного доступа к каталогам Active Directory (AD LDS)

Как и любая служба каталогов с поддержкой LDAP, службы Microsoft Active Directory облегченного доступа к каталогам Lightweight Directory Services (AD LDS – ранее они назывались ADAM) требуют от пользователя привязки перед исполнением любых операций LDAP в каталоге. Эту привязку можно осуществить несколькими различными методами, включая простую привязку LDAP, привязку уровня простой проверки подлинности и безопасности (SASL) или даже перенаправление привязки. Привязка также может быть анонимной, в этом случае пользователь представляет пустой пароль. В этой статье я намерен обсудить и проанализировать один определенный метод — перенаправление привязки, также известное как проверка подлинности прокси.

Что такое проверка подлинности прокси

Проверка подлинности прокси позволяет пользователю выполнить простую привязку к экземпляру AD LDS, в то же время поддерживая связь с учетной записью Active Directory. В транзакцию вовлечены две учетных записи. Первая — это специальный объект в AD LDS, именуемый объектом userProxy. Вторая — это учетная запись пользователя в Active Directory.

Объект userProxy AD LDS является представлением учетной записи Active Directory. Объект прокси привязан к учетной записи Active Directory через идентификатор безопасности (SID) этой учетной записи. На самом объекте прокси пароли не хранятся.

Когда пользователь выполняет простую привязку к экземпляру LDS с помощью объекта прокси, привязка перенаправляется к Active Directory путем передачи идентификатора SID и пароля контроллеру домена. Сервер AD LDS выполняет проверку подлинности, и весь этот процесс невидим для конечного пользователя. Это проиллюстрировано на рис. 1, где Люси подключается к экземпляру AD LDS, именуемому "CN=AppDir,DC=contoso,DC=com", с помощью своей учетной записи пользователя AD LDS.

Рис. 1. Подключение к AD LDS

В целях проверки подлинности Люси использует простую привязку, предоставляя свое различенное имя (DN) и пароль, как если бы это была обычная привязка LDAP. Хотя и кажется, будто Люси подключается с помощью своей обычной учетной записи пользователя LDS, на деле она использует объект прокси. Проверка подлинности Active Directory происходит автоматически, и Люси даже не знает, что на деле она использует для привязки свою учетную запись Active Directory.

Достоинства проверки подлинности прокси

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

Опасность использования существующего неиспользованного атрибута заключается в том, что атрибут, вероятно, находится там с другой целью. Даже если он не используется сейчас, это может произойти в будущем; если он используется для какой-либо иной цели, администраторам Active Directory необходимо следить за тем, как это происходит. И что если разработчику приложения нужно более одного атрибута?

В случае проверки подлинности прокси в каталоге AD LDS существует представление объекта пользователя Active Directory. Относящийся к конкретному приложению каталог позволяет разработчику приложения модифицировать схему любым нужным образом в контексте AD LDS. Атрибуты могут быть добавлены или изменены. Они также могут получить новые назначения по выбору разработчика, и администратору Active Directory не нужно беспокоиться о внесении нескольких изменений в схему или отслеживании того, как используются атрибуты. Если другое приложение подключается и ему нужно использовать тот же атрибут, это не проблема, поскольку оно может быть отдельным экземпляром AD LDS и не вызывать конфликтов атрибутов.

Проверка подлинности прокси также может быть полезна в случаях, требующих формата X.500. В Active Directory не используется обычная номенклатура X.500 для различенных имен. Например, объект пользователя в Active Directory имеет различенное имя (DN) "CN=Lucy D. Smith,CN=Users,DC=contoso,DC=com". Но в AD LDS различенное имя пользователя может быть "CN=Lucy D. Smith,CN=Users,O=Contoso,C=US", что совместимо с X.500.

Это полезно при использовании клиента LDAP от сторонних производителей или попытках интеграции с каталогом от сторонних производителей, требующим формата X.500. Тогда LDS может быть промежуточным каталогом между каталогом от стороннего производителя и Active Directory. При использовании проверки подлинности прокси учетная запись службы, которую каталогу от стороннего производителя необходимо использовать для привязки к экземпляру LDS, может храниться в Active Directory, а не в LDS.

Внутри объекта прокси

Пока что я дал краткий обзор того, как объект прокси LDS привязан к учетной записи пользователя Active Directory. Теперь я рассмотрю это подробнее и исследую, что именно происходит за кулисами процесса, начиная с класса объекта.

В Windows Server 2008 каталог %SYSTEMROOT%\ADAM содержит два файла LDF, представляющих объект прокси:

• MS-UserProxy.LDF и
• MS-UserProxyFull.LDF

MS-UserProxy.LDF содержит определение простого класса userProxy, имеющего базовые атрибуты и содержащего вспомогательный класс msDS-BindProxy. MS-UserProxyFull.LDF содержит и вспомогательный класс msDS-BindProxy, но он также заранее вводит дополнительные атрибуты пользователя в атрибут класса mayContain. В силу этого классам атрибутов необходимо существовать заранее. Так что при импорте класса userProxyFull необходимо сначала импортировать пользователя либо класс inetOrgPerson. Как пользователь, так и inetOrgPerson содержат определения класса атрибута для атрибутов, используемых userProxyFull. На рис. 2 показаны различия между классом userProxy и классом userProxyFull.

Рис. 2. Классы userProxy и userProxyFull

Важен тот факт, что оба класса содержат msDS-BindProxy как вспомогательный класс. Вспомогательный класс – это тип класса, предоставляющий дополнительные данные структурному классу. В LDS, к примеру, класс User («Пользователь») – это структурный класс, порожденный от класса Organizational-Person, а это значит, что класс User имеет все, что имел класс Organizational-Person. Но у класса User также есть вспомогательный класс, именуемый msDS-BindableObject, а это значит, что User содержит все обязательные и необязательные атрибуты msDS-BindableObject в дополнение к атрибутам класса Organizational-Person. В данном случае использование msDS-BindableObject в качестве вспомогательного класса делает класс User привязываемым.

Поскольку у класса userProxy есть msDS-BindProxy в качестве вспомогательного класса (см. рис. 3), теперь он также содержит весь набор обязательных и необязательных атрибутов msDS-BindProxy. Объект в объект прокси превращает именно вспомогательный класс msDS-BindProxy, поэтому даже в случае пользовательского класса можно добавить вспомогательный класс msDS-BindProxy и использовать пользовательские объекты для проверки подлинности прокси.

Рис. 3. Создание объекта прокси

Если изучить класс msDS-BindProxy, то можно заметить, что определен лишь один обязательный атрибут – objectSID. Это атрибут, в который будет помещен SID учетной записи пользователя Active Directory для создания связи между прокси-объектом в LDS и объектом пользователя в Active Directory. Этот атрибут может быть заполнен лишь при создании объекта. Его нельзя изменить без удаления объекта и воссоздания его.

Как в действительности выполняется проверка подлинности

Чтобы по-настоящему понять, что происходит за кулисами, необходимо немного более подробно рассмотреть механизм проверки подлинности. Я разберу две трассировки сети, которые помогут показать, как работает проверка подлинности прокси. Первая трассировка – это сетевая запись простой привязки пользователя прокси от рабочей станции Windows XP к экземпляру LDS на Windows Server 2008. В данной записи Люси выполняет привязку с помощью своего объекта пользователя прокси, используя LDP.EXE со своей рабочей станции.

На рис. 4 показаны три пакета в записи, которую нам нужно рассмотреть. Пакет 1 – это запрос на привязку от рабочей станции (10.0.0.107) к серверу LDS Active Directory (10.0.0.201). Запрос на привязку содержит различенное имя Люси, "cn=lucy,cn=people,cn=appdir,dc=contoso,dc=com". Пакет 2 — это ответ рабочей станции от сервера LDS Active Directory, указывающий успешную привязку. А пакет 3 — это подтверждение от рабочей станции серверу LDS Active Directory, указывающее принятие запроса на привязку.

Рис. 4. Запрос на привязку и ответ

Если подробнее рассмотреть пакет 1 (см. рис. 5), можно заметить нечто шокирующее. Пароль, предоставленный Люси, (P@ssw0rd), отображен в записи открытым текстом. В реальности это один из недостатков использования простой привязки LDAP для проверки подлинности. Если привязка не обернута в шифрование SSL, пароль пользователя будет выдан всем, кто прослушивает сеть.

Рис. 5. Простая привязка с отключенным SSL

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

Вторая трассировка – это запись сети от сервера LDS Active Directory к контроллеру домена. Эта трассировка несколько больше предыдущей, так что я разобью ее на части. Первые девять пакетов этой трассировки показаны на рис. 6.

Рис. 6. Подключение AD LDS к контроллеру домена

Первый пакет должен быть знаком читателям. Это входящий запрос на привязку от рабочей станции. Опять же, этот пакет содержит различенное имя и пароль Люси открытым текстом. Пакеты со второго по девятый показывают сервер AD LDS (10.0.0.201), подключающийся к контроллеру домена (10.0.0.200). Это состоит из нескольких сообщений протокола разрешения адресов (ARP), за которыми следует подключение к контроллеру домена через удаленный вызов процедуры (RPC).

На рис. 7, пакеты 10 и 11 вызывают метод, именуемый LsarLookupSids3, вызов RPC, указывающий контроллеру домена взять пакет идентификаторов SID и возвратить соответствующие им имена. Сервер LDS AD выполняет запрос в пакете 10 и получает ответ от контроллера домена в пакете 11.

Рис. 7. Попытка проверки подлинности Kerberos

Затем, после краткого подтверждения TCP для запуска сеанса Kerberos (пакеты 12–14), в пакете 15 сервер AD LDS пытается получить билет службы проверки подлинности (AS-REQ) от центра распространения ключей (KDC). В пакете 16 запрос билета службы проверки подлинности получает отказ, поскольку контроллер домена ожидает некоторые предпроверочные данные, которые сервер LDS AD не предоставил. В данном случае контроллер домена требует метку времени, чтобы ее можно было использовать для проверки удостоверения. Сеанс Kerberos заканчивается, и дается запрос на сброс (пакеты 17–19).

На рис. 8 показана остальная часть записи. Пакеты 20-22 устанавливают новый сеанс Kerberos, и новый запрос службы проверки подлинности отправляется от сервера LDS AD на контроллер домена в пакете 23. Этот новый запрос содержит необходимые предпроверочные данные, указанные успешным ответом от контроллера домена в пакете 25. У сервера LDS AD теперь есть билет службы проверки подлинности, и он может отправлять запросы службе выдачи билетов, чтобы проверить подлинность учетных данных Люси.

Рис. 8. Успешная проверка подлинности

Запрос и ответ службы выдачи билетов фиксируются в пакетах 33 и 34. Получение KRB_TGS_REP в пакете 34 указывает успешную проверку подлинности Люси. Наконец, в пакете 38 сервер AD LDS передает ответ привязки обратно рабочей станции, давая Люси знать, что она успешно провела привязку к экземпляру AD LDS. Хотя этот процесс включает несколько этапов, общее время всей транзакции составляет лишь примерно 1/10 секунды.

А что бы произошло, введи Люси неверный пароль? В нашем примере запрос службы проверки подлинности потерпел бы сбой в пакете 25. Неудача запроса службы проверки подлинности сообщила бы серверу LDS AD, что учетные данные Люси были недопустимы. Вместо направления запроса службе выдачи билетов серверу LDS AD пришлось бы выдать запрос привязки обратно к рабочей станции, указывая, что учетные данные были неверны.

Вот воспроизведение того, что произошло в успешном обмене.

1. Рабочая станция отправляет запрос на привязку серверу LDS AD.
2. Сервер LDS AD устанавливает связь с контроллером домена.
3. Сервер LDS AD просит контроллер домена перевести SID Люси в идентификатор, который можно использовать для проверки подлинности.
4. Контроллер домена выдает серверу LDS AD идентификатор Люси.
5. Сервер LDS AD получает билет предоставления билета (ticket granting ticket – TGT) с идентификатором Люси от контроллера домена.
6. Сервер LDS AD получает билет сеанса для себя, используя TGT Люси.
7. Сервер LDS AD отправляет ответ успешной привязки обратно рабочей станции.

Этот процесс показывает, что подключение рабочей станции к серверу LDS AD – стандартная транзакция привязки LDAP. Затем, от сервера LDS AD к контроллеру домена, Kerberos используется для безопасной проверки подлинности пользователя.

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

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

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

• Установить LDS AD на сервере-члене домена.
• Отключить требование SSL для проверки подлинности прокси.
• Импортировать класс userProxy в схему LDS AD .
• Создать объект прокси и назначить права для него.
• Провести привязку к каталогу LDS AD с помощью объекта прокси.

Сначала нужно установить LDS AD на сервере Windows Server 2008, входящем в домен. В диспетчере серверов пункт установки LDS можно найти в мастере добавления ролей. После установки роли в меню средств администрирования появится новый пункт, именуемый «Мастер установки служб Active Directory облегченного доступа к каталогам». Используйте этот мастер для создания нового экземпляра LDS.

При запросе имени раздела приложения введите любое различенное имя на выбор. Помните, что LDS поддерживает имена X.500, так что использовать имя в стиле "DC=" не обязательно. В примерах я использовал "cn=appdir,dc=contoso,dc=com", но мог бы использовать "cn=appdir,o=contoso,c=us".

После установки экземпляра AD LDS, следующим этапом является отключение требования SSL для проверки подлинности прокси. В оснастке ADSI Edit (adsiedit.msc) следует подключиться к разделу настройки экземпляра LDS AD, указывая учетную запись администратора, указанную в ходе установки. Если различенное имя раздела настройки неизвестно, то можно выбрать "Configuration" («Настройка») из раскрывающегося списка "Select a well known naming context" («Выберите хорошо известный контекст именования») в диалоге параметров подключения ADSI Edit.

Перейдите к контейнеру "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={guid}" и откройте диалог свойств контейнера "CN=Directory Service". В списке атрибутов имеется строковый атрибут с множественными значениями, именуемый msDS-Other-Settings, в котором перечисляются несколько строк, каждая из которых указывает свой параметр для экземпляра LDS AD. Откройте этот атрибут и измените строковое значение "RequireSecureProxyBind" на 0.

Следующим этапом является импорт определения класса схемы для класса userProxy. Возможно, он был уже импортирован, когда мастер AD LDS запросил об этом. Если это так, то данный этап можно пропустить. Если он еще не импортирован, сделайте это с помощью следующей команды LDIFDE.EXE. Убедитесь в том, что в команде указывается имя сервера LDS AD и верный порт:

C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext

Теперь, когда класс объекта импортирован, можно создать объект прокси. Я использую LDP.EXE, но для этого также подойдет другое средство или какой-либо программный метод. Используя LDP, подключитесь к экземпляру LDS AD и проведите привязку с помощью своих учетных данных администратора. Перейдите к различенному имени экземпляра LDS AD и выберите контейнер, в котором следует создать объект прокси. Щелкните контейнер правой кнопкой мыши и выберите Add Child («Добавить дочерний») из раскрывающегося списка. В диалоге Add («Добавить») будет необходимо ввести различенное имя нового объекта прокси в поле DN. Например, можно использовать "cn=lucy,cn=appdir,o=contoso,c=us".

Кроме того, будет необходимо создать два атрибута с этим объектом. Первый – это objectClass, указывающий род создаваемого объекта. Значением для данного примера должно быть userProxy. Поместите эту информацию в раздел диалога Edit Entry («Редактировать запись») и нажмите клавишу ВВОД.

Второй атрибут для добавления – это objectSID, содержащий SID учетной записи пользователя Active Directory, с которой связан данный объект прокси. Получить этот SID можно различными методами, но я просто подключился к Active Directory в отдельном экземпляре LDP и скопировал атрибут objectSID из учетной записи пользователя там. После ввода этой информации диалог Add должен быть подобен показанному на рис. 9. Наконец, нажмите кнопку Run («Выполнить»), чтобы внести изменения.

Рис. 9. Создание объекта прокси

Чтобы использовать только что созданный объект прокси, необходимо дать ему некоторые права. Это можно выполнить без труда, выбрав объект "CN=Readers" из контейнера "CN=Roles" в LDP. Щелкните правой кнопкой мыши и выберите Modify («Изменить») из раскрывающегося списка. Добавьте атрибут, именуемый вызываемым членом, а в качестве его значения введите различенное имя созданного объекта userProxy. Не забудьте нажать клавишу ВВОД перед щелчком Run. Теперь объект userProxy должен быть членом группы Readers («Читатели») в экземпляре LDS.

Все должно быть готово, так что теперь можно приступить к проверке подлинности прокси. Откройте новый экземпляр LDP и подключитесь к серверу LDS AD. Но на этот раз при привязке к экземпляру выберите Simple Bind («Простая привязка») и введите различенное имя объекта прокси в поле имени пользователя. В поле, предназначенное для пароля, введите пароль учетной записи Active Directory, к которой привязан данный объект прокси. Нажмите кнопку «ОК» – теперь должна быть привязка к экземпляру в режиме «только для чтения».

Уделите немного времени снятию трассировок сети и опробованию различных методов привязки. Одно из упражнений может заключаться во включении SSL обратно и снятия записи процесса привязки LDAP. Можно даже намеренно ввести имя пользователя или его пароль неверно и увидеть, что произойдет в процессе проверки подлинности.

Заключение

Не стоит опасаться сложности проверки подлинности прокси.. Я выбрал демонстрацию этого процесса с помощью LDP и ADSI Edit потому, что это позволяет лучше разглядеть его внутренний механизм. По этой причине разобранный мною пример иллюстрирует проверку подлинности прокси с весьма практической точки зрения.

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