Asp свойства объектов adsi


Содержание

Встроенный редактор атрибутов объектов Active Directory в ADUC

Редактор атрибутов Active Directory (Attribute Editor) это встроенный графический инструмент для тонкого редактирования свойств объектов AD (пользователей, компьютеров, групп). Именно из редактора атрибута вы сможете получить и изменить значения атрибутов объектов AD, которые недоступны в свойствах объекта в консоли ADUC.

Использование Attribute Editor в консоли Active Directory Users and Computer

Итак, чтобы воспользоваться редактором атрибутов AD вам нужно установить оснастку dsa.msc (или ADUC — Active Directory Users and Computer).

Попробуйте открыть свойства любого пользователя в AD. Как вы видите доступны несколько вкладок с атрибутами пользователя. Основные из них:

  • Общие (General) – основные свойства пользователя, которые задаются при создании учетной записи в AD (имя, фамилия, телефон, email и т.д.);
  • Адрес (Address);
  • Учетная запись (Account) – имя учетной записи (samAccountName, userPrincipalName). Здесь можно указать список компьютеров, на которых разрешено работать пользователю (LogonWorkstations), опции: пароль не истекает, пользователь не может сменить пароль, включена ли учетная запись и ее срок действия и т.д.;
  • Профиль (Profile) – можно настроить путь к профилю пользователя (в сценариях с перемещаемыми профилями); скрипт, выполняемый при входе, домашнюю папку, сетевой диск;
  • Телефоны (Telephones);
  • Организация (Organization) – должность, департамент, компания пользователя, имя менеджера.

В этом окне вам доступен только базовый набор свойств пользователя, хотя в классе User в AD гораздо больше атрибутов (200+).

Чтобы отобразить расширенный редактор атрибутов, вам нужно в меню ADUC включить опцию View -> Advanced Features (Вид -> Дополнительные компоненты).

Advanced Features » w />

Теперь еще раз откройте свойства пользователя и обратите внимание, что появилась отдельная вкладка Attribute Editor. Если перейти на нее, перед вами откроется тот самый редактор атрибутов пользователя AD. Здесь в таблице представлен список всех атрибутов пользователя AD и их значения. Вы можете щелкнуть на любом атрибуте и изменить его значение. Например, изменив значение атрибута department, вы увидите, что сразу изменилось наименование департамента в свойствах пользователя на вкладке Organization.

Из редактора атрибутом можно скопировать значение поля distinguishedName (в формате CN=Sergey A. Ivanov,OU=Users,OU=Msk,DC=winitpro,DC=ru — уникальное имя объекта в AD), CN (Common Name), узнать дату создания учётной записи (whenCreated) и т.д.

Внизу окна редактора атрибутов AD присутствует кнопка Filter. По умолчанию в окне атрибутов отображаются только непустые атрибуты (включена опция Show only attributes that have values / Отображать только атрибуты со значениями). Если вы отключите эту опцию, в коноли будуут показаны все атрибуты класса User. Также обратите внимание на опцию Show only writable attributes. Если включить ее, вам станут доступны только те атрибуты, на правку которых вам делегированы полномочия (если у вас нет полномочий на изменение атрибутов данного пользователя, список атрибутов будет пуст).

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

  • можно найти информацию о последнем входе пользователя в домен — атрибут lastLogonTimestamp (как вы видите в консоли редактора атрибутов время отображается в нормальном виде, но если щелкнуть по нему, вы увидите, что на самом деле время хранится в виде timestamp);
  • состояние учетной записи хранится в атрибуте userAccountControl. Вместо битовой маски вы видите более удобное представление. Например, 0x200 = (NORMAL_ACCOUNT) вместо цифры 512;
  • однако фото пользователя в AD (атрибут thumbnailPhoto) не отображается, и хранится в бинарном виде;

Не доступна вкладка Attribute Editor через поиск Active Directory

Основной недостаток редактора атрибутов AD, он не открывается в свойствах объекта, если вы нашли его через поиск (почему так сделано — я не понимаю). Для использования Attribute Editor вы должны в дереве AD развернуть контейнер (OU), в котором находится объект, найти в списке нужный объект и открыть его свойства (все это дико не удобно).

Для себя я нашел небольшой лайфхак, который все-таки позволяет открыть редактор атрибутов пользователя, найденного через поиск в консоли ADUC.

  1. С помощью поиска найдите нужного пользователя;
  2. Перейдите на вкладку со списком групп пользователя (Member of);
  3. Откройте одну из групп (желательно, чтобы в ней было как можно меньше пользователей);
  4. В свойствах группы перейдите на вкладку с членами группы (Member) и закройте (!) окно свойств пользователя;
  5. Теперь в списке членов группы щелкните по своему пользователю и перед вами откроется окно свойств пользователя со вкладкой Attribute Editor.

Также вы можете открыть редактор атрибутов пользователя без его ручного выбора в дереве AD через сохраненные запросы в консоли ADUC.

Либо вы можете использовать Active Directory Administrative Center, в котором вкладка редактора атрибутов пользователя (компьютера) доступна даже через поиск (вкладка Extension).

Вместо Attribute Editor для просмотра и редактирования всех атрибутов пользователей, групп и компьютеров можно использовать командлеты PowerShell:

Просмотр значений всех атрибутов объектов:

  • Пользователя: Get-ADUser username -Properties *
  • Компьютера: Get-ADСomputer computername -Properties *
  • Группы: Get-ADGroup groupname -Properties *

Чтобы изменить атрибуты объектов в AD соответственно используются командлеты Set-ADUser , Set-ADComputer и Set-ADGroup .

Запрос свойства объектов Active Directory из приложения ASP.NET возвращает старые результаты

Уже несколько дней , теперь я пытаюсь получить некоторые проверки подлинности пользовательского Активной основы каталогов работать. Все это работает в теории , но , видимо , моя теория неверна. Пользователи , которые вошли в домен записи строки маркера (например , PIN — код) в своей области недвижимости в Active Directory ( на самом деле не имеет значения , какой, но я использовал primaryInternationISDNNumber для этого) при входе в приложение ASP.NET Этот PIN — код всегда генерируется и написано программно.

Чтобы объяснить это грубо, веб-браузер загружает Java-апплет, который затем загружает родную DLL, написанную на C ++, который генерирует и записывает PIN-код в поле Active Directory текущего пользователя. То DLL, затем возвращает сгенерированный PIN-код для апплета, который затем передает его в браузер, который выполняет вызов AJAX с возвращаемыми данными, чтобы инициировать аутентификацию. Приложение, которое имеет доступ к AD, считывает это значение поля для соединительного объекта пользователя и проверяет, соответствует ли это с одним пользователем в комплекте поставки. Если PIN-коды совпадают, то пользователь успешно прошел проверку подлинности.

Это пример кода приложения ASP.NET используется для чтения AD:

Это прекрасно работает, часто. Но часто это не приемлемо. Он должен всегда работать.

Проблема заключается в том , что приложение ASP.NET иногда получает значение , которое было ранее в этой области, а не фактическое значение. Как будто есть какой — то кэширование. Я пытался добавить , de.UsePropertyCache = false но это дало те же результаты.

Я создал два Win32 консольных приложений для целей тестирования. Один пишет PIN — код, а другой считывает PIN — код. Они всегда работают отлично!

Я думал, это должен быть какой-то проблемы с пулом приложений IIS. Таким образом, я создал родной DLL, которая будет загружаться с помощью приложения ASP.NET с использованием платформы Invoke. Эта библиотека создает новый поток, вызывает CoInitialize и считывает PIN-код. Это код:

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

Так что теперь я подумал, хорошо, я не был в состоянии избежать пула приложений IIS и с этого нужно быть проблемой с пулом приложений IIS, я создать собственное приложение для Windows , который я будет выполнять с помощью Process.Start метода. Я верну свой PIN — код с помощью выходного кода процесса (так как это целое число в любом случае). Приложение использует подобный C ++ код как выше DLL.

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

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


И я думал, что Java был ад . Кто-нибудь имеет ни малейшего представления о том, что могло бы быть здесь происходит?

Управляем объектами в Active Directory. Часть 1

Архив номеров / 2008 / Выпуск №5 (66) / Управляем объектами в Active Directory. Часть 1

