Главная Networks, Windows, Без рубрики, Новое Вопросы по Active Directory + Ответы
  • Вопросы по Active Directory + Ответы

    logo Нашел в себе силы написать ответы на вопросы. Старался как можно полнее и яснее ответить на эти вопросы. Но сами понимаете, это достаточно трудно, да и если все детально описывать, то получится очередной resource kit. Пытался больше сосредоточиться на вопросах связанных с логикой работы AD, на другие вопросы предоставил ссылки в конце статьи. Большинство решений по вопросам проверены на практике или на стендах, на другие отвечал с использованием теории или логики. Будем верить, что теория не врет. По неясным вопросам готов пояснить дополнительно в комментариях («Истина рождается в споре»).

     

    Вопросы:

    1. Какие изменения в методах репликации произошли в GC Windows Server 2003 по сравнению с GC Windows Server 2000 при изменении (добавлении, удалении) признака PAS (partial attribute set) в схеме?

    При изменении признака PAS в схеме у атрибута, GC под управлением Windows 2000 Server производил полную репликацию всех объектов, всех атрибутов (PAS) контекстов именования доменов, что способствовало увеличению репликации. В Windows Server 2003 производится репликация (а при удалении признака PAS локальное удаление) только измененного атрибута.

    2. Сколько полных реплик NC (naming context), без учета NC-приложений, находится на GC в трех доменном лесе? Частичных реплик?

    Полных три: схема, конфигурация, домен. Частичных реплик две.

    3. Возможен ли поиск по всему лесу при соединении с GC по порту 389? Почему?

    Нет, не возможен. При соединении с GC по порту 389, GC работает в контексте обычного DC и не позволяет использовать глобальный поиск, хотя может возвращать LDAP-пересылки.

    4. Требуется ли доступность GC для разрешения членства в универсальных группах в однодоменном лесу? В много доменном лесу для пользователя из домена с функциональным уровнем Windows Server 2000 Native/2003? Имеет ли значение уровень домена/леса при таких операциях? Какой?

    В однодоменном лесу не требуется. Все членство в группах находится в контексте именования домена. Уровень домена не влияет.
    В много доменном требуется. Пользователь из домена с режимом 2000 Native или выше может состоять в универсальных группах других доменов, эти группы, в свою очередь, могут использоваться для авторизации (доступа к ресурсам) в родном домене. Соответственно требуется доступность GC. Функциональный уровень домена пользователя имеет значение. Если уровень домена 2000 Mixed, то пользователь не может состоять в универсальных группах как родного, так и другого домена (при добавлении в универсальную группу в неродном домене производится проверка уровня функциональности домена добавляемого объекта), поэтому наличие GC не нужно.

    5. Сценарий доступности GC из 4, но для операций логона по UPN в однодоменном лесу? В многодоменном лесу? Имеет ли значение уровень леса/домена при таких операциях? Какой?

    Контроллер домена при обработке UPN-входов использует локальную базу для разрешения UPN-логинов. Если в собственной БД UPN-логина нет, то производится обращение к GC. Поэтому в однодоменном лесу GC не требуется, в многодоменном в определенных случаях требуется, в других нет. Уровень домена/леса не имеет значение.

    6. Для чего членство универсальных групп реплицируется на глобальный каталог?

    Смотрите ответ на 4.

    7. Членство в каких группах (доменно-локальных, глобальных, универсальных) реплицируется на GC? Членство каких групп может быть на GC?

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

    8. Как происходит разрешение UPN при логоне, если пользователь из одного леса, входит на рабочую станцию другого леса, при этом существуют доверительные отношения между доменами леса (для упрощения — двухсторонние, глобальные (domain-wide))? Как происходит вход по UPN между лесами при наличии forest-trust? А если в обоих лесах есть домены с одинаковыми именами?

    8.1. Поскольку TDO внешнего доверительного отношения не содержит список UPN-суффиксов леса доверяющего домена, то вход по UPN ограничен UPN-именами вида имяпользователя@доверяющий_домен.

    8.2. TDO для forest— trust содержит дополнительную информацию, такую как, список UPN-суффиксов, список SPN-суффиксов и т.д. Поэтому между лесами возможен вход по UPN.

    8.3. При наличии одинаковых UPN-суффиксов в двух лесах, суффиксы (одинаковые) разрешаются локально, обращение к другому лесу не происходит.

    9. Рассмотрим такую топологию: один лес, два сайта (A и B), два домена (A и B); в сайте A есть 3 контроллера домена из домена A, в сайте B есть три контроллера домена из домена B и один из домена A. Если указать один контроллер домена из сайта A в качестве предпочтительного сервера-плацдарма (Bridgehead Server, BH) и впоследствии он будет выведен из строя (недоступен), будет ли выбран другой контроллер домена из этого же сайта в качестве BH? Предположим, что в сайте A не указаны предпочтительные BH, а в сайте B в качестве предпочтительных BH указаны контроллеры домена из домена B, будет ли контроллер домена из домена A сайта B выбран в качестве сервера-плацдарма для репликации NC домена A?

    9.1. В данном случае, если в сайте А выбран в качестве BH GC, то при его недоступности другой BH выбран не будет. Если BH не GC и есть другой GC в сайте А, то 9.2.

    9.2. Да. В сайте должен быть как минимум один BH на раздел, поэтому KCC выберет контроллер домена A в сайте B в качестве BH для репликации контекста именования домена А.

    10. При обращении к GC по 3268 возможны ли операции модификации объектов? возвращение атрибутов не входящих в PAS?

    Модификация объектов не возможна. Возвращение атрибутов не из PAS, а соответственно и поиск, невозможен. Даже для объектов родного домена. Объясняется это тем, что при использовании DC по порту 3268 (3269), DC переключается в режим работы GC.

    12. В каких случаях используется UDP для LDAP?

    Используется механизмом DCLocator из Netlogon. Получается некий LDAP-пинг по UDP. Используется первый ответивший контроллер домена. Далее стандартный механизм поиска ближайшего контроллера.

    13. Для репликации каких контекстов именования можно использовать SMTP в качестве транспорта?

    Любых, кроме родного доменного контекста. Я думаю это связано с безопасностью транспортировки данных контекста домена – пароли и другие секреты.

    14. Какие контексты именования не поддерживают авторизованное восстановление?

    Авторизованное восстановление это изменение метаданных репликации атрибутов или значений (LVR). Применение команды авторизованного восстановление (ntds … auth restore) поддерживается для любых типов контекстов именования. Но не для всех объектов/атрибутов происходит изменение этих метаданных, например для схемы они вообще не изменяются, для других выборочно. Поэтому не все можно восстановить с помощью авторизованного восстановления. Дополнительная информация об авторизованном восстановлении обсуждается в 60 вопросе.

    15. Рассмотрим ситуацию: Вы добавили группу MyAccountAdmin в группу Account Operators (Уровень леса Windows Server 2003), после этого вы делегировали полномочия другому администратору на добавление членов в группу MyAccountAdmin. Все работает, человек с делегированными правами добавляет пользователей в группу MyAccountAdmin. Спустя некоторое время вам сообщают о невозможности добавления членов в группу MyAccountadmin. Что случилось?

    Скорее всего, на PDC запустился процесс SDProp. Запускается по умолчанию каждый час. Есть ряд групп, которые защищаются с использованием AdminSdHolder – Domain Admins, Enterprise Admins, Account Operators и т.д. При запуске данного процесса происходит проверка ACL всех участников безопасности (пользователей, групп, компьютеров), которые состоят в этих защищенных группах (явно или неявно) с ACL AdminSDHolder. Если ACL расходятся, то они затираются ACL AdminSDHolder (даже если ACL наследуется от родителя).

    16. Какие типы групп кэшируются в процессе Universal Group Membership Caching (UGMC)?

    Глобальные и универсальные.

    17. Для чего необходима FSMO-роль Infrastructure? желательно развернуть ответ со ссылкой на внутреннюю структуру NTDS.dit.

    FSMO-роль Infrastructure используется для обновления информации фантомных объектов. В таблицах NTDS.dit используется специальный идентификатор (DNT, 32бита) для идентификации объектов. Ссылки на объекты также реализуются с помощью DNT. Все объекты хранятся в одной таблице. Чтобы один объект мог ссылаться на другой, необходимо его присутствие в БД. Поэтому если пользователь из одного домена добавляется в группу другого домена, то необходимо создать некий фантомный объект пользователя в БД, присвоить ему DNT, а после этого ссылаться на него. Информацию об этих фантомных объектах (например, SID, имя) нужно обновлять. Infrastructure Master использует GC (поскольку на нем есть все объекты леса) для обновления информации о фантомных объектах, эти изменения затем реплицируются на другие контроллеры в домене. Если Infrastructure Master также является GC, то создавать фантомы ему не нужно, обновлять информацию о них также не нужно, поскольку все эти данные находятся локально в БД. Поэтому изменившая информация объектов других доменов при размещении Infrastructure Master на GC не будет распространена на другие контроллеры в домене. Если остальные контроллеры домена также являются GC, то ни каких проблем не возникает.

    18. Что такое объекты Foreign Security Principal?

    Эти объекты (Foreign Security Principal) создаются при добавлении участников безопасности из внешних доменов в группы и фактически являются их фантомами. В отличие от фантомов (в случае Infrastructure Master), их можно увидеть в CN=ForeignSecurityPrincipals контекста именования домена.
    Также к этому классу относятся специальные участники безопасности (располагаются также в cn=WellKnown Security Principals). Можно сказать что это системные группы с динамическим содержанием, в их числе Authenticated Users, EveryOne и т.д.

    19. Какой ролью обновляются объекты Foreign Security Principal и соответствующие ссылки на эти объекты?

    Создаются при добавлении участника безопасности из внешнего домена в группу. Далее никак не обновляются.

    20. Во время изменения схемы проверяются ли объекты других контекстов именования на валидность новой схемы?

    Нет. Схема имеет такие особенности и правила изменения, что существующие данные в других контекстах будут согласованы и не требуют проверки.

    21. Рассмотрим такую ситуацию: есть определенный в схеме атрибут, attrX, строковый, максимальная длина 25, атрибут ассоциирован с некоторым классом — classX. Предположим что существуют объекты класса classX, атрибут attrx которых заполнен до 25 символов. Что произойдет со значениями атрибута attrX существующих объектов classX, если мы изменим максимальную длину атрибута attrX до 10?

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

    22. Опишите процесс входа пользователя по UPN (однодоменный лес, много доменный лес):

    В однодоменном лесу происходит разрешение UPN-входа с использованием локальной базы DC. В много доменном происходит разрешение UPN-входа с использованием локальной базы DC, с которым компьютер установил защищенный канал. В случае неудачи, идет обращение этим DC к GC для поиска UPN-логина, затем пользователь перенаправляется на «родной» DC. Вход между лесами описан в вопросе 8.

    23. Где хранится кэш универсальных групп полученный в процессе Universal Group Membership Caching (UGMC)?

    Кэш групп хранится в атрибуте msDS-Cached-Membership, данный атрибут не реплицируется. На процесс кэширования могут влиять следующие атрибуты – msDS-Cached-Membership-Time-Stamp, msDS-Site-Affinity и некоторые значения реестра. В основном эти значения используются для определения устаревания КЭШа.

    24. Как сохранить кэш универсальных групп полученный в процессе Universal Group Membership Caching при перезапуске контроллера домена?

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

    25. Опишите процесс Universal Group Membership Caching при первом входе пользователя в сайт? Обновление кэша? Последующий вход?

    25.1. Пользователь впервые аутентифицируется на контроллере домена в сайте с включенной опцией UGMC, контроллер домена извлекает все SID пользователя, включая sidHistrory, SIDы глобальных групп и, используя эту информацию, запрашивает данные о членстве в универсальных группах с GC. Далее членство в глобальных и универсальных группах сохраняются в атрибуте msDS-Cached-Membership, в атрибут msDS-Cached-Membership-Time-Stamp записывается время обновления КЭШа, в атрибут msDS— Site— Affinity записывается сайт входа пользователя и время (на запись этого атрибута могут влиять параметры реестра SamNoGcLogonEnforceNTLMCheck и SamNoGcLogonEnforceKerberosIpCheck). Затем извлекаются доменнолокальные группы. Далее процесс входа штатный.

    25.2. Заполнение (а также обновление) КЭШа контроллерами домена в сайте основывается на атрибуте msDS-Site-Affinity. Если этот атрибут отсутствует, то два других атрибута очищаются (по 64 учетных записей за цикл). Также этот атрибут проверяется на устаревание, в случае чего очищается. Иначе происходит запрос глобальных и универсальных групп с GC и обновление атрибутов msDS-Cached-Membership и msDS-Cached-Membership-Time-Stamp. Процесс, по умолчанию, происходит для 500 учетных записей. Оставшиеся – не обновляются.

    25.3. Пользователь аутентифицируется на контроллере домена в сайте, для которого включена опция UGMC. Контроллер домена проверяет наличие значений атрибутов msDS— Cached— Membership и msDs— Chaced— Membership— Time— Stamp. Если значение кэша не просрочено (текущая_дата – msDS— Cached— Membership— Time— Stamp < значения реестра Cached Membership Staleness (minutes)), то используются универсальные и глобальные группы из атрибута msDS— Cached— Membership, если просрочен, то инициируется запрос к GC, как при первоначальном входе. Атрибут msDS-Site-Affinity является реплицируемым, поэтому обновлять его можно нечасто (сходимость данных в AD). На частоту обновления этого атрибута влияет значение реестра Cached Membership Site Stickiness (minutes). Далее процесс входа штатный.

    26. Как происходит выбор глобального каталога при Universal Group Membership Caching.

    Используется GC в соответствии со стоимостью связей сайтов, если не выбран конкретный сайт.

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

    Учетной записи администратора.

    28. Как происходит обмен кэшем Universal Group Membership Caching между контроллерами домена?

    Сам обмен КЭШем не происходит, атрибут msDS-Cached-Membership является не реплицируемым. Кэш на каждом контроллере домена (Win2k3+) в сайте с данной опцией обновляется самостоятельно, с определенным интервалом, по умолчанию 8 часов. Заполнение КЭШа основывается на атрибуте msDS-Site-Affinity пользователя, этот атрибут реплицируется, он указывает на то, в каком сайте аутентифицировался пользователь и время аутентификации.

    29. Максимальное (по умолчанию) число учетных записей для которых производится обновление кэша универсальных групп?

    500. Значение реестра Cached Membership Refresh Limit, ветка реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

    30. Может ли быть включена опция кэширования универсальных групп, если в сайте есть Windows 2000 Server контроллеры домена? Если включить опцию при этих условиях, каковы возможные последствия?

    Данная опция может быть включена, опция ни как не влияет на контроллеры домена windows 2000 Server (они ничего не знают про UGMC). В сайтах с Windows 2000 Server могут наблюдаться расхождения членства в группах. Windows 2000 использует данные о членстве пользователя в группах в соответствии со своей локальной базой, а также возможно информацию о универсальных группах с GC. Windows Server 2003 использует информацию о членстве в универсальных и глобальных группах из КЭШа и обновляет его с определенной периодичностью. Поэтому пользователь аутентифицирующийся с помощью двух разных контроллеров домена может получить различное членство в группах.

    31. Используется ли расписание репликации связи сайтов (site link) в процессе обновления кэша универсальных групп?

    Да, процесс обновления КЭШа использует расписание связи сайтов для обновления членства в глобальных и универсальных группах с выбранного GC.

    32. Для построения маркера (возврат списка групп) используются данные о членстве в группах из кэша или непосредственно из "родного" контекста именования контроллера домена?

    Для построения маркера (для заполнения PAC-поля билета TGT в случае аутентификации Kerberos) используются данные из КЭШа (UGMC). Поэтому если вы, добавите пользователя в глобальную или универсальную группу из того же домена, то эти данные запишутся в БД на DC, далее они должны будут реплицироваться на GC, а потом с этого GC будет произведено обновления КЭШа (в соответствии с периодичностью обновления и расписанием репликации). Только после этого эти данные попадут в маркер пользователя (во время входа или обновления билета- TGT).

    33. Какая служба предоставляет матрицу стоимости сайтов? Какими компонентами используется?

    Матрица стоимости сайтов предоставляется службой Intersite Messaging (IM). При уровне леса меньше Windows 2003, KCC на ISTG использует данную службу для построения топологии репликации. При более поздних уровнях леса, KCC на ISTG не использует IM. Также такие компоненты как, NetLogon, DFS, UGMC, используют матрицу стоимости сайтов генерируемую IM. При конфигурировании мостов связей сайтов, а также при отключении Bridge all site links необходимо учитывать особенности использования матрицы стоимости сайтов этими службами.

    34. Что будет если указать сайт для обновления кэша универсальных групп, в котором нет глобального каталога или на момент процесса обновления кэша глобальный каталог недоступен?

    Будет использоваться GC из ближайшего сайта, в соответствии с матрицей стоимости сайтов.

    35. Как очистить кэш UGMC?

    Для очистки КЭШа отдельной учетной записи необходимо очистить атрибуты msDS— Cached— Membership и msDS-Cached-Membership-Time-Stamp этой учетной записи. Для очистки КЭШа для всех учетных записей контроллера домена, необходимо установить значение реестра Cached Membership Site Stickiness (minutes) = 0 и запустить процесс обновления кэша.

    36. Как запустить процесс обновления кэша UGMC?

    Установите значение updateCachedMemberships в 1 объекта rootDSE контроллера домена или перезагрузите контроллер домена.

    37. Рассмотрим такую ситуацию: есть сайт, для него включен механизм UGMC, в сайте два контроллера из разных доменов (DC1 и DC2), пользователь впервые входит в домен (DC1). Когда и как будет заполнен UGMC на DC2 для этого пользователя?

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

    38. Почему не рекомендуется назначать права на объекты Active Directory с использованием доменно-локальных групп?

    На глобальный каталог реплицируются все объекты с соответствующими дескрипторами безопасности. Если пользователь будет искать объекты на глобальном каталоге неродного домена и на эти объекты будут назначены разрешения с использованием доменно-локальных групп, то пользователю будет отказано в доступе (если нет разрешений с использованием других групп или непосредственного назначения прав пользователя). Это происходит потому, что членство в доменно-локальных группах не реплицируется на глобальный каталог и доменно-локальные группы исключаются из TGT— referal.

    39. Назовите условия объявления GC к готовности выполнять свои функции (isGlobalCatalogReady=true), при различных версиях ОС? Допускается ли объявление GC без репликации частичных реплик всех доменов леса (кроме своего)? Допускается ли неполная (не все объекты) репликация частичных реплик на DC до объявления DC в качестве GC (isGlobalCatalogReady=true)?

    Условия объявления GC готовым к работе (rootDse.isGlobalCatalogReady=true, регистрация SRV-записей GC) различны, настраиваемы и отличаются в различных версиях AD. В Windows Server 2003 и Windows 2000 Server SP3 необходимо чтобы все частичные реплики леса были полностью реплицированы на GC. В Windows 2000 Server SP1 и SP2, чтобы все частичные реплики сайта были полностью реплицированы. Условия варьируются от «не требуется репликации реплик» до «полностью все реплики в лесу». Настраивается значением реестра Global Catalog Partition Occupancy Level Values = от 0 до 6. Если необходимо реплицировать реплики, то все объекты реплики должны быть реплицированы, прежде чем GC будет готов к работе. Это поведение изменяется значением реестра Global Catalog Delay Advertisement (sec).

    40. Может ли выступать GC в качестве источника репликации для другого GC? Может ли выступать GC в качестве источника репликации для DC (не GC)?

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

    41. Что такое up-to-dateness vector? Для чего предназначен?

    Up— to— Dateness vector – это ассоциативный массив используемый при фильтрации реплицируемых атрибутов. Состав элемента – InvocationID (Database GUID), наивысший реплицированный оригинальный USN (Origination USN), время последней удачной репликации (появился во второй версии вектора – win2k3). InvocationID является ключом этого ассоциативного массива.

    42. Что такое high-watermark ? Для чего предназначен?

    High— watermark или direct up— to— dateness vector – значение наивысшего локального USN реплицируемого с конкретного DC. Используется для фильтрации объектов, которые необходимо реплицировать

    43. В чем отличие up-to-dateness от high-watermark?

    Два данных значения используется совместно, но один используется для фильтрации необходимых для репликации объектов (high— watermark), а другой для фильтрации необходимых для репликации атрибутов (up— to— dateness vector). То есть при необходимости репликации, dc-назначение передает high— watermark dc-источнику, dc-источник использует значение из high— waterark для фильтрации всех объектов, которые уже были реплицированы на dc-назначение с этого DC (usnChanged>high— watermark). После этого используется up— to— dateness vector для фильтрации атрибутов отфильтрированных объектов, которые необходимо реплицировать (некоторые атрибуты могли ранее реплицироваться через другие контроллеры-посредники).

    44. Что такое invocationID? Как используется при восстановлении из резервной копии?

    InvocationID – это уникальный идентификатор БД NTDS.DIT, он изменяется при восстановлении БД (также при добавлении и удалении разделов приложений в БД ntds.dit). Используется в up— to— dateness vector при репликации. После восстановления изменяется, старое значение добавляется в up— to— dateness vector. Далее этот вектор используется для запроса изменений с контроллеров домена, то есть в принципе процесс ничем не отличается от обычной репликации.

    45. Почему существует практическое ограничение (примерно) на 5000 членов в группе в лесу с функциональным уровнем windows 2000? Осталось ли ограничение на добавление одновременно более 5000 членов в группу в лесу с функциональным уровнем Windows 2003?

    Практическое ограничение основано на ограничении LDAP-транзакции. Контекст LDAP-транзакции – объект. Практическое максимальное число значений, изменяемых в одной транзакции равно 5000. В windows 2000 Server (уровень леса) не используется LVR репликация, поэтому существует ограничение на 5000 значений в атрибуте member. При LVR метаданные репликации хранятся для каждого отдельного значения многозначного связанного атрибута. В случае с Windows 2000 Server, метаданные репликации хранятся для целого многозначного связанного атрибута, поэтому при изменении одного значения атрибута member необходимо реплицировать весь атрибут, поскольку реплицируется весь атрибут, возникает практическое ограничение размера LDAP-транзакции.
    В Windows Server 2003 (уровень леса) ограничение на размер транзакции остается, но используется LVR-репликация. Поэтому одновременное добавление более 5000 членов может вызвать проблемы, но в группе может быть больше 5000 членов и проблем с репликацией не возникает. Стоит заметить, что при репликации, измененные значения могут записываться в разных транзакциях, из-за использования LVR.

    46. Какие проблемы могут быть при авторизованном восстановлении объектов с обратными ссылками после перехода на лес с функциональным уровнем Windows Server 2003? Какие есть способы решения данных проблем?

    Рассмотрим пример с восстановлением пользователя, который входил в некоторые группы. Поскольку при уровне леса Windows 2000 не используется LVR, то метаданные репликации хранятся для цельного атрибута member. Если мы перешли на лес Windows 2003, то метаданные автоматически не изменятся. При изменении значения в этом атрибуте, для него (конкретного значения) создаются отдельные метаданные репликации. Если LVR для значения есть (прямая ссылка), то ntdsutil (windows Server 2003) при авторизованном восстановлении пользователя использует эти метаданные и производит авторизованное восстановление прямой ссылки (обратная ссылка вычисляется). Если метаданных для прямой ссылки нет, то она не восстанавливается и членство пользователя в группе (ах) не восстанавливается. Членство пользователя в группах других доменов также не восстанавливается. Для решения этих проблем используются средства ntdsutil из Win2k3 Sp1, а также ряд других способов.

    47. Рассмотрим такую ситуацию: Имеется три сайта (SiteA, SiteB, SiteC), два домена (DomainA, DomainB), два контроллера домена для DomainA (DC1, DC2) и один контроллер домена для DomainB (DC3). DC1 и DC3 – глобальные каталоги. Связь сайтов LINK-A-B связывает сайты SiteA и SiteB, связь сайтов LINK-B-C связывает сайты SiteB и SiteC. Контроллеры домена DC1, DC2 и DC3 располагаются в сайтах SiteA, SiteC, и SiteB соответственно. Все остальные настройки по умолчанию. При недоступности связи между контроллерами домена DC1 и DC2 (сайтами SiteA и SiteC) будут ли созданы соединения (между этими контроллерами) для репликации DomainA? При недоступности связи между контроллерами домена DC1 и DC2 (сайтами SiteA и SiteC) будет ли реплицироваться контекст DomainA (попадут ли изменения сделанные на DC1 на DC2)?

    47.1. Соединения для репликации контекста DomainA будут созданы, поскольку bridge all site links включен по умолчанию. DC3 в промежуточном сайте хоть и содержит раздел DomainA, но выступать в качестве источника репликации не может. Поэтому будет создано соединение для репликации DomainA между DC1 и DC2.

    47.2. При недоступности связи между контроллерами DC1 и DC2 репликация DomainA не возможна, хотя на DC3 изменения будут реплицироваться.

    48. Опишите принцип объявления атрибута как прямой ссылки (forward-link) и обратной ссылки (backward link)? Как это выглядит в БД ntds.dit?

    Атрибут LinkID у атрибута в схеме указывает на то, что атрибут является связанным. При этом четное число указывает на прямую ссылку (forward— link), а следующее число указывает на обратную ссылку. Например, для атрибута member LinkID=2, а для атрибута memberOf LinkID=3. Значение этого атрибута должно быть уникальным в лесу.

    Выглядит в БД примерно так (на примере членства пользователя в группе):

    tabl

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

    49. Как в LDAP-запросе вернуть значения многозначного атрибута частично (порциями)?

    Есть ограничение на число возвращаемых значений из многозначного атрибута. Для Win2k – 1000, для Win2k3 – 1500. Для того чтобы вернуть значения по частям, необходимо использовать специальный спецификатор – Range. Формат использования: атрибут;Range=начальное_значение— конечное_значение. Например в ldp, необходимо в Attributes вписать “member;Range=1500—3000”. Использование в ADSI и System.DirectoryService аналогичное. LDAP-сервер должен поддерживать специальный контрол – .2.840.113556.1.4.802.

    50. Что такое конфиденциальный атрибут?

    Это тип атрибута, появившийся в Windows Server 2003 SP1, для чтения которого необходимы не только права READ_PROPERTY, но и CONTROL_ACCESS. По умолчанию, только группе Administrators делегированы права Contol_access на все объекты. Этот способ также используется совместно с FAS, для обеспечения безопасности конфиденциальной информации в среде с RODC. Настраивается на уровне атрибута в схеме, для этого необходимо изменить атрибут searchFlags.

    51. Назовите категории классов, которые можно создать в схеме. Опишите особенности и назначение каждой категории.

    В AD существует четыре вида классов: структурные, абстрактные, добавочные (auxiliary) и классы-88 (устаревшие, относятся к старой спецификации – до 1993 года; в AD не используются). У каждого типа классов есть особенности наследования. Объекты в AD могут быть созданы только на основе структурных классов. Структурный класс может наследоваться от абстрактного класса, но не наоборот. В остальном наследование классов ограничено только своей категорией. Абстрактные классы описывают общность, на их основе нельзя создать экземпляры. Добавочные классы можно добавлять к структурным классам, при определенных условиях удалять из этих классов. Добавочные классы используются для расширения классов.

    52. изменение коннектов репликации. Изменение при помощи adsiedit.msc.

    Здесь подразумевался вопрос про владельцев соединений репликации, их изменение, а также изменение через ldap/adsi-утилиты.

    53. Кратко опишите способы отката расширения схемы в лесу.

    1) Необходимо выбрать один подходящий DC в каждом домене. Критерии «хороший» бэкап, DNS- сервер, не-GC, RID, Schema Master и Domain Naming Master.
    2) Изолировать выбранные DC, остальные отключить физически от сети или выключить.
    3) Начиная с корневого домена, восстановить DC из резервной копии, SYSVOL восстановить авторизовано. Убедиться в целостности данных. Отключить требование проведения первоначальной репликации для продолжения выполнения своих функций как DC и как FSMO-мастера.
    4) Если это GC, то нужно удалить GC.
    5) Увеличить RID-пул на большое количество (рекомендуется 100000)
    6) Очистить метаданные других контроллеров, сбросить пароль на учетке контроллера домена (дважды), сбросить пароль на krbtgt (дважды), сбросить пароль TDO-объектов для доменов (trusting) леса.
    7) провести операции с 3-6 для других доменов, начиная с родительских.
    Установить дополнительные DC через dcpromo. Сделать ребилд RODC.
    Это если вкратце. Вообще процесс достаточно сложный и тут необходимо его хорошо изучить и постоянно тестировать в изолированной среде. В конце статьи есть ссылка на документ, описывающий данные процедуры.
    Поясню лишь некоторые особенности восстановления:
    Почему необходимо восстанавливать только один DC? Можно восстанавливать и несколько DC, но тогда возрастает вероятность появление поврежденных данных в лесу.
    Почему не рекомендуется восстанавливать GC? Потому что GC содержит данные из других разделов и при восстановлении могут появиться lingering-объекты. Если все таки, восстанавливается GC, то необходимо удалить признак GC, а потом заново включить (тут возникнут проблемы с репликацией объектов из других контекстов и объявления isGlobalCatalog – решается определенными значениями в реестре) или удалить lingering-объекты посредство repadmin.
    Почему нужно очищать метаданные других контроллеров, сбрасывать пароли на учетной записи компьютера, сбрасывать пароль на krbtgt, TDO? Все это делается для того чтобы гарантировать, что поврежденные контроллеры домена не смогут реплицироваться с восстановленным DC и опять повредить данные в лесу. Если есть гарантия, что контроллеры в лесу выключены, то данные действия проводить не нужно. Очистка метаданных осуществляется еще и для оптимизации процессов генерации топологии KCC.
    Почему нужно делать ребилд RODC? В них также могут находиться устаревшие данные (lingering-объекты) – нет гарантий, что резервная копия содержит самые последние данные (этого очень трудно добиться).
    Почему нужно увеличивать следующий RID-пул? Даже если контроллер домена был RID, после восстановления необходимо увеличить следующий RID-пул, поскольку со времени резервной копии могли быть созданы участники безопасности и назначены соответствующие права этим учетным записям.

    54. Почему не рекомендуется размещать FSMO-роль Infrastructure на GC? При каких условиях можно/нельзя?

    См. ответ на 17.

    55. Может ли использоваться протокол Kerberos между не доменной машиной и доменной?

    Да. Может использоваться между не доменной машиной из не- Windows Kerberos-сферы и доменной машиной. Также Kerberos может использоваться между лесами без доверительных отношений. Между не доменной машиной и доменной используется NTLM.

    56. Можно ли удалить объекты из контекста именования схемы? Как предотвратить немедленное удаление экземпляров отключенных классов? Как предотвратить немедленную очистку атрибутов у экземпляров классов, у которых есть отключенные атрибуты? Доступны ли экземпляры отключенных классов для чтения, изменения, удаления? Доступны ли для чтения, изменения, удаления отключенные атрибуты у экземпляров классов (операции проводятся с экземплярами классов, у которых есть отключенные атрибуты)?

    Удалить объекты из контекста именования схемы нельзя (на уровне DSA). Удаление экземпляров отключенных классов не происходит, они остаются в БД. Очистки значений отключенных атрибутов также не происходит. Экземпляры отключенных классов доступны на чтение, соответственно поиск, а также удаление. Значения отключенных атрибутов доступны на чтение, очистку, по ним можно искать.

    57. Может ли FSMO-роль Schema и Domain Naming располагаться на DC не из корневого домена?

    Да. По причине глобальности двух разделов Schema и Configuration (контейнер Partition).

    58. Можно ли создать объекты класса или атрибута в схеме с одинаковыми идентификаторами (AttributeID, governsID, ldapDisplayName и т.д.)? Могут ли быть эти классы активными?

    В Windows Server 2003 появилась возможность создавать классы/атрибуты с одинаковыми идентифицирующими атрибутами (AttributeID, governsID, ldapDisplayName и т.д.). Единственное условие, чтобы DN этих классов или атрибутов были различными. Атрибуты или классы с одинаковыми идентифицирующими атрибутами не могут быть активными одновременно. В Windows Server 2000 нельзя было создать два класса или атрибута с одинаковыми идентифицирующими атрибутами.

    59. —

    60. Можно ли откатить назад операцию повышения функционального уровня леса/домена?

    Да, в Windows Server 2008 R2 появилась функция отката функционального режима леса/домена с 2008 R2 на 2008. Для функционального уровня леса дополнительным условием является отключенная корзина AD.
    Также можно произвести восстановление леса, процедура описана в ответе на вопрос 53.
    Можно также предположить, что достаточно будет авторизованное восстановления раздела конфигурации и домена. Если авторизовано восстановить конфигурацию (CN=Partitions,CN=Configuration) и раздел домена, то из этого ничего не выйдет, данные о функциональном уровне будут реплицированы обратно. Это происходит по причине того, что ntdsutil увеличивает версии атрибутов выборочно, и для msDs— BehaviorVersion этого не происходит. Это правильно для функционального уровня леса и домена. Но что же случится, если восстановить (авторизовано или неавторизованно, не имеет значения) контекст домена (msDS— BehaviorVersion есть у объекта домена) и в лесу есть контроллеры доменов из других доменов, а из этого домена это единственный контроллер домена? С глобальных каталогов этот атрибут не может реплицироваться. Данный атрибут, на самом деле, вычисляется на основе атрибута msDS— BehaviorVersion контейнера cn=partitions (то есть на основе уровня леса). И получается следующее: Был уровень леса и домена 2003, сделали резервную копию, подняли уровень домена до 2008R2, уровень леса до 2008. После восстановления из резервной копии уровень леса будет 2008, уровень домена откатится до 2008. Хотя я предполагал, что уровень домена восстановится на прежний уровень (то есть на 2008R2) за счет использования атрибута msDS— BehaviorVersion объектов cross— ref (у них также не происходит изменение метаданных при авторизованном восстановлении).

    61. В какой версии Windows появились функциональные уровни леса?

    Windows Server 2003. В Windows 2000 Server нет соответствующих атрибутов для идентификации функциональных уровней (DC, домена, леса). Хотя есть признак mixed у домена.

    62. Поддерживает ли режим функционирования Windows 2003 Interim контроллеры домена Windows 2000 Server? Контроллеры домена Windows Server 2008? Контроллеры домена Windows Server 2008 R2?

    Нет, только Windows Server 2003. Данный режим используется для обновления с Win NT 4.0. Windows 2008/2008 R2 не поддерживают контроллеры домена Win NT 4.0.

    63. Какие проверки делаются при повышении функционального режима леса? Домена? (с учетом различных версий контроллеров домена и различных уровней функционирования домена).

    Уровни леса и домена, в том виде как они представлены по сей день, появились, начиная с Windows Server 2003. В Windows 2000 Server был лишь переключатель режима домена от смешанного (mixed) к основному (native). Помимо функционального уровня леса и домена, существует функциональный уровень контроллера домена, его нельзя повысить или понизить. Атрибут msDSBehaviorVersion указывает на функциональный уровень; он есть у объектов доменов, cross— reference, NTDS Settings, CN=Partitions. При повышении уровня леса или домена, происходит проверка этого атрибута у объектов NTDS Settings контроллеров домена в контексте конфигурации. msDSBehaviorVersion леса или домена не должен быть больше соответствующего атрибута контроллеров домена.
    У WinNT 4.0 контроллеров домена нет объектов в конфигурации, в этой ситуации происходят дополнительные проверки. При повышении уровня леса до win2k3, происходит проверка доменов на признак работы в основном режиме (ntMixedDomain=0), это гарантирует отсутствие WinNT 4.0 контроллеров (хотя они конечно могут быть:)). Проверки на отсутствие WinNT4.0 контроллеров домена при повышении уровня домена до Win2k3 или при переключении в основной режим 2k, возлагаются системного администратора.
    При переключении в режим 2003 Interim проверяется отсутствие контроллеров с windows 2000 Server, проверка на основной режим домена не производится.

    Полезные ссылки и литература:

    Распределенные системы. Ресурсы Windows 2000.
    Windows Server2008 Resource Kit. Active Directory.
    Ограничения Active Directory: http://technet.microsoft.com/en-us/library/cc756101 (v=WS.10).aspx
    Цикл технических статей по AD: http://technet.microsoft.com/en-us/library/cc780036 (v=WS.10).aspx
    AdminSDHolder, SDPROP: http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx
    Структура Up-To-Dateness: http://msdn.microsoft.com/en-us/library/cc228451 (v=PROT.13).aspx
    Использование Range-спецификатора: http://msdn.microsoft.com/en-us/library/ms676302 (v=VS.85).aspx
    Windows Security Collection: http://technet.microsoft.com/en-us/library/cc784886 (v=WS.10).aspx
    Planning for Active Directory Forest Recovery: http://technet.microsoft.com/en-us/library/planning-active-directory-forest-recovery (WS.10).aspx
    Восстановление объектов AD: http://technet.microsoft.com/ru-ru/magazine/2007.09.tombstones.aspx и http://technet.microsoft.com/en-us/magazine/2007.04.adrecovery.aspx

    Gennady Efimov

