Получить активные объекты контейнера каталога для нового пользователя
Я хочу создать дерево контейнерных объектов в домене активного каталога, к которому можно добавить нового пользователя. Я могу пройти через домен и получить все в каталоге, но я хочу ограничить свою область ТОЛЬКО контейнерами, которые действительны для пользователей.
Как будет выглядеть запрос LDAP для захвата дочерних элементов node, подходящих для пользовательского объекта? Есть ли лучший способ сделать это?
Я использую С#, System.DirectoryServices и .net 3.5, если вам интересно.
Ознакомьтесь с отличной статьей MSDN «Управление принципами безопасности каталогов» в .NET Framework 3.5 о том, как использовать новые функции в System.DirectoryServices.AccountManagement в .NET 3.5, если вы еще этого не сделали.
Чтобы привязываться к вашему контейнеру, вам нужно знать его путь LDAP, и с этим вы можете установить контекст, основанный на этом контейнере:
В этом контексте вы можете теперь, например, поиск определенных типов участников в этом контексте:
Это работает для вас? Это то, что вы ищете?
Если я правильно понял ваш вопрос, то что вы хотите знать, какие объекты в Active Directory могут содержать объект User.
Я думаю, вы можете получить ответ из раздела схемы AD. Я быстро проверил свой раздел схемы, который работает под управлением Windows 2003 AD. Объекту User разрешено назначать OU, контейнеру, builtinDomain и domainDNS.
Я не проверял Windows 2008, но считаю, что он должен быть таким же. Многие люди знают, что такое OU и контейнер. Мало кто знает, что такое builtinDomain и domainDNS. Я сомневаюсь, что это полезно в вашем случае. builtinDomain — специальный контейнер, используемый для хранения встроенной учетной записи. По умолчанию AD создал встроенный домен в CN=Builtin,DC=yourdomain,DC=com . domainDNS — это путь вашего корневого домена DC=yourdomain,DC=com .
Вот функция поиска всех объектов в Active Directory под определенным node. Если вы считаете, что builtinDomain и domainDNS не имеют смысла в вашем случае, просто выньте его из фильтра LDAP.
Как скрыть контейнеры в Active Directory
Сразу после установки нового домена Active Directory в корне консоли Active Directory User and Computers (ADUC) появляется несколько предопределенных служебных контейнеров (OU). Большинство из них редко используются при повседневном администрировании Active Directory, однако занимают место в консоли, и «мозолят» глаза администратору AD. В этой статье мы разберемся, как можно скрыть ненужные контейнеры AD в консоли AD Users and Computers.
Напомним, по-умолчанию, в консоли ADUC отображаются следующие контейнеры:
На самом деле объектов верхнего уровня намного больше, чтобы отобразить все, в том числе скрытые объекты AD с расширенными атрибутами, в консоли ADUC нужно в меню View отметить опцию “Advanced Features”.
Microsoft таким образом просто «скрыла» достаточно редко используемые стандартные элементы каталога AD, ежедневный доступ к которым не требуется (если вообще нужен). Каким образом любой OU в AD сделать скрытым, чтобы он не отображался в обычном режиме работы консоли ADUC?
Для этого нужно изменить атрибут, управляющий видимостью любого контейнера в AD под названием showInAdvancedViewOnly. Данный атрибут впервые появился еще в версии AD Windows 2000 Server. Для его правки в Windows 2000/Windows 2003 нужно было устанавливать специальную консоль ADSIEDIT (входящую в состав утилит администратора Windows — Support Tools). В Windows 2008 /2008 R2 Microsoft сделала функционал этого инструмента частично доступным прямо в консоли AD Users and Computers (в расширенном режиме работы при включенной Advanced Features), для этого достаточно в окне свойств объекта выбрать вкладку Attribute Editor.
Например, у контейнера ForeignSecurityPrincipals значение showInAdvancedViewOnly=False. Это означает, что данный контейнер не является скрытым.
Поменяем значение параметра showInAdvancedViewOnly на true, в результате данный контейнер перестанет отображаться в консоли ADUC.
Какие же из стандартных контейнеров в AD можно скрыть?
Builtin: можно скрыть. В этом контейнере содержатся стандартные (встроенные) группы AD: Account Operators, Backup Operators, Event Log Readers, Guests, Server Operators и т.д. Состав этих групп меняется редко.
ForeignSecurityPrincipals: — также стоит скрыть. Контейнер используется для хранения идентификаторов безопасности (SID), связанных с внешними доверенными доменами. Используется крайне редко
Users: можно скрыть. Несмотря на свое название, данный контейнер не рекомендуется использовать для создания и хранения пользовательских учетных записей. В OU Users хранятся такие важные доменные группы, как Domain Admins, Enterprise Admins, Schema Admins и т.д.
Managed Service Accounts: контейнер появился в Windows 2008 R2 и используется для управления сервисными учетными записями. Также можно скрыть.
Computers: стандартный OU для компьютеров, добавляемых в домен (например, с помощью первого способа, описанного в статье Как включить Windows 8 в домен). Согласно документации Microsoft, не рекомендуется использовать данный контейнер для повседневной работы. Учетные записи, появляющиеся здесь нужно переносить в продуктивные OU (в зависимости от структуры каталога), либо же с помощью команды redircmp перенаправлять компьютеры сразу в новую OU (подробнее описано в статье Замена стандартного OU Computers в AD).
В результате, скрыв часть структуры каталогов, в консоли не отображается ничего лишнего, и упрощается повседневная работа администратора с консолью с ADUC, за счет вот такого компактного вида. Если необходимо отредактировать любой объект в «скрытой» части AD, достаточно переключить консоль AD в «расширенный вид».
get active directory container objects for new user
I want to create a tree of container objects in an active directory domain that a new user can be added to. I can recurse through the domain and get everything within the directory, but I want to limit my scope to ONLY containers that are valid for users.
What would an LDAP query look like to grab the children of a node that were suitable for a user object? Is there a better way to do this?
I’m using c#, System.DirectoryServices, and .net 3.5 if you are curious.
2 Answers 2
Check out the excellent MSDN article Managing Directory Security Principals in the .NET Framework 3.5 on how to use the new features in System.DirectoryServices.AccountManagement in .NET 3.5, if you haven’t already.
In order to bind to your container, you need to know it’s LDAP path and with this, you can establish a context based on that container:
With this context, you can now e.g. search for certain types of principals in that context:
Does that work for you? Is that what you’re looking for?
If I understand your question correctly, what you want to know is what kind of objects in Active Directory can contain User object.
I think you can get the answer from the AD schema partition. I had a quick check on my schema partition which is running Windows 2003 AD. The User object is allowed to be assigned to OU, container, builtinDomain and domainDNS.
I didn’t check Windows 2008 but I believe it should be the same. Many people know what OU and container are. Few people know what builtinDomain and domainDNS are. I doubt if it’s useful in your case. builtinDomain is a special container used to contain the built-in account. By default, AD created a builtinDomain at CN=Builtin,DC=yourdomain,DC=com . domainDNS is your root domain path DC=yourdomain,DC=com .
Here is a function to find all kinds of objects in Active Directory under a particular node. If you think builtinDomain and domainDNS is not meaningful in your case, just take it out from the LDAP filter.
TCP/IP и DNS
Хранилище зоны DNS
Информация зоны DNS хранится либо в текстовом файле, либо в Active Directory . При создании главной или остаточной зоны можно указать место хранения для файла зоны. Файлы вторичных зон хранятся только в формате текстовых файлов.
Сохранение информации зоны в текстовом файле
Информации зоны в текстовом файле по умолчанию сохраняется в папке %systemroot%\system32\dns . Имя файла может быть любым; обычно оно имеет вид [имя_зоны].DNS (например, microsoft.com.dns ). Файл зоны изменяется через консоль MMC для DNS, однако при остановке службы DNS это можно сделать напрямую, отредактировав текстовый файл зоны. Если запись занимает несколько строк, то разрывы строк должны заключаться в скобки. Комментарии в файле зоны DNS определяются точками с запятой («;»), расположенными перед ними. На рисунке 8.10 показан пример файла зоны DNS.
Ниже приводится описание записей, находящихся в файле зоны DNS.
Запись SOA . Первая запись в файле зоны DNS является записью Start of Authority (Начало полномочий). Запись SOA состоит из следующих полей:
Исходный компьютер. Определяет узел, на котором создан файл.
Контактный адрес электронной почты. Адрес электронной почты лица, ответственного за данный файл зоны. Символ «@» в адресе электронной почты заменяется на символ точки («.»).
Серийный номер. Серийный номер данной версии файловой базы данных зоны, используемый для контроля версий.
Время обновления. Время (с), в течение которого данная информация будет считаться актуальной. Данная запись информирует вторичный сервер об интервале времени, по прошествии которого нужно загружать новую копию файла зоны.
Время повтора. Информирует вторичный сервер о промежутке времени, по прошествии которого нужно повторить неудавшуюся попытку передачи зоны.
Срок действия. Время (в с), в течение которого информация считается действительной. Запись информирует вторичный сервер о промежутке времени, по прошествии которого все данные должны быть сброшены. Этот счетчик сбрасывается в случае успешной передачи зоны. Таким образом, в процессе взаимодействия вторичного сервера с главным сервером данные сбрасываться не будут.
Минимальное время жизни (TTL). Передается вместе с запросом на преобразование имени. Означает минимальный промежуток времени (с), в течение которого запрашивающий кэширует имя для отображения в IP-адрес. Значение по умолчанию – 1 час. При значении, равном 0, кэширования данных не происходит.
Другие записи. Другие записи в файле зоны DNS наследуют TTL из записи ресурса SOA , однако могут игнорироваться в индивидуальных записях. Синтаксис для индивидуальной записи имеет вид: .
- Имя. Имя узла или записи, подлежащей преобразованию.
- Класс. Содержит стандартный текст, означающий класс записи источника. IN означает, что запись источника принадлежит классу Internet. Это единственный класс, поддерживаемый Windows DNS.
- Тип. Указывает тип записи источника. Например, A означает, что запись источника хранит информацию об адресе узла.
- Данные. Это поле содержит особые данные записи. Формат может быть различным в зависимости от типа записи.
Сохранение информации зоны в Active Directory
Интегрированные зоны Active Diectory содержатся в контейнере, расположенном в дереве Active Directory под контейнером объекта домена. База данных Active Directory представляет собой расширяемое хранилище с названием ntds . dit . Он создается при создании контроллера домена. Объекту контейнера присваивается имя по имени зоны, присвоенного ей при ее создании.
Преимущества интеграции с Active Directory
Хранение зон DNS в Active Directory является рекомендуемым методом для серверов WS03, поскольку он дает следующие преимущества.
Отказоустойчивость. Хранение DNS в Active Directory обеспечивает отказоустойчивость зон DNS, поскольку информация о зонах DNS сохраняется на каждом контроллере домена внутри рассматриваемого домена. Даже если на определенном контроллере домена служба DNS не работать, он все равно содержит копию базы данных. Таким образом, в случае отказа сервера DNS база данных DNS потеряна не будет.
Многоабонентское обновление. WS03 Active Directory позволяет выполнять так называемое многоабонентское обновление, подразумевающее существование нескольких копий базы данных DNS с возможностью обновления любой из них. Так как интегрированные с Active Directory зоны DNS сохраняются в базе данных Active Directory, каждый контроллер домена содержит копию зоны. При добавлении нового контроллера домена база данных DNS реплицируется на этот контроллер домена. Любой контроллер домена WS03 с работающей службой DNS Server может обновлять главную копию зоны DNS.
Это серьезное усовершенствование системы DNS, которая, как правило, имеет один источник ошибок – главную копию базы данных, находящуюся в локальном файле на одном сервере. При использовании стандартного сервера DNS, если главный сервер является недоступным, обновления DNS выполняться не будут.
Безопасность. Интегрированные с Active Directory зоны позволяют использовать списки контроля доступа (ACL) для ограничения доступа к зонам или записям в них. Например, только некоторым пользователям или компьютерам разрешено обновлять записи в данной зоне. Этот процесс известен как безопасное динамическое обновление, и он используется по умолчанию для интегрированных с Active Directory зон.
Улучшенная производительность. Стандартные зоны DNS требуют репликации всей зоны на вторичные серверы при изменении записи . Зоны, интегрированные с Active Directory, реплицируют только сами изменения. Это кардинально уменьшает объем трафика репликации и упрощает сам процесс репликации. Изменения в DNS реплицируются с помощью репликации Active Directory, поэтому планирование репликации зон DNS исключается, что также уменьшает объем задач по администрированию.
Динамическое обновление DNS
Службы DNS системы WS03 позволяют проводить динамическое обновление, посредством которого клиенты могут вводить свои собственные записи A (Address) и PTR ( Pointer Resource ) в DNS . Обычная DNS является статической, поэтому при изменении IP -адресов соответствующие записи DNS становятся рассинхронизированными. Раньше это не представляло особой проблемы, поскольку записи DNS располагались только на серверах, а IP -адреса серверов в большинстве случае являются статическими. Кроме того, основная часть задач по преобразованию имен выполнялась системой WINS. Теперь Windows опирается, в основном, на DNS , и самое главное – все компьютеры содержатся в DNS . Многие клиенты располагаются на DHCP и могут получать различные IP -адреса, поэтому без обновления DNS при изменении адресов IP все может пойти наперекосяк. Здесь-то и вступает в игру динамическая DNS . При получении новых IP -адресов клиенты регистрируют свои записи, и администратору не приходится выполнять задачи, связанные с их обновлением.
При создании зоны DNS можно использовать безопасное динамическое обновление (от него потом можно отказаться). А теперь обсудим различия между двумя типами обновлений – обычным и безопасным.
Обычное динамическое обновление
При использовании динамических обновлений клиент или сервер DHCP является ответственным за обновление записей DNS A и PTR . Поскольку имя может зарегистрировать каждый, невозможно предотвратить злоумышленную регистрацию IP-адреса на имя, представляющее важность. Такая возможность является не безопасной; поэтому была разработана система безопасного динамического обновления.
Безопасное динамическое обновление
Безопасное динамическое обновление доступно только для интегрированных с Active Directory зон. Оно позволяет аутентифицировать клиентов, регистрирующих имена. Безопасные зоны имеют стандартные списки контроля доступа ACL, поэтому обновлять записи могут только те клиенты, которые отвечают разрешениям безопасности. Такой подход удобен следующим: можно заблокировать зоны, чтобы свои записи обновляли только серверы и DHCP-сервер. Таким образом, произвольная регистрация имен становится невозможной.
Прикручиваем LDAP-авторизацию к Kubernetes
Небольшая инструкция о том, как используя Keycloak можно связать Kubernetes с вашим LDAP-сервером и настроить импорт пользователей и групп. Это позволит настраивать RBAC для ваших пользователей и использовать auth-proxy чтобы защитить Kubernetes Dashboard и другие приложения, которые не умеют производить авторизацию самостоятельно.
Установка Keycloak
Предположим что у вас уже есть LDAP-сервер. Это может быть Active Directory, FreeIPA, OpenLDAP или что-либо еще. Если LDAP-сервера у вас нет, то в принципе вы можете создавать пользователей прямо в интерфейсе Keycloak, либо использовать публичные oidc-провайдеры (Google, Github, Gitlab), результат получится почти такой же.
Первым делом установим сам Keycloak, установка может выполняться отдельно, так и сразу в Kubernetes-кластер, как правило если у вас имеется несколько Kubernetes-кластеров, было бы проще установить его отдельно. С другой стороны вы всегда можете использовать официальный helm-чарт и установить его прямо в ваш кластер.
Для хранения данных Keycloak вам понадобится база данных. По умолчанию используется h2 (все данные хранятся локально), но возможно также использовать postgres , mysql или mariadb .
Если вы все же надумали установить Keycloak отдельно, более подробные инструкции вы найдете в официальной документации.
Настройка федерации
Первым делом создадим новый realm. Realm — это пространство нашего приложения. Каждое приложение может иметь свой realm с разными пользователями и настройками авторизации. Master realm используется самим Keycloak и использовать его для чего-нибудь еще неправильно.
Нажимаем Add realm
| Option | Value |
|---|---|
| Name | kubernetes |
| Display Name | Kubernetes |
| HTML Display Name |
Kubernetes по умолчанию проверяет подтвержден у пользователя email или нет. Так как мы используем собственный LDAP-сервер, то тут эта проверка почти всегда будет возвращать false . Давайте отключим представление этого параметра в Kubernetes:
Client scopes Email Mappers Email verified (Delete)
Теперь настроим федерацию, для этого перейдем в:
User federation Add provider. ldap
Приведу пример настройки для FreeIPA:
| Option | Value |
|---|---|
| Console Display Name | freeipa.example.org |
| Vendor | Red Hat Directory Server |
| UUID LDAP attribute | ipauniqueid |
| Connection URL | ldaps://freeipa.example.org |
| Users DN | cn=users,cn=accounts,dc=example,dc=org |
| Bind DN | u > |
| Bind Credential | |
| Allow Kerberos authentication: | on |
| Kerberos Realm: | EXAMPLE.ORG |
| Server Principal: | HTTP/freeipa.example.org@EXAMPLE.ORG |
| KeyTab: | /etc/krb5.keytab |
Пользователя keycloak-svc нужно создать заранее на нашем LDAP-сервере.
В случае с Active Directory, достаточно просто выбрать Vendor: Active Directory и необходимые настройки подставятся в форму автоматически.
Нажимаем Save
User federation freeipa.example.org Mappers First Name
| Option | Value |
|---|---|
| Ldap attribure | givenName |
Теперь включим маппинг групп:
User federation freeipa.example.org Mappers Create
| Option | Value |
|---|---|
| Name | groups |
| Mapper type | group-ldap-mapper |
| LDAP Groups DN | cn=groups,cn=accounts,dc=example,dc=org |
| User Groups Retrieve Strategy | GET_GROUPS_FROM_USER_MEMBEROF_ATTRIBUTE |
На этом настройка федерации закончена, перейдем к настройке клиента.
Настройка клиента
Создадим нового клиента (приложение которое будет получать пользователей из Keycloak). Переходим:
Clients Create
| Option | Value |
|---|---|
| Client ID | kubernetes |
| Access Type | confidenrial |
| Root URL | http://kubernetes.example.org/ |
| Valid Redirect URIs | http://kubernetes.example.org/* |
| Admin URL | http://kubernetes.example.org/ |
Так же создадим scope для групп:
Client Scopes Create
| Option | Value |
|---|---|
| Template | No template |
| Name | groups |
| Full group path | false |
И настроим mapper для них:
Client Scopes groups Mappers Create
| Option | Value |
|---|---|
| Name | groups |
| Mapper Type | Group membership |
| Token Claim Name | groups |
Теперь нам нужно включить маппинг груп в нашем client scope:
Clients kubernetes Client Scopes Default Client Scopes
Выбираем groups в Available Client Scopes, нажимаем Add selected
Теперь настроим аутентификацию нашего приложения, переходим:
Clients kubernetes
| Option | Value |
|---|---|
| Authorization Enabled | ON |
Нажимем save и на этом настройка клиента завершена, теперь на вкладке
Clients kubernetes Credentials
вы сможете получить Secret который мы будем использовать в дальнейшем.
Настройка Kubernetes
Настройка Kubernetes для OIDC-авторизации достаточно тривиальна и не является чем-то очень сложным. Все что вам нужно это положить CA-сертификат вашего OIDC-сервера в /etc/kubernetes/pki/oidc-ca.pem и добавить необходимые опции для kube-apiserver.
Для этого обновите /etc/kubernetes/manifests/kube-apiserver.yaml на всех ваших мастерах:
А так-же обновите kubeadm конфиг в кластере, что бы не потерять эти настройки при обновлении:
На этом настройка Kubernetes завершена. Вы можете повторить данные действия во всех ваших Kubernetes-кластерах.
Начальная авторизация
После данных действий вы уже будете иметь Kubernetes-кластер с настроенной OIDC-авторизацией. Единственный момент, что ваши пользователи пока что не имеют настроенного клиента как и собственного kubeconfig. Что бы эту проблему решить нужно настроить автоматическую выдачу kubeconfig пользователям после успешной авторизации.
Для этого можно использовать специальные web-приложения, которые позволяют провести аутентификацию пользователя а затем скачать готовый kubeconfig. Одно из самых удобных — это Kuberos, он позволяет в одном конфиге описать все Kubernetes-кластеры и легко переключаться между ними.
Для настройки Kuberos достаточно описать template для kubeconfig и запустить со следующими параметрами:
Для более детальной информации смотрите Usage на Github.
Так же возможно использовать kubelogin если вы хотите производить авторизацию непосредственно на компьютере пользователя. В этом случае пользователю откроется браузер с формой авторизации на localhost.
Полученный kubeconfig можно проверить на сайте jwt.io. Просто скопируейте значение users[].user.auth-provider.config.id-token из вашего kubeconfig в форму на сайте и сразу получите расшифровку.
Настройка RBAC
При настройке RBAC можно ссылаться как на имя пользователя (поле name в jwt-токене), так и на группу пользователей (поле groups в jwt-токене). Вот пример настройки прав для группы kubernetes-default-namespace-admins :
Больше примеров для RBAC можно найти в официальной документации Kubernetes
Настройка auth-proxy
Есть замечательный проект keycloak-gatekeeper, который позволяет защитить любое приложение, предоставляя пользователю возможность аутентифицироваться на OIDC-сервере. Я покажу как можно настроить его на примере Kubernetes Dashboard:
Сценарии для Active Directory. Часть 1
Многие системные администраторы Windows 2000 и Windows NT убедились, что разработка обычных сценариев для управления инфраструктурой принципиально отличается от использования традиционных графических инструментальных средств. Тем, кто придерживается такой точки зрения, я советую изучить технологию Windows Script (WS) и сопутствующие ей, в частности Active Directory Service Interfaces (ADSI). Писать пользовательские сценарии для управления средой не требуется, а создавать сценарии для Active Directory (AD), позволяющие осуществлять администрирование, становится намного проще. В этой статье я расскажу о трех основных интерфейсах в ADSI (IADsOpenDSObject, IADs и IADsContainer) и покажу, каким образом, используя эти основные интерфейсы, можно выполнить более 80% обычных задач управления AD.
Что такое ADSI?
Интерфейс ADSI — это набор COM-объектов для программирования, которые позволяют единообразно манипулировать многочисленными гетерогенными каталогами. Интерфейс ADSI — это основной программный интерфейс к AD, разработанный Microsoft, его используют все графические средства управления AD.
Изначально ADSI поддерживал протоколы Lightweight Directory Access Protocol version 3 (LDAPv3), NT 4.0 SAM, Novell Directory Services (NDS) и NetWare Bindery. Поскольку ADSI поддерживает LDAP, он может использоваться для управления каталогами, основанными на LDAP/X.500, включая Windows 2000 AD, Microsoft Exchange Server 5.5 и Site Server 3.0. Хотя я буду рассматривать именно AD, многие принципы, обсуждаемые в этой статье, применимы и к другим каталогам.
Так как интерфейс ADSI предназначен для программирования, его можно применять для написания сценариев управления каталогом в любой COM-совместимой среде, включая Windows Script Host (WSH), VBScript, JScript и ActivePerl. Интерфейс ADSI также поддерживает быстродействующие, только для чтения, запросы ActiveX Data Objects (ADO) через OLE DB.
ADSI устанавливает интерфейсы на стороне клиента. Это означает, что инсталлировать его нужно только на тот компьютер, который запускает сценарии. Дополнительно устанавливать ADSI на целевые контроллеры домена не требуется. Система Win-dows 2000 включает ADSI, но если планируется запускать сценарии ADSI на компьютерах с Windows NT или Windows 9x, то его необходимо загрузить и установить. ADSI 2.5 — это текущая версия, которую можно загрузить с Web-сайта Microsoft по ADSI (http://www.microsoft.com/adsi). На сайте также размещены связанные с ADSI официальные документы и средства для разработчиков, например набор инструментальных средств разработки для ADSI (SDK).
Терминология AD и ADSI
Чтобы эффективно использовать ADSI, необходимо изучить терминологию сценариев AD.
AD — это служба каталогов (DS) Win-dows 2000. DS — сетевая служба, которая идентифицирует и хранит информацию обо всех сетевых ресурсах и обеспечивает пользователям и приложениям доступ к ней. Служба каталогов AD — это распределенный иерархический тиражируемый каталог информации (Distributed information tree, DIT), который хранится в каталоге \%systemroot% tds на всех контроллерах домена Windows 2000 в фaйле ntds.dit. Можно обновить любую копию AD, и изменения AD будут тиражироваться на все контроллеры домена.
Служба каталогов AD в чем-то сходна с базой данных (например, AD тоже хранит информацию). Однако, в отличие от реляционных баз данных, которые предназначены для выполнения операций вставки, обновления и удаления, AD — это иерархическая структура, оптимизированная для операций чтения.
Каждый контроллер домена Windows 2000 поддерживает доступную для записи копию каталога (реплику), и каждая реплика состоит как минимум из трех разделов (известных как контексты именования): контекста именования по умолчанию, контекста именования схемы и контекста именования конфигурации. Контекст именования по умолчанию хранит информацию об общих объектах домена (таких, как компьютеры, группы, организационные единицы (OU), пользователи). Контекст именования схемы хранит схему AD (которая будет описана ниже), а контекст именования конфигурации хранит информацию о конфигурации узла и подсети. Основные интерфейсы обеспечивают общий и постоянный доступ к управляемым объектам во всех трех контекстах именования.
Компонент «схема» — это коллекция описаний классов и атрибутов; она определяет, какую информацию может хранить AD. Класс подобен шаблону для объекта, а атрибут — это свойство объекта (например, общее имя, описание, отличительное имя (DN)). Схема описывает обязательные и дополнительные атрибуты объекта. В рамках ADSI-сценариев можно получить доступ к схеме для установки обязательных и дополнительных свойств объектов. Кроме того, схема определяет структуру дерева каталога DIT. Объекты, которые могут содержать другие объекты, называются контейнерами; объекты, которые не могут содержать другие объекты, называются листьями.
Служба каталогов AD представляет сетевые ресурсы как объекты. С точки зрения AD объект есть заданный именованный набор свойств и связанных с ними значений, которые представляют конкретные сетевые ресурсы (например, компьютер, названный US-E-FN-01; группа, имеющая имя Investors, организационное подразделение OU с именем Finance, пользователь Джуди). С точки зрения программы или сценария объект есть экземпляр класса схемы.
Интерфейсы в ADSI являются механизмами, которые используются для модификации свойств объектов. Термин «интерфейс» — не единственный в ADSI. В программировании COM-интерфейс — это набор методов и свойств, которые предоставляет COM-объект. Методы оказывают некоторое воздействие на объект, а свойства характеризуют состояние объекта. Объекты COM могут предоставлять разнообразные интерфейсы. Например, ADSI обеспечивает более 50 интерфейсов. Однако всего три базовых интерфейса позволят выполнить многие задачи в AD.
Таким образом, ADSI — это набор программных интерфейсов, который используется для управления объектами AD. Интерфейсы ADSI обеспечивают методы и свойства для создания, удаления и модификации объектов. Объект есть набор свойств, которые представляет сетевой ресурс. Описание класса объекта, которое хранит схема, определяет свойства, создающие объект. Схема класса определяет обязательные и дополнительные атрибуты объекта. Сценарий ADSI использует методы ADSI для создания и удаления объектов и модификации свойств.
Каждый объект в AD имеет несколько имен. Отличительное имя DN и относительное отличительное имя (RDN) являются основными в соглашении об именовании для обращения к объектам из сценариев ADSI. Имя DN определяет точное расположение объекта в дереве DIT, основанном на именах атрибутов. Имя RDN — это обязательный атрибут «имя» объекта. Соотношение между именами DN и RDN в AD подобно соотношению между полностью определенным путем к файлу и именем файла в файловой системе.
Каждый DN-компонент есть RDN, а каждый RDN есть строка, состоящая из двух частей (параметр и значение), которая изображается как «key=va-lue». Key идентифицирует реальный тип атрибута, а value является значением атрибута.
В документе Internet Engineering Task Force (IETF) Request for Comments (RFC) 2253, «Lightweight Directory Access Protocol (v.3): UTF-8 String Representation of Distinguished Na-mes», описаны параметры и типы атрибутов, которые используются для создания имен DN в LDAPv3. В Таблице 1 перечислены некоторые из обычно применяемых параметров и соответствующие типы атрибутов.
Приведу пример связи между DN и RDN. На Рисунке 1 показаны DN и RDN для пользователя Джуди Шнайдер. RDN для Джуди — это «cn=Judy Schneider»; cn — это параметр для общего имени атрибута, а строка «Judy Schneider» является значением. Мы можем проверить имя DN Джуди, чтобы определить его точное месторасположение в DIT. Джуди входит в подразделение Finance OU, а то, в свою очередь, относится к домену acme.com. Можно представить DN как комбинацию всех объектов RDN при перемещении от объекта к корню дерева.
| Рисунок 1. Имена DN и RDN. |
Имя DN объекта должно быть уникальным во всем каталоге, а RDN объекта должно быть уникальным в текущем контейнере. Параметр и знак равенства — это обязательные компоненты RDN. Типы объектов, которые не имеют конкретного параметра, используют по умолчанию общее имя параметра «cn=».
Общие задачи AD
Три базовых интерфейса ADSI можно использовать для создания, модификации и удаления почти любого объекта AD (например, учетной записи пользователя, учетной записи компьютера, группы, OU, сайта, подсети). Можно просматривать контейнеры и создавать настраиваемые отчеты так же, как добавлять новые классы и атрибуты для расширения схемы.
Процесс написания любого ADSI-сценария включает несколько основных этапов. В следующем сценарии я перечислил действия, необходимые для создания объекта «пользователь» и управления им.
Компания Acme Widgets приглашает Джуди Шнайдер на работу в качестве инспектора. Джуди будет работать в финансовом подразделении компании — Finance OU. Вместе с системным администратором Acme Widgets совершим четыре шага для создания нового пользователя.
- Используя функцию GetObject VBScript, подсоединимся к целевому контейнеру («ou=Finance» в этом примере), который будет содержать нового пользователя.
- Используя метод Create из ADSI, создадим новый объект «пользователь» в локальном кэше свойств. Интерфейс IADsContainer предоставляет метод Create.
- Используя методы Put и PutEx из ADSI, установим обязательные и дополнительные свойства объекта «новый пользователь». Интерфейс IADs обеспечивает методы Put и PutEx.
- С помощью метода SetInfo из ADSI запишем новый объект в каталог. SetInfo также является частью интерфейса IADs.
Джуди покупает новый дом и переезжает. Необходимо обновить ее домашний адрес и номер домашнего телефона, поэтому выполняем следующие действия.
Джуди выдвигается на пост финансового директора компании (CFO). Необходимо перевести Джуди из финансового подразделения (Finance OU) в руководство (Executive OU), для этого выполняем два шага.
Джуди переходит к конкуренту. Необходимо удалить объект пользователя, поэтому выполним два последних шага.
В этом примере показаны основные шаги, которые являются общими для большинства сценариев ADSI. Приступая к выполнению каждой задачи, нужно подключиться к объекту. После подключения к объекту используются методы, содержащиеся в двух основных интерфейсах IADs и IADs-Container, с помощью которых и происходит управление жизненным циклом объекта.
Эти основные шаги можно применять и к другим объектам в каталоге. Для этого нужно отвлечься от основных интерфейсов в ADSI и выполнить перечисленные шаги в сценарии на базе функций. Я использую easyadsi.vbs в качестве примера и исследую основной интерфейс IADsOpenDSObject. В Листинге 1 показана часть сценария, которая выполняет первые четыре шага для создания нового объекта пользователя. Полностью листинг можно загрузить с Web-сайта Win-dows 2000 Magazine по адресу: http://www.win2000mag.com/. (Введите 9168 в текстовом окне InstantDoc ID и загрузите файл 9168.zip.)
| Листинг 1. Файл Easyadsi.vbs. |
Подключение к AD
Подключение — это первый шаг для взаимодействия с AD; соединение с объектом в LDAP называют запросом на привязку (bind request). Привязка — это точка в сценарии ADSI, в которой происходит процесс аутентификации. Внутренние LDAP-провайдеры интерфейса ADSI (adsldp.dll и wldap32.dll) создают и возвращают ссылку на указанный объект (например, домен, OU, группа, пользователь, принтер, служба, совместно используемый ресурс, сайт, класс схемы).
Используем функцию GetObject из VBScript для привязывания к объекту AD. Строка, передаваемая в Get-Object, — это ADSI LDAP — путь, который идентифицирует целевой объект. Для связывания с объектом можно использовать несколько подходов, которые основаны на синтаксисе LDAP-пути. ADSI LDAP-путь необходимо начать с «LDAP:». Далее может следовать строка с дополнительными элементами, как показано в примере на Рисунке 2.
Обязательный префикс «LDAP:» — это программный идентификатор (ProgID) для провайдера LDAP в ADSI. Идентификатор ADSI ProgIDs определяет ADSI провайдера DLL, через который сценарий поддерживает связь с каталогом. Идентификатор ADSI ProgIDs является чувствительным к регистру, поэтому для префикса «LDAP:» необходимо всегда использовать заглавные буквы. Остаток ADSI LDAP-пути нечувствителен к регистру.
Дополнительные элементы LDAP-пути включают имя целевого сервера, IP-адрес, номер порта LDAP и DN. Элементы, добавляемые к префиксу «LDAP:», определяют, как ADSI привязывается к AD.
Серверные привязки создаются при добавлении имени целевого сервера или IP-адреса как части LDAP-пути, что показано в примерах на Рисунке 3. Следует избегать привязок с явным указанием имени сервера или IP-адреса, потому что сценарий выдаст ошибку, если сервер окажется отключенным. Можно установить номер порта LDAP, если DS прослушивает другой порт, а не порт LDAP по умолчанию (порт 389). Однако не нужно беспокоиться о прослушивании AD по другому порту, потому что контроллеры домена Windows 2000 резервируют порт 389 для AD. Запросы без привязки к серверу удаляют зависимость, связанную с LDAP-путями, которые содержат явно указанные имена серверов. Поэтому целесообразнее использовать пути без имени сервера. Если не указать имя целевого сервера или его IP-адрес, ADSI выдает запрос к новому Win32 API (DSGetDCNa-me), который запрашивает DNS для поиска контроллера в домене, где зарегистрировался данный пользователь. Интерфейс ADSI пытается определить местоположение контроллера домена и подключиться к нему в локальном узле рабочей станции, основываясь на IP подсети. Если ADSI не может определить контроллер домена в узле, он использует первый ответивший сервер каталога.
Пути LDAP без указания сервера обычно включают имя DN, которое идентифицирует целевой объект. В запросе на привязку, показанном в Листинге 1 под меткой А, я сделал привязку к Finance OU, которая находится в домене acme.com. Строковое значение в переменной strContainer указывает его местоположение.
На Рисунке 4 показаны запросы на привязку, которые содержат другие виды путей LDAP без указания сервера. В первом примере на Рисунке 4 я выполнил привязку точно к de-faultNamingContext (где находятся объекты «пользователь», «компьютер», «группа» и OU) из домена acme.com. Во втором примере я сделал привязку к объекту конкретного пользователя. Третий пример является запросом на привязку без указания DN. При таком типе запроса ADSI создает привязку к специальному LDAPv3-объекту, Root Directory Ser-vice Entry (rootDSE), и использует свойство defaultNamingContext объекта rootDSE для привязки к корню DIT. Результат такой же, как и в первом примере, но использование запроса без указания DN снимает зависимость от специфики домена.
Можно также явно сделать привязку к объекту rootDSE. Введенный в версии LDAPv3 rootDSE находится на вершине дерева DIT каждого контроллера домена. В отличие от принципа привязки без DN (например «LDAP:»), в котором rootDSE возвращает только имя DN для defaultNamingContext, привязка напрямую к rootDSE позволяет получить доступ ко всей информации о каталоге сервера, предоставившего объект rootDSE. В этой информации будут и имена DN для всех контекстов именования каталога. Как показано в Листинге 2, я использовал свойства defaultNa-mingContext, schemaNa-mingContext и configura-tionNamingContext объекта rootDSE, отмеченные как A, B и C, для привязки к корню каждого контекста именования каталога и просмотра высокоуровневых объектов.
| Листинг 2. Файл RootDSE.vbs. |
До сих пор я надеялся на имеющиеся у меня разрешения при проверке запроса на привязку. Хотя такой метод аутентификации достаточно эффективен, в некоторых случаях бывает необходимо указать другие учетные данные или соответствующий тип аутентификации. Интерфейс IADSOpenDSOb-ject из ADSI предоставляет для выполнения привязки к объекту метод OpenDSObject, который предполагает использование указанных пользователем учетных данных. Метод Open-DSObject допускает четыре параметра, которые перечислены в Таблице 2.
В Листинге 1 показано, как использовать OpenDSObject вместо текущих учетных данных пользователя (метка B). Замените код с меткой A в Листинге 1 кодом с меткой B в Листинге 1 для использования Open-DSObject. Перед тем как обратиться к Open-DSObject, нужно ввести
чтобы получить ссылку на провайдера LDAP. В качестве имени пользователя можно указать DN, User Principal Name (UPN), низкоуровневое учетное имя SAM (pre-Windows 2000) или Anonymous.
Советы по привязкам
Интерфейс ADSI обеспечивает большую гибкость при выполнении привязок к объектам AD. При разработке собственных ADSI-сценариев нужно иметь в виду следующее.
- Используйте текущие учетные данные всегда, когда это возможно.
- Никогда не применяйте явно указанные пароли в своих сценариях. При необходимости использовать пароль нужно создать запрос, адресованный пользователю, или извлечь пароль из системы безопасности. Затем следует сохранить его во временной переменной и уничтожить содержимое переменной сразу же после запроса на привязку.
- Используйте rootDSE, когда сценарий делает привязку к корню текущего домена.
- Избегайте явного указания имен серверов в путях LDAP.
- Делайте привязки к контейнерам для создания, перемещения и удаления объектов в контейнере.
- Делайте привязки к объектам-листьям для модификации свойств объекта.
В следующей статье, посвященной ADSI, я планирую рассказать о двух других основных интерфейсах ADSI — IADs и IADsContainer. А пока рекомендую читателям попробовать привязаться к некоторым объектам в своем каталоге. Для большего эффекта советую включить Network Monitor и попытаться задействовать несколько методов привязки.
БОБ УЭЛЛС — консультант по программному обеспечению; специализируется на вопросах проектирования и реализации инфраструктуры информационных систем, основанных на NT. Имеет сертификаты MCSE и MCT. С ним можно связаться по адресу: bobwells@win2000mag.com.
| Key | Attribute Type |
| CN | commonName |
| L | localityName |
| ST | stateOrProvinceName |
| O | organizationName |
| OU | organizationalUnitName |
| C | countryName |
| STREET | streetAddress |
| DC | domainComponent |
| UID | userid |
Поделитесь материалом с коллегами и друзьями
Asp объекты контейнеры adsi
Thank you for your examples. I had try the codes,
but I do not know «o=BSP». If I have a domain name
called «mksh.phc.edu.tw», how can I set the «o=??»
Thanks for your advice.
Sincerely,
ZenJohn
| LDAP query slows down too long | emmpergul | 1-Aug-06 11:02 |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