Управляем объектами в Active Directory

Управление объектами в Active Directory осуществляется с помощью соответствующих мастеров. Какие поля при этом изменяются в каталоге Active Directory – покрыто тайной.

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

Создание каждого сценария для начинающего программиста или системного администратора – это битва. Чтобы ее выиграть, необходимо проявить смекалку и сообразительность, перерыть множество источников. Не проще ли, как говорят, поставить все точки над «i»?

Типы объектов в Active Directory

Каталог Active Directory поддерживает 8 основных типов объектов (см. таблицу 1), каждый из которых описывается набором свойств. Часть из них повторяется, часть – индивидуальна. С другой стороны значения некоторых полей можно просмотреть и изменить с помощью встроенного в Active Directory мастера, а часть – только с помощью специализированного программного обеспечения или сценария.

Тип объекта определяется набором параметров, которые хранятся в Active Directory в массиве objectClass. Некоторые значения присутствуют везде, например Top, другие строго идентифицируют объект. Избыточность значений необходима для совместимости доменов, построенных на основе Windows 2К и Windows NT.

При составлении поисковых запросов в качестве фильтра используют только индивидуальные значения массива objectClass для однозначной идентификации. Значения многих элементов объектов разных типов пересекаются.

Таблица 1. Взаимосвязь типов объектов Active Directory и значений параметра objectClass

Фрагмент поискового запроса

Учетная запись компьютера

Контакт, используется в почтовых приложениях

Учетная запись пользователя, не совместимая с доменами Windows 2k

Папка дерева каталогов Active Directory

Опубликованный в Active Directory сетевой принтер

Опубликованная в Active Directory сетевая папка

Учетная запись пользователя, совместимая с доменами Windows NT

Механизм поиска объектов рассмотрим после того, как вы получите представление об объектной модели Active Directory.

Параметры объектов в Active Directory

Все параметры объектов можно разделить на три группы:

  • Явно задаваемые. Значения этих параметров напрямую задаются системным администратором. Самый яркий пример – имя объекта.
  • Неявно определяемые. Эти параметры администратор задает завуалированно. К ним относятся тип и местоположение объекта.
  • Скрытые объекты. Эти объекты создаются или изменяются системой. С помощью сценария или мастера их, как правило, невозможно изменить. К таким параметрам относятся SID и GUID объекта, время создания объекта.

Объектная модель Active Directory