Комментарии

  1. 1)В споре, как известно, рождается ненависть и раздор, по этому спорить не буду;)
    2)!Спасибо! Пиши еще!
    3)Знать все это круто!
    4)Скажи есть ли вопросы возникшие в боевой обстановке? Ты работаешь в большом интеграторе?

  2. 1) эт верно.
    2) по возможности. 🙂
    3) тоже хотел бы все знать
    4) Я работал в большом интеграторе. Сейчас надеюсь найти альтернативу.
    Так скажем, что вопросы представленные здесь имеют интеграторский характер. О них нужно задумываться на этапе планирования. Был очень крупный проект (~9000 рабочих мест, ~400 различных серверов, 35-40 доменов, 40-50 площадок, банковская закрытая сеть), миграция AD, Exchange. Там конечно пришлось столкнуться с множеством вопросов: были проблемы с правами, с репликацией, были моменты с восстановлением данных, с порчей. В общем, что только не было.

    Причем я работал на тот момент в интеграторе всего месяц, до этого работал программером. Увлекался сдачей сертификационных экзаменов (MCSE, CCNA и другие). Теоретические знания очень помогли, сразу удалось включиться в работу, ну и в проекте был на особом счету :). Особенно помогло мое увлечение системным программированием, приходилось писать различные системные утилиты для миграции. Было очень интересно 🙂

  3. Вообще советую интеграторам и системным администраторам заниматься и программированием тоже. Особенно системным.
    Сразу появляется другой взгляд на используемые продукты, более низкоуровневый. Изучение этих продуктов станет более интересным и быстрым. Причем даже не зная работу тех или иных продуктов/компонентов, можно будет правильно угадывать (делать предположения) их устройство и методы взаимодействия.
    Соответственно сразу повышается уровень использованной литературы. Если вы раньше использовали Technet и Resource Kitы, то теперь сможете использовать MSDN и спецификацию протоколов.

  4. Ну что я могу сказать – потрясен 🙂
    А вот самое интересное – это описанная вами миграция с 9000 рабочих мест.
    Если бы смогли описать – думаю было бы очень интересно. Ведь немногие сис админы у нас имеют дело с такими сетями. У меня вообще почти все клиенты по 10-20 машинок, сильно много опыта не получишь.

  5. Потихоньку читаю вопросы и буду давать свои комментарии.

    Ответ на вопрос 4 не точный, в частности не учтена функциональность Universal Group Membership Caching, появившаяся в Win 2003. Однако, задам еще вопрос на эту тему: а как вообще контроллер определяет, нужно ли ему при формировании PAC проверить членство пользователя в универсальных группах из других доменов, чтобы добавить их SID-ы в PAC?

  6. 8.3 работа доверительных отношений в такой ситуации возможна, если правильно настроить маршрутизацию UPN/SPN-ов и изключить из маршрутизации конфликтующие имена доменов или конфликтующие пространства имен.

  7. п12. Для LDAP Ping-а используется не первый ответивший контроллер, а контроллер который был найден через DNS как ближайший (естественно это делается без учета стоимости связей сайтов, а только на основе net mask ordering, потом приоритетов и Site-coverage).
    Снадартный механизм поиска называется DC Locator и результат LDAP Ping для него имеет первостепенное значение. Имеено в ответе на LDAP Ping содержится указание на тот сайт, который является наиболее подходящим клиенту.

  8. п.13: причин того, почему не используется SMTP для репликации доменного контекста – много. Корень всех причин в том, что SMTP-репликация асинхронна и не гарантирует 100% доставку каждого конкретного сообщения из всей цепочки доставки до конечного контроллера домена. Безопасность тут совершенно не причем, т.к. все сообщения закрыты S/MIME шифрованием и для репликации все контроллеры должны иметь сертификаты.

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

    Раздача RID-пулов, AdminSDHolder процесс, изменение в топологии репликации NTFRS/DFS-R, мгновенное проталкивание изменения паролей учетных записей компьютеров и пользователей и т.п. Все эти изменения необходимо очень оперативно распространять по домену. Именно потому SMTP тут не годиться.

  9. п.38, посяни подробнее что ты имел ввиду. Есть сомнения в правильности понимания тобой сути TGT-referral и изменения состава PAC. Не забывай, что при доступе к GC не из своего домена, ты должен получить TGS, для доступа к этому GC и если ты его получаешь, то членство в доменных локальных группах целевого домена будет добавлено в PAC но уже TGS, а не TGT.

  10. П.43 – для фильтрации атрибутов используется так же high-watermark, т.к. в метаданных ВСЕ атрибуты помимо номера версии и тайм-стампа имеют еще и USN для их обновления, сам же up-to-dateness вектор используется для предотвращения (демфирования) циклического обновления объектов.

  11. п.44 – зачем разработчикам приспичило менять Invocation ID для NTDS.dit после ее восстановления или добавления новых партиций репликации (на самом деле если бы можно было добавлять удалять доменную партицию, схему или конфигурацию так же как и Application партиции значение Invocation ID так же менялось бы).

    Как увидеть, менялось ли хоть раз у контроллера значение Invocation ID за всю его жизнь? 😉

  12. п.45 – на самом деле дело не в транзакции, а в размере страницы библиотеки ESE выбранной для БД NTDS.dit, равной 8Кб. Если было дело только в транзации, то это ограничение можно было бы преодолеть увеличив размер страницы для запросов LDAP, однако это не возможно. В реальности по свой сути B-деревья, на основе которых построена логика работы движка ESE и ссылок DTN и PDTN, не позволяет записать объект в базу более чем на одну страницу. Отсюда и ограничение.

  13. п.38, посяни подробнее что ты имел ввиду. Есть сомнения в правильности понимания тобой сути TGT-referral и изменения состава PAC. Не забывай, что при доступе к GC не из своего домена, ты должен получить TGS, для доступа к этому GC и если ты его получаешь, то членство в доменных локальных группах целевого домена будет добавлено в PAC но уже TGS, а не TGT.

    ———
    Клиент хочет получить Service Key (SK) для GC из другого домена.
    Делает запрос на SK своему DC, передает TGT. Родной DC видит, что служба не из родного домена, есть доверительные отношения с этим доменом (явные/неявные), передает клиенту TGT-ссылку. TGT-ссылка это новый TGT, подписанный секретом доверительных отношений, а не секретом krbtgt родного домена. Из TGT-ссылки происходит исключение доменных локальных групп родного домена и этот TGT передается клиенту.
    Клиент передает TGT-ссылку контроллеру домена этого глобального каталога (будем считать что существуют непосредственные доверительные отношения). Контроллер домена формирует SK и выдает SK клиенту. Клиент обращается к GC с этим SK, строится маркер доступа.

  14. >>>Konstantin Leontiev
    >>>п.13….

    Согласен, неотложная репликация имеет большое значение. Но она не распространяется мгновенно между сайтами (не считая случаев разрешения оповещений между сайтами).
    Для случая с account locout происходит неотложная (urgent) репликация на PDC, на локальные DC по отношению к PDC и DC-инициатора, на DC в других сайтах, если включено оповещение между сайтами.
    Для случаев смены паролей пользователей или компьютеров происходит неотложная репликация на PDC, далее стандартное распространение изменение (даже если PDC недоступен).
    Некоторые другие случаи, которые запускают urgent-репликацию, распространяют изменения на DC в том же сайте или в других сайтах, если включено оповещение.

    Репликация изменений в процессе работы SDProp (AdminSDHolder), на сколько мне известно, не происходит мгновенно. Хотя изменения в SD защищенных групп безусловно важны. Но тогда можно рассматривать и вариант с межсайтовой репликацией по RPC (большой цикл репликации).

    Насчет RID-пулов: тут конечно доступность по RPC важна.

    Вот о распространении SYSVOL с помощью FRS/DFSR я не подумал. Думаю это одна из основных причин.

  15. >>>Konstantin Leontiev
    >>>П.43 — для фильтрации атрибутов используется так же high-watermark, т.к. в >>>метаданных ВСЕ атрибуты помимо номера версии и тайм-стампа имеют еще и USN >>>для их обновления, сам же up-to-dateness вектор используется для >>>предотвращения (демфирования) циклического обновления объектов.

    Согласен. Но первостепенно high-watermark все же используется для фильтрации объектов по LocalUSN, далее (возможно и в принципе логично) атрибутов по LocalUSN. После этого применяется up-to-dateness вектор для фильтрации атрибутов на основе OriginationUSN, которые уже могли реплицироваться по другим путям репликации (демфирование, надо запомнить:)).

  16. >>>Konstantin Leontiev
    >>>п.45 — на самом деле дело не в транзакции, а в размере страницы библиотеки ESE выбранной для БД NTDS.dit, равной 8Кб. Если было дело только в транзации, то это ограничение можно было бы преодолеть увеличив размер страницы для запросов LDAP, однако это не возможно. В реальности по свой сути B-деревья, на основе которых построена логика работы движка ESE и ссылок DTN и PDTN, не позволяет записать объект в базу более чем на одну страницу. Отсюда и ограничение.

    ————————————————–
    В документации указывается именно ограничение транзакции, причем не просто на 5000 значений, а сказано что для связанных многозначных атрибутов примерное практическое ограничение равно 5000. Сразу конечно приходит на ум что именно в размере дело, только вот чего?
    Предположим, что по причине 8КБ размера страниц ESE. Но тогда почему 5000? Если даже взять размер (PDNT(4Байта)*5000) + DNT + идентификатор атрибута, то получается примерно 20000 байт, или 19,5КБ.
    Для несвязанных атрибутов это ограничение имеет место быть: объект не может располагаться более чем на одной странице – чуть меньше 8КБ. Опять же есть BLOB-поля, размер которых может достигать 2ГБ. Для таких атрибутов хранится только ссылка на начальную страницу – несколько байт, точно не помню.

    Вопрос в принципе остается открытым, не ясна первопричина. Предположу несколько вариантов этого ограничения:
    1) На транзакцию выделяется ограниченное число ресурсов – оперативной памяти.
    2) На транзакцию выделяется ограниченное число страниц для version store.

  17. ….Клиент хочет получить Service Key (SK) для GC из другого домена….
    Конечно же Service Ticket (ST).. ошибся

  18. Ваш комментарий

  19. Здравствуйте! Помогите пожалуйста разобраться с таким делом: в моей организации нужно поменять приблизительно 500 пользователям sam id. как это сделать с минимальными затратами времени?

  20. to Alex:
    способов решения этой задачи мульён..

    powershell, vbscript/jscript, bat, dsquery | dsmod
    можете в Excel сформировать список пользователей (например, используя AD Module for Powershell или csvde), далее заполнить новое имя, экспортировать в csv. После этого использовать powershell для импорта из csv и все тем же модулем для powershell обновить samid.
    на просторах интернета должны быть готовые скрипты по работе с CSV-файлами

    можете использовать ldifde, выгрузить в файл пользователей, подправить (ручками) samid и импортировать через тот же ldifde

  21. Вопрос 1:
    Хотел изменить samid через командную строку
    dsquery -samid старый_логин> | dsmod – samid новый_логин
    оказалось у dsmod нету параметра -samid

    Теперь получилось изменить при помощи powershella

    $objUser=[ADSI]”LDAP://cn=test,ou=test,dc=test,dc=ru”
    $objUser.put(“sAMAccountName”, “новый_логин”)
    $objUser.SetInfo()

    Но тут доступ к объекту получен через DN, а мне крайне желательно через samid. Т.е. подключаемся к объекту через самид и меняем это самид на новый
    Как это сделать?

    Вопрос 2:
    В повершеле чтобы импортировать пользователей из цсв используем:
    $dataSource=import-csv “NewUsers.csv”
    foreach($dataRecord in $datasource) { и присваиваем переменным значения записей}

    Какая аналогичная функция в Visual Basicе?

  22. вообще такие вопросы лучше на форумах задавать, в комментариях как-то не очень.. есть хороший форум social.technet.microsoft.com.. там помогут…

    1) для dsquery нужно добавить параметр user.. как-то так: dsquery user -samid gyefimov | dsmod user -samid gefimov
    2) можно использовать другой провайдер и моникер – WinNT.. как-то так: $objUser = [adsi]”WinNT://SITRU/gyefimov,user” http://msdn.microsoft.com/en-us/library/windows/desktop/aa772316(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa746534(v=vs.85).aspx
    3) в vbs можно конечно поискать соответствующие объекты автоматизации, но я не встречал и реализовывал чтение из csv/excel собственноручно.. вам лучше поискать в интернете как это делается, примеров должно быть много.