Назад | Перейти на главную страницу

Windows 2008 R2 Folder Sharing across domain displays <unknown contact=""></unknown>

[Windows Server 2008 R2 SP1, последние исправления по состоянию на 15 марта 2013 г.]. У меня есть группа безопасности под названием «ИТ» в Домене 1. У меня есть server2 в Domain2. Существует одностороннее доверие от домена 1 к домену 2. Я хочу предоставить общий доступ к папке под названием «Приложения» на сервере 2, чтобы ИТ-группа домена 1 могла получить к ней доступ. Делюсь успешно, но что-то странное. Когда я изначально добавил Domain1 \ IT в качестве группы для доступа к общей папке, он появился с правильным значком и текстом в диалоговом окне общего доступа. Но когда я снова открываю диалоговое окно «Совместное использование» для просмотра разрешений, требуется очень долго перечислять, а потом наконец показывает? значок с текстом «<Неизвестный контакт>». Общая папка правильно доступна ИТ-группе в Домене 1, но это заставляет меня чувствовать, что что-то не так. Кто-нибудь знает почему?

Когда между доменом в лесу и доменом вне этого леса устанавливается доверие, участники безопасности из внешнего домена могут получать доступ к ресурсам во внутреннем домене. Active Directory создает объект внешнего участника безопасности во внутреннем домене для представления каждого участника безопасности из доверенного внешнего домена. Эти внешние участники безопасности могут стать членами локальных групп домена во внутреннем домене. Объекты каталога для сторонних участников безопасности создаются Active Directory и не должны изменяться вручную. Вы можете просматривать объекты сторонних участников безопасности из Active Directory - пользователи и компьютеры, включив расширенные функции.

Итак, ваш «Неизвестный контакт» - это так называемый иностранный участник безопасности в Domain2. В контексте именования по умолчанию вашего каталога есть контейнер по адресу CN=ForeignSecurityPrincipals,DC=domain2,DC=com. Внутри этого контейнера должны быть указатели, которые Active Directory будет использовать для разрешения всех людей из домена 1, известных домену 2. Domain2 знает SID, но он должен попросить Domain1 любезно преобразовать этот SID в SamAccountName.

Поскольку ваше доверие одностороннее, Domain2 не может этого сделать, потому что Domain1 ему не доверяет.

Вы можете включить анонимную трансляцию SID в Domain1, но это угроза безопасности. Или вы можете сделать свое доверие двусторонним.

То, что у вас есть сейчас, «Неизвестный контакт», не мешает ничему работать, как вы заметили, поскольку SID достаточен для проверки доверия леса. Сейчас это просто эстетическая проблема.

Дополнительная документация MS:

Реализация

LookupAccountSid вызовет LsaLookupSids с одним идентификатором безопасности для разрешения. Итак, LsaLookupSids рассматривается в этом разделе.

LSA на компьютере, на который отправляется вызов (с использованием интерфейса LSA RPC), разрешит идентификаторы безопасности, которые он может сопоставить, и отправит оставшиеся неразрешенные идентификаторы безопасности на контроллер домена в основном домене. Контроллер домена будет преобразовывать дополнительные идентификаторы безопасности в имена учетных записей из локальной базы данных, включая идентификаторы безопасности, найденные в SidHistory в глобальном каталоге.

Если там невозможно разрешить SID, контроллер домена отправит оставшиеся SID контроллерам домена в доверенном домене, где доменная часть SID совпадает с информацией о доверии.

И, наконец, этот фрагмент из блога Microsoft AskDS (кстати, отличный блог):

Предполагая, что порты открыты, есть какая-то другая часть, блокирующая перевод. Чаще всего мы видим это, когда задействовано одностороннее доверие и анонимные переводы заблокированы. Вы можете легко разрешить анонимный перевод SID / имени в групповой политике. Эта политика применяется только к контроллерам домена, поскольку они являются серверами, которые фактически будут обрабатывать запрос на перевод.

http://blogs.technet.com/b/askds/archive/2011/07/28/troubleshooting-sid-translation-failures-from-the-obvious-to-the-not-so-obvious.aspx

Редактировать: В качестве обходного пути вы можете рассмотреть возможность создания группы безопасности в Домене 2 под названием «Люди, которые могут получить доступ к приложениям на Сервере 2» и добавить участников-пользователей из Домена 1 в эту группу.