Не так давно на сайте Microsoft появилось описание полей Active Directory (http://msdn2.microsoft.com/en-us/library/ms675090(VS.85).aspx).

Описание сделано в стиле Microsoft, т.е. использовать эту информацию по принципу «как есть» невозможно. В ней приведена вся схема каталога в ужасно сокращенном виде, без примеров.

Чтобы посмотреть «начинку» объекта, рекомендуется использовать утилиту (см. рис. 1), недавно созданную сотрудниками Microsoft – Active Directory Explorer 1.01 (http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx), однако она не так удобна в использовании, как хотелось бы.

Рисунок 1. Внешний вид программы Active Directory Explorer 1.01

Существует более удачный вариант – утилита Softerra LDAP Browser (http://www.ldapbrowser.com), о которой я неоднократно упоминал ранее в своих статьях. Безусловно, эта утилита удобнее, но несколько сложнее в использовании.

Управление объектами в Active Directory

Рассмотрим процессы управления объектами с точки зрения взаимосвязей стандартных инструментов, прилагаемых Microsoft, и объектной модели LDAP.

Из ранее перечисленных объектов чаще всего используются следующие: учетная запись пользователя, группа безопасности и папка.

С объектами в Active Directory можно проделывать следующие манипуляции: создавать, читать, изменять (если возможно), удалять и, наконец, искать.

Рассмотрим подробнее каждое из этих действий на примере работы мастера. Начнем с учетной записи пользователя.

Учетная запись пользователя

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


Создание учетной записи пользователя. Основные принципы

Для инициализации процесса создания учетной записи необходимо запустить соответствующий мастер в ММС-оснастке Active Directory. Для этого установите курсор на папку, в которой будет создана учетная запись, и, вызвав контекстное меню папки, выберите в нем пункт «New -> User» (см. рис. 2). Выполнив эти действия, системный администратор неявным образом определил местоположение учетной записи будущего пользователя, а именно часть параметра distinguishedName: CN=User,DC=msk, DC=ru и тип объекта – параметра objectClass.

Рисунок 2. Создание учетной записи пользователя

Замечение: если папка является встроенной, то ее имя определяется параметром CN. Все остальные параметры идентифицируются параметром OU (Organizational Unit), например OU=Test,CN=User,DC=msk, DC=ru.

Работа мастера состоит из трех частей. Рассмотрим последовательно каждую из них.

Во время создания учетной записи пользователя на первом шаге необходимо указать фамилию, имя и отчество пользователя. Необязательно задавать все три параметра: достаточно задать один из них. Полное имя (поле 4) формируется на основе Ф.И.О., заданных с помощью первых трех полей. Его значение формируется автоматически, однако администратор может изменить его на любое другое. Первые четыре параметра могут быть позже изменены (см. рис. 3). Для этого необходимо войти в свойства пользователя во вкладку «General» (отображается по умолчанию).

Рисунок 3. Работа мастера «Создание учетной записи пользователя». Шаг 1

Вторая группа параметров – имя пользователя в сети и дополнительное имя, требуемое для связи доменов, построенных на основе Windows NT и Windows 2K. В Active Directory им соответствуют параметры userPrincipal Name и sAMAccountname. Каждое из этих имен состоит из двух частей: имени пользователя и текущего домена. Имя текущего домена определяется автоматически и не может быть изменено. В таблице 2 приведено описание полей, задействованных на первом шаге работы мастера.

Таблица 2. Параметры учетной записи пользователя. Шаг 1

Сценарии для Active Directory. Часть 2

Еще два интерфейса Active Directory Scripting Interfaces, которые необходимо знать специалистам по AD.

В первой части статьи я рассказал о том, что при создании сценария для Active Directory (AD) для выполнения 80% задач из более 50 программных интерфейсов Active Directory Scripting Interfaces (ADSI) необходимо использовать только 3. В частности, рассматривался один из трех основных интерфейсов IADsOpenDSObject. Напомню, что интерфейс IADsOpenDSObject содержит метод OpenDSObject, который применяется для аутентификации при соединении с AD. В первой части также была описана терминология AD, ADSI и составных имен (DN). Во второй части я расскажу о двух оставшихся интерфейсах — IADs и IADsContainer.

Ключи к сценарию

Прежде чем подробно рассматривать интерфейсы IADs и IADsContainer, надо сказать несколько слов о той роли, которую они играют. Даже простые задачи при написании сценариев ADSI невозможно решить без использования хотя бы одного из этих интерфейсов. Свойства и методы, которые обеспечивают IADs и IADsContainer, используются для создания, удаления и изменения почти каждого объекта AD. Поэтому тем, кто хочет заниматься написанием ADSI-сценариев, рекомендую запомнить эти два интерфейса. Они включают только полдюжины свойств интерфейсов и с десяток методов, поэтому задача не так сложна, как может показаться на первый взгляд.

Интерфейс IADs

Интерфейс IADs реализуется всеми объектами AD одинаково. Он содержит шесть свойств и семь методов. Шесть свойств IADs, которые перечислены в Таблице 1, дают нам важную информацию об объекте.

Рассмотрим несколько сценариев, в которых будут использоваться свойства IADs. Допустим, требуется использовать ADSI-поставщика OLEDB/ADO и запрос к AD, а затем модифицировать объекты, возвращенные в результатах запроса. Однако записи набора, который возвращает ADSI-поставщик OLEDB/ADO, являются записями только для чтения, поэтому необходимо осуществлять привязку к каждому объекту из результатов запроса, чтобы иметь возможность модифицировать данный объект. Чтобы это сделать, необходимо иметь действительный ADsPath для выполнения операции связывания. Так как каждый объект предоставляет свой ADsPath через интерфейс IADs, можно идентифицировать ADsPath как одно из значений, возвращаемых в результатах запроса. Такой метод рекомендуется применять всякий раз при запросе AD.

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

Глобальный уникальный идентификатор (GUID) — это единственное свойство объекта, которое никогда не изменяется. Свойство GUID используется для привязки к объекту способом, который не зависит от его перемещения и переименования. Свойство Name — это относительное составное имя (RDN); оно представляет собой первичное имя объекта и уникально идентифицирует объект в текущем контейнере. Можно использовать свойства Parent вместе со свойствами ADsPath и Schema, работая с двоичным информационным деревом Directory Information Tree (DIT).

Рубрика: Администрирование / Администрирование
Листинг 1. Свойства схемы через IADs.

Свойство Schema нужно применять для создания ссылки на схему класса объекта для определения обязательных и дополнительных свойств этого объекта, как показано в Листинге 1. После связывания с целевым объектом я вывожу значения шести свойств IADs (см. Листинг 1, метка A). Меткой B в Листинге 1 я пометил путь, с помощью которого свойство Schema объекта обеспечивает связывание с классом схемы объекта. В ответ я получил ссылку на описание пользовательского класса схемы, базирующегося на типе объекта, который отражен в первой строке Листинга 1. Получив ссылку, я отразил содержимое атрибутов must-Contain и mayContain пользовательского класса. На Экране 1 показана часть результатов исполнения Листинга 1.

Экран 1. Частичный вывод на консоль из Листинга 1.

Семь методов IADs, показанных в Таблице 2, обеспечивают механизмы, которые используются для добавления, изменения и удаления данных объекта. Хотя методы IADs просты в применении, некоторые сценарии бывают весьма коварны. Но прежде, чем я расскажу о них, необходимо понять, что такое кэш свойств ADSI.

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

Кэш свойств является адресным пространством объекта, которое ADSI выделяет в тот момент, когда происходит связывание с объектом. Однако сначала кэш пуст. Методы IADs используются для инициализации и взаимодействия со значениями в локальном кэше свойств и нижележащей базой каталога, как показано на Рисунке 1.

Из семи методов IADs только GetInfo, GetInfoEx и SetInfo непосредственно взаимодействуют с базовым каталогом. Get, GetEx, Put и PutEx взаимодействуют только со значениями в кэше свойств, с одним исключением, о котором чуть позже. Процесс, используемый в работе с данными объекта и кэшем свойств, зависит от конкретной задачи. Например, при создании объекта и инициализации его свойств необходимо использовать следующие методы и функции.

  1. Функцию GetObject VBScript — для связывания с целевым контейнером, который будет содержать новый объект (сетевой трафик).
  2. Метод Create IADsContainer — для создания нового объекта в локальном кэше свойств (нет сетевого трафика).
  3. Метод Put или PutEx IADs или оба вместе — для установки новых обязательных и дополнительных свойств объекта в локальном кэше свойств (нет сетевого трафика).
  4. Метод IADs SetInfo — для фиксации (записи) нового объекта или соответствующих свойств в кэше свойств в базе службы каталога (сетевой трафик).

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

  1. Использовать функцию GetObject VBScript для связывания с целевым объектом (сетевой трафик).
  2. Использовать методы GetInfo или GetInfoEx IADs для извлечения свойств объекта из базы службы каталога, чтобы наполнить (инициализировать) локальный кэш свойств (сетевой трафик).
  3. Использовать методы Get или GetEx IADs или оба вместе для чтения свойств в локальном кэше свойств (нет сетевого трафика).
  4. Использовать методы Put или Put-Ex IADs или оба вместе для модификации свойств в локальном кэше свойств (нет сетевого трафика).
  5. Использовать метод IADs SetInfo для фиксации (записи) модифицированных свойств в кэше свойств в базе службы каталога (сетевой трафик).
  6. Использовать методы GetInfo или GetInfoEx IADs для реинициализации локального кэша свойств, чтобы отразить изменения, которые были сделаны на пятом шаге (сетевой трафик).

Теперь применим приобретенные знания для изменения версии сценария easyadsi.vbs, о котором шла речь в первой части статьи. Я использую код Листинга 2 как основу для дальнейшего обсуждения. Мы не будем проходить по сценарию построчно. Я объясню каждый метод IADs, затем приведу пример метода в Листинге 2. Однако я не показываю все доступные методы IADs, поскольку Листинг 2 можно использовать на практике, а некоторые методы IADs применяются редко.

GetInfo. Метод GetInfo извлекает свойства объекта из AD и загружает значения свойства в локальный кэш свойств, инициализируя его. Метод GetInfo загружает в кэш только те свойства, которые содержат значения.

В Листинге 2 метод GetInfo не используется по двум причинам. Во-первых, я создал новый объект пользователя (см. Листинг 2, метка А), поэтому не могу вызвать GetInfo для объекта, которого еще не существует. И хотя я обновил несколько свойств в метке B Листинга 2, я не затрагивал предыдущие значения свойств. Не нужно инициализировать кэш с существующими значениями, если планируется перезаписать значения (если только не требуется по какой-либо причине сохранить старые значения, к примеру, для фиксации изменений в управлении).

Использовать GetInfo в Листинге 2 нужно только в том случае, если требуется проверить новые значения, установленные в метке B. Чтобы это сделать, нужно вызвать GetInfo после вызова SetInfo и обновить значения в кэше. Если вызвать GetInfo перед SetInfo (и после Put-предложений), GetInfo перезапишет кэшированные значения (которые использовали Put и PutEx для модификации) оригинальными или старыми значениями из базы каталога, и изменения не сохранятся.

Хотя использование GetInfo — неплохой метод обновления кэша, он не считается самым эффективным. Например, я обновил три свойства в метке B Листинга 2. Вызов GetInfo после метки B извлекает все значения для более 50 свойств в метке A Листинга 2. Вместо GetInfo лучше применить GetInfoEx.

GetInfoEx. Метод GetInfoEx также инициализирует локальный кэш свойств, извлекая свойства объекта из AD и загружая значения свойства в кэш. Однако GetInfoEx загружает только свойства, перечисленные в массиве свойств, который является первым параметром GetInfoEx. Следовательно, метод GetInfoEx более эффективен для восстановления обновленных значений. Однако, как и в случае с GetInfo, перед вызовом GetInfoEx с именем обновленного свойства следует вызывать SetInfo.

Для проверки существующего значения метод GetInfoEx также более эффективен. Например, если нужно проверить значение одного свойства в AD, лучше использовать GetInfoEx. Вместо того чтобы выполнять явный вызов GetInfo или использовать Get для неявного вызова GetInfo, следует передать GetInfoEx массив, содержащий один элемент, который идентифицирует подлежащее проверке свойство.

Еще одна ситуация, в которой требуется GetInfoEx, связана с тем, что вызовы ADSI не загружают рабочие атрибуты (например, стандартное canonicalName) в кэш. Необходимо использовать GetInfoEx в запросе рабочего атрибута перед его прочтением, как, например, в коде, показанном на Рисунке 2. В противном случае система выдает сообщение об ошибке: «The Active Directory property cannot be found in the cache.»

Рисунок 2. Кэш свойств ADSI.


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

Get возвращает однозначные свойства как скалярные переменные и многозначные свойства как переменные массивы. Метод GetEx возвращает все значения свойств как переменные массивы, поэтому он возвращает однозначное свойство в одноэлементном массиве.

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

Код в Листинге 2 не вызывает Get или GetEx потому, что в возможностях этих методов нет необходимости в силу особенностей сценария, и сам сценарий не производит вывод на консоль или в файл. Если мне нужно отобразить значения свойства, я должен вставить соответствующее предложение вывода, придерживающееся такого же синтаксиса «объект.метод_свойства» (object.propertymet-hod), который использовался для установки значений свойства в метке A Листинга 2. Код на Рисунке 2 представляет собой пример синтаксиса object.propertymethod, который используется совместно с предложением Wscript.Echo.

Put и PutEx. Метод Put применяется для записи однозначных свойств в кэш свойств, а PutEx — для добавления, модификации, замены и очищения многозначных свойств в кэше свойств. Put и PutEx записывают и модифицируют значения только в кэше свойств. Для записи изменений из кэша в AD необходимо ввести SetInfo. Хотя Put можно использовать для модификации многозначных свойств, этот метод не позволяет управлять свойствами имеющихся данных. Put будет вслепую заменять все существующие многозначные данные так же, как он заменял однозначные свойства. Используйте метод PutEx в ситуациях, когда необходимо сохранить существующие данные в многозначном свойстве.

Как показано в Таблице 2, PutEx использует управляющий код для передачи типа выполняемого обновления. По ADS_PROPERTY_APPEND добавляется новое значение в то время, как существующие значения сохра-няются. ADS_PROPERTY_DELETE удаляет определенное значение и оставляет другие значения нетронутыми. Подобно Put, ADS_PROPERTY_UPDATE заменяет все существующие значения новыми, а ADS_PROPERTY_CLEAR удаляет все значения, очищая свойство.

Метка B Листинга 2 указывает на пример использования Put и PutEx. В случае с PutEx я добавил новое значение атрибуту otherHomePhone (замечу, что управлять порядком величин в многозначных свойствах нельзя).

SetInfo. Метод SetInfo записывает новые или модифицирует существующие значения свойства из кэша в AD. Метод SetInfo всегда вызывается явно; когда кэш свойств не инициализирован, SetInfo никогда не активизируется неявным образом, как это происходит в случае с Get или GetEx, вызывающими GetInfo. Любые изменения значений свойства, сделанные Put или PutEx, теряются при вызове GetInfo или, может быть, перед вызовом SetInfo. Можно использовать один вызов SetInfo для внесения целого ряда изменений, но необходимо понимать, что SetInfo — это бескомпромиссная операция типа «все или ничего». Т. е. SetInfo записывает все изменения, сделанные до вызова SetInfo, в базу каталога или не вносит изменений, если происходит ошибка (например, при нарушении требований системы безопасности).

Синтаксические соглашения object.pro-pertymethod. Синтаксис object.propertymethod — это соглашение, которое OLE-клиенты могут использовать вместо Get или Put. Синтаксис позволяет программистам на Visual Basic (VB) и VBScript использовать привычную нотацию dotMethodOrPro-pertyName. Синтаксис состоит из двух частей, отделенных точкой (.). Имя слева от точки является объектной ссылкой; имя справа от нее — это отображаемое имя атрибута, извлекаемого или записываемого в кэш, написанное по правилам Lightweight Directory Access Protocol (LDAP). Использование синтаксиса object.propertymethod в правой части оператора присваивания или выражении эквивалентно Get. Использование этого синтаксиса в левой стороне оператора присваивания эквивалентно Put. Требования к поведению синтаксиса object.propertymethod — те же самые, что и к Get и Put (т. е. те же типы возвращаемых Get результатов и ограничения на Put при обновлении многозначных свойств).

Я использовал object синтаксис .propertymethod в метке A Листинга 2 для установки исходных значений как для однозначных, так и многозначных свойств. В метке B Листинга 2 я задействовал Put и PutEx, поскольку обновил многозначное свойство под именем otherHomePhone.

Интерфейс IADsContainer

Интерфейс IADsContainer служит для управления жизненным циклом объектов AD. Контейнерные объекты создают иерархию и образуют организацию DIT. Каждый контейнерный объект в AD реализует IADs Container. IADsContainer имеет четыре свойства, которые перечислены в Таблице 3, и пять методов, указанных в Таблице 4.

Из четырех свойств IADsContainer два доступны через провайдера LDAP. Тем не менее можно использовать непосредственно и VBScript, вызвав только одно свойство: Filter. Имя говорит само за себя, свойство Filter позволяет применять фильтр к контейнеру и выбирать отдельные типы объекта. Например, при привязке к OU, когда нужно выбрать только группу объектов, входящих в OU, к OU применяется Group Filter, как показано на Рисунке 3.

Можно добавить в массив другие типы объектов, проводя фильтрацию по различным типам объектов. Например, Array («Group», «Computer») перечисляет все объекты типа Group и Computer. Кроме того, можно еще раз применить фильтр с другими типами объектов и получить совершенно другой перечень. Однако если используется свойство Filter для фильтрации объектов User, то в перечне появятся как объект User, так и Computer, потому что Computer является дочерним по отношению к User в иерархии классов AD. Чтобы избежать такой ситуации, можно применить фильтр для объектов Computer, запомнив список только объектов Computer. Далее создается второй список для фильтра по User, сравниваются два списка, и из списка пользователей удаляются позиции из списка компьютеров. Или же можно полностью заменить фильтр запросом ADO.

Другое свойство IADsContainer, применяемое к провайдеру LDAP, называется NewEnum. Однако непосредственно NewEnum не вызывается; предложение For Each из VBScript осуществляет просмотр контейнера и неявным образом вызывает NewEnum, как показано на Рисунке 3.

Из пяти методов IADsContainer к методам Create, Delete, GetObject и MoveHere нельзя получить доступ с помощью провайдера LDAP. Вместе все четыре метода обеспечивают первичные механизмы управления жизненным циклом объектов AD.

Create. Метод Create применяется для создания новых объектов AD (например, User, OU, Group, Com-puter, Site). Код, показанный меткой A в Листинге 2, осуществляет привязку к соответствующему контейнеру и вызывает Create для создания нового объекта. Некоторых общих ошибок при использовании метода Create можно избежать, если не пропускать установку новых обязательных свойств объекта перед вызовом SetInfo или не забывать указывать «key=» как часть относительного имени RDN объекта. Можно использовать сценарий, подобный приведенному в Листинге 1, для определения обязательных (must-Containe) и дополнительных (may-Containe) свойств объекта.

Система сама присваивает значения большинству обязательных свойств (например, objectClass, objectCategory, objectSid, ntSecurityDescriptor, instanceType). Из семи обязательных свойств пользователя, которые показаны на Экране 1, приходится иметь дело только с cn и sAMAccountName. Установка свойства cn происходит как часть вызова метода Create, а Put используется для установки sAMAc-countName. Обычно обязательные свойства, которые обрабатывает система, не инициализируются.

Delete. Метод Delete несложен (см Листинг 2 метка D). Сначала происходит привязка к родительскому контейнеру объекта, который нужно удалить. Далее вызывается метод Delete контейнера и идентифицируется целевой дочерний объект для удаления. Как и в случае с методом Create, требуется указание соответствующего «key=», как части имени RDN целевого объекта.

Удаление объекта — действие необратимое. Но Delete не может удалить контейнеры, в которых хранятся объекты. Сначала необходимо рекурсивно удалить все дочерние объекты, затем, если требуется использовать метод Delete для удаления целого сегмента дерева каталога, также рекурсивно удалить вложенные контейнерные объекты. Если очевидно, что нужно отрезать целую ветвь дерева каталога, используется метод DeleteObject, предоставляемый интерфейсом IADs-De-leteOps, который обеспечивает удаление контейнера и всех его объектов.

GetObject. Метод GetObject из IADs-Container подобен функции GetObject из VBScript тем, что GetObject из IADs-Container создает ссылку на объект программирования ADSI. Различие между ними заключается в том, что метод GetObject из IADsContainer позволяет привязываться только к дочерним объектам в контейнере ADSI. Это объясняет, почему сигнатуры методов (т. е. списки параметров) двух методов с одним и тем же названием различны. Функции GetObject из VBScript предоставляется ADsPath, в то время как методу GetObject из IADsContainer требуется имя класса и RDN целевого объекта в текущем контейнере. Последний метод обеспечивает легкость просмотра контейнера и привязки к каждому дочернему объекту из списка.

MoveHere. MoveHere используется для переноса объекта из одного контейнера в другой, что происходит при перемещении между доменами или переименовании объекта. Из рассматриваемых четырех методов пользователи чаще всего совершают ошибки с MoveHere. Ошибкой является непонимание того, что MoveHere — это механизм, который используется для переименования объектов AD. Нельзя изменить обязательное свойство cn объекта или эквивалентное ему (например, ou в случае OU), чтобы переименовать объект AD, как это обычно делается при изменении других атрибутов. Нужно использовать MoveHere. Другая общая ошибка — это попытка создать ADsPath для перемещения или переименования объекта. Для решения этой задачи лучше использовать свойство IADs::ADs Path или переменные, пример показан в Листинге 2, метка С.

При использовании MoveHere всегда происходит привязка к целевому контейнеру, который может быть текущим родительским контейнером объекта. При перемещении объекта происходит привязка к целевому контейнеру; при переименовании объекта — к родительскому контейнеру объекта. Если объект и перемещается и переименовывается, осуществляется привязка к целевому контейнеру. После получения интерфейса целевого или родительского контейнера можно вызывать MoveHere. Первый параметр MoveHere — ADsPath объекта для перемещения или переименования — всегда один и тот же, он не зависит от типа операции. Второй параметр — это одно из двух возможных значений. При переименовании объекта вторым параметром является новое имя RDN объекта. Если объект не переименовывается, то вторым параметром будет текущее RDN объекта.

Дополнительные интерфейсы в ADSI

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

  • методы SetPassword и ChangePas-sword, которые интерфейс IADsUser предоставляет для управления паролями пользователей, как показано в Листинге 2, метка А;
  • метод Group, который интерфейс IADsUser предоставляет для перечисления групп, принадлежащих пользователю;
  • методы Members, IsMember, Add и Remove, которые предоставляет интерфейс IADsGroup для управления членством в группах;
  • интерфейсы системы защиты IADs-SecurityDescriptor, IADsAccessCont-rolList и IADsAccessControlEntry для управления безопасностью объектов AD.

Чтобы понять, какой интерфейс, отличный от IADs или IADsContainer, необходимо применить, нужно сделать следующее.

  1. Идентифицировать тип объекта, с которым вы работаете (например, объекты Computer, Group, User).
  2. Обратиться к документации по ADSI и выяснить, существует ли интерфейс для такого типа объекта. Названия интерфейсов начинаются с IADs, затем идет имя типа объекта (например, IADsComputer, IADsGro-up, IADsOU, IADsUser). Найти полный список интерфейсов можно в Microsoft Developer Network (MSDN) Online Library.
  3. Если интерфейс в ADSI существует, нужно оценить те свойства и методы, которые он предоставляет, чтобы найти подходящий метод или свойство.

Актуализируем учетные данные Active Directory

Многие помнят то чувство, когда компания расширяется до тех размеров, когда рабочих групп недостаточно, и поднимается первый домен Active Directory: «О, уж теперь-то все будет как следует!» Ан нет, домен потихонечку разрастается, создаются новые учетки, блокируются старые, добавляются, удаляются компьютеры, девушки выходят замуж, меняют фамилии и, в конце концов, база данных службы каталогов выглядит, как полный швах. В этом топике мы наладим связь между базой Active Directory и кадровой системой предприятия, а также создадим механизм для поддержания данных сотрудников в AD в актуальном состоянии.

Первым делом, мы опишем требования, которые мы должны предъявить к учетным записям сотрудников. А эти требования мы постараемся прикинуть, исходя из потребностей пользователя. Не секрет, что многие корпоративные системы, использующие аутентификацию через Active Directory, для отображения и в своих админках, и просто в ходе работы зачастую используют разнообразные поля учетных записей AD: это и Sharepoint, и Citrix, и многие-многие другие. В качестве примера такой системы я возьму известный всем MS Outlook, да не полностью, а лишь его адресную книгу, которая черпает свои данные напрямую из Active Directory.

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

  • Фамилия Имя Отчество
  • Должность
  • Организация
  • Подразделение
  • Почтовый индекс
  • Тип занятости

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

Механизм

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

Сведения о пользователе Active Directory не исчерпываются сведениями, которые можно увидеть в оснастке Active Directory Users and Computers (устоявшееся сокращение ADUC), причем очень далеко не исчерпываются. На самом деле объект пользователя имеет триллион атрибутов, и эти атрибуты даже могут быть добавлены администратором схемы. Например, есть такой атрибут, как carLicense, содержащий информацию о водительском удостоверении, или drink, характеризующий любимый напиток пользователя. В общем, Microsoft в этом смысле предусмотрела многое.

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

Также для заполнения полей пользователя мы будем использовать атрибуты:

  • displayName и CN для хранения ФИО
  • department для хранения подразделения
  • company для хранения организации
  • title для хранения должности
  • employeeType для хранения типа сотрудника
  • postalCode для хранения индекса


Педанты могут, конечно, дополнительно использовать givenName, initials и sn для хранения имени, инициалов и фамилии соответственно, но я думаю, что это уже тонкости.

Итак, наше приложение будет работать таким образом:

  1. Перечислять учетные записи, у которых заполнен employeeID
  2. Искать в кадровой системе для каждой учетной записи изменившиеся данные
  3. Обновлять данные в Active Directory
  4. Протоколировать изменения в файле

К делу

Первым делом следует проставить employeeID, который у нас представляет табельный номер, всем пользователям. Если пользователей мало, то сделать это проще всего через ADSI Edit, если их чуть больше, то можно прикрутить скрипт для прописывания, например вот так. А если пользователей много, расстановку идентификаторов необходимо делегировать, хочется приятный интерфейс и используются дополнительные фенечки, то можно создать вот такую дополнительную вкладку в ADUC:

впрочем, создание такой вкладки это само по себе тема для отдельного топика.

Второе тонкое место в том, что иногда случается так, что для некоторых людей менять следует только некоторые атрибуты. Есть, например, у нас сотрудник, назовем его Кудрымунбеков Садруддин Фатхулларович, но все его называют просто Сан Саныч. А есть генеральный директор, должность которого в кадрах записана не иначе, как Генеральный Директор Открытого Акционерного Общества Дальней Космической Связи «Рога И Копыта», которого в AD лучше бы просто оставить точно со связью, но точно без рогов и копыт. Таким образом, мы видим необходимость в закладывании в логику работы нашего приложения некоторых исключений, а хранить эти исключения мы будем там же, в Active Directory в атрибуте flags. Этот атрибут имеет величину в четыре байта, а значит, устанавливая тот или иной бит в то или иное значение, мы сможем при необходимости запомнить аж 32 исключения. Впрочем, использовать мы все равно будем только шесть.

Переходим к реализации на powershell:

Создадим тестовую среду, абсолютно произвольно присвоим имена учетным записям:

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

Как видим, после выполнения, мы получили хорошие читаемые имена, отличные должности и великолепные наименования компаний:

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

upd Подправил маленькую ошибочку, перенес обнуление флажков во внутрь цикла

Запрос свойства объекта Active Directory из ASP.NET приложение возвращает старые результаты

В течение нескольких дней я пытался получить некоторые пользовательские проверки подлинности на основе Active Directory для работы. Все это работает в теории, но, очевидно, моя теория неверна. Пользователи, вошедшие в домен, пишут строковый маркер (например, PIN-код) в свое собственное поле свойства в Active Directory (не имеет значения, какое именно, но для этого я использовал primaryInternationISDNNumber) при входе в ASP.NET приложение этот PIN-код всегда генерируется и пишется программным способом.

Чтобы объяснить это грубо, веб-браузер загружает Java-апплет, который затем загружает собственную DLL, написанную на C++, которая генерирует и записывает PIN-код в поле Active Directory текущего пользователя. Эта библиотека DLL возвращает сгенерированный PIN-код апплету, который затем передает его браузеру, который выполняет вызов AJAX с данными, возвращенными для инициализации аутентификации. Приложение, получившее доступ к объявлению, считывает значение этого поля для подключающегося объекта пользователя и проверяет, совпадает ли оно с указанным пользователем. Если пин-коды совпадают, пользователь успешно аутентифицируется.

Это пример кода ASP.NET приложение, используемое для чтения объявления:

Это работает хорошо, часто. Но часто это неприемлемо. Он должен всегда работать.

Беда в том, что ASP.NET приложение иногда получает значение, которое ранее было в этом поле, а не фактическое значение. Как будто есть какое-то кэширование. Я пытался добавить de.UsePropertyCache = false , но это дало те же результаты.

Я создал два консольных приложения Win32 для тестирования. Один пишет ПИН-код, другой читает ПИН-код. Они всегда работают отлично!

Я подумал, это должно быть какая-то проблема с пулом приложений IIS. Таким образом, я создал собственную DLL, которая загружается ASP.NET приложение, использующее вызов платформы. Эта библиотека DLL создает новый поток, вызывает CoInitialize и считывает PIN-код. Это код:

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

Так что теперь я думал, Хорошо, я не смог избежать пула приложений IIS и так как это должно быть проблемой с пулом приложений IIS, я создам собственное приложение Windows, которое я выполню с помощью процесса.Метод Start. Я верну свой PIN-код с помощью кода выхода процесса (так как это целое число в любом случае). Приложение использует аналогичный код C++, как DLL выше.

Поэтому я запускаю приложение, жду его завершения, читаю код выхода. Возвращает плохое значение!

Но хорошо, я бы сказал, что процесс запускается с использованием текущих учетных данных пользователя, который снова является пулом приложений IIS. Поэтому я запускаю приложение под разными учетными данными. И знаешь что?…. он возвращает старое значение снова (. ).

А я думал, что Ява-это ад… Кто-нибудь имеет представление о том, что здесь происходит?

1 ответ

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

Поскольку это может оказаться полезным для кого-то, я сделал это с помощью следующего кода.

Использование службы каталогов Active Directory Service Interface (ADSI)

Использование службы каталогов Active Directory Service Interface (ADSI)

Обсудим сначала термины «каталог» и «служба каталога», которые будут использоваться в этом разделе. Под каталогом в общем смысле этого слова подразумевается источник информации, в котором хранятся данные о некоторых объектах. Например, в телефонном каталоге хранятся сведения об абонентах телефонной сети, в библиотечном каталоге — данные о книгах, в каталоге файловой системы — информация о находящихся в нем файлах.

Что касается компьютерных сетей (локальных или глобальных), здесь также уместно говорить о каталогах, содержащих объекты разных типов: зарегистрированные пользователи, доступные сетевые принтеры и очереди печати и т.д. Для пользователей сети важно уметь находить и использовать такие объекты (а их в крупной сети может быть огромное количество), администраторы же сети должны поддерживать эти объекты в работоспособном состоянии. Под службой каталога (directory service) понимается та часть распределенной компьютерной системы (компьютерной сети), которая предоставляет средства для поиска и использования имеющихся сетевых ресурсов. Другими словами, служба каталога — это единое образование, объединяющее данные об объектах сети и совокупность служб, осуществляющих манипуляцию этими данными.

В гетерогенной (неоднородной) компьютерной сети могут одновременно функционировать несколько различных служб каталогов, например, NetWare Bindery для Novell Netware 3.x, NDS для Novell NetWare 4.x/5.x, Windows Directory Service для Windows NT 4.0 или Active Directory для Windows 2000. Естественно, для прямого доступа к разным службам каталогов приходится использовать разные инструментальные средства, что усложняет процесс администрирования сети в целом. Для решения этой проблемы можно применить технологию ADSI — Active Directory Service Interface фирмы Microsoft, которая предоставляет набор объектов ActiveX, обеспечивающих единообразный, не зависящий от конкретного сетевого протокола, доступ к функциям различных каталогов.

Объекты ADSI включены в операционные системы Windows ХР/2000, а также могут быть установлены в более ранних версиях, для чего их нужно скачать с сервера Microsoft (http://www.microsoft.com/NTWorkstation/downloads/Other/ADSI25.asp).

Для того чтобы находить объекты в каталоге по их именам, необходимо определить для этого каталога пространство имен (namespace). Скажем, файлы на жестком диске находятся в пространстве имен файловой системы. Уникальное имя файла определяется расположением этого файла в пространстве имен, например:

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

? «LDAP://» — для службы каталогов, созданной на основе протокола LDAP (Lightweight Directory Access Protocol), в том числе для Active Directory в Windows 2000;

? «WinNT://» — для службы каталогов в сети Windows NT 4.0 или на локальной рабочей станции Windows ХР/2000;

? «NDS://» — для службы каталогов NetWare NDS (Novell Directory Service);


? «NWCOMPAT://» — для службы каталогов NetWare Bindery.

Вторая часть строки ADsPath определяет расположение объекта в конкретном каталоге. Приведем несколько примеров полных строк ADsPath:

В этом разделе мы подробно рассмотрим несколько простых сценариев, использующих объекты ADSI для автоматизации некоторых распространенных задач администрирования на отдельной рабочей станции с операционной системой Windows ХР; поняв принцип их работы, вы без труда сможете написать аналогичные сценарии для локальной сети, которая функционирует под управлением Active Directory или контроллера домена с Windows NT 4.0 (множество подобных примеров приведено в [18]).

Напомним, что на выделенном компьютере с Windows ХР имеется база данных, содержащая информацию обо всех локальных пользователях этого компьютера. Пользователи компьютера определяются своими атрибутами (имя регистрации, полное имя, пароль и т.п.) и могут объединяться в группы. Ниже мы приведем примеры сценариев WSH, с помощью которых можно:

? получить список имеющихся в локальной сети доменов;

? получить список всех групп, определенных на компьютере;

? добавить и удалить пользователя компьютера;

? определить всех пользователей заданной группы или все группы, в которые входит определенный пользователь;

? просмотреть атрибуты пользователя и изменить его пароль.

Для получения более полной информации по технологии ADSI следует обратиться к документации Microsoft или специальной литературе (см. введение).

Архитектура Membership API

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

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

Для преодоления этой проблемы в ASP.NET 2.0 было добавлено средство под названием , которое в ASP.NET 4, по сути, осталось без изменений. Интерфейс Membership API — это платформа, построенная на основе существующей инфраструктуры аутентификации с помощью форм. При использовании Membership API даже не понадобится реализовывать страницы входа или хранилища удостоверений.

Платформа Membership API предоставляет полный набор готовых функций управления пользователями:

Возможность создавать и удалять пользователей — как программно, так и с помощью веб-утилиты конфигурирования ASP.NET.

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

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

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

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

Уровень абстракции, который обеспечивает независимость приложений от конкретного лежащего в основе хранилища данных через классы поставщиков членства. Любая функциональность, перечисленная выше, работает совершенно независимо от конкретного используемого хранилища данных, и одни хранилища данных можно заменять на другие — совершенно без необходимости в какой-либо модификации приложений. По умолчанию Membership API полагается на базу данных SQL Server Express для хранения информации о пользователях и ролях.

На рисунке ниже показана фундаментальная архитектура Membership API, которая состоит из поставщиков, собственно API-интерфейса и элементов управления для создания соответствующих пользовательских интерфейсов:

Платформа Membership API спроектирована для полностью независимой работы от используемого им хранилища данных. Вы, как разработчик приложения, в основном имеете дело с элементами управления, предоставленными ASP.NET, а также классом Membership. Класс Membership предлагает набор методов для программного доступа к пользователям и ролям, находящимся в хранилище. Методы работают с поставщиком членства. Этот поставщик реализует доступ к лежащему в основе хранилищу данных. Все классы, относящиеся к Membership API, размещены в пространстве имен System.Web.Security. Их список с краткими описаниями приведен в таблице ниже:

Классы Membership API

Класс Membership — центральная точка взаимодействия с Membership API. Он предоставляет ряд методов для управления пользователями, их проверки и переустановки паролей

Исключение, генерируемое в случае возникновения ошибки при попытке создания пользователя классом Membership

Представляет отдельного пользователя, записанного в хранилище данных Membership API. Этот объект содержит всю информацию о пользователе и возвращается несколькими методами класса Membership, например, GetUser()

Коллекция пользователей Membership. Например, метод GetUsers() класса Membership возвращает экземпляр этой коллекции

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

Коллекций доступных поставщиков членства на машине для данного веб-приложения

Реализаций класса MembershipProvider, работающая с базами данных SQL Server

Реализация класса MembershipProvider, работающая со службой Active Directory


Класс, который наследует всю функциональность MembershipUser и добавляет некоторые специфичные для Active Directory свойства

ASP.NET включает готовых поставщиков членства для SQL Server и Active Directory (что позволяет создавать собственные страницы входа для пользователей, хранящихся в Active Directory). Но основная идея поставщиков состоит в том, что они предоставляют возможность полного расширения инфраструктуры. Таким образом, можно реализовать собственный поставщик членства, который будет представлять собой класс, унаследованный от System.Web.Security.MembershipProvider. Поставщик членства конфигурируется, прежде всего, в файле web.config, в новом разделе .

Хотя Membership API и поддерживает службу Active Directory в качестве одного из поставщиков, все же существует большая разница между использованием Windows-аутентификации и Membership API для аутентификации пользователей веб-приложений.

В случае настройки приложения на применение интерфейса Membership API, который в действительности основан на аутентификации с помощью форм, удостоверения пересылаются по сети в виде простого текста (если только не используется SSL) и, как было показано ранее, для аутентификации применяются так называемые билеты аутентификации. С другой стороны, при настройке Windows-аутентификации пользователь аутентифицируется либо через NTLM, либо через Kerberos (в случае доменов Windows Server). Оба метода намного более безопасны, поскольку удостоверения никогда не пересылаются через сеть.

В приведенной таблице присутствует выделенный класс по имени ActiveDirectoryMembershipUser, который применяется в сочетании с ActiveDirectoryMembershipProvider. Однако класса по имени SqlMembershipProviderUser вы не найдете. Это значит, что класс SqlMembershipProviderUser для представления пользователей использует базовый класс MembershipUser. Причина в том, что версия поставщика Active Directory расширяет класс MembershipUser множеством специфичных для Active Directory атрибутов, доступных пользователям Active Directory. Таких специфичных свойств у SqlMembershipProviderUser не предусмотрено, поэтому создание отдельного класса SqlMembershipProviderUser просто не понадобилось.

Интерфейс Membership API служит только для управления и аутентификации пользователей. Он не реализует никакой функциональности авторизации и не предоставляет функциональности управления пользовательскими ролями. Для этой цели предназначен интерфейс Roles API рассматриваемый позже.

Asp свойства объектов adsi

Далее я опишу подробно все свои действия:
Сначала импортирую ActiveDs_TLB.pas: Project -> Import Type Library. -> Active DS Type Library (Version 1.0) -> Create unit

Потом в новом проекте:
1) Объявляю функцию: function ADsGetObject(PathName: WideString; const riid: TGUID; out ppObject): HRESULT; stdcall; external «activeds.dll»;
2) Прописываю в uses ActiveDs_TLB и бросаю TButton и TMemo.
3) На событии кнопки OnClick пишу:
procedure TForm1.Button1Click(Sender: TObject);
var
PropList: IADsPropertyList;
PropEntry: IADsPropertyEntry;
i, Count: Integer;
AdsUser: IAdsUser;
begin
ADsGetObject(«WinNT://MyDomainName/MyUserName», IID_IADsUser, AdsUser); // здесь нужно прописать действительные имя домена и пользователя
PropList:=AdsUser as IADsPropertyList;
AdsUser.GetInfo;
Count:=PropList.PropertyCount;

Memo1.Lines.Clear;
for i:=1 to Count do
begin
PropEntry:=IDispatch(PropList.Next) as IADsPropertyEntry;
Memo1.Lines.Add(PropEntry.Name+#9+VarToStr(AdsUser.Get(PropEntry.Name)));
end;
end;

Но при этом получаю почему то не все свойства. Отсутствуют например «TelephoneNumber», «OfficeLocations», «EmailAddress» и др., хотя эти поля заполнены (в чём можно убедиться если зайти в консоль Active Directory Users and Computers)
Если же попытаться получить значение этих свойств (например так: ShowMessage(AdsUser.Get(«EmailAddress»)) или так: ShowMessage(AdsUser.EmailAddress)), то получаю странное сообщение об ошибке: «Свойства службы каталогов не могут быть найдены в кэше.»

Странно, что нет ни одного ответа.
Здаётся мне, что эта ошибка из-за того, что просто у «WinNT» нет таких свойств и нужно использовать чтото другое, например ADsGetObject(«LDAP://. , но у этого LDAP синтаксис жуткий — что я не подсовывал — не работает. :( Уже весь инет пролазил, перепробовал все возможные варианты параметров, никак не пойму в каком же виде ему нужно подсовывать имя домена (и другие параметры). :(

У «WinNT» нет АД и LDAP


> Anatoly Podgoretsky © (02.11.09 12:23) [2]
> У «WinNT» нет АД и LDAP

Я имел ввиду провайдера. Тоесть, чтобы получить свойства которые не доступны через провайдера «WinNT» (который я вызываю так: ADsGetObject(«WinNT://MyDomainName/MyUserName» ) нужно видимо обращаться к провайдеру «LDAP» так: ADsGetObject(«LDAP://далее_жутко_непонятные_параметры/которые_у_меня_не_хотят_работать . Или иначе почему я не могу прочитать некоторые свойства, которые видно в консоли?
Как же получить параметры через «LDAP»? У меня даже не хочет работать объект «NameTranslate» который умеет переводить имена домена из формата «WinNT://» в формат «LDAP://». :(
Блин засада. :(


> clickmaker © (02.11.09 12:54) [4]
> LDAP://servername/CN=username,CN=users
> как-то так

Вызываю: ADsGetObject(«LDAP://S-HELIOS01/CN=ganitskiy-aa,CN=users», IID_IADsUser, AdsUser) получаю ошибку $8007203A.


> clickmaker © (02.11.09 14:02) [6]
> http://www.google.ru/#hl=ru&newwindow=1&q=LDAP+0x8007203A&lr=&aq=f&oq=&fp=be4313e544833b95

Это я уже смотрел (говорю, что уже весь интернет облазил) — только пользы никакой.
Смысл в том, что в консоли видно много дополнительных свойств, но я не могу их программно получить ни через ADsGetObject(«WinNT:// ни через ADsGetObject(«LDAP:// .
Вот снимок экрана: http://s42.radikal.ru/i095/0911/74/99d1422793f6.jpg
Видно, что в консоли видно и номер телефона и e-mail и даже номер кабинета, я же не могу получить эти параметры хоть тресни. :(

Вот нашёл на MSDN: http://msdn.microsoft.com/en-us/library/aa746507(VS.85).aspx
Перечисляются свойства которые не поддерживает провайдер «WinNT://» в интерфейсе IADsUser , но при этом не пишут, как же эти свойства получить. :(

У провайдера WinNT другой набор свойств.
iadsnametrnslate (гугли) поможет сконвертировать domain\userid имя к формату LDAP, а там уже вытаскивай свойства, которые тебе нужны.

заметки для себя по IT

понедельник, 24 марта 2014 г.

Атрибуты AD

Изменение атрибутов на вкладках свойств учетной записи пользователя

В большинстве случаев, дополнительные свойства пользовательских учетных записей конфигурируются при помощи оснастки «Active Directory – пользователи и компьютеры». Для изменения объекта пользователя откройте диалоговое окно свойств учетной записи. В данном диалоговом окне, атрибуты объекта пользователя распределяются по нескольким обширным категориям на различных вкладках. Большинство атрибутов объекта пользователя вполне понятны. Рассмотрим шесть основных вкладок, которые в первую очередь подлежат изменениям с соответствующими атрибутами:

    Вкладка «Общие». Данная вкладка содержит свойство имени, которое настраивается при создании объекта пользователя, а также его основное описание и контактные данные. На данной вкладке вы моете отконфигурировать девять атрибутов объекта пользователя, а именно: имя пользователя (атрибут givenName), фамилию (атрибут sn), инициалы (атрибут initials), выводимое имя (атрибут displayName), описание объекта (атрибут description), номер комнаты (атрибут physicalDeliveryOfficeName), контактный номер телефона (атрибут telephoneNumber), адрес электронной почты (атрибут mail), а также адрес веб-сайта пользователя (атрибут wWWHomePage). Кроме того, на данной вкладке вы можете указать дополнительный телефонный номер, который указывается атрибутом otherTelephone. Также вы можете указать дополнительный веб-сайт, определяемый атрибутом url. Если вы добавите более двух номеров телефона или веб-сайтов, они будут записываться в последние атрибуты через точку с запятой;

Рис. 1. Вкладка «Общие» диалогового окна свойств объекта пользователя

Вкладка «Адрес». На этой вкладке вы можете указать контактные сведения о месте проживания вашего сотрудника. Для редактирования доступны шесть тестовых полей и, соответственно, шесть атрибутов. Вы можете изменять следующие параметры: улицу, на которой живет ваш сотрудник (атрибут streetAddress), номер дома, который можно указать в текстовом поле «Почтовый ящик» (атрибут postOfficeBox), город, в котором живет ваш пользователь (атрибут l). Помимо этого вы можете указать область или край (атрибут st), почтовый индекс (атрибут postalCode), страна (за этот параметр отвечают три атрибута, а именно c – буквенное сокращение страны, co – название страны, countryCode – код страны);

Рис. 2. Вкладка «Адрес» диалогового окна свойств объекта пользователя

Вкладка «Учетная запись». Для администрирования, данная вкладка является самой важной, так как именно здесь вы можете настроить имена входа, пароль и параметры учетной записи. Здесь вы можете задать следующие атрибуты: имя входа пользователя (атрибут userPrincipalName), имя входа пользователя пред-Windows 2000 (атрибут sAMAccountName, о котором мы говорили ранее), время входа пользователя (определяется атрибутом logonHours в шестнадцатеричном формате). Также вы можете указать компьютеры, на которые пользователь может выполнять вход (атрибут userWorkstations). Если учетная запись пользователя заблокирована, то вы можете ее разблокировать, установив соответствующий флажок. Помимо этого, вы можете добавить следующие параметры учетной записи: требовать смены пароля при следующем входе в систему, запрещение смены пароля пользователем, установка неограниченного срока действия пароля и прочее. Также вы можете указать срок действия учетной записи (атрибут accountExpires);

Рис. 3. Вкладка «Учетная запись» диалогового окна свойств объекта пользователя

Вкладка «Профиль». На этой вкладке вы можете настроить путь к профилю пользователя (атрибут profilePath), сценарий входа (атрибут scripPath), а также домашнюю папку указав локальный путь (атрибут homeDirectory) или сетевой диск (атрибут homeDrive);

Рис. 4. Вкладка «Профиль» диалогового окна свойств объекта пользователя

Вкладка «Телефоны». Текущая вкладка предназначена для заполнения таких контактных сведений о пользователе, как номера его телефонов. На этой вкладке доступно для редактирования шесть параметров, а именно: домашний, в котором вы можете указать домашний номер телефона пользователя (атрибут homePhone), номер пейджера (атрибут pager), номер мобильного телефона (атрибут mobile). Также вы можете указать номер факса (атрибут facsimileTelephoneNumber) или номер IP-телефона (атрибут ipPhone). Помимо этого, на данной вкладке размещено текстовое поле «Заметки», сопоставленное с атрибутом info, которое используется для занесения дополнительной информации. Также вы можете добавить дополнительные номера телефонов (например, за дополнительный номер мобильного телефона отвечает атрибут otherMobile, за дополнительный номер пейджера – otherPager, за дополнительные номера домашнего телефона, факса и IP-телефона, соответственно, otherHomePhone, otherFacsimileTelephoneNuber и otherIpPhone);

Рис. 5. Вкладка «Телефон» диалогового окна свойств объекта пользователя

Вкладка «Организация». Эта вкладка содержит такую информацию, которая относится к должности, отделу пользователя и т.п. Для изменения на этой вкладке доступны пять следующих опций: должность данного сотрудника (атрибут title), название отдела (атрибут department), наименование организации (атрибут company). Помимо этого на данной вкладке вы можете указать непосредственного начальника для текущего пользователя (атрибут manager), а также просмотреть всех прямых подчиненных в поле «Прямые подчиненные»;

Рис. 6. Вкладка «Организация» диалогового окна свойств объекта пользователя

Просмотр и изменение атрибутов, не отображаемых в свойствах объектов пользователей

Как вы заметили, при помощи графического интерфейса, а именно диалогового окна свойств объекта пользователя оснастки «Active Directory – пользователи и компьютеры» можно отредактировать большинство атрибутов пользователя. Но некоторые атрибуты при помощи основного набора вкладок свойств пользователя у вас настроить не получится, так как они не отображены в графическом интерфейсе. У вас может возникнуть вопрос: для чего же тогда нужны такие атрибуты, которые невозможно так просто настроить? Такие атрибуты могут использоваться различными приложениями для хранения дополнительных данных о пользователях, причем, некоторые из этих параметров могут для вашей организации оказаться очень полезными. Для того чтобы просмотреть все атрибуты, которые принадлежат конкретному пользователю, вам нужно в диалоговом окне свойств текущего пользователя перейти на вкладку «Редактор атрибутов». По умолчанию данная вкладка не отображена и для того чтобы она отобразилась, вам нужно в меню «Вид» самой оснастки установить флажок на опции «Дополнительные компоненты». Редактор атрибутов отображает все системные атрибуты для текущего объекта. Помимо вкладки свойств объекта пользователя, любые атрибуты вы можете просмотреть и изменить при помощи таких инструментов, как оснастки ADSIEdit.msc и утилиты Ldp.exe. Например, если вам нужно знать, когда пользователь в последний раз выполнял вход, который не отображается на основных вкладках диалогового окна свойств пользователя. Для этого вы можете перейти на вкладку «Редактор атрибутов», найти там атрибут lastLogonTimestamp, где и будет указано последнее выполнение входа в сеть (например, если пользователь вошел в систему в 11:40:26 18 декабря 2011 года, значение будет равняться «129371388262579662»). Для того чтобы изменить выбранный вами атрибут, нажмите на кнопку «Изменить» и в отобразившемся диалоговом окне внесите изменения в выбранный вами атрибут. С помощью кнопки «Фильтр» вы можете отфильтровать вывод системных атрибутов в таком виде, как вам будет удобнее с ними работать. Вы можете просмотреть обязательные атрибуты, установив соответствующий флажок, дополнительные атрибуты, только те атрибуты, в которых указаны значения, а также атрибуты, доступные для записи. Кроме этого вы можете просматривать обратные ссылки и построенные атрибуты.

Увеличить рисунок
Рис. 7. Вкладка «Редактор атрибутов» диалогового окна свойств объекта пользователя
Обратными ссылками называются атрибуты, которые образуются в результате ссылок на объект из других объектов. Рассмотри простой пример: при добавлении пользователя в группу изменяется многозначный атрибут группы member, в который добавляется отличительное имя пользователя, называемое прямой ссылкой. В свою очередь, в объекте пользователя, при ссылке на пользователя атрибутом member группы, атрибут memberOf обновляется автоматически.
Построенные атрибуты формируются в результате вычисления в Active Directory. Некоторые атрибуты не хранятся как часть объекта пользователя и не поддерживаются динамически, а высчитываются только при необходимости. Например, существует атрибут tokenGroups, представляющий собой список SID всех групп, к которым принадлежит пользователь, включая вложенные группы. В этом случае, Active Directory должна просчитать действующее членство пользователя в группах, что повлечет за собой выполнение нескольких циклов. Так как для получения построенных атрибутов необходима дополнительная обработка, по умолчанию на вкладке «Редактор атрибутов» такие атрибуты не отображаются.
В том случае, если вам нужно отредактировать одинаковые атрибуты для большого количества объектов, вы можете использовать различные сценарии с использованием утилит командной строки или командлетов Windows PowerShell. Для изменения атрибутов, которые отображены на вкладках свойств объектов пользователей оснастки «Active Directory – пользователи и компьютеры» и могут быть общими для нескольких объектов одновременно, вы можете выделить объекты одного класса (например, пользователей) при помощи клавиши Ctrl, нажать на них правой кнопкой мыши и из контекстного меню выбрать опцию «Свойства». В данном случае, вы можете редактировать лишь определенные атрибуты на пяти вкладках: «Общие», «Учетная запись», «Адрес», «Профиль» и «Организация». Например, вы можете изменять те же атрибуты на вкладке «Организация» для нескольких пользователей, как и для конкретного пользователя, как показано на следующей иллюстрации:

Рис. 8. Изменение атрибутов для нескольких пользователей одновременно

Илон Маск рекомендует:  Что такое код imap_unsubscribe
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Компонент Описание
Membership
MembershipCreateUserException
MembershipUser
MembershipUserCollection
MembershipProvider
MembershipProviderCollection
SqlMembershipProvider
ActiveDirectoryMembershipProvider
ActiveDirectoryMembershipUser