Вопросы по Active Directory.

Решил сделать небольшую подборку интересных вопросов по Active Directory. Данные вопросы в основном нацелены на проверку понимания работы служб Active Directory. На некоторые из этих вопросов трудно ответить сходу, в таких случаях необходимо время на поиск. Таким образом, можно проверить, на сколько хорошо специалист умеет искать информацию, анализировать ее, фильтровать и правильно трактовать. Проще говоря, это называется уметь читать. В наш информационный век это чуть ли не самое главное качество и достоинство специалиста. Данное мастерство приходит с годами, а точнее с количеством прочитанных книг.
Данные вопросы, думаю можно смело задавать соискателю на должность инженера, эксперта по Core Infrastructure. Я, кстати, в данный момент являюсь соискателем :). Ответы можно присылать по адресу f o r m a t 0 0 7 @ y a n d e x . r u, в ответ напишу правильные. В дальнейшем придумаю еще вопросы (здесь только часть) по AD, ну и по Core Infrastructure в целом. Возможно по Messaging (хотя сейчас это уже UC).

Стоит отметить, что данные вопросы относятся в основном к Windows Server 2003 Active Directory (иначе указан конкретная версия AD). Не смотря на это, многие из вопросов относятся и к Windows 2000 Server, к 2008 и 2008 R2.

