У меня есть доверительные отношения между двумя лесами Windows Server 2008 R2 (функциональные уровни домена и леса в Windows Server 2008 R2). Домены A и B являются корневыми доменами леса в своих соответствующих лесах, а домен C является дочерним доменом домена B.
А <-> В - С
Доверие - это двустороннее транзитивное доверие леса, настроенное с проверкой подлинности на уровне леса. Когда я смотрю на объекты TDO в каждом домене, я вижу, что у domainB есть TDO для domainA и domainC, но у domainC есть только TDO для domainB. domainA также имеет TDO только для domainB. Я вижу, что то же самое отражается в доменах Active Directory и доверительных отношениях в каждом домене.
При выборе раскрывающегося списка «Войти в» на компьютере с доменом C я вижу в списке только domainB и domainC. При выборе раскрывающегося списка «Войти в» на компьютере с доменом B я вижу в списке domainB, domainC и domainA. При выборе раскрывающегося списка «Войти в» на компьютере domainA я вижу в списке только domainA и domainB.
Межлесное разрешение DNS-имен работает между всеми тремя доменами через серверы условной пересылки между domainA и domainB, и я могу успешно запрашивать записи AD SRV в domainA из domainC и наоборот.
Я не понимаю транзитивность домена в доверительных отношениях между лесами? Разве транзитивность не должна распространяться от domainC к domainA и наоборот?
редактировать
На основании ответа Райана:
Я начал думать о том же, но у меня нет непосредственного опыта работы с Forest Trust, где существует дочерний домен, поэтому я не знаю наверняка, что я должен видеть. Хотя транзитивность должна существовать между доменами A и C, это не обязательно подразумевает «видимость». Я бегал nltest /dclist, nltest /dsgetdc и nltest /dnsgetdc и все успешно возвращаются из доменов A в C и наоборот. Что меня озадачило, так это то, что при попытке добавить пользователя в локальную группу домена в домене A я могу видеть только домен B в Locations, а не домен C. Это может быть ожидаемым поведением, но кажется странным. например, если бы я хотел добавить пользователя домена C в локальную группу домена «Пользователи удаленного рабочего стола» в домене, AI не смог бы туда попасть, потому что я не вижу домен C в местах в домене A. Нет возможности «вложить» пользователь домена C в группе домена B, а затем добавьте группу домена B в группу домена A (из-за области действия группы). Итак, если я хочу предоставить доступ пользователям домена C для входа на серверы RDS в домене A, как мне этого добиться?
Я считаю, что то, что вы видите в раскрывающемся списке «Войти в» на члене домена C, является нормальным поведением. В этом раскрывающемся списке будут отображаться только соседние домены (транзитивность не учитывается), но это не должно мешать вам войти в систему члену DomainC с именем пользователя DomainA \ joeqwerty или joeqwerty @ DomainA. Если для вас очень важно иметь возможность видеть DomainA в раскрывающемся списке, когда вы находитесь на компьютере в DomainC, вы можете добиться этого с помощью ярлыка доверия.
В этом документе есть несколько хороших мудрых советов:
http://technet.microsoft.com/en-us/library/cc773178(v=WS.10).aspx
Такие как,
Ограничения поиска доверия
Когда клиент ищет путь доверия, поиск ограничивается доверительными отношениями, которые устанавливаются непосредственно с доменом, и теми, которые являются транзитивными в пределах леса. Дочерний домен, например, не может использовать внешнее доверие между своим родительским доменом и доменом в другом лесу. Это связано с тем, что должен быть построен полный путь доверия, прежде чем клиент сможет начать свой путь по пути к запрошенному домену ресурсов. Windows Server 2003 не поддерживает слепых обращений; если клиент не может определить путь доверия, он не будет пытаться искать доступ к запрошенному ресурсу в другом домене. Дочерние домены не могут идентифицировать внешние доверительные отношения или доверительные отношения области для органов безопасности за пределами своего леса, потому что TDO, представляющие эти доверительные отношения, публикуются только в домене, который разделяет доверие, а не в глобальных каталогах. Таким образом, клиенты не знают о доверительных отношениях, которые их домены разделяют с органами безопасности, отличными от их родительских или дочерних доменов, и поэтому не могут использовать их для доступа к ресурсам.
редактировать
На основе вашего редактирования:
Например, если я хочу добавить пользователя домена C в локальную группу домена «Пользователи удаленного рабочего стола» в домене A, я не могу туда попасть, потому что не вижу домен C в местах в домене A.
Это может быть педантично, но я лично не стал бы добавлять пользователя в локальную группу домена «Пользователи удаленного рабочего стола». Я бы вложил туда только группы безопасности, а не отдельных пользователей / учетные записи. В статьях TechNet, ссылки на которые приведены ниже, также рекомендуется использовать и встраивать группы безопасности управления доступом на основе ролей в качестве передовой практики, а не назначать разрешения для отдельных пользователей для ресурсов.
Во всяком случае, из ссылки TechNet ниже:
• Группы с локальной областью действия домена могут иметь следующих членов: учетные записи, группы с универсальной областью действия и группы с глобальной областью действия, все из любого домена. Эта группа также может иметь в качестве членов другие группы с локальной областью домена из того же домена.
И,
Чтобы сгруппировать пользователей из одного леса, которым требуется одинаковый доступ к одним и тем же ресурсам в другом лесу, создайте универсальные группы, соответствующие ролям глобальной группы. Например, в ForestA создайте универсальную группу с именем SalesAccountsOrders и добавьте в нее глобальные группы SalesOrder и AccountsOrder.
Следует иметь в виду еще две вещи, которые могут помочь вам в достижении этой цели: группы с ограниченным доступом групповой политики для добавления желаемой группы к пользователям удаленного рабочего стола и право пользователя «Разрешить вход через службы терминалов».
Возможно, вы не сможете графически просматривать учетные записи в другом лесу посредством транзитивного доверия, но просто введите полное имя учетной записи, например GroupInDomainA@DomainA.com или DomainA\GroupInDomainA, и т.д.
Дополнительные ресурсы:
http://technet.microsoft.com/en-us/library/cc772808(v=WS.10).aspx
http://technet.microsoft.com/en-us/library/cc776499(v=ws.10).aspx