Вопросы:
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 изменения будут реплицироваться.
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, проверка на основной режим домена не производится.