Не отрицаю, что могут быть ошибки, комментируйте, исправлю.
Приступим:
1.  Какие изменения в методах репликации произошли в GC Windows Server 2003 по сравнению с GC Windows Server 2000 при изменении (добавлении, удалении) признака PAS (partial attribute set) в схеме?
2.  Сколько полных реплик NC (naming context), без учета NC-приложений, находится на GC в трех доменном лесе?  Частичных реплик?
3.  Возможен ли поиск по всему лесу при соединении с GC по порту 389? Почему?
4.  Требуется ли доступность GC для разрешения членства в универсальных группах в однодоменном лесу? В много доменном лесу для пользователя из домена с функциональным уровнем Windows Server 2000 Native/2003? Имеет ли значение уровень домена/леса при таких операциях? Какой?
5.  Сценарий доступности GC из 4, но для операций логона по UPN в однодоменном лесу? В многодоменном лесу? Имеет ли значение уровень леса/домена при таких операциях? Какой?
6.  Для чего членство универсальных групп реплицируется на глобальный каталог?
7.  Членство в каких группах (доменно-локальных, глобальных, универсальных) реплицируется на GC? Членство каких групп может быть на GC?
8.  Как происходит разрешение UPN при логоне, если пользователь из одного леса, входит на рабочую станцию другого леса,  при этом существуют доверительные отношения между доменами леса (для упрощения — двухсторонние, глобальные (domain-wide))? Как происходит вход по UPN между лесами при наличии forest-trust? А если в обоих лесах есть домены с одинаковыми именами?
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?
10. При обращении к GC по 3268 возможны ли операции модификации объектов? возвращение атрибутов не входящих в PAS?
12. В каких случаях используется UDP для LDAP?
13. Для репликации каких контекстов именования можно использовать SMTP в качестве транспорта?
14. Какие контексты именования не поддерживают авторизованное восстановление?
15. Рассмотрим ситуацию: Вы добавили группу MyAccountAdmin в группу Account Operators (Уровень леса Windows Server 2003), после этого вы делегировали полномочия другому администратору на добавление членов в группу MyAccountAdmin.  Все работает, человек с делегированными правами добавляет пользователей в группу MyAccountAdmin. Спустя некоторое время вам сообщают о невозможности добавления членов в группу MyAccountadmin. Что случилось?
16. Какие типы групп кэшируются в процессе Universal Group Membership Caching (UGMC)?
17. Для чего необходима FSMO-роль Infrastructure? желательно развернуть ответ со ссылкой на внутреннюю структуру NTDS.dit.
18. Что такое объекты Foreign Security Principal?
19. Какой ролью обновляются объекты Foreign Security Principal и соответствующие ссылки на эти объекты?
20. Во время изменения схемы проверяются ли объекты других контекстов именования на валидность новой схемы?
21. Рассмотрим такую ситуацию: есть определенный в схеме атрибут, attrX, строковый, максимальная длина 25, атрибут ассоциирован с некоторым классом — classX. Предположим что существуют объекты класса classX, атрибут attrx которых заполнен до 25 символов. Что произойдет со значениями атрибута attrX существующих объектов classX, если мы изменим максимальную длину атрибута attrX до 10?
22. Опишите процесс входа пользователя по UPN (однодоменный лес, много доменный лес).
23. Где хранится кэш универсальных групп полученный в процессе Universal Group Membership Caching (UGMC)?
24. Как сохранить кэш универсальных групп полученный в процессе Universal Group Membership Caching при перезапуске контроллера домена?
25. Опишите процесс Universal Group Membership Caching при первом входе пользователя в сайт? Обновление кэша? Последующий вход?
26. Как происходит выбор глобального каталога при Universal Group Membership Caching.
27. Какой учетной записи разрешается входить в домен при недоступности глобального каталога (upn-вход, универсальные группы)?
28. Как происходит обмен кэшем Universal Group Membership Caching между контроллерами домена?
29. Максимальное (по умолчанию) число учетных записей для которых производится обновление кэша универсальных групп?
30. Может ли быть включена опция кэширования универсальных групп, если в сайте есть Windows 2000 Server контроллеры домена? Если включить опцию при этих условиях, каковы возможные последствия?
31. Используется ли расписание репликации связи сайтов (site link) в процессе обновления кэша универсальных групп?
32. Для построения маркера (возврат списка групп) используются данные о членстве в группах из кэша или непосредственно из «родного» контекста именования  контроллера домена.
33. Какая служба предоставляет матрицу стоимости сайтов? Какими компонентами используется?
34. Что будет если указать сайт для обновления кэша универсальных групп, в котором нет глобального каталога или на момент процесса обновления кэша глобальный каталог недоступен?
35. Как очистить кэш UGMC?
36. Как запустить процесс обновления кэша UGMC?
37. Рассмотрим такую ситуацию: есть сайт, для него включен механизм UGMC, в сайте два контроллера из разных доменов (DC1 и DC2), пользователь впервые входит в домен (DC1). Когда и как будет заполнен UGMC на DC2 для этого пользователя?
38. Почему не рекомендуется назначать права на объекты Active Directory с использованием доменно-локальных групп?
39. Назовите условия объявления GC к готовности выполнять свои функции (isGlobalCatalogReady=true), при различных версиях ОС? Допускается ли объявление GC без репликации частичных реплик всех доменов леса (кроме своего)? Допускается ли неполная (не все объекты)   репликация частичных реплик на DC до объявления DC в качестве GC (isGlobalCatalogReady=true)?
40. Может ли выступать GC в качестве источника репликации для другого GC? Может ли выступать GC в качестве источника репликации для DC (не GC)?
41. Что такое up-to-dateness vector? Для чего предназначен?
42. Что такое high-watermark ? Для чего предназначен?
43. В чем отличие up-to-dateness от high-watermark?
44. Что такое invocationID? Как используется при восстановлении из резервной копии?
45. Почему существует практическое ограничение (примерно) на 5000 членов в группе в лесу с функциональным уровнем windows 2000? Осталось ли ограничение на добавление одновременно более 5000 членов в группу в лесу с функциональным уровнем Windows 2003?
46. Какие проблемы могут быть при авторизованном восстановлении объектов с обратными ссылками после перехода на лес с функциональным уровнем Windows Server 2003? Какие есть способы решения данных проблем?
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)?

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

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

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

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

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

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

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

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

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

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

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

59. -

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

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

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

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

Безопасность в Active Directory. Часть 2.

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

Рис. 1.1. Архитектура Web-приложений

Клиент, используя обозреватель Интернет, взаимодействует с Web-сервером, Web-сервер в свою очередь запрашивает данные из БД, файловых или других источников.
Примерами таких систем являются порталы Sharepoint, Forefront Identity Manager, собственные разработки на ASP.NET и т.д.

В пределах корпоративной сети, как правило используется делегирование Kerberos, тоесть Web-сервер олицетворяет клиента и использует его права для доступа к данным.

При неправильном конфигурировании Kerberos-делегирования, могут возникнуть серьезные проблемы в плане информационной безопасности.

Рассмотрим несколько возможных сценариев неправильных настроек и их последствия.

Сценарий 1. Назовем его "Классический".
В данной архитектуре у нас присутствует Web-Сервер IIS. Как правило база данных находится на другом компьютере с Microsoft SQL Server. На IIS сервере включена имперсонация, MS SQL Server использует windows-аутентификацию. Web-сервер от лица клиентов обращается за данными на MS SQL Server.
Если MS SQL и IIS находятся на разных серверах, то необходимо включить делегирование для учетной записи под которой работает IIS. И тут, как правило, системные администраторы просто включают неограниченное делегирование.
Злоумышленник может воспользоваться этим (в качестве злоумышленника может выступать и сам Web-программист, поддерживающий или разрабатывающий данный программный продукт).

Перечислим необходимые действия для получения дополнительных полномочий:
1) Включаем имперсонацию в IIS. В файл Web.config добавляем следующие строки.

<authentication mode="Windows"></authentication>
<identity impersonate="true"></identity>

Подробнее:
http://msdn.microsoft.com/en-us/library/134ec8tc(VS.80).aspx

2) Включаем делегирование для учетной записи компьютера (Пул-IIS нашего приложения запускается под учетной записью SYSTEM).
Свойство учетной записи компьютера, вкладка Delegation, галочка Trust this computer for delegation to any service (Kerberos only).

3) Используем следующий код (c#):


//Создание пользователя, добавление пользователя в группу Domain Admins
protected void Button1_Click(object sender, EventArgs e)
{
DirectoryEntry de = new DirectoryEntry("LDAP://CN=Users,DC=CONTOSO,DC=COM");
DirectoryEntry user = de.Children.Add("CN=User01", "user");
user.Properties["sAMAccountName"].Value = new object[] { "User01" };
user.CommitChanges();
user.Invoke("SetPassword", new object[] { "P@ssw0rd" });
user.InvokeSet("AccountDisabled", new object[] { false });
user.CommitChanges();
DirectoryEntry admgroup = new DirectoryEntry("LDAP://CN=Domain Admins,CN=Users,DC=CONTOSO,DC=COM");
admgroup.Invoke("Add", new object[] { user.Path });
}
//-----------------------

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

Варианты решения данной проблемы:
1) Отслеживать код приложений. Данный способ крайне неудобен и сложен (можно так упрятать деструктивный код, что никто и не найдет при обзоре).
2) Не использовать делегирование и совмещать роли back-end и front-end серверов. Этот способ препятствует масштабированию.
3) Не использовать полномочные учетные записи для выполнения задач, не требующих таких полномочий. Это основное правило. Действует не только в описываемом случае. Безусловно нужно придерживаться данной рекомендации.
4) Использовать расширение протокола Kerberos - Constrained Delegation (более подробнее обсуждается далее).

Сценарий 2. Повышение полномочий.
Данный сценарий на самом деле также использует одно из расширений протокола Kerberos, появившееся в Windows Server 2003 - Protocol Transition (также можно встретить как Service-for-User-to-Self [S4U2Self]).

Подробнее - http://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx

Вкратце, данное расширение позволяет без знания пароля пользователя получать Kerberos-билет и на его основе формировать маркер безопасности. Данный маркер запросившая служба использует для себя. Есть несколько режимов использования маркера - Identify и Impersonation. Первый используется для получения списка групп и полномочий пользователя (очень удобно с учетом распределенности службы Active Directory), второй можно использовать для олицетворения, локально, в системе.

Для использования режима Identify, особых условий не нужно, достаточно только сервера Windows Server 2003 и такого же уровня домена.
Для использования режима Impersonation необходимо соблюдение условий для Identify, плюс наличие полномочий "Act as part of the operating system" локальной политики безопасности. Данная привилегия по умолчанию есть у NT AUTHORITY\SYSTEM. При желании можно дать данную привилегию другой учетной записи, чего не следует делать (только если это действительно нужно).

Опишу данный сценарий по шагам:
1) У нас есть сервер IIS, на нем крутится приложение ASP.NET. Код приложения:
//отключаем делегирование (оно у меня включено в web.config)
WindowsImpersonationContext ctx = WindowsIdentity.Impersonate(IntPtr.Zero);
//Далее используем Protocol Transition
WindowsIdentity wi = new WindowsIdentity("gefimov@contoso.com");
ctx = null;
try
{
ctx = wi.Impersonate();
Response.Write("User:" + wi.User.Value);
File.Create("c:\\gefimov1\\myfile01.txt"); // Здесь полезная нагрузка, у меня просто создание файла в папке (папка находится в эксклюзивном владении - для чистоты эксперимента).
ctx.Undo();
}
catch (Exception err)
{
Response.Write("Error: " + err.Message + "");
}
//-----------------------------

Я не стал здесь правильно обрабатывать ошибки, инициализацию и освобождение. Кому интересно узнать как это правильно делается ("запросам ресурсов путем инициализации")ю необходимо обратиться к книге Бьерна Страуструпа "Язык программирования C++", второе издание, 9 глава.

2) Пул приложения IIS запущен под учетной записью, у которой есть полномочие "Act as part of the operating system".

3) В процессе выполнения кода, поток получает полномочия указанной учетной записи (в нашем случае gefimov@contoso.com), совершенно без пароля (правда какими усилиями:)).

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

Сценарий 3. Расширения Kerberos.
В данном сценарии рассказывается о получении полномочий с использованием двух расширений Kerberos, появившихся в Windows Server 2003:
1) Protocol Transition - Service-for-User-to-Self (S4U2Self) (обсуждалось выше).
2) Constrained Delegation - Service-for-User-to-Proxy (S4U2Proxy).

В общих чертах, используя два этих расширения можно 1) получать билет Kerberos без знания долгосрочного ключа пользователя (проще говоря, пароля) и при этом 2) использовать данный билет для доступа к другим службам в домене.

У данного способа есть свои ограничения (куда же без них):
1) Служба должна работать на сервере с Windows Server 2003 или выше.
2) Уровень домена должен быть Windows Server 2003.
3) Необходимо наличие прав "Act as part of operating system" (напомню что по умолчанию, это право есть у LocalSystem).
4) Необходимо настроить Kerberos Constrained Delegation для учетной записи, под которой выполняется служба.
5) Делегирование может осуществлять только в пределах локального для службы домена. Это не беда, получив права доменного админа, можно с легкостью получить права во всем лесу. (Смотрите мою первую статью про безопасность Active Directory http://gexeg.blogspot.com/2009/12/active-directory.html, также существуют другие способы, в будущем возможно опишу).

1 и 2 выполняется достаточно легко (с учетом того, что на дворе 2010 год). Получение прав для 3 случая проблем тоже не вызывает (ERD Commander и различные Live CD вам в помощь). Осталось только упросить системного администратора включить делегирование Kerberos для учетной записи компьютера или служебной учетной записи (4). Ограничение 5 приходится воспринимать как должное, тут уж никуда не денешься.
Может быть вам удастся уговорить системного администратора дать вам права "Enable computer and user accounts to be trusted for delegation" (данное полномочие позволяет владельцу учетной записи настраивать делегирование, как ему вздумается), тогда вы сами сможете настроить нужное вам делегирование.

По шагам опишу весь процесс:
1) У нас есть приложение ASP.NET на IIS (c#):
//----------
WindowsImpersonationContext ctx = WindowsIdentity.Impersonate(IntPtr.Zero);
WindowsIdentity wi = new WindowsIdentity("Administrator@contoso.com");
ctx = wi.Impersonate();
createuser(); //Создание пользователя
ctx.Undo();
//Обработка ошибок

2) Пул приложения запущен под учетной записью SYSTEM ("Act as part of operating system").
3) Для учетной записи компьютера, я настроил constrained delegation, делегируемая служба LDAP/FIM-DC01.
4) Выполняется код, происходит имперсонация и делегирование, наш поток работает с маркером Администратора домена (Administrator@contoso.com).
5) В процессе выполнения приложения, создается учетная запись пользователя и добавляется в группу Domain Admins. Миссия выполнена.

Как же этого избежать? Конечно же нужно очень трепетно относиться к делегированию.
Приведу некоторые правила:
1) Никому не давайте права "Enable computer and user accounts to be trusted for delegation".
2) Запускайте службы под учетными записями с ограниченными полномочиями (актуально для SharePoint, самому иногда было лень разбираться с доступом - запускал под SYSTEM, но конечно же не в корпоративной среде ;))
3) Ограничивайте использование полномочия "Act as part of operating system".
4) Используйте делегирование только тогда, когда это действительно нужно.
4) Используйте Constrained Delegation, при этом не указывайте службы "на всякий случай, а вдруг используется", указывайте только действительно нужные и используемые службы в делегировании.

Напоследок приведу список полезной литературы:
http://msdn.microsoft.com/en-us/library/134ec8tc(VS.80).aspx
http://gexeg.blogspot.com/2009/12/active-directory.html
http://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx
http://msdn.microsoft.com/en-us/library/ff647404.aspx#paght000023_impersonatingbyusingwindowsidentity

Во вложении файл с проектом Visual Studio 2008:

http://rapidshare.com/files/412781198/ADSEC02.rar

MD5: DA8E5373CB6775E4F8B0C6090D67D4B7