[gl00mie]

Цитата:

Сообщение от Lemming

служба каталогов Active Directory работает на базе ОС Windows 2000. На форме Users есть кнопочка импорт, она позволяет импортировать пользователей из списка пользователей указанного домена Active Directory. Так вот, при использовании этого мастера, в списке пользователей, я вижу только несколько служб, а так же пользователей, которые так или иначе занимаются администрированием нашего домена.

Очень интересно было бы еще узнать, на чем крутится сам AOS - Win2000 или Win2003.

Цитата:

Сообщение от KiselevSA

А какому контейнеру в AD принадлежат эти пользователи? Случаем не базовому контейнеру Users? Если так, то необходимо проверять методы в классе импорта. Увы, у меня AX4 нет.

Дело вовсе не в контейнерах AD, поскольку класс xAxaptaUserManager, используемый в мастере добавления пользователей, делает рекурсивную выборку объектов класса user категории person по всему домену, возвращаемому rootDSE.defaultNamingContext.
Выборку эту можно смоделировать, например, с помощью VBScript и ADSI. Во вложении - два скрипта, которые я использовал для экспериментов. Рабочий скрипт (adsi-list-user-account-groups.vbs) производит выборку, аналогичную той, что делает xAxaptaUserManager, и пишет краткую информацию о выбранных пользователях в текстовый файл; установочный скрипт (adsi-list-user-account-install.vbs) используется для установки рабочего скрипта в качестве сервиса. Сервис нужен для запуска скрипта под аккаунтом LocalSystem (при установке на w2k) либо Network Service (на wxp/w2k3), т.е. теми, которые использует по умолчанию сервис AOS.
Особенности установки сервиса:

• Для установки и запуска скрипта как сервиса необходимо наличие в системном каталоге виндов утилиты srvany.exe. Если ее нет, то можно взять из Windows Server 2003 Resource Kit;
• При установке рабочий скрипт копируется из каталога, откуда запускается установочный скрипт, в каталог %windir%\temp. Необходимо иметь соотв. права на создание нового сервиса и на запись в указанный каталог;
• Сервис будет писать выходной файл в каталог %windir%\temp. При установке на wxp/w2k3 необходимо обеспечить для этого каталога необходимые права для NT Authority\Network Service. Мне хватало Create Files/Write Data;
• Оба скрипта используют WMI; необходимо, чтобы на компьютере, где они выполняются, была запущена служба "Windows Management Instrumentation";
• Чтобы удалить установленный сервис, достаточно запустить скрипт установки с каким-нибудь параметром, при этом скопированный в %windir%\temp рабочий скрипт также будет удален.

Собственно, сервис просто запускает cscript с указанием рабочего скрипта в качестве параметра, при этом создается выходной файл, и затем работа cscript завершается. После этого сервис (srvany) будет продолжать висеть как запущенный, хотя реально он уже никакой работы не выполняет - его можно спокойно остановить. Главное, не останавливать слишком быстро после запуска, иначе srvany прибъет порожденный процесс cscript, и в выходной файл попадут не все данные. К слову, при запуске под обычным пользователем выходной файл создается в каталоге %temp%.
В домене с несколькими сотнями пользователей, удовлетворяющими критериям выборки, создание выходного файла может занимать до 10-15 секунд, при этом если на одной машине запустить несколько экземпляров скрипта одновременно, то это время существенно возрастет.
Так вот, что, собственно получилось у меня. Я проводил тестирование на 3-х разных доменах: один с доменными контроллерами под управлением w2k, один с w2k/w2k3 доменными контроллерами, и один - только с доменными контроллерами w2k3, при этом все домены работают в windows 2000 native mode (см. kb322692). Сбор сведений производился с серверов под управлением w2k sp4 и w2k3 sp1, с правами пользователей LocalSystem, Network Service (только под w2k3), доменного администратора и простого доменного пользователя. Скажу сразу, что запускать скрипт в качестве сервиса непосредственно на доменных контроллерах бессмысленно: дело в том, что в случае DC аккаунт LocalSystem имеет полный доступ к AD, кроме того, вряд ли кто-то станет устанавливать AOS на DC. На картинке приведены результаты тестирования, цифры - количество пользователей, попавших в выборку рабочего скрипта. Разница между 21 и 22 пользователями в случае доменов w2k связана с тем, что при использовании аккаунта доменного пользователя он сам тоже попал в выборку, а и получилось на 1 объект больше, чем при использовании LocalSystem.
На какие мысли наталкивают полученные результаты? Ответ, похоже, можно найти в MSDN (раздел How Security Affects Operations in Active Directory Domain Services):

Цитата:

Active Directory uses access control to grant or deny access to objects, properties, and operations based on the identity of the user performing the access attempt. When your application binds to the directory, it binds with specific user credentials. When authenticated, these credentials determine your application's security context. Regardless of whether the credentials are those of the logged-on user, a specified user, a service account, a computer account, or an unauthenticated user (Guest/Everyone), Active Directory verifies the user's right to access an object before any operation is performed on that object.
...
Security is an implicit filter for searching, enumerating containers, or reading properties. If you do not have the necessary access rights, attempts to list objects or read properties can fail with error even thought the object or property exists. The impact of security on read operations is not necessarily manifested as an error. For example, a search operation can succeed, but the search results do not include objects or properties to which the caller does not have access.

Мой вывод такой: в доменах w2k и w2k3 на объекты AD устанавливается разный доступ по умолчанию для доменных пользователей и доменных компьютеров (в качестве которых для AD, насколько я понимаю, предстает служба, запущенная под LocalSystem на входящем в домен компьютере). В ближайшее время я постараюсь доработать тестовый скрипт сбора данных, чтобы получить подтверждение этому...