Доверительные отношения с доменом: Восстанавливаем доверительные отношения в домене

Ошибка «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» при выполнении входа в Windows 7

Проблема

При входе в систему на компьютере с Windows 7 в доменной среде появляется следующее сообщение об ошибке:

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом.

Решение

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

1. Используя учетную запись локального администратора, войдите в систему.

2. Откройте менюПуск, Нажмите и удерживайте (или щелкните правой кнопкой мыши) Компьютер > Свойства.

3. Нажмите кнопкуИзменить настройки рядом с названием компьютера.

4. На вкладке Имя компьютера щелкните

   Изменить.

5. Под заголовком Член группы выберите Рабочая группа, введите имя рабочей группы и нажмите OK.

6. В ответ на предложение перезагрузить компьютер нажмите кнопку OK.

7. На вкладке Имя компьютера снова выберитеИзменить.

8. Под заголовком Член группы выберите Домен, и введите имя домена.

9. НажмитеOK, и введите учетные данные пользователя, который авторизован в данном домене.

10. В ответ на предложение перезагрузить компьютер нажмите кнопку OK.

11. Перезагрузите компьютер.

Как установить доверительные отношения между компьютером и основным доменом

Здравствуйте Уважаемые читатели Хабрахабра! В просторах интернета каждый из нас может найти много отдельных статей о не прохождении аутентификации компьютера через домен-контроллер, если точнее сказать, компьютер подключенный к домену теряет связь с ним.

Итак, приступим к изучению этой проблемы.

У многих IT – инженеров, которые работают в больших и малых компаниях, имеются компьютеры с операционной системой Windows 7, 8.1 и т.п. и все эти компьютеры подключены к доменной сети (DC).

Данная проблема происходит из-за того, что сетевой протокол Kerberos не может синхронизироваться и пройти аутентификацию с компьютером (The trust relationship between this workstation and the primary domain failed), который подключен к домену. Тогда мы можем увидеть такую ошибку (см. фото ниже).

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

Используя Windows Batch scripting, я хочу создать bat file и автоматизировать процесс создания и добавления локального админа. Единственное, что нам будет необходимо, так это после создания данного файла запустить его.

Открываем наш текстовой редактор, вписываем команду, которая показана внизу.

net user admin Ww123456 /add /active:yes
	
WMIC USERACCOUNT WHERE "Name='admin'" SET PasswordExpires=FALSE
	
net localgroup Administrators admin /add 

net localgroup Users admin /delete 

netsh advfirewall set allprofiles state off

Пройдем все команды по пунктам для устранения неясных моментов.

• net user admin (вместо слова админ Вы можете добавить любое имя, которое Вас устраивает, по умолчанию ставится administrator, в моем случае это admin).

Далее мы видем пароль, который я там поставил Ww123456(Вы можете поставить любой запоминающийся для Вас пароль).

После мы видем /add /active:yes –добавить и активировать: ДА

• WMIC USERACCOUNT WHERE «Name=’admin’» SET PasswordExpires=FALSE – данная команда означает, что админ, который добавляется, имел постоянный пароль без срока действия (см. картинку ниже).

• Третий и четвертый пункт связаны между собой тем, что по умолчанию, когда создается локальный админ в пункте Member Of стоит Users (см. фото). Нам он не нужен (Users), потому что мы создаем полноправного администратора для нашей ОС. Поэтому четвертая команда — net localgroup Users admin /delete – удаляет Users, а предыдущая команда — net localgroup Administrators admin /add, добавляет администратора (см. фото).

• Последняя команда- netsh advfirewall set allprofiles state off, отключает брандмаузер Windows-a.
Иногда, чтобы установить какую-либо программу или дать какую-либо команду в Windows-e необходимо отключить firewall (После запуска скрипта Вы можете ввести команду- netsh advfirewall set allprofiles state on и включить его заново. У меня по умолчанию стоит off, так как я использую сторонний брандмаузер. Данный момент на усмотрение каждого лично).

Далее идем к нашему блокноту, нажимаем File, save as… (сохранить как…) вводим имя нашего скрипта( в моем случае: localadmin).Затем ставим точку (.) и пишем формат скрипта bat. Выбираем место, где сохранить данную запись и нажимаем save. Более детально показано на картинке.

Получается вот такой скрипт (см. фото).

Данный скрипт при запуске необходимо открывать от имени администратора:

• Нажимаем правую кнопку мыши и Run as administrator (см. фото).

После запуска скрипта у Вас должно появиться вот такое окошко (см. фото).

Если по каким-либо причинам выйдет ошибка, то в 90% таких случаев это связано с тем, что у Вас образ с которого Вы установили Windows, имеет нелицензионный характер, какие-либо repack или т.п. Скачивайте и используйте лицензионный и проверенный софт.

После удачного добавления локального админа, Вы можете этот скрипт запустить на всех рабочих машинах в Вашем офисе, в которых установлена ОС Windows.

Если у Вас когда-нибудь появится такая ошибка: The trust relationship between this workstation and the primary domain failed- Вам нужно будет только сделать switch user и где логин написать.\admin (запомните! В начале до слеша ставится точка!), далее внизу вводите пароль, который Вы добавили в Ваш скрипт (в моем случае: Ww123456). После этого Вы заходите на рабочую ОС.

Осталось снять наш компьютер с домена и добавить в Workgroup-у. Вместо Workgroup-а вписываем любую букву (см. фото).

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

После перезагрузки ещё раз заходим под нашим локальным админом и дальше уже добавляем компьютер к нашему домену. Система в очередной раз требует перезагрузиться и Вуаля! Наш User опять может подключиться к домену без всяких проблем!

P.S – Данная система работает также для серверной части Windows, однако если Вы будете писать такой скрипт для серверов после отключения брандмаузера необходимо будет включить его еще раз (до — netsh advfirewall set allprofiles state off, после netsh advfirewall set allprofiles state on).

Благодарю за внимание!

Потеря доверительного отношения с доменом Windows и Active Directory — Блог

В обслуживаемой организации у некоторых сотрудников эпизодически возникала ошибка:

По наблюдениям, возникала данная ошибка у сотрудников чаще всего после отпусков, либо длительных командировок. Исследование показало, что это связано с несоответствием вариантов паролей, хранящихся на рабочей станции и домене, при долгом отсутствии компьютера в корпоративной сети, не происходили обновления OS и обновление пароля для компьютера. При появлении компьютера в корпоративной сети после простоя происходило обновление пароля и установка обновление ОС. При следующем запуске ОС может запросить восстановление системы что приводит к откату состояния системы и как следствие возврат к предыдущему паролю для компьютера, у домена для данного компьютера остаётся сохранён новый пароль.

Пути решения

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

Решение 1 — Повторное введение в домен

Самый простой способ в соответствии со статьёй рекомендации с support.microsoft
При удалении компьютера из домена и повторном введении в домен, компьютер получает новый SID и теряет членство в группах.
Возможен вариант без изменения имени компьютера на контролере домена открываем оснастку «Active Directory Users and Computers» выбираем нужный компьютер после чего в контекстном меню выбираем «Reset Account», теперь на компьютере под учётной записью локального администратора заново вводим компьютер в домен (данный вариант был использован нами при решении проблемы, простой и надёжный как советский консервный ключ).

Данный способ работает всегда.

Минусы:
Необходимость активной учётной записи локального администратора или личное присутствие.
При удалении компьютера из домена необходимо будет повторно добавлять для него необходимые группы.

Решение 2 — Использование командлета PowerShell

PowerShell должен быть версии 3 (начиная с Windows 8/Server 2012 входит в состав системы, для более ранних версий можно установить отдельно https://www.microsoft.com/en-us/download/details.aspx?id=34595), необходимо войти под локальным администратором и запустить с правами администратора.

Reset-ComputerMachinePassword -Server DC -Credential Domain\Admin

—Server DC вместо DC имя вашего контролера домена (если контроллеров домена несколько, то можно указать любой, желательно из того же сегмента сети)
—Credential Domain / Admin вместо Domain/Admin указать данные домена и пользователя с правом добавления в домен.
После удачного завершения команды не выводит никаких сообщений, выходим из локальной учётной записи и заходим на компьютере в доменную учётную запись, перезагрузка не требуется.

Такой же результат получим при использовании следующего командлета PowerShell:

Test-ComputerSecureChannel -Repair -Credential domain\user

Вместо Domain\User Укажите Ваш домен и пользователя с правом добавления в домен.

Минусы:
НеобходимPowerShell 3.0 доступный по умолчанию только с версии Windows 8/Server 2012
Запуск программы необходимо выполнить от локального администратора.

Решение 3 — утилита Nltest

Как и в случае с Nlщиками бесполезна в данной ситуации, но может быть полезна при других проблемах и для проверки защищенного сеанса между компьютером и контролером домена, а так же для проверки после ввода компьютера в домен. Итак данная утилита есть на всех современных и не только версиях Windows (в том числе и серверных). На компьютере, что потерял доверие, выполняем следующие команды:

Nltest /query

для проверки безопасного соединения с доменом;

Nltest/sr_reset:YOUDOMAIN

сбрасываем учётную запись компьютера в домене;

Nltest/sc_change_pwd:YOUDOMAIN

Изменяем пароль компьютера в Вашем домене.

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

Минусы:
Хоть и данная утилита есть на любом компьютере, запускается она от пользователя под которым Вы вошли в систему и нет возможности ввести данные для авторизации.

Решение 4 — утилита Netdom

Увы с ней тоже не все так гладко, её нет по умолчанию на любом компьютере, на Windows Server она доступна начиная с версии 2008, на рабочие компьютер можно установить из пакета RSAT (средство удалённого администрирования сервера). Для её использования так же необходимо зайти на целевую систему под локальным администратором и выполнить следующие действия:

Netdom resetpwd /Server:DC /UserD:Admin /PasswordD:Password

где:
DC – имя любого доменного контролера.
Admin – учётная запись администратора домена
Password – пароль администратора домена

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

Минусы:
Необходимо запустить командную строку от имени локального администратора.
Данную утилиту необходимо заранее установить на компьютер, а при потере доверительных отношений с доменом у Вас не будет возможности установить ПО от имени доменного администратора или учётной записи с необходимыми правами.

Понимание доверительных отношений | Журнал сетевых решений/LAN

Доверительные отношения в Active Directory еще важнее, чем в NT 4.0. При создании доменов в «лесу доменов» такие отношения устанавливаются автоматически, но, в отличие от NT 4.0, они «транзитивны». Это важное понятие мы разъясним ниже. Кстати, Windows Server 2008 хоть и предлагает множество новинок, но доверительные отношения по-прежнему действуют так же, как в Windows Server 2003.

Для большинства администраторов процесс установления доверительных отношений все еще требует привыкания, поскольку отдельные понятия немного запутаны. В результате в техническом плане возможность связи доменов Windows друг с другом представляется более «загадочной», чем есть на самом деле (см. Рисунок 1). Поэтому сначала остановимся на основных понятиях.

В Active Directory существует два различных вида доверительных отношений: «однонаправленные» и «двунаправленные». В первом случае один домен доверяет другому, но не наоборот. Пользователи Домена 1 могут получить доступ к ресурсам Домена 2, однако у пользователей Домена 2 нет доступа к ресурсам Домена 1. Естественно, возможен и обратный случай. Другие варианты доверительных отношений: «исходящие» и «входящие». При исходящих доверительных отношениях Домен 1 доверяет Домену 2, т. е. пользователи Домена 2 могут обращаться к ресурсам Домена 1.

При таком процессе домен, от которого доверительные отношения исходят, является доверяющим доменом (Trusting Domain). Домен с входящими доверительными отношениями — доверенный домен (Trusted Domain), в нем создаются учетные записи пользователей, обладающих правами в доверяющем домене.

В Windows NT 4.0 тоже можно было устанавливать доверительные отношения, но не транзитивные. Если в Windows NT 4.0 создавались доверительные отношения между доменами А и В, а также между доменами В и С, то это не значило, что домен А автоматически будет доверять домену С или, наоборот, домен С — домену А. Эту связь приходилось устанавливать вручную. В Active Directory делается иначе. Домены можно связывать практически без ограничений через домены, дочерние домены и деревья с автоматическим установлением между ними доверительных отношений. В Active Directory каждый домен доверяет любому другому домену, если является частью того же леса. Устанавливать доверительные отношения вручную возможно, но необходимости в этом уже нет (ключевая фраза: урезанные доверительные отношения).

В отдельном лесу существует определенный регулирующий алгоритм: доверительные отношения автоматически создаются между выше- и ниже-стоящими доменами. Microsoft обозначает этот тип как «подчиненные доверительные отношения». Кроме того, доверительные отношения автоматически создаются между корневыми доменами отдельных деревьев. Однако доверительных отношений между подчиненными доменами различных деревьев не существует. Они доверяют друг другу на основе транзитивных доверительных отношений (см. Рисунок 2). Доверительные отношения между корневыми доменами различных лесов называются «доверительными отношениями между лесами» (Forest Trust).

Как уже говорилось, дополнительные доверительные отношения можно определять и вручную. Это требуется по различным причинам. Так, возможны, к примеру, внешние доверительные отношения к доменам Windows NT 4.0 или отдельным доменам другого леса.
В Windows Server 2003 появились сохранившиеся в Windows Server 2008 доверительные отношения между лесами, когда связываются корневые домены двух различных лесов. В результате все домены обеих структур связаны автоматически транзитивными доверительными отношениями. Доверительные отношения можно создавать между подчиненными доменами разных деревьев в пределах одного леса. Они называются «прямыми доверительными отношениями» (Shortcut Trusts). Этот вид доверительных отношений часто используется, чтобы ускорить доступ к ресурсам между подчиненными доменами различных деревьев в одном лесу.

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

Управление доверительными отношениями осуществляется с помощью дополнительного модуля (Snap-in) «Домены Active Directory и доверительные отношения». Если вызвать в нем свойства какого-либо домена, то на соответствующей вкладке можно найти все его доверительные отношения и задать новые. Если требуется создать доверительное отношение с внешним доменом, то сначала нужно убедиться в том, что распознавание имен между доменами осуществляется без ошибок. Лишь когда обеспечено стабильное и надежное разрешение имен, можно устанавливать доверительные отношения. Здесь будет полезна оптимальная инфраструктура серверов DNS/WINS. Дело в том, что если нужно создать доверительные отношения с доменом Windows NT 4.0, то сервер WINS подходит лучше, чем DNS. В принципе, связь между доменом Windows NT 4.0 и доменом Active Directory можно установить и без WINS, но она будет нестабильной и сложно реализуемой.

Чтобы создать доверительные отношения, в дополнительном модуле «Домены Active Directory и доверительные отношения» необходимо вызвать свойства того домена, от которого они должны исходить. Во вкладке «Доверительные отношения» нужно нажать на кнопку «Новое доверительное отношение». Windows запускает ассистента. На второй странице отображается имя домена, к которому будет устанавливаться доверительное отношение. Если это домен Active Directory, то следует использовать имя DNS, в то время как для соединения с доменом Windows NT 4.0 лучшим выбором будет имя NetBIOS. Затем ассистент проверяет, возможна ли связь с доменом и должны ли доверительные отношения быть однонаправленными или двунаправленными (см. Рисунок 3).

При двунаправленном соединении пользователи каждого из доменов могут аутентифицироваться в другом домене для получения доступа к ресурсам. При выборе «Однонаправленные: входящие» устанавливается, что данный домен является доверенным,
т. е. пользователь этого домена может аутентифицироваться в другом домене и обращаться к его ресурсам. В варианте «Однонаправленные: исходящие» пользователи другого домена могут регистрироваться в нем, а вот пользователи этого домена в другом — нет.

Затем определяется область аутентификации доверительных отношений. Большинство администраторов используют вариант «Общедоменная аутентификация». При этом пользователи одного домена получают доступ к ресурсам другого через групповое членство или прямое разрешение. Если же выбирается вариант «Избирательная аутентификация», то для каждого сервера, к которому разрешен доступ пользователей другого домена, в локальных настройках безопасности или правилах должна активироваться опция «Может аутентифицировать». Такая настройка повышает безопасность, но одновременно усложняется структура распределения прав. Пользователям другого домена автоматически отказывается в доступе к отдельным серверам предприятия.

Теперь следует отменить отказ для каждого отдельного сервера, а затем установить пароль для доверительных отношений, который позднее потребуется для верификации и установления доверительных отношений в другом направлении. В следующем окне нужно выбрать, будет ли доверительное отношение проверяться. При создании доверительных отношений с доменом Windows NT 4.0 необходимо сначала установить их со стороны этого домена. Пользователи получают доступ к ресурсам лишь после верификации доверительных отношений как активных. Если создание доверительных отношений не удается, то обычно это происходит из-за проблем с разрешением имен или наличием прав.

ФИЛЬТРАЦИЯ SID В ДОВЕРИТЕЛЬНЫХ ОТНОШЕНИЯХ

После завершения установления внеш-них доверительных отношений автоматически высвечивается указание, что для этих отношений был активирован фильтр идентификаторов пользователей (SID). Это происходит автоматически, если доверительные отношения создаются контроллером домена под управлением Windows Server 2003 или Windows Server 2000 (SP4 и выше). Фильтрация SID защищает исходящие доверительные отношения. Она призвана воспрепятствовать раздаче администраторами доверенных доменов неправомерных полномочий в пределах доверяющих доменов. Фильтр SID следит за тем, чтобы в доверяющем домене аутентифицировались только те пользователи доверенного домена, чьи SID содержат SID этого домена. Если деактивировать фильтрацию SID, то внешний пользователь, обладающий правами администратора в доверенном домене, сможет прослушать сетевой трафик доверяющего домена, определить SID администратора, а затем присоединить этот SID к своей истории SID и заполучить права администратора в доверяющем домене.

Однако при активации фильтра SID может случиться так, что будет игнорироваться история SID пользователей, получивших ее из других доменов в результате миграции. Тогда возникнут проблемы с аутентификацией при доступе к ресурсам, поэтому фильтр SID не всегда можно использовать. Если фильтр применяется для укрепления доверительных отношений Windows NT 4.0, то здесь проблемы возникают реже, чем при построении внешних доверительных отношений к домену в Active Directory. Если универсальной группе из Active Directory доверенного домена выдаются разрешения на ресурсы доверяющего домена, то нужно убедиться в том, что эта группа была создана именно в доверенном домене, а не в каком-либо другом домене Active Directory. В противном случае она не содержит SID доверенного домена, и фильтр SID не разрешит доступ к ресурсам доверяющего домена.

Универсальные группы состоят из локальных и глобальных групп. Как локальные, они могут включать участ-ников из всего леса. Как глобальные, они видны во всех доменах. В случае универсальных групп на глобальные серверы каталогов тиражируются не только сведения о существовании этой группы, но и информация обо всех ее членах. Иными словами, если в универсальной группе много членов, то придется тиражировать большой объем информации. Деактивация фильтрации SID осуществляется через программу командной строки netdom.exe (см. Рисунок 4). Этот инструмент включен в комплект инструментов поддержки Windows, которые находятся в папке Support на диске Windows Server 2003. Их рекомендуется инсталлировать на каждый сервер, поскольку они включают полезные диагностические инструменты, к примеру, dcdiag.exe или netdiag.exe. Такие инструменты требуются во многих местах для администрирования Active Directory. Чтобы деактивировать фильтрацию SID, в командной строке необходимо ввести команду Netdom trust /domain: / quarantine:no /userD: / passwordD:.

ДОВЕРИТЕЛЬНЫЕ ОТНОШЕНИЯ К ДОМЕНАМ NT 4.0

Фильтрация SID активируется заново очень простым способом. Опцию /quarantine нужно установить на :yes: Netdom trust /domain: /quarantine:yes /userD: /passwordD:.

Иногда возникают проблемы с ус-тановлением доверительных отношений. Виной тому — ошибочное распознавание имен, защищенные маршрутизаторы между различными подсетями или ошибки на серверах WINS. Если не получается создать доверительные отношения между двумя контроллерами доменов, то часто помогает создание файла lmhosts на обоих серверах. Этот файл находится в папке Windowssystem32driversetc. Для обеспечения распознавания имен файл нужно переименовать в lmhosts без расширения. В указанном файле настраивается разрешение доменов, так что серверы DNS или WINS будут пропускаться. Для этого нужно добавить в файл следующие строки:

#pre #dom:
”

Не удалось установить доверительные отношения

Введение

Привет! Бывает такое, что требуется восстановить компьютер или сам контроллер домена из точки восстановления/снэпшота (если это виртуальная машина). И частенько это приводит к потере доверительных отношений между компьютером и доменом. Мы получаем ошибку:

Не удалось восстановить доверительные отношения между рабочей станцией и доменом.

Или в английском варианте: The trust relationship between this workstation and the primary domain failed.

Или

База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией.

В английском варианте: The security database on the server does not have a computer account for this workstation trust relationship.

Для того, чтобы восстановить доверительные отношения можно пойти тремя способами. Давайте их рассмотрим ниже.

Да, для того чтобы восстановить доверительные отношения с доменом необходимо на компьютер зайти под локальной учётной записью. Если доступа к локальной учётной записи нет, то необходимо сбросить пароль Windows.

Восстановить доверительные отношения путём повторного ввода в домен

Самый долгий, но самый верный способ, который поможет восстановить доверительные отношения с доменом при любом раскладе! Работет железебетонно 😎.

Открываем свойства системы Win + R sysdm.cpl Enter и переходим в Изменение имени компьютера или домена через кнопку изменить…. Возвращаем компьютер в любую рабочую группу (придумываем сами), сохраняемся без перезагрузки. Теперь повторно вводим компьютер в домен и перезагружаемся чтобы восстановить доверительные отношения с доменом.

Как восстановить доверительные отношения через PowerShell

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

У этого способа есть один минус. Он не работает на старых системах, так что у кого до сих пор Windows XP 😨, то сносите это гавно мамонта и установите нормальную ось переходите сразу к следующему способу.

Итак, запускаем PowerShell Win + R powershell Shift + Enter. Давайте проверим, действительно ли компьютеру не удалось установить доверительные отношения через проверку канала между локальным компьютером и его доменом:

Test-ComputerSecureChannel –verbose

Если False – то нет доверия этому компьютеру 😆; если True – то всё в порядке. Если у вас ошибка: не удалось установить доверительные отношения то скорее всего вы увидите False. Для того, чтобы восстановить доверительные отношения в домене необходмио cбросить канал между локальным компьютером и его доменом командой:

Test-ComputerSecureChannel –Repair

Если не сработала команда выше, то используйте другую команду (с запросом учётных данных):

Test-ComputerSecureChannel –Repair –Credential (Get-Credential)

В этом случае будет запрошен логин и пароль администратора домена. Вводим его и подтверждаем сброс канала.

Поздавляю! Вам удалось восстановить доверительные отношения в домене. Это можно проверить выполнив эту же команду с ключом –verbose:

Test-ComputerSecureChannel –verbose

И в заключение хочу добавить:

Если в у вас несколько контроллеров домена, то проверить канал между локальным компьютером и конкретным контроллером домена можно выполнив команду:

Test-ComputerSecureChannel -Server "dc-03.itlocate.ru"        
    

Где dc-03.itlocate.ru – ваш контроллер домена.

Как восстановить доверительные отношения через командную строку (cmd)

Восстановить доверительные отношения можно при помощи утилиты netdom. Она идёт штатно вместе с Windows Server от 2008. На рабочие машины её можно установить с RSAT (Скачать средств администрирования windows можно с официального сайта Microsoft). Для использования утилиты Netdom необходимо командную строку запустить от имени Администратора. И выполнить команду:

Netdom resetpwd /Server:dc-03 /UserD:admin /PasswordD:pass

Где dc-03 – контроллер домена; admin – учётная запись администратора домена; pass – пароль от этой учётной записи.

Теперь ошибка Не удалось установить доверительные отношения устарнена до следующего отката системы с точки восстановления 😅.

Восстановление доверительных отношений в домене

Рано или поздно, но администраторам доменной сети на базе продуктов Microsoft приходится сталкиваться с двумя похожими ошибками: «Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом» и «База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией». Помимо данных сообщений также наблюдается невозможность зайти в компьютер под доменными учетными записями.

Разберем причины появления ошибок и методы их лечения.

В доменных сетях Windows всем компьютерам и учетным записям пользователей присваиваются свои идентификаторы безопасности (SID). В сущности, можно сказать, что каждый компьютер в домене также обладает своей учетной записью типа «компьютер». По аналогии с учетной записью пользователя, такая учетная запись тоже будет иметь пароль. Данный пароль создается и предъявляется компьютером контроллеру домена автоматически. Таким образом между рабочими станциями и контроллером домена и формируются те доверительные отношения, о которых упоминается в тексте ошибок.

Каждые 30 дней или при первом включении после длительного перерыва компьютер автоматически изменяет свой пароль. В теории всё красиво, и машина вроде бы не может ошибиться и «ввести» неправильный пароль. Однако иногда такое происходит по нескольким причинам.

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом

Самой распространенной причиной является откат операционной системы Windows на более ранее состояние. Естественно, чем раньше была создана точка восстановления, тем больше вероятность появления ошибки. В данном случае после восстановления компьютер примется предъявлять контроллеру домена устаревший пароль, а контроллер уже содержит новый.

Ошибка может возникнуть и в случае нахождения в домене двух станций с одинаковыми именами. Такая ситуация может возникнуть, например, если дать новому компьютеру имя выведенной из эксплуатации машины, а затем снова включить старый компьютер, забыв его переименовать.

С возможными причинами разобрались. Теперь о решении проблемы. Способов несколько, но все они так или иначе заключаются в переустановке учетной записи компьютера или сбросе его пароля.

Первый способ заключается в переустановке учетной записи в Active Directory.

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

Далее компьютер снова необходимо ввести в домен и перезагрузить. После этого уже можно заходить доменным пользователем.

Вторым способом является сброс пароля через Windows PowerShell. Оговоримся однако, что нам потребуется PowerShell версии 3.0 и выше. Также заходим на компьютер локальным администратором и вводим следующий командлет:

Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin

В данном случае -Server это имя контроллера домена, а -Credential это учетная запись администратора домена.

Командлет не выведет никаких сообщений в случае своего успешного завершения. Данный способ привлекателен тем, что перезагрузка не требуется — достаточно сменить пользователя и войти в машину под доменной учетной записью.

Третий способ сброса пароля компьютера заключается в использовании утилиты Netdom, которая появилась в серверных ОС Microsoft начиная с Windows Server 2008. В клиентских операционных системах её можно добавить с помощью пакета RSAT (Средства удаленного администрирования сервера).

Как и в предыдущих способах, этот тоже выполняется из-под локального администратора. Введите в командной строке:

Netdom resetpwd /Server:DomainController /UserD:Admin /PasswordD:Password /SecurePasswordPrompt

Принцип схож с тем, что мы видели в примере с PowerShell. /Server это контроллер домена, /UserD — учетная запись администратора домена, /PasswordD — пароль от учетной записи администратора домена. Вы также можете использовать параметр /SecurePasswordPrompt, чтобы скрыть пароль за звездочками. Перезагрузка также не требуется.

Способ четвертый и последний в нашей статье заключается в использовании утилиты Nltest, которая по умолчанию есть на любой рабочей станции.

Запустим утилиту в командной строке и для начала проверим безопасное соединение с доменом:

Nltest /query

Затем сбросим учетную запись компьютера в домене:

Nltest /sc_reset:Domain

И, наконец, сбросим пароль компьютера:

Nltest /sc_change_pwd:Domain

К сожалению, у такой прекрасной утилиты есть свои минусы. В первую очередь, утилита не спрашивает логин/пароль администратора домена и, соответственно, исполняется из-под запустившего его пользователя, что может привести к ошибке доступа.

Есть и еще одна ошибка, связанная с доверительными отношениями внутри домена и вынесенная в начало этой статьи. Выглядит она следующим образом:

В данном случае нам опять же поможет утилита Nltest. Снова проверяем безопасное соединение с доменом:

Nltest /query

Если появится сообщение об ошибке, то для исправления ошибки достаточно установить этот патч. Если же статус подключения будет NERR_Success, то выполняем следующие действия:

netdom reset /d:Domain ComputerName

или

netdom reset /d:Domain ComputerName /server:DomainController /uo:Admin /po:Password

Во втором случае мы явно указываем контроллер домена, с которым хотим установить доверительные отношения.

Утилита порадует нас сообщением о том, что безопасный канал был сброшен и новое соединение установлено.

Итак, вот несколько способов восстановить доверительные отношения в домене. Надеюсь, что применять их вам придется как можно реже. 🙂

Восстанавливаем доверие в домене | ИТ Заметки

Как и учетные записи пользователей, учетные записи компьютеров в домене имеют свой пароль. Пароль этот нужен для установления так называемых «доверительных отношений» между рабочей станцией и доменом.  Пароли для компьютеров генерируются автоматически и также автоматически каждые 30 дней изменяются.

Домен хранит текущий пароль компьютера, а также предыдущий, на всякий случай 🙂 . Если пароль изменится дважды, то компьютер, использующий старый пароль, не сможет пройти проверку подлинности в домене и установить безопасное соединение. Рассинхронизация паролей может произойти по разным причинам, например компьютер был восстановлен из резервной копии, на нем была произведена переустановка ОС или он просто был долгое время выключен. В результате при попытке входа в домен нам будет выдано сообщение о том, что не удается установить доверительные отношения с доменом.

Для восстановления доверительных отношений существует несколько способов. Рассмотрим их все по порядку.

Способ первый

Открываем оснастку «Active Directory Users and Computers» и находим в ней нужный компьютер. Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «Reset Account». Затем заходим на компьютер под локальной учетной записью и заново вводим его в домен.

Примечание. Кое где встречаются рекомендации удалить компьютер из домена и заново завести. Это тоже работает, однако при этом компьютер получает новый SID и теряет членство в группах, что может привести к непредсказуемым последствиям.

Способ этот довольно громоздкий и небыстрый, т.к. требует перезагрузки, однако работает в 100% случаев.

Способ второй

Заходим на компьютер, которому требуется сбросить пароль, открываем командную консоль обязательно от имени администратора и вводим команду:

Netdom Resetpwd /Server:SRV1 /UserD:Administrator /PasswordD:*

где SRV1 — контролер домена, Administrator — административная учетная запись в домене. Дополнительно можно указать параметр /SecurePasswordPrompt, который указывает выводить запрос пароля в специальной форме.

В открывшемся окне вводим учетные данные пользователя и жмем OK. Пароль сброшен и теперь можно зайти на компьютер под доменной учетной записью. Перезагрузка при этом не требуется.

Что интересно, в рекомендациях  по использованию и в справке написано, что команду Netdom Resetpwd можно использовать только для сброса пароля на контролере домена, другие варианты использования не поддерживаются. Однако это не так, и команда также успешно сбрасывает пароль на рядовых серверах и рабочих станциях.

Еще с помощью Netdom можно проверить наличие безопасного соединения с доменом:

Netdom Verify WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*

Или сбросить учетную запись компьютера:

Netdom Reset WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*

где WKS1 — рабочая станция, которой сбрасываем учетку.

Способ достаточно быстрый и действенный, однако есть одно но: по умолчанию утилита Netdom есть только на серверах с установленной ролью  Active Directory Domain Services (AD DS). На клиентских машинах она доступна как часть пакета удаленного администрирования Remote Server Administration Tools (RSAT).

Способ третий

Еще одна утилита командной строки — Nltest. На компьютере, который потерял доверие, выполняем следующие команды:

Nltest /query — проверить безопасное соединение с доменом;

Nltest /sc_reset:Contoso.com — сбросить учетную запись компьютера в домене;

Nltest /sc_change_pwd:Contoso.com — изменить пароль компьютера.

Самый быстрый и доступный способ, ведь утилита Nltest по умолчению есть на любой рабочей станции или сервере. Однако, в отличие от Netdom, в которой предусмотрен ввод учетных данных, Nltest работает в контексте запустившего ее пользователя. Соответственно, зайдя на компьютер под локальной учетной записью и попытавшись выполнить команду можем получить ошибку доступа.

Способ четвертый

PowerShell тоже умеет сбрасывать пароль копьютера и восстанавливать безопасное соеднение с доменом. Для этого существует командлет Test-ComputerSecureChannel . Запущенный без параметров он выдаст состояние защищенного канала — True или False.

Для сброса учетной записи компьютера и защищенного канала можно использовать такую команду:

Test-ComputerSecureChannel -Server SRV1 -Credential Contoso\Administrator -Repair

где SRV1 — контролер домена (указывать не обязательно).

Для сброса пароля также можно также воспользоваться такой командой:

Reset-ComputerMachineChannel -Server SRV1 -Credential Contoso\Administrator

Способ быстрый и удобный, не требующий перезагрузки. Но и здесь есть свои особенности. Ключ -Credential впервые появился  в PowerShell 3.0. Без этого параметра командлет, запущенный из под локального пользователя, выдает ошибку доступа. Получается что данный метод можно использовать только на  Windows 8 и Server 2012, ведь для остальных ОС PowerShell 3.0 пока недоступен.

Как видите, способов восстановления доверительных отношений более чем достаточно. Однако если проблема приобретает постоянный характер, то проще подойти к ее решению с другой стороны.

Изменение параметров смены пароля компьютера

Смена пароля в домене происходит следующим образом:

Каждые 30 дней рабочая станция отправляет ближайшему контролеру домена запрос на изменение пароля учетной записи компьютера. Контролер принимает запрос, пароль изменяется, а затем изменения передаются на все контролеры в домене при следующей репликации.

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

Если настройки необходимо применить к группе компьютеров, то проще всего использовать групповую политику. Настройки, отвечающие за смену паролей, находятся в разделе Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options. Нас интересуют следующие параметры:

Disable machine account password change — отключает на локальной машине запрос на изменение пароля;

Maximum machine account password age — определяет максимальный срок действия пароля компьютера. Этот параметр определяет частоту, с которой член домена будет пытаться изменить пароль. По умолчанию срок составляет 30 дней, максимально можно задать 999 дней;

Refuse machine account password changes — запрещает изменение пароля на контролерах домена. Если этот параметр активировать, то контролеры будут отвергать запросы компьютеров на изменение пароля.

Для одиночной машины можно воспользоваться настройками реестра. Для этого в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters есть два параметра :

 DisablePasswordChange — если равен 1, то запрос на обновление пароля компьютера отключен, 0 — включен.

MaximumPasswordAge — определяет максимальный срок действия пароля компьютера в днях. При желании можно задать более 1 миллиона дней !!!

И в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, только у контролеров домена, параметр:

RefusePasswordChange — если равен 1, то запрещает контролеру домена принимать запрос на изменение пароля. Этот параметр надо задать на всех контролерах в домене.

Вот вроде и все про доверительные отношения. Как видите, доверие в домене — штука тонкая, так что старайтесь его не терять.

https:\\zametkiiit.ru

Руководство по атаке на доверительные домены — damagej0y

Прошло много времени (почти 2 года) с тех пор, как я написал сообщение, посвященное исключительно доверию доменов Active Directory. После погружения в исследование группы я обнаружил несколько тонких заблуждений, которые у меня были ранее относительно трастов и членства в группах. Это, в сочетании с изменениями, внесенными в PowerView в прошлом году, убедило меня опубликовать обновленное руководство по подсчету и атакам на доверительные отношения доменов. Скорее всего, это будет последний пост, посвященный доверию доменов, который я публикую в течение некоторого времени, и на более чем 8000 словах это не совсем легкое чтение (не то, чтобы кто-то читал длинные посты;) В общем, я не просто пишу свои оперативные заметки в блоге. — Я стараюсь писать сообщения, которые функционируют как полные руководства для членов моей команды, в надежде, что эта информация может быть полезна другим (как с наступательной, так и с оборонительной точки зрения.)

Я хочу, чтобы это было как можно более полным, поэтому я расскажу обо всех аспектах трастов в том виде, в каком мы их понимаем в настоящее время. Как и в случае с моими предыдущими сообщениями, я хочу максимально обобщить свои знания по теме на данный момент . Акцент на «данный момент времени». Наши знания и профессионализм постоянно развиваются, и доверительные отношения не исключены. Когда я начал писать о них, у меня было несколько нечетких заблуждений относительно доверительных отношений между доменами. Я никогда не был системным администратором или архитектором AD — мои знания приобретались по частям, что (надеюсь) объясняет пробелы, обнаруженные в моих прошлых сообщениях, и те, которые, я уверен, будут возникать и дальше.

Итак, я собираюсь начать все сначала, на случай, если вы не знакомы с предыдущими сообщениями о трастах, которые я опубликовал. Таким образом, в некоторых частях этого поста будут переработаны определенные элементы и формулировки из предыдущей работы, интегрированные с обновленными знаниями и синтаксисом PowerView. И поскольку это что-то вроде фолианта статьи, я уверен, что где-то есть ошибки и вещи, которые я пропустил, поэтому, когда вы их обнаружите, дайте мне знать, и я обновлю их соответствующим образом!

Самая последняя версия

PowerView всегда будет находиться в ветке разработки PowerSploit.

WTF — это доверие домена?

На высоком уровне доверие домена устанавливает возможность для пользователей в одном домене аутентифицироваться в ресурсах или действовать в качестве участника безопасности в другом домене. У Microsoft есть много информации о доверительных отношениях между доменами, а также «Рекомендации по безопасности для доверительных отношений», и иногда это может немного сбивать с толку. Как описывает Microsoft, « Большинство организаций, имеющих более одного домена, имеют законную потребность в доступе пользователей к общим ресурсам, расположенным в другом домене », а доверительные отношения позволяют организациям с несколькими доменами предоставлять пользователям в отдельных доменах доступ к общим ресурсам. Леса доменов — это наборы контейнеров домена, которые доверяют друг другу. Сами леса также могут иметь между собой доверительные отношения. У Microsoft есть отличный пост о том, как работают доверительные отношения между доменами и лесами. Если вы не знакомы с этой темой, рекомендую вам ознакомиться с ней.

По сути, все, что делает траст, — это связывает системы аутентификации двух доменов и позволяет трафику аутентификации проходить между ними через систему рефералов. Если пользователь запрашивает доступ к имени участника-службы (SPN) ресурса, который находится за пределами домена, в котором он сейчас находится, его контроллер домена вернет специальный реферальный билет, указывающий на центр распределения ключей (KDC, в Windows). случае контроллер домена) чужого домена.

Билет предоставления билета (TGT) пользователя включен в этот реферальный билет TGS-REP (ответ службы предоставления билетов), и этот билет зашифрован / подписан с помощью межсферного доверительного ключа, которым домены ранее обменивались, вместо аккаунт krbtgt первого домена. Этот билет обычно называют «билетом выдачи билетов между областями / TGT». Затем внешний домен проверяет / дешифрует TGT, включенный в переадресацию, расшифровывая его с помощью ранее согласованного межобластного доверительного ключа, и выполняет остальную часть обычного процесса Kerberos.

Шон Меткалф подробно описал этот процесс в своем посте «Все о доверии», и он описывает этот процесс как: « Как только между двумя доменами возникает доверие… служба выдачи билетов каждого домена (« область ») на языке Kerberos) регистрируется в качестве участника безопасности в службе Kerberos (KDC) другого домена. Это позволяет службе выдачи билетов в каждом домене рассматривать службу в другом домене как еще одну службу, обеспечивающую междоменный доступ к службам для ресурсов в другом домене. ”

Итак, в основном, когда внешний домен расшифровывает реферальный билет с согласованным доверительным ключом, он видит TGT пользователя и говорит: « ОК, другой домен уже аутентифицировал этого пользователя и сказал, что это те, кем они себя называют / это группы. пользователь находится внутри, поэтому я доверяю этой информации как точной, потому что я доверяю домену, который отправил переход. “

Вот изображение для визуализации процесса Kerberos через границы доверия:

Целью установления доверия является предоставление пользователям из одного домена доступа к ресурсам (например, локальной группе администраторов на сервере), их вложения в группы или иного использования в качестве участников безопасности в другом домене (например,грамм. для списков управления доступом к объектам AD). Одним из исключений являются доверительные отношения внутри леса (доверительные отношения между доменами, которые существуют в одном лесу Active Directory) — любой домен, созданный в лесу, сохраняет неявные двусторонние транзитивные доверительные отношения с каждым другим доменом в лесу. Это имеет множество последствий, которые будут рассмотрены позже в этом посте.

Но перед этим мы должны рассмотреть еще несколько характеристик трастов.

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

• Родительский / дочерний — часть того же леса — дочерний домен сохраняет неявное двустороннее транзитивное доверие со своим родительским.Это, вероятно, самый распространенный тип доверия, с которым вы можете столкнуться.
• Перекрестная ссылка — также известное как «сокращенное доверие» между дочерними доменами для сокращения времени обращения. Обычно ссылки в сложном лесу должны фильтроваться до корня леса, а затем обратно в целевой домен, поэтому для географически разнесенного сценария перекрестные ссылки могут иметь смысл для сокращения времени проверки подлинности.
• Внешний — неявно нетранзитивное доверие, созданное между разнородными доменами.« Внешние доверительные отношения обеспечивают доступ к ресурсам в домене за пределами леса, к которому еще не подключено доверие леса. ”Внешние доверительные отношения обеспечивают фильтрацию SID, защиту безопасности, о которой будет рассказано далее в этом посте.
• Корень дерева — неявное двустороннее транзитивное доверие между корневым доменом леса и новым корнем дерева, которое вы добавляете. Я не слишком часто сталкивался с доверительными отношениями на основе корня дерева, но, судя по документации Microsoft, они создаются, когда вы создаете новое дерево доменов в лесу.Это доверительные отношения внутри леса, которые сохраняют двустороннюю транзитивность, позволяя дереву иметь отдельное доменное имя (вместо child.parent.com).
• Лес — транзитивное доверие между одним корневым доменом леса и другим корневым доменом леса. Доверительные отношения леса также обеспечивают фильтрацию SID.
• MIT — траст с доменом Kerberos, не совместимым с Windows RFC4120. Я надеюсь еще больше погрузиться в трасты Массачусетского технологического института в будущем.

Транзитивность, а? Другой аспект доверительных отношений между доменами состоит в том, что они транзитивны или нетранзитивны.Процитируем документацию MSDN по транзитивности: « Транзитивное доверие расширяет доверительные отношения на другие домены; Нетранзитивное доверие не распространяет доверительные отношения на другие домены. ”. Это означает, что транзитивные доверительные отношения могут быть связаны, так что пользователи потенциально могут получить доступ к ресурсам в нескольких доменах. Это означает, что если домен A доверяет B, а B доверяет C, то A неявно доверяет C. Если конкретное доверительное отношение является транзитивным, то доверяющий домен может перепаковать TGT пользователя в дополнительные реферальные билеты и перенаправить их на домены , которым доверяет домен .

Также трасты могут быть односторонними или двусторонними. Двунаправленное (двустороннее) доверие на самом деле представляет собой просто два односторонних доверительных отношения. Одностороннее доверие означает, что пользователи и компьютеры в доверенном домене потенциально могут получить доступ к ресурсам в другом доверяющем домене . Одностороннее доверие действует только в одном направлении, отсюда и название. Пользователи и компьютеры в доверяющем домене не могут получить доступ к ресурсам в доверенном домене . У Microsoft есть хорошая диаграмма, чтобы это наглядно представить:

https: // technet.microsoft.com/en-us/library/cc759554(v=ws.10).aspx

Это было что-то, что волновало меня, когда я начинал — с наступательной точки зрения, нас волнует направление доступа , не направление траста . При одностороннем доверии, где A -trusts-> B , если доверие перечислено из A, доверие помечается как исходящее , а если такое же доверие перечисляется из B, доверие помечается как входящее , а потенциальный доступ — от B до A .Это будет иметь больше смысла в разделе Перечень внешних связей .

Зачем заботиться?

Но на самом деле, зачем это нужно?

Доверительные отношения между доменами часто создают непреднамеренные пути доступа между средами. Во многих организациях доверительные отношения были внедрены несколько лет (иногда более 10) назад без особого внимания к безопасности. Некоторые корпоративные организации, которые сосредоточены на приобретении, часто просто «подключают» новую сеть Active Directory компании либо как дочерний домен, либо как внешнее доверие, не полностью учитывая последствия для безопасности.

Поскольку исторически существовало не так много наборов инструментов, которые позволяли бы легко отображать, перечислять и визуализировать риски, связанные с неверно настроенными доверительными отношениями, многие архитекторы доменов не осознают непреднамеренный риск, связанный с их архитектурами доверия Active Directory. Это связано с идеей «неверной конфигурации долга», о которой @ wald0, @cptjesus и я говорили на Derbycon в этом году. Из-за этого различные красные команды (и, вероятно, APTz, как я предполагаю) в течение многих лет с большим успехом злоупотребляли доверительными отношениями Active Directory.

Распространенным сценарием является компрометация домена разработки или дочернего домена и использование этого доступа для перехода в безопасный корень / анклав. Это также открывает возможности для настойчивости — зачем оставлять код работающим в защищенной среде, если у вас могут быть имплантаты, работающие в менее защищенном (но надежном) домене, которые затем можно использовать для повторной компрометации вашей цели по желанию?

Доверие внутри леса (родительский / дочерний или корень дерева) представляет удивительный вектор атаки, описанный в Trustpocalypse далее в этом посте.Внешнее / межлесное доверие не гарантирует какого-либо привилегированного доступа, но, как минимум, доверие означает, что вы можете запрашивать любую обычную информацию Active Directory из доверяющего вам домена (да, это означает, что в некоторых случаях вы можете Kerberoast через доверительные отношения, подробнее об этом в конце сообщения.) В конце концов, Active Directory задумана как запрашиваемая база данных информации, и доверие не меняет этого!

Стратегия доверительных атак

Прежде чем мы перейдем к техническим деталям того, как перечислять доверительные отношения и злоупотреблять ими, я хотел бы остановиться на стратегии высокого уровня, которую я использую при аудите доверительных отношений.Когда я говорю о «стратегии атаки на доверие», я имею в виду способ бокового перехода из домена, в котором в настоящее время находится ваш доступ, в другой домен, на который вы нацеливаетесь.

(1) Первый шаг — перечислить все доверительные отношения вашего текущего домена, а также любые доверительные отношения , которые имеют эти домены , и так далее. По сути, вы хотите создать сопоставление всех доменов, к которым вы можете подключиться из текущего контекста через привязку доверенных рефералов. Это позволит вам определить домены, через которые вам нужно пройти, чтобы добраться до вашей цели, и какие методы вы можете применить, чтобы (возможно) достичь этого.Любые домены в сопоставленной «сетке», которые находятся в одном лесу (например, отношения родитель-> потомок), представляют особый интерес из-за техники переключения доверия SIDhistory, разработанной Шоном Меткалфом и Бенджамином Делпи, также описанной в The Trustpocalypse раздел.

(2) Следующим шагом является перечисление всех пользователей / групп / компьютеров (участников безопасности) в одном домене, которые либо (1) имеют доступ к ресурсам в другом домене (то есть членство в группах локальных администраторов или записи ACE DACL) , или (2) находятся в группах или (если группа) имеют пользователей из другого домена.Дело здесь в том, чтобы найти отношения, которые каким-то образом пересекают отображенные границы доверия и, следовательно, могут обеспечить своего рода «мост доступа» от одного домена к другому в сети. Хотя междоменные вложенные отношения не гарантируют облегчения доступа, доверительные отношения обычно реализуются по определенной причине, что означает, что чаще всего существует какой-либо тип междоменного «вложенности» пользователей / групп / ресурсов, и во многих организациях эти отношения неправильно настроены. Еще одно замечание — как уже упоминалось, Kerberoasting через доверительные отношения может быть еще одним вектором для переключения границы доверия.Дополнительную информацию можно найти в разделе Еще одно примечание: Kerberoasting Across Domain Trusts .

(3) Теперь, когда вы наметили сеть доверия, типы и междоменные вложенные отношения, у вас есть карта того, какие учетные записи вам нужно скомпрометировать, чтобы перейти от текущего домена к целевому. Выполнив целенаправленную компрометацию учетной записи и используя SID-history-hopping для доверительных отношений между доменами в лесу, мы смогли развернуть до 7+ доменов в полевых условиях для достижения нашей цели.

Как минимум помните, что если домен доверяет вам, то есть если доверие является двунаправленным или односторонним и входящим, то вы можете запросить любую информацию Active Directory из доверяющего домена . И помните, что все родительские-> дочерние (доверительные отношения между доменами внутри леса) сохраняют неявное двустороннее транзитивное доверие друг с другом. Кроме того, из-за того, как добавляются дочерние домены, группа «Администраторы предприятия» автоматически добавляется в локальную группу домена «Администраторы» в каждом домене в лесу.Это означает, что доверие «течет вниз» из корня леса, что делает нашей целью переход от дочернего к корню леса на любом соответствующем этапе в цепочке атаки.

Хорошо, как мне перечислить трасты?

Хорошо, Уилл, ты заинтересовал меня. Как мне выяснить, какие доверительные отношения существуют в моей среде?

Насколько мне известно, существует три основных метода перечисления доверительных отношений: вызовы Win32 API, различные методы .NET и LDAP. Каждый из них (к сожалению) возвращает разный набор информации, и каждый имеет разные методы выполнения.Я расскажу о старых и новых способах, от встроенных (и внешних) двоичных файлов до .NET, вызовов API Win32, PowerShell / PowerView и BloodHound.

Образец архитектуры доверия, который я буду использовать в этой публикации:

Это изображение было создано с новым выходом TrustVisualizer (описанным в разделе Визуализация доверия доменов ). В этом новом выводе зеленые, кромки означают «внутри леса», красные, обозначают внешние, а синие обозначают доверительные отношения между лесами.Как и в случае с DomainTrustExplorer @ sixdub, граничные направления для одностороннего доверия означают направление доступа , а не направление доверия .

Методы .NET

.NET предоставляет нам несколько хороших оболочек методов, которые могут перечислить хороший фрагмент информации о доверии домена и леса. Это был первый метод, реализованный в PowerView, до перехода на методы Win32 API и LDAP.

Пространство имен [System.DirectoryServices.ActiveDirectory.Domain] имеет статический метод GetCurrentDomain (), который возвращает System.Экземпляр класса DirectoryServices.ActiveDirectory.Domain. Этот класс реализует метод GetAllTrustRelationships (), который красиво: « извлекает все доверительные отношения для этого домена. ”Одним из преимуществ этого метода является его простота — информация представлена ​​в виде, удобном для чтения и понимания. Одним из недостатков является то, что он не содержит некоторой дополнительной информации, которую производят другие методы перечисления.

([System.DirectoryServices.ActiveDirectory.Domain] :: GetCurrentDomain ()). GetAllTrustRelationships ()

Раньше это был метод перечисления Get-DomainTrust PowerView по умолчанию. Недавно я изменил метод по умолчанию на LDAP, поскольку этот метод .NET не возвращает доверительные отношения лесов по умолчанию, в то время как перечисление LDAP делает это. Итак, чтобы выполнить этот метод, теперь вам нужно запустить Get-DomainTrust -NET .

Вот как выглядит мой пример настройки домена, выполняющий перечисление из подпрограммы .dev.testlab.local :

Доверие леса функционально отличается от доверия домена. Поэтому, если вы хотите перечислить любые текущие отношения доверия между лесами и лесами, вам нужно вместо этого вызвать [System.DirectoryServices.ActiveDirectory.Forest]. Результирующие объекты леса также имеют свой собственный метод GetAllTrustRelationships (), который возвращает любые текущие доверительные отношения леса:

([System.DirectoryServices.ActiveDirectory.Forest] :: GetCurrentForest ()). GetAllTrustRelationships ()

Это реализовано как методы перечисления по умолчанию для функции PowerView Get-ForestTrust .Вот как это выглядит для моего примера настройки домена, снова из sub.dev.testlab.local :

Win32API

Вы также можете перечислить доверительные отношения доменов с помощью вызова Win32 API DsEnumerateDomainTrusts (), который возвращает структуру DS_DOMAIN_TRUSTS. Хотя информация немного сложнее, чем методы .NET, она возвращает SID и GUID целевого домена, а также некоторые полезные флаги и атрибуты. Флаги задокументированы здесь и сообщают вам направление доверия, находится ли доверие в том же лесу и т. Д.Атрибуты задокументированы здесь в соответствии со спецификацией TrustAttributes и включают такие вещи, как WITHIN_FOREST, NON_TRANSITIVE, FILTER_SIDS и другие. FILTER_SIDS является эквивалентом QUARANTINED_DOMAIN, если вы когда-либо видели эту номенклатуру.

Этот метод можно вызвать с помощью Get-DomainTrust -API (тот же домен происхождения sub.dev.testlab.local):

Следует отметить, что это похоже на то, что nltest.exe использует со своим флагом / trusted_domains :

Это также метод, который BloodHound использует для подсчета доверенных доменов.Вы можете выполнить это с помощью нового приемника SharpHound.ps1, используя синтаксис Invoke-BloodHound -CollectionMethod доверяет . Обратите внимание, что это также можно комбинировать с -Domain для перечисления внешнего доверия.

LDAP

Доверительные отношения домена хранятся в Active Directory как «объекты доверенного домена» с объектным классом trustDomain . Это означает, что вы можете использовать любой метод запросов LDAP, который вам нужен, чтобы узнать информацию о любых отношениях доверия с доменами, которые присутствуют, с помощью фильтра LDAP (objectClass = trustDomain) .

Например, вот dsquery (доступен только на серверах Windows):

dsquery * -filter "(objectClass = trustedDomain)" -attr *

Эквивалентный синтаксис Adfind Joeware — . \ Adfind.exe -f objectclass = trusteddomain .

И, наконец, PowerView, который теперь снова использует этот LDAP в качестве метода перечисления по умолчанию для Get-DomainTrust :

Поскольку этот метод LDAP теперь используется по умолчанию для PowerView Get-DomainTrust , я собираюсь разбить некоторые свойства результата, которые могут немного сбивать с толку.

TrustType:

• НИЖНИЙ УРОВЕНЬ (0x00000001) — доверенный домен Windows, на котором НЕ работает Active Directory. Это выводится как WINDOWS_NON_ACTIVE_DIRECTORY в PowerView для тех, кто не знаком с терминологией.
• UPLEVEL (0x00000002) — доверенный домен Windows, на котором работает Active Directory. Это выводится как WINDOWS_ACTIVE_DIRECTORY в PowerView для тех, кто не знаком с терминологией.
• MIT (0x00000003) — доверенный домен, на котором работает не-Windows (* nix), RFC4120-совместимый дистрибутив Kerberos.Это обозначено как MIT из-за того, что MIT публикует RFC4120.

Атрибуты доверия:

• NON_TRANSITIVE (0x00000001) — доверие нельзя использовать транзитивно. То есть, если DomainA доверяет DomainB, а DomainB доверяет DomainC, то DomainA не доверяет автоматически DomainC. Кроме того, если доверие не является транзитивным, вы не сможете запрашивать какую-либо информацию Active Directory из доверительных отношений вверх по цепочке от непереходной точки. Внешние доверительные отношения неявно нетранзитивны.
• UPLEVEL_ONLY (0x00000002) — доверие могут использовать только операционная система Windows 2000 и более новые клиенты.
• QUARANTINED_DOMAIN (0x00000004) — включена фильтрация SID (подробнее об этом позже). Для простоты вывести как FILTER_SIDS с PowerView.
• FOREST_TRANSITIVE (0x00000008) — доверительные отношения между лесами между корнем двух лесов домена, работающих как минимум на функциональном уровне домена 2003 или выше.
• CROSS_ORGANIZATION (0x00000010) — доверие относится к домену или лесу, который не является частью организации, который добавляет OTHER_ORGANIZATION SID.Это немного странно. Я не помню, чтобы встречал этот флаг в поле, но, согласно этому сообщению, это означает, что включена защита выборочной аутентификации. Для получения дополнительной информации ознакомьтесь с этим документом MSDN.
• WITHIN_FOREST (0x00000020) — доверенный домен находится в том же лесу, что означает отношение родитель-> потомок или перекрестные ссылки
• TREAT_AS_EXTERNAL (0x00000040) — доверие должно рассматриваться как внешнее для целей границы доверия.Согласно документации, « Если этот бит установлен, то доверие между лесами к домену должно рассматриваться как внешнее доверие для целей фильтрации SID. Межлесные трасты фильтруются более строго, чем внешние трасты . Этот атрибут ослабляет доверительные отношения между лесами, чтобы они были эквивалентны внешним довериям. ”Звучит заманчиво, и я не уверен на 100% в отношении безопасности этого заявления ¯ \ _ (ツ) _ / ¯, но я обновлю этот пост, если что-то новое появится.
• USES_RC4_ENCRYPTION (0x00000080) — если TrustType имеет значение MIT, указывает, что доверие поддерживает ключи RC4.
• USES_AES_KEYS (0x00000100) — не указан в связанной документации Microsoft, но согласно некоторой документации, которую я смог найти в Интернете, в ней указано, что ключи AES используются для шифрования KRB TGT.
• CROSS_ORGANIZATION_NO_TGT_DELEGATION (0x00000200) — « Если этот бит установлен, билеты, предоставленные в рамках этого доверия, НЕ ДОЛЖНЫ быть доверенными для делегирования. »Подробнее об этом см. [MS-KILE] 3.3.5.7.5 (Междоменное доверие и переходы).
• PIM_TRUST (0x00000400) — « Если этот бит и бит TATE (рассматривать как внешний) установлены, то межлесное доверие к домену должно рассматриваться как доверие Privileged Identity Management для целей фильтрации SID. »Согласно [MS-PAC] 4.1.2.2 (Фильтрация SID и преобразование утверждений),« Домен может управляться извне с помощью домена, находящегося за пределами леса.Доверяющий домен позволяет SID, локальным для его леса, переходить через доверие PrivilegedIdentityManagement. ”Хотя я не встречал этого на практике, и он поддерживается только функциональным уровнем домена 2012R2 и выше, он также требует дальнейшего изучения :)

Все эти методы также могут быть выполнены для домена, который в настоящее время вам доверяет. Это означает, что если ваш текущий домен имеет двунаправленное доверие с ИНОСТРАННЫМ доменом или если доверие является односторонним и входящим (это означает, что указанный домен доверяет вам и, следовательно, у вас есть какой-то доступ), вы можете выполнить эти методы для указанного домена, чтобы найти трасты для ТОГО домена.Если вы хотите сделать это с помощью PowerView, просто укажите параметр -Domain , более подробно описанный в следующем разделе.

Перечисление данных между доверительными отношениями с помощью PowerView

В прошлом году я описал свою переработку PowerView с нуля. Одно из упомянутых изменений заключалось в том, что теперь любая функция Get-Domain * использует перечисление LDAP, что означает, что мы можем извлекать указанную информацию из домена, который нам доверяет. Это делается с помощью -Domain <домен.fqdn> параметр:

Так что же на самом деле происходит под капотом?

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

Это означает, что при сегментации сети между компьютером, с которого в данный момент выполняется запрос, и основным контроллером домена доверяющего домена вы не сможете получить никаких результатов> _ <

Со стороны Kerberos, «под капотом», это означает, что автоматически выдается серия межсферных реферальных билетов, которые позволяют нашему пользователю в конечном итоге запросить билет службы LDAP из целевого домена.Если мы используем нашу примерную архитектуру домена и в настоящее время находимся в sub.dev.testlab.local при запросе prod.contoso.local , то вывод klist выглядит следующим образом:

Вы можете увидеть, как межсферные билеты фильтруют цепочку доверия до testlab.local , в конечном итоге до contoso.local и, наконец, до prod.contoso.local .

Доверительные отношения между доменами

Я знаю несколько способов сопоставить «сетку» одного или нескольких доверительных отношений, существующих в вашей среде.Первый — через глобальный каталог. Я немного говорил об этом в своем сообщении «Руководство для пентестера по определению групповой области», но здесь я повторю часть этой информации.

Глобальный каталог — это частичная копия всех объектов в лесу Active Directory, что означает, что некоторые свойства объекта (но не все) содержатся в нем. Эти данные реплицируются между всеми контроллерами домена, отмеченными как глобальные каталоги леса. Объекты доверенных доменов реплицируются в глобальный каталог, поэтому мы можем очень быстро перечислить каждое внутреннее и внешнее доверие, которое имеют все домены в нашем текущем лесу, и только с трафиком к нашему текущему PDC, запустив Get-DomainTrust -SearchBase «GC: // $ ($ ENV: USERDNSDOMAIN) ” через PowerView.Вот как это выглядит при запуске этой функции из домена sub.dev.testlab.local :

Это намного больше, чем просто Get-DomainTrust !

Второй метод медленнее, но даст еще больше результатов. Поскольку мы можем перечислить любые доверительные отношения, которые есть в нашем текущем контексте домена, и посредством рефералов через LDAP, мы можем запросить любые объекты (objectClass = trustedDomain) из доменов, которые в настоящее время доверяют нашему домену, тогда мы можем продолжать отправлять эти запросы для любых результаты и «сканировать» все доступные домены.Любые домены, помеченные как нетранзитивные, могут испортить эти результаты, но мы все равно можем получить хорошее количество результатов.

Для этого используется функция PowerView: Get-DomainTrustMapping (ранее Invoke-MapDomainTrust). Эти результаты можно экспортировать в CSV с помощью конвейера с Get-DomainTrustMapping с по | Export-CSV -NoTypeInformation trusts.csv .

Последний путь через BloodHound / SharpHound. Опять же, вы можете выполнить это с помощью нового приемника SharpHound.ps1, используя синтаксис Invoke-BloodHound -CollectionMethod доверяет , и это можно комбинировать с -Domain для перечисления внешнего доверия.

Важно помнить, что точное сопоставление доверия, которое вы получите, будет зависеть от домена, в котором вы сейчас находитесь. Поскольку доверие между доменами external.local и sub.dev.testlab.local является единым -way нетранзитивное внешнее доверие , если вы запрашиваете из external.local , вы не сможете увидеть доверительные отношения, которые имеет contoso.local , опять же, потому что sub.dev.testlab.local не превратит ваш TGT в межсферный TGT, который можно перенаправить на любой другой домен. Кроме того, если вы пытаетесь перечислить доверительные отношения во внешнем домене, вам необходимо иметь возможность выполнить привязку к контроллеру домена (обычно это основной контроллер домена / основной контроллер домена) во внешнем домене, который вы запрашиваете. Таким образом, даже если существует транзитивное доверие, которое позволит вам запрашивать информацию, если сегментация сети не позволяет вам разговаривать с целевым иностранным доменом, вам не повезло.

Визуализация доверия доменов

Данные — это одно, а визуализации — другое.Несколько лет назад один из моих бывших коллег по работе, Джастин Уорнер, просмотрел все эти необработанные данные и создал инструмент под названием DomainTrustExplorer, который мог выполнять некоторый узловой анализ и визуализацию с отображенными данными доверия PowerView.

Поскольку выходные данные доверия по умолчанию изменились и BloodHound позаботился о узловом анализе для нас, я переписал проект Джастина в упрощенной форме, которая будет принимать обновленные файлы доверия .CSV, TrustVisualizer:

Полученный в результате graphml можно визуализировать с помощью yEd, как описано здесь.Вот как я создал предыдущую визуализацию образца доверительной архитектуры:

Опять же, в этом новом выводе зеленых кромок означают «внутри леса», красные обозначают внешние, а синие обозначают доверительные отношения между лесами. Как и в случае с DomainTrustExplorer @ sixdub, граничные направления для одностороннего доверия означают направление доступа , а не направление доверия .

При использовании SharpHound для сбора данных о доверии и BloodHound для их визуализации, вот как выглядят те же данные выше:

Перечень международных связей

Теперь, когда мы нанесли на карту все доверительные отношения доменов, достижимые с машины, с которой мы запрашиваем, следующий шаг в фазе планирования атаки затрагивает несколько ветвей, в зависимости от конкретных типов доверительных отношений, с которыми мы столкнулись.Эти следующие шаги необходимо выполнить для перехода от каждого домена к другому на пути атаки.

Если следующий переход домена находится в том же лесу, что и домен, из которого мы перемещаемся, и , мы можем скомпрометировать хэш krbtgt дочернего домена, тогда мы можем использовать метод, описанный в следующий раздел Trustpocalypse , чтобы скомпрометировать корень леса.

Если мы не можем скомпрометировать повышенный доступ в текущем / сводном дочернем домене или если следующим шагом на пути доверительной атаки является внешнее доверие / доверие леса, то нам нужно перечислить, какие пользователи (если есть) из домена мы являемся частью групп в целевом домене (или на следующем этапе пути атаки домена.)

К сожалению, с этим шагом есть много недостатков. Точный характер доверия, которое ваш текущий домен сохраняет с запрашиваемым вами доверяющим доменом , будет влиять на то, какую информацию вы можете получить, и на конкретные методы, которые вы можете использовать. В общем, опять же, это перечисление во многом зависит от того, запрашиваете ли вы внешний домен в том же лесу или через внешнее / межлесное доверие. Постараюсь объяснить все тонкости.

Существует три основных способа, которыми участники безопасности (пользователи / группы) из одного домена могут иметь доступ к ресурсам в другом внешнем / доверяющем домене :

• Их можно добавить в локальные группы на отдельных машинах, т.е.е. локальная группа «Администраторы» на сервере.
• Их можно добавлять в группы в чужом домене. В зависимости от типа доверия и области действия группы есть несколько предостережений, которые будут описаны вкратце.
• Они могут быть добавлены как принципалы в список управления доступом, что наиболее интересно для нас как принципалы в ACE в DACL. Для получения дополнительной информации о списках ACL / DACL / ACE ознакомьтесь с техническим документом «ACE Up The Sleeve».

Случай 1: Членство в локальной группе

Это включает перечисление локального членства одной или нескольких систем через удаленную SAM (SAMR) или через корреляцию GPO.Я не буду здесь подробно останавливаться на этом случае, но отмечу, что в прошлом мы добивались успеха с целевым перечислением SAMR важных серверов или контроллеров домена для переключения доверия. Функция PowerView для выполнения этого вручную — Get-NetLocalGroupMember , и BloodHound сделает все это автоматически за вас.

Случай 2: Членство в иностранной группе

Случай членства в группе становится немного сложнее. Свойство member группы Active Directory и свойство memberOf объекта пользователя / группы имеют особый тип отношений, называемый связанными атрибутами.Я рассмотрел это более подробно в предыдущем посте, но со связанными атрибутами Active Directory вычисляет значение заданного атрибута, называемого обратной ссылкой (например, memberOf с пользователями / группами) из значения другого атрибута, указанного в качестве прямого канала (например, член , с группой). Суть в том, что членство в группе в конечном итоге сохраняется внутри самой целевой группы в свойстве member , и все это становится немного сложнее по сравнению с доверительными отношениями.Надеюсь, вскоре это станет более понятным. Отражает ли свойство memberOf , сохраненное с объектом пользователя / группы, их членство в чужой группе, зависит от характера доверия и области действия иностранной группы, членом которой они являются.

Вот разбивка по трем группам с указанием типа добавленных иностранных участников:

• Локальные группы домена могут иметь пользователей внутри леса между доменами (пользователи в том же лесу, что и группа), добавленные в качестве членов, а также пользователи между лесами между доменами (внешние участники безопасности.)
• Глобальные группы не могут иметь междоменного членства даже в одном лесу. Поэтому для наших целей мы можем их игнорировать.
• Универсальные группы может иметь любого пользователя в лесу в качестве члена, но «внешние участники безопасности» (т. Е. Пользователи из леса / внешних доверительных отношений) не могут быть частью универсальных групп.

Если пользователь / группа вложена в группу в другом домене, который находится в том же лесу (например, «локальный домен» или «универсальная группа»), то в зависимости от области действия целевой группы членство может быть обновлено в пользователе. / group’s memberOf собственности.Членство в группах с «универсальной» областью действия реплицируется в глобальном каталоге леса, что означает обновление memberOf пользователя. Если область действия группы, в которую добавлен пользователь, является «локальным доменом», тогда memberOf пользователя НЕ будет обновляться (в глобальном каталоге), поскольку группа с областью «локальный домен» не имеет репликации членства в лесу. . Таким образом, единственный способ определить членство пользователя в чужой группе, просто взглянув на объект пользователя, — это добавить ли он в универсальную группу в том же лесу.Однако это также означает, что если мы можем выполнить привязку к глобальному каталогу леса, мы сможем легко перечислить все эти конкретные междоменные отношения.

Если пользователь вложен в группу в домене через лес / внешнее доверие, тогда все обрабатывается немного по-другому. Пользователи, которые существуют через внешние доверительные отношения или доверие леса, по-прежнему могут быть добавлены в локальные группы домена в указанном домене. Эти пользователи отображаются как новые записи в CN = ForeignSecurityPrincipals, DC = domain, DC = com в домене, в который они добавляются, которые используются как своего рода прокси, который позволяет добавлять внешние идентификаторы безопасности в ресурсы в домене.

Как объясняет Microsoft, « Когда устанавливается доверие между доменом в лесу и доменом вне этого леса, участники безопасности из внешнего домена могут получать доступ к ресурсам во внутреннем домене. Active Directory создает объект внешнего участника безопасности во внутреннем домене для представления каждого участника безопасности из доверенного внешнего домена. Эти участники внешней безопасности могут стать членами локальных групп домена во внутреннем домене “.Если «локальный домен» или «групповая область видимости» вам не подходят, ознакомьтесь с моим предыдущим постом по этой теме.

Tl; dr, насколько я понимаю, эти ForeignSecurityPrincipal действуют как псевдонимы для «реального» пользователя, который является внешним по отношению к домену / лесу, и именно ForeignSecurityPrincipal фактически добавляется к группам в целевом домене. SID данного ForeignSecurityPrincipal совпадает с SID внешнего пользователя, что упрощает последующую фильтрацию.

Случай 3: Иностранные участники ACL

К счастью, большая часть свойства ntSecurityDescriptor объектов Active Directory (1) доступна любому аутентифицированному пользователю домена и (2) реплицируется в глобальном каталоге.Это означает, что если из текущего контекста домена, вы можете запросить списки DACL для всех объектов в домене , которому доверяет , и отфильтровать любые записи ACE, где сторонний участник безопасности имеет данное право на объект, который вы перечисляете.

Вы можете использовать функцию PowerView Get-DomainObjectACL -Domain для получения этих ACE, но чтобы найти междоменные отношения DACL, вам нужно будет отфильтровать участников / SecurityIdentifiers, которые не соответствуют SID домен, который вы запрашиваете.Я расскажу об этом в следующей публикации PowerView PowerUsage .

Руководство по эксплуатации

Примечание. Я также рассмотрю все шаги, необходимые в разделе «Пример использования », далее в этой публикации, если некоторые из них не имеют смысла.

Если вы в настоящее время находитесь в дочернем домене в лесу, и DO имеют повышенный доступ в указанном дочернем домене, см. Раздел Trustpocalypse .

Если вы в настоящее время находитесь в дочернем домене в лесу, и НЕ имеет повышенного доступа в указанном дочернем домене, то вы можете запустить функцию PowerView Get-DomainForeignUser для перечисления пользователей, которые находятся в группах за пределами текущего пользователя. домен.Это «исходящий» доступ домена, то есть пользователи / группы, которые могут иметь некоторый доступ к другим группам домена в том же лесу. Эта функция может быть полезна также для сопоставления других отношений пользователя / группы внутри лесного домена:

Если вы нацеливаетесь на внешний домен / домен леса или целевой домен в одном лесу, вы можете использовать функцию PowerView Get-DomainForeignGroupMember -Domain . Это перечисляет групп в целевом домене, которые содержат пользователей / группы , которые не находятся в целевом домене.Это «входящий» доступ домена, то есть группы в целевом домене с входящими отношениями членства:

Кроме того, к счастью для нас, ForeignSecurityPrincipals реплицируются в глобальном каталоге, как и объекты доверенного домена (упомянутые в разделе Mapping Domain Trusts ). Поэтому, если вы хотите быстро перечислить всех сторонних участников безопасности (то есть любых входящих сторонних групп / пользователей), которые являются членами групп внутри домена в текущем / целевом лесу, вы можете запросить любой глобальный каталог с помощью фильтра LDAP ‘(объектный класс = foreignSecurityPrincipal) ‘.И поскольку эти внешние участники могут быть добавлены только в группы с локальной областью действия домена, мы можем извлечь домен, в который был добавлен внешний пользователь, из отличительного имени, запросить этот домен напрямую для групп с локальной областью домена с членами, предполагая, что у нас есть какой-то тип прямого или транзитивного доверия с этим целевым доменом. Это позволяет нам сравнивать членство каждой из этих локальных групп домена со списком иностранных пользователей:

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

Если вы используете BloodHound с его новым приемником SharpHound, вы все равно можете использовать -Domain с приемником в сочетании с опциями -CollectionMethod для ‘Group’, ‘LocalGroup’ и / или ‘ACL ‘. BloodHound моделирует узлы пользователей / групп с синтаксисом name @ в схеме. Это устраняет необходимость выполнять сложную аналитику для извлечения этих взаимосвязей после того, как данные были собраны. Если user @ dev.testlab.local является членом [email protected] , это отношение memberOf моделируется автоматически. Если эта вложенная групповая взаимосвязь обнаруживается на любом пути атаки, она будет автоматически включена в ваш график без дополнительных усилий.

Имеет смысл, правда? :) Это сложная тема, если вы не знакомы, поэтому перечитайте предыдущий раздел несколько раз, пока не поймете, как выявить эти междоменные отношения. Ознакомьтесь с разделом «Пример использования », чтобы получить реалистичное представление об эталонной архитектуре, которую я использовал в этом посте.

Trustpocalypse — SID расширяет внутрилесные трасты

Это одна из моих любимых вещей, о которых я узнал в сфере безопасности за последние несколько лет. Так же, как большинство людей помнят, как впервые увидели, как Mimikatz извлек из памяти пароль в виде открытого текста, так и в моей голове остались воспоминания о том, когда я понял, что повлекло за собой эту атаку.

Это началось, как и многие из моих головокружительных моментов, с просмотра твита Бенджамина Делпи в июне 2015 года и поначалу непонимания последствий:

После разговора с Бенджамином, чтобы подтвердить, что я думал о последствиях, его ответ был: «Простите за голову :)».

Это все благодаря работе, над которой работали Бенджамин и Шон Меткалф, чтобы сделать Золотые билеты еще более «золотыми».Я писал об этом в августе 2015 года после того, как их работа была опубликована в посте под названием «Trustpocalypse».

До этой работы наша стратегия заключалась в том, чтобы составить карту членства в чужих пользователях / группах и перейти от дочернего доверительного управления к корню леса «вручную», что часто было трудоемким процессом в больших средах с большим количеством доменов. Как описано в разделе «Стратегия атаки на доверие », мы всегда интерпретировали доверие как «перетекание» из корня леса в дочерние домены из-за группы «Администраторы предприятия».Однако в течение многих лет Microsoft заявляла, что «лес является границей безопасности для Active Directory », и атака на домены внутри леса была известна (по крайней мере) с 2005 года.

Но сначала, чтобы это имело полный смысл, я должен объяснить sidHistory и механизм безопасности фильтрации SID, и что все это означает для доменов в лесу.

sidHistory был добавлен с Windows 2000 Active Directory и предназначался для облегчения миграции пользователей из одного домена в другой.Если пользователь переносится, его старый идентификатор безопасности (SID) вместе с SID любой группы, частью которой он ранее был, можно дополнительно добавить к атрибуту sidHistory его новой учетной записи пользователя. Когда новый пользователь пытается получить доступ к ресурсу, «, если SID или история SID совпадают, доступ к ресурсу предоставляется или запрещается в соответствии с доступом, указанным в ACL. ». Это означает, что любой SID группы / старого пользователя, установленный в свойстве sidHistory пользователя, предоставляет им доступ , как если бы они были этим пользователем или членом этих групп .

Из-за того, как доверительные отношения работают в лесу Active Directory, свойство sidHistory («ExtraSids» в PAC) соблюдается в доменах леса, поскольку эти идентификаторы безопасности не отфильтровываются в междоменных переходах с помощью «фильтрации SID». »Защита. Таким образом, любой пользователь в дочернем домене, у которого для sidHistory / ExtraSids установлен, скажем, SID «Администраторы предприятия» (группа, которая существует только в корне леса), будет эффективно работать с , как если бы он был администратором предприятия. .Поскольку Microsoft знала, что это проблема, и эта информация стала общедоступной, по крайней мере, с момента публикации этой статьи 2005 ITPro Windows и почти наверняка раньше, что sidHistory является защищенным атрибутом, который чрезвычайно трудно изменить.

Ранее злоупотребление этим требовало довольно сложного процесса и включало изменение sidHistory в базе данных Active Directory (ntds.dit) связанного домена. Более подробно о том, почему и как это работает, рассказывается в разделе «Эпилог : SID Filtering ».

ПОЧЕМУ ЛЕС ЯВЛЯЕТСЯ «ГРАНИЦЕЙ ДОВЕРИЯ» В АКТИВНОМ КАТАЛОГЕ, А НЕ ДОМЕН!

Бенджамин и Шон поняли, что с введением Золотых билетов Mimikatz злоумышленник может установить раздел ExtraSids структуры KERB_VALIDATION_INFO, созданной для билета (структура, которая « определяет информацию для входа и авторизации пользователя, предоставляемую DC . “). Раздел ExtraSids описывается как « Указатель на список структур KERB_SID_AND_ATTRIBUTES, которые содержат список SID, соответствующих группам в доменах, отличных от домена учетной записи, которому принадлежит принципал » (здесь определяется структура KERB_SID_AND_ATTRIBUTES.)

Это означает, что если злоумышленник скомпрометирует права «Администратора домена» (или эквивалентные, фактически просто любую учетную запись, поддерживающую DCSync;) в ЛЮБОМ дочернем домене в лесу всего на 5 минут, хэш krbtgt дочернего домена может быть получен, и / sids: можно добавить в созданный билет Mimikatz без изменения базы данных Active Directory. Это дает злоумышленнику возможность «поднять» доверительные отношения леса и скомпрометировать корневой домен леса.

Если вы впервые слышите об этой технике, как сказал Бенджамин: «Простите за голову. :) ”

Для нашей стратегии оперативной атаки это означает, что если мы в настоящее время находимся в дочернем домене и можем скомпрометировать доступ DCSync / DA, или если мы можем скомпрометировать этот уровень доступа в любом дочернем домене в нашей цепочке атаки, мы можем отказаться от обременительных внешних перечисление отношений, чтобы повысить доверие и мгновенно поставить под угрозу корень леса. Мы сделали это в полевых условиях, и да, это здорово.:) Для оперативных советов / рекомендаций ознакомьтесь с моим предыдущим постом на Trustpocalypse от 2015 года.

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

Пример использования

Итак, рассмотрим еще раз примерную схему доверия:

Допустим, мы открыли счет в external.местный . Поскольку sub.dev.testlab.local доверяет external.local , external.local может запрашивать информацию из sub.dev.testlab.local , тогда как SUB не может делать то же самое с EXTERNAL. Из внешнего контекста мы можем запросить доверительные отношения, которые есть у SUB:

Но это возвращает только прямые доверительные отношения, которые sub.dev.testlab имеет с другими доменами ( dev.testlab.local и external.local ).Если мы можем запросить глобальный каталог (не всегда возможно) из sub.dev.testlab и вернуть все доверительные отношения доменов во всем лесу!

Обратите внимание: поскольку это одностороннее, непереходное внешнее доверие к sub.dev.testlab.local , мы не можем запросить доверительные отношения, которые имеет contoso.local из ВНЕШНЕГО контекста, поскольку наш Kerberos трафик не будет передан должным образом. Это то, что обычно означает эта ошибка, если вы ее встретите:

Итак, отсюда мы запустим Get-DomainForeignGroupMember -Domain sub.dev.testlab.local , чтобы увидеть, есть ли в каких-либо группах в SUB участники из EXTERNAL:

Оттуда мы попытаемся взломать целевую учетную запись, чтобы передать доверие в sub.dev.testlab.local . Команда Get-DomainForeignUser здесь бесполезна из-за предупреждений о репликации связанных значений и доверия, описанных в разделе Перечисление внешних связей .

Однако, поскольку external.local -> sub.dev.testlab.local — это внешние доверительные отношения, они неявно нетранзитивны, поэтому не удалось запросить членство в локальной группе домена dev.testlab.local или testlab.local .

Если бы мы смогли скомпрометировать учетные данные администратора домена (или эквивалентные) в sub.dev.testlab.local , мы могли бы создать золотой билет с переключением доверия sidHistory, как описано в разделе « Trustpocalypse », чтобы скомпрометировать testlab.local корневой домен леса.Если бы мы не смогли обеспечить повышенный доступ, мы бы запустили Get-DomainForeignUser , чтобы проверить, есть ли у пользователей из sub.dev.testlab.local доступ к другим группам в лесу. Опять же, помните предыдущую информацию об области видимости — здесь будет отражено только универсальных членов группы :

Мы также запустим Get-DomainForeignGroupMember -Domain dev.testlab.local и Get-DomainForeignGroupMember -Domain testlab.local , чтобы увидеть, что группы в этих других лесных доменах имеют «входящий» доступ:

Один раз / если бы мы смогли скомпрометировать часть или весь корень леса testlab.local с помощью любого из предыдущих подходов, мы бы затем запустили Get-DomainForeignGroupMember -Domain contoso.local и Get-DomainForeignGroupMember -Domain prod .contoso.local , чтобы узнать, есть ли в лесу TESTLAB пользователи, входящие в чужую группу в лесу CONTOSO.

Попутно мы могли бы запустить Get-NetLocalGroupMember для целевого набора серверов (включая контроллеры домена), чтобы увидеть, пересекли ли какие-либо пользователи эту границу через локальные группы компьютеров. Мы также могли бы использовать целевой Get-DomainObjectACL -Domain с различными фильтрами для проверки членства в сторонних списках ACL.

Или мы могли бы просто вытащить все с помощью BloodHound и полагаться на схему для моделирования переходов между лесами.:)

Sidenote: Forging Inter-Realm Trust Tickets

Для использования доверительных отношений можно подделать билеты доверия между областями. Поскольку Шон очень хорошо осветил этот вопрос в своем сообщении «Все о доверии», я отсылаю вас к его документации для получения более подробной информации о работе и просто расскажу о последствиях этого метода и о том, как он вписывается в нашу стратегию атаки на доверие.

Вспомните объяснение того, как Kerberos работает через доверительные отношения:

Таким образом, когда пользователь представляет это межобластное перенаправление билета-билета на чужой домен, снова подписанное межобластным доверительным ключом, TGT пользователя включается в него.И снова, поскольку чужой домен доверяет домену, который выдал реферальный билет, чужой домен доверяет TGT пользователя и всей включенной в него информации, чтобы быть точным.

Опять же, на английском языке, когда чужой домен расшифровывает реферальный билет с согласованным доверительным ключом, он видит TGT пользователя и говорит: « Хорошо, другой домен уже аутентифицировал этого пользователя и сказал, что это то, кем они являются / они группы, в которых состоит пользователь, поэтому я верю, что это верно, потому что я доверяю этому домену. “

Итак, если мы можем получить хэш межсферного доверительного ключа, можно подделать реферальный билет (как описывает Шон), который позволяет нам притвориться любым пользователем из первого домена при запросе доступа ко второму домену. Получение этого хэша можно выполнить обычным сбросом пароля или через DCSync, запросив FOREIGN_DOMAIN_SHORTNAME учетную запись $ :

Однако, если мы можем получить ключ доверия между областями, то почти во всех случаях мы сможем получить хэш krbtgt ссылающегося домена.Если у нас есть это, мы можем создать билет для домена, ссылающегося на пользователя, выдавая себя за любого пользователя, которого мы хотим для внешнего домена. Вот почему у меня не было необходимости подделывать межсферные доверительные рефералы на местах, но есть один конкретный случай, когда это становится интересным.

Еще в 2015 году, когда все начали в полной мере осознавать значение Золотых билетов, Microsoft выпустила скрипты, которые позволяют организациям изменять пароль учетной записи krbtgt. Чтобы это было эффективно для леса с одним доменом, пароль необходимо изменить дважды.Теперь, из-за реализации атаки с перескоком sidHistory, пароль для учетной записи krbtgt в КАЖДОМ домене в лесу дважды.

Предположим, что организация делает это и меняет пароли для на каждую учетную запись с повышенным уровнем в на каждый домен в лесу, безопасны ли они? Что ж, хотя ключи межсферного доверия автоматически меняются каждые 30 дней в соответствии с разделом 6.1.6.9.6.1 Технической спецификации Active Directory, они не меняются при изменении учетной записи krbtgt.Таким образом, если злоумышленник владеет межсферными ключами, он все равно может использовать подход sidHistory для установления доверия, как уточняет Шон. Опять же, есть миллион и еще один способ скрыть Active Directory. ¯ \ _ (ツ) _ / ¯

Итак, есть только одно решение, если вы хотите быть уверенным (спасибо @gentilkiwi :)

Еще одно примечание: Kerberoasting через доверительные отношения между доменами

Мы любим Kerberoasting. Представленный Тимом Медином в 2014 году, мы «зажарили тонну наших обязательств».И если у нас есть домен, который нам доверяет, мы можем перебраться через эти границы доверия с одной незначительной поправкой в ​​некоторых ситуациях.

При использовании .NET-класса System.IdentityModel.Tokens.KerberosRequestorSecurityToken (а затем его метода .GetRequest ()) мы указываем имя участника-службы (SPN) для запроса TGS-REP, а затем используем GetRequest () для получения байты для AP-REQ, предназначенные для отправки целевой службе. Этот AP-REQ содержит билет службы, который мы затем извлекаем и используем для автономного Kerberoasting / взлома паролей.

Документация для KerberosRequestorSecurityToken.ServicePrincipalName красиво описывает формат как « host / @ или , где hostname — это имя компьютера, на котором размещена целевая веб-служба, а домен — это полностью квалифицированное доменное имя области Kerberos, в которой находится хост-компьютер. ”Поэтому, если у вас есть какие-либо проблемы с Kerberoasting через доверительные отношения (особенно внешние и лесные доверительные отношения), попробуйте использовать SERVICE / [email protected] , и, возможно, вы добьетесь большего успеха. Это возможно с помощью PowerView Get-DomainSPNTicket , функции, на которой построен Invoke-Kerberoast .

Эпилог: Фильтрация SID

Итак, мы ранее говорили о том, как и почему лес является границей доверия в Active Directory, а не домен. Большая часть этого — защита безопасности, о которой я уже упоминал несколько раз, ранее называемая SID Filtering. Лучшим справочником по фильтрации SID является документация [MS-PAC] «Структура данных сертификата атрибутов привилегий», в частности раздел 4.1.2.2 «Фильтрация SID и преобразование утверждений». Я постараюсь объяснить несколько важных моментов.

Когда TGT пользователя представлен новому домену через ссылку, этот TGT содержит сертификат привилегированного атрибута (PAC), который содержит, среди прочего, идентификатор безопасности пользователя (SID), идентификаторы безопасности групп, в которых они находятся, и все, что присутствует в ранее обсужденном поле sidHistory (т.е. часть ExtraSids PAC, описанная в разделе Trustpocalypse ).Эта информация идентификации безопасности в PAC анализируется и анализируется доверяющим доменом , и в зависимости от типа доверия выполняются различные фильтры.

SID, соответствующие определенным шаблонам, отклоняются доверяющим доменом при различных обстоятельствах в качестве защиты безопасности. Фильтрация SID предназначена для того, чтобы помешать злоумышленникам с повышенными учетными данными в домене / лесу доверять от получения контроля над доменом / лесом, которому доверяют . Это также описано в документации Microsoft «Вопросы безопасности для доверительных отношений».

Существует набор идентификаторов безопасности, для которых установлено значение «AlwaysFilter», что означает, что они всегда отфильтровываются доверяющим доменом, независимо от типа доверия. Основной SID, который нас интересует, «Администраторы предприятия» (S-1-5-21- -519), тот, который позволяет нам выполнять атаку с переключением sidHistory, установлен на «ForestSpecific» для фильтрации . Как описывает Microsoft, « Правило ForestSpecific предназначено для тех SID, которые никогда не допускаются в PAC, который исходит из леса или из домена, который был помечен как QuarantinedWithinForest, если он не принадлежит этому домену. ». Это снова объясняет, почему лес является границей доверия, а не домен, поскольку этот повышенный SID (вместе со многими другими) не может быть передан через границу доверия, кроме случаев, когда целевой домен находится в том же лесу.

На карантине в лесу, да? Так получилось, что домены в пределах леса можно установить как «помещенные в карантин», что реализует фильтрацию SID версии для домена, даже если он находится в лесу. Однако, как указано в документации: « Единственными идентификаторами безопасности, которые могут быть переданы из такого домена, являются SID« Контроллеры домена предприятия »(S-1-5-9) и те, которые описаны объектом доверенного домена (TDO). . »Итак, поскольку SID« Контроллеры домена предприятия »НЕ отфильтровывается для доменов, помещенных в карантин внутри леса, все еще существует способ« перепрыгнуть »цепочку доверия леса и скомпрометировать корень леса:

Это то, что я пытался объяснить несколько лет назад, не понимая проблему должным образом, но теперь, после прочтения кучи документации Microsoft, это имеет немного больше смысла :)

Обертывание

Трасты — непростая тема. Большинство пентестеров (и многие системные администраторы!) Не понимают должным образом доверительные отношения и риски, связанные с различными неправильными конфигурациями доверия.К сожалению для нас, некоторые злоумышленники так и поступают, и доверительные отношения использовались почти с самого начала Active Directory для использования доступа в одном домене для перехода в другой.

Если ваша архитектура доверия домена настроена неправильно, что тогда ответ? К сожалению, как и в случае со многими серьезными архитектурными недостатками подобного рода, простого решения не существует. Реорганизация крупного развертывания Active Directory может быть долгим, дорогостоящим и болезненным процессом, но все же есть путеводный свет: административная среда с усиленной безопасностью (ESAE), обычно называемая «Красный лес», которая представляет собой защищенную архитектуру Active Directory. что уменьшает огромное количество уязвимостей / неправильных конфигураций Active Directory.Хотя Microsoft опубликовала аспекты архитектуры, единственный способ, который я в настоящее время знаю, как получить ESAE / Red Forest, — это заплатить Microsoft за его реализацию. ¯ \ _ (ツ) _ / ¯

Я хотел бы в конечном итоге опубликовать руководство о том, как организации реализуют среду «в стиле красного леса», которая, хотя «официально» не соответствует эталонной архитектуре, все же будет лучше, чем текущие реализации многих организаций. Если у кого-то есть документация или руководство о том, как это сделать на практике, свяжитесь со мной (@ damagej0y или will [at] hazj0y.net), и я с радостью получу такую ​​информацию.

---

Также опубликовано на Medium.

основных и доверенных доменов — приложения Win32

• 31.05.2018
• 2 минуты на чтение

В этой статье

Следующие термины описывают домены, существующие в удаленных системах.

Основной домен

Первичный домен — это домен, который отвечает за установление дальнейших доверительных отношений и выполнение аутентификации (или за передачу запроса аутентификации в соответствующий доверенный домен). Контроллеры домена в основном домене обрабатывают или передают запросы проверки подлинности, исходящие от рабочей станции.

При входе в систему LSA проверяет встроенный домен и домен учетной записи на предмет аутентификационной информации. Если учетная запись, в которую выполняется вход, не находится ни в одном из этих доменов, запрос на вход передается в основной домен системы.

Надежный домен

Доверенный домен — это домен, которому локальная система доверяет для аутентификации пользователей. Другими словами, если пользователь или приложение аутентифицируются доверенным доменом, эта аутентификация принимается всеми доменами, которые доверяют аутентифицирующему домену.

Каждый подчиненный домен автоматически имеет двусторонние доверительные отношения с основным доменом. По умолчанию это доверие является транзитивным, что означает, что если система доверяет домену A, она также доверяет всем доменам, которым доверяет домен A.Односторонние доверительные отношения также поддерживаются для операционных систем, предшествующих Windows 2000, которые не поддерживают транзитивные двусторонние доверительные отношения.

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

На контроллерах домена LSA создает экземпляр объекта TrustedDomain для каждого домена, которому доверяет локальная система.

Например, если рабочая станция Windows XP доверяет контроллеру домена Windows 2000, который, в свою очередь, доверяет четырем другим системам, рабочая станция, подключенная с использованием транзитивного доверия, будет иметь пять объектов TrustedDomain в своей локальной системе.

Как работают доверительные отношения для доменных служб Azure AD

• 06.07.2020
• 19 минут для чтения

В этой статье

Доменные службы Active Directory (AD DS) обеспечивают безопасность в нескольких доменах или лесах через доверительные отношения между доменами и лесами.Прежде чем проверка подлинности может происходить через доверительные отношения, Windows должна сначала проверить, имеет ли домен, запрашиваемый пользователем, компьютером или службой, доверительные отношения с доменом запрашивающей учетной записи.

Чтобы проверить это доверительное отношение, система безопасности Windows вычисляет доверительный путь между контроллером домена (DC) для сервера, который получает запрос, и DC в домене запрашивающей учетной записи.

Механизмы управления доступом, предоставляемые AD DS и распределенной моделью безопасности Windows, обеспечивают среду для работы доверительных отношений домена и леса.Чтобы эти доверительные отношения работали правильно, каждый ресурс или компьютер должен иметь прямой путь доверия к DC в домене, в котором он расположен.

Путь доверия реализуется службой сетевого входа в систему с использованием аутентифицированного подключения удаленного вызова процедур (RPC) к доверенному органу домена. Защищенный канал также распространяется на другие домены AD DS через междоменные доверительные отношения. Этот защищенный канал используется для получения и проверки информации о безопасности, включая идентификаторы безопасности (SID) для пользователей и групп.

Обзор того, как доверительные отношения применяются к Azure AD DS, см. В разделе Концепции и функции леса ресурсов.

Чтобы начать использовать доверие в Azure AD DS, создайте управляемый домен, который использует доверие леса.

Потоки доверительных отношений

Поток защищенных коммуникаций через доверительные отношения определяет эластичность доверия. То, как вы создаете или настраиваете доверие, определяет, как далеко распространяется обмен данными внутри или между лесами.

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

На следующей диаграмме показано, что все домены в Tree 1 и Tree 2 по умолчанию имеют транзитивные доверительные отношения. В результате пользователи в Tree 1 могут получить доступ к ресурсам в доменах в Tree 2 , а пользователи в Tree 1 могут получить доступ к ресурсам в Tree 2 , если для ресурса назначены соответствующие разрешения.

Односторонние и двусторонние трасты

Доверительные отношения позволяют доступ к ресурсам может быть как односторонним, так и двусторонним.

Одностороннее доверие — это однонаправленный путь аутентификации, созданный между двумя доменами. При одностороннем доверии между доменом A и доменом B пользователи в домене A могут получить доступ к ресурсам в домене B . Однако пользователи в Домене B не могут получить доступ к ресурсам в Домене A .

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

При двустороннем доверии домен A доверяет домену B и домену B доверяет домену A .Эта конфигурация означает, что запросы аутентификации могут передаваться между двумя доменами в обоих направлениях. Некоторые двусторонние отношения могут быть нетранзитивными или транзитивными в зависимости от типа создаваемого доверия.

Все доверительные отношения доменов в лесу AD DS являются двусторонними транзитивными доверительными отношениями. Когда создается новый дочерний домен, между новым дочерним доменом и родительским доменом автоматически создается двустороннее транзитивное доверие.

Транзитивные и нетранзитивные трасты

Транзитивность определяет, можно ли расширить доверие за пределы двух доменов, с которыми оно было сформировано.

• Транзитивное доверие может использоваться для расширения доверительных отношений с другими доменами.
• Нетранзитивное доверие может использоваться для отказа от доверительных отношений с другими доменами.

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

Запросы аутентификации следуют этим путям доверия, поэтому учетные записи из любого домена в лесу могут быть аутентифицированы любым другим доменом в лесу. С помощью единого входа в систему учетные записи с соответствующими разрешениями могут получать доступ к ресурсам в любом домене леса.

Лесные фонды

Доверительные отношения леса помогают управлять сегментированной инфраструктурой AD DS и поддерживать доступ к ресурсам и другим объектам в нескольких лесах.Лесные трасты полезны для поставщиков услуг, компаний в процессе слияния или поглощения, совместных бизнес-сетей и компаний, ищущих решение для административной автономии.

Используя доверительные отношения лесов, вы можете связать два разных леса, чтобы сформировать односторонние или двусторонние транзитивные доверительные отношения. Доверие леса позволяет администраторам соединять два леса AD DS с помощью одного доверительного отношения, чтобы обеспечить беспрепятственную проверку подлинности и авторизацию в лесах.

Доверие леса может быть создано только между корневым доменом леса в одном лесу и корневым доменом леса в другом лесу. Доверительные отношения между лесами могут быть созданы только между двумя лесами и не могут быть неявно распространены на третий лес. Такое поведение означает, что если доверие леса создается между Лес 1 и Лес 2 , а другое доверие леса создается между Лес 2 и Лес 3 , Лес 1 не имеет неявного доверия с Лес 3 .

На следующей схеме показаны два отдельных доверительных отношения между тремя лесами AD DS в одной организации.

Этот пример конфигурации обеспечивает следующий доступ:

• Пользователи в Forest 2 могут получить доступ к ресурсам в любом домене в Forest 1 или Forest 3
• Пользователи в лесу 3 могут получить доступ к ресурсам в любом домене в лесу 2
• Пользователи в лесу 1 могут получить доступ к ресурсам в любом домене в лесу 2

Эта конфигурация не позволяет пользователям в Forest 1 получать доступ к ресурсам в Forest 3 или наоборот.Чтобы пользователи в Forest 1 и Forest 3 могли совместно использовать ресурсы, между двумя лесами должно быть создано двустороннее транзитивное доверие.

Если между двумя лесами создано одностороннее доверие, члены доверенного леса могут использовать ресурсы, расположенные в доверяющем лесу. Однако трест действует только в одном направлении.

Например, когда создается одностороннее доверие леса между Лес 1 (доверенный лес) и Лес 2 (доверяющий лес):

• Члены Forest 1 могут получить доступ к ресурсам, расположенным в Forest 2 .
• Члены Forest 2 не могут получить доступ к ресурсам, расположенным в Forest 1 , используя то же доверие.

Важно

Лес ресурсов доменных служб Azure AD поддерживает одностороннее доверие леса только к локальной службе Active Directory.

Требования лесного фонда

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

• Один корневой DNS-сервер является корневым DNS-сервером для обоих пространств имен DNS леса — корневая зона содержит делегирования для каждого из пространств имен DNS, а корневые ссылки всех DNS-серверов включают корневой DNS-сервер.

• При отсутствии общего корневого DNS-сервера и корневых DNS-серверов в каждом пространстве имен DNS леса используют серверы условной пересылки DNS для каждого пространства имен DNS для маршрутизации запросов для имен в другом пространстве имен.

  Важно

  Лес ресурсов доменных служб Azure AD должен использовать эту конфигурацию DNS. Размещение пространства имен DNS, отличного от пространства имен DNS леса ресурсов, не является функцией доменных служб Azure AD. Условные пересылки — это правильная конфигурация.

• Когда нет общего корневого DNS-сервера и используются корневые DNS-серверы в каждом пространстве имен DNS леса, вторичные зоны DNS настраиваются в каждом пространстве имен DNS для маршрутизации запросов для имен в другом пространстве имен.

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

Доверие исходящего леса для доменных служб Azure AD создается на портале Azure. Вы не можете вручную создать доверие с самим управляемым доменом. Входящее доверие леса должно быть настроено пользователем с привилегиями, ранее указанными в локальной Active Directory.

Доверительные процессы и взаимодействия

Многие междоменные и межлесные транзакции зависят от доверия домена или леса для выполнения различных задач. В этом разделе описаны процессы и взаимодействия, которые происходят при доступе к ресурсам через доверительные отношения и оценке ссылок на аутентификацию.

Обзор обработки ссылок для аутентификации

Когда запрос на аутентификацию направлен в домен, контроллер домена в этом домене должен определить, существуют ли доверительные отношения с доменом, из которого поступает запрос.Направление доверия и то, является ли доверие транзитивным или нетранзитивным, также должно быть определено до аутентификации пользователя для доступа к ресурсам в домене. Процесс аутентификации, который происходит между доверенными доменами, зависит от используемого протокола аутентификации. Протоколы Kerberos V5 и NTLM по-разному обрабатывают отсылки для аутентификации в домен

Обработка ссылок Kerberos V5

Протокол проверки подлинности Kerberos V5 зависит от службы сетевого входа в систему на контроллерах домена для проверки подлинности и авторизации клиента.Протокол Kerberos подключается к онлайн-центру распространения ключей (KDC) и хранилищу учетных записей Active Directory для билетов сеанса.

Протокол Kerberos также использует доверительные отношения для межсферных служб выдачи билетов (TGS) и для проверки сертификатов атрибутов привилегий (PAC) по защищенному каналу. Протокол Kerberos выполняет проверку подлинности между областями только с областями Kerberos операционной системы, отличными от Windows, такими как область MIT Kerberos, и не требует взаимодействия со службой сетевого входа.

Если клиент использует Kerberos V5 для проверки подлинности, он запрашивает билет на сервер в целевом домене у контроллера домена в домене своей учетной записи. Kerberos KDC действует как доверенный посредник между клиентом и сервером и предоставляет ключ сеанса, который позволяет двум сторонам аутентифицировать друг друга. Если целевой домен отличается от текущего домена, KDC следует логическому процессу, чтобы определить, можно ли передать запрос аутентификации:

1. Доверяет ли текущий домен напрямую домену запрашиваемого сервера?

   • Если да, отправьте клиенту ссылку на запрошенный домен.
   • Если нет, переходите к следующему шагу.

2. Существуют ли транзитивные доверительные отношения между текущим доменом и следующим доменом на пути доверия?

   • Если да, отправьте клиенту ссылку на следующий домен на пути доверия.
   • Если нет, отправьте клиенту сообщение об отказе во входе.

Обработка переадресации NTLM

Протокол проверки подлинности NTLM зависит от службы сетевого входа в систему на контроллерах домена для проверки подлинности и авторизации клиента.Этот протокол аутентифицирует клиентов, которые не используют аутентификацию Kerberos. NTLM использует доверительные отношения для передачи запросов проверки подлинности между доменами.

Если клиент использует NTLM для аутентификации, первоначальный запрос аутентификации идет напрямую от клиента к серверу ресурсов в целевом домене. Этот сервер создает вызов, на который отвечает клиент. Затем сервер отправляет ответ пользователя контроллеру домена в домене учетной записи компьютера. Этот контроллер домена проверяет учетную запись пользователя по своей базе данных учетных записей безопасности.

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

1. Имеет ли текущий домен прямые доверительные отношения с доменом пользователя?

   • Если да, контроллер домена отправляет учетные данные клиента контроллеру домена в домене пользователя для сквозной проверки подлинности.
   • Если нет, переходите к следующему шагу.

2. Имеет ли текущий домен транзитивные доверительные отношения с доменом пользователя?

   • Если да, передать запрос аутентификации следующему домену в доверительном пути. Этот контроллер домена повторяет процесс, проверяя учетные данные пользователя по своей базе данных учетных записей безопасности.
   • Если нет, отправить клиенту сообщение об отказе в входе в систему.

Обработка запросов проверки подлинности на основе Kerberos через доверительные отношения леса

Когда два леса связаны доверием леса, запросы проверки подлинности, сделанные с использованием протоколов Kerberos V5 или NTLM, могут маршрутизироваться между лесами для обеспечения доступа к ресурсам в обоих лесах.

При первом установлении доверия леса каждый лес собирает все доверенные пространства имен в своем партнерском лесу и сохраняет информацию в объекте доверенного домена. Надежные пространства имен включают имена доменного дерева, суффиксы имени участника-пользователя (UPN), суффиксы имени участника-службы (SPN) и пространства имен идентификатора безопасности (SID), используемые в другом лесу. Объекты TDO реплицируются в глобальный каталог.

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

• DNS-имя хоста.
• DNS-имя домена.
• Отличительное имя объекта точки подключения службы.

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

Следующая диаграмма и шаги предоставляют подробное описание процесса проверки подлинности Kerberos, который используется, когда компьютеры под управлением Windows пытаются получить доступ к ресурсам с компьютера, расположенного в другом лесу.

1. User1 входит в систему Workstation1 , используя учетные данные из europe.tailspintoys.com домен. Затем пользователь пытается получить доступ к общему ресурсу на FileServer1 , расположенном в лесу usa.wingtiptoys.com .

2. Workstation1 связывается с Kerberos KDC на контроллере домена в своем домене, ChildDC1 , и запрашивает билет службы для FileServer1 SPN.

3. ChildDC1 не находит SPN в своей базе данных доменов и запрашивает глобальный каталог, чтобы узнать, есть ли какие-либо домены в tailspintoys .com лес содержит это SPN. Поскольку глобальный каталог ограничен собственным лесом, имя участника-службы не найдено.

   Затем глобальный каталог проверяет свою базу данных на наличие информации о любых доверительных отношениях между лесами, установленных с его лесом. При обнаружении он сравнивает суффиксы имен, перечисленные в объекте доверенного домена доверия леса (TDO), с суффиксом целевого SPN, чтобы найти совпадение. Как только совпадение найдено, глобальный каталог предоставляет подсказку маршрутизации к ChildDC1 .

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

4. ChildDC1 отправляет ссылку для своего родительского домена обратно на Workstation1 .

5. Workstation1 обращается к контроллеру домена в ForestRootDC1 (его родительский домен) для обращения к контроллеру домена ( ForestRootDC2 ) в корневом домене леса wingtiptoys.com лес.

6. Workstation1 связывается с ForestRootDC2 в лесу wingtiptoys.com для получения билета на запрашиваемую услугу.

7. ForestRootDC2 связывается со своим глобальным каталогом, чтобы найти SPN, и глобальный каталог находит соответствие для SPN и отправляет его обратно в ForestRootDC2 .

8. ForestRootDC2 затем отправляет ссылку на usa.wingtiptoys.com обратно на Workstation1 .

9. Workstation1 связывается с KDC на ChildDC2 и согласовывает билет для User1 , чтобы получить доступ к FileServer1 .

10. Как только Workstation1 получает билет службы, он отправляет билет службы FileServer1 , который считывает учетные данные безопасности User1 и соответственно создает маркер доступа.

Надежный доменный объект

Каждое доверие домена или леса в организации представлено объектом доверенного домена (TDO), хранящимся в контейнере System в своем домене.

Содержание TDO

Информация, содержащаяся в TDO, варьируется в зависимости от того, был ли TDO создан доверием домена или доверием леса.

При создании доверия домена такие атрибуты, как имя домена DNS, SID домена, тип доверия, транзитивность доверия и взаимное доменное имя, представлены в TDO. TDO доверия леса хранят дополнительные атрибуты для идентификации всех доверенных пространств имен из партнерского леса. Эти атрибуты включают имена доменного дерева, суффиксы имени участника-пользователя (UPN), суффиксы имени участника-службы (SPN) и пространства имен идентификатора безопасности (SID).

Поскольку доверительные отношения хранятся в Active Directory как TDO, всем доменам в лесу известны доверительные отношения, существующие во всем лесу. Точно так же, когда два или более леса объединяются через доверительные отношения лесов, корневые домены леса в каждом лесу имеют сведения о доверительных отношениях, существующих во всех доменах в доверенных лесах.

Изменение пароля TDO

Оба домена в доверительных отношениях имеют общий пароль, который хранится в объекте TDO в Active Directory.В рамках процесса обслуживания учетной записи каждые 30 дней доверенный контроллер домена меняет пароль, хранящийся в TDO. Поскольку все двусторонние трасты на самом деле являются двумя односторонними трастами, идущими в противоположных направлениях, для двусторонних трастов процесс происходит дважды.

Доверие имеет доверяющую и доверенную сторону. На доверенной стороне для процесса может использоваться любой доступный для записи контроллер домена. На доверенной стороне эмулятор PDC выполняет изменение пароля.

Чтобы изменить пароль, контроллеры домена выполняют следующий процесс:

1. Эмулятор основного контроллера домена (PDC) в доверяющем домене создает новый пароль.Контроллер домена в доверенном домене никогда не инициирует смену пароля. Он всегда инициируется эмулятором PDC доверяющего домена.

2. Эмулятор PDC в доверяющем домене устанавливает поле OldPassword объекта TDO в текущее поле NewPassword .

3. Эмулятор PDC в доверяющем домене устанавливает в поле NewPassword объекта TDO новый пароль. Сохранение копии предыдущего пароля позволяет вернуться к старому паролю, если контроллер домена в доверенном домене не может получить изменение или если изменение не реплицируется до того, как будет сделан запрос, использующий новый пароль доверия.

4. Эмулятор основного контроллера домена в доверяющем домене делает удаленный вызов контроллеру домена в доверенном домене с просьбой установить новый пароль для доверенной учетной записи.

5. Контроллер домена в доверенном домене меняет доверительный пароль на новый пароль.

6. На каждой стороне доверия обновления реплицируются на другие контроллеры домена в домене. В доверенном домене изменение вызывает срочную репликацию объекта доверенного домена.

Теперь пароль изменен на обоих контроллерах домена. Обычная репликация распределяет объекты TDO на другие контроллеры домена в домене. Однако контроллер домена в доверенном домене может изменить пароль без успешного обновления контроллера домена в доверенном домене. Этот сценарий может возникнуть из-за того, что не удалось установить защищенный канал, необходимый для обработки смены пароля. Также возможно, что контроллер домена в доверенном домене может быть недоступен в какой-то момент во время процесса и может не получить обновленный пароль.

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

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

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

Обновления пароля доверия необходимо реплицировать на контроллеры домена обеих сторон доверия в течение 30 дней. Если пароль доверия изменяется через 30 дней, а контроллер домена имеет только пароль N-2, он не может использовать доверие со стороны доверяющего и не может создать безопасный канал на доверенной стороне.

Сетевые порты, используемые трастами

Поскольку доверительные отношения должны быть развернуты через различные границы сети, они могут охватывать один или несколько межсетевых экранов. В этом случае вы можете либо туннелировать трафик доверия через брандмауэр, либо открывать определенные порты в брандмауэре, чтобы разрешить прохождение трафика.

Важно

Доменные службы Active Directory не поддерживают ограничение трафика RPC Active Directory определенными портами.

Прочтите раздел Windows Server 2008 и более поздних версий статьи службы поддержки Microsoft Как настроить брандмауэр для доменов Active Directory и доверительных отношений, чтобы узнать о портах, необходимых для доверия леса.

Для поддержки доверия и аутентификации используются некоторые дополнительные функции и инструменты управления.

Чистый вход

Служба сетевого входа в систему поддерживает защищенный канал от компьютера под управлением Windows к контроллеру домена. Он также используется в следующих процессах, связанных с доверием:

• Настройка и управление доверием — Net Logon помогает поддерживать пароли доверия, собирает информацию о доверии и проверяет доверие, взаимодействуя с процессом LSA и TDO.

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

• Аутентификация — предоставляет учетные данные пользователя по защищенному каналу контроллеру домена и возвращает SID домена и права пользователя для пользователя.

• Расположение контроллера домена — помогает находить или находить контроллеры домена в домене или между доменами.

• Сквозная проверка — учетные данные пользователей в других доменах обрабатываются Net Logon. Когда доверяющему домену необходимо проверить личность пользователя, он передает учетные данные пользователя через Net Logon в доверенный домен для проверки.

• Проверка сертификата атрибута привилегий (PAC) — когда серверу, использующему протокол Kerberos для аутентификации, необходимо проверить PAC в билете службы, он отправляет PAC по защищенному каналу своему контроллеру домена для проверки.

Местная служба безопасности

Local Security Authority (LSA) — это защищенная подсистема, которая хранит информацию обо всех аспектах локальной безопасности в системе. В совокупности известный как локальная политика безопасности, LSA предоставляет различные услуги для преобразования между именами и идентификаторами.

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

Инструменты управления

Администраторы могут использовать доменов Active Directory и доверительные отношения , Netdom и Nltest для предоставления, создания, удаления или изменения доверительных отношений.

• Домены и доверие Active Directory — это консоль управления Microsoft (MMC), которая используется для администрирования доверительных отношений домена, функциональных уровней домена и леса, а также суффиксов имени участника-пользователя.
• Инструменты командной строки Netdom и Nltest могут использоваться для поиска, отображения, создания и управления доверительными отношениями. Эти инструменты напрямую взаимодействуют с органом LSA на контроллере домена.

Следующие шаги

Дополнительные сведения о лесах ресурсов см. В разделе Как работают доверительные отношения лесов в Azure AD DS?

Чтобы приступить к созданию управляемого домена с лесом ресурсов, см. Раздел Создание и настройка управляемого домена Azure AD DS.Затем вы можете создать доверие исходящего леса для локального домена.

Настройка доверия домена к домену NETID

Для завершения этого процесса вам понадобится следующее:

• Доступ к учетной записи пользователя в локальном домене / лесу, которая является членом группы администраторов домена или администраторов предприятия
• Ближайший телефон (из соображений безопасности мы не отправляем пароли доверительных отношений по электронной почте)
• Примерно 20 минут свободного времени

---

Для создания одностороннего исходящего внешнего доверия для одной стороны доверия

1. Откройте инструмент администрирования доменов и доверия Active Directory.
2. В дереве консоли щелкните правой кнопкой мыши свой домен и выберите Свойства .
3. На вкладке Доверительные отношения щелкните Новое доверие , а затем щелкните Далее .
4. На странице Trust Name введите DNS-имя домена, для которого вы хотите создать доверие, а затем нажмите Next .
   

   Для инфраструктуры Windows UW введите: netid.washington.edu .

5. На странице Тип доверия щелкните Внешнее доверие , а затем нажмите Далее .
6. На странице Направление доверия щелкните Односторонний: исходящий , а затем щелкните Далее .
7. На странице Доверительные стороны щелкните Только этот домен , а затем щелкните Далее .
8. На странице Уровень проверки подлинности исходящего доверия выберите либо Проверка подлинности на уровне домена , либо Выборочная проверка подлинности , а затем щелкните Далее
9. На странице Trust Password дважды внимательно введите пароль доверия и нажмите Next .(Инженер UW Technology сообщит вам этот пароль по телефону.)
10. На странице Trust Selections Complete просмотрите результаты и нажмите Next .
11. На странице Trust Creation Complete просмотрите результаты и нажмите Next .
12. На странице Подтвердить исходящее доверие нажмите Да, подтвердить исходящее доверие . Новое доверие будет подтверждено и проверено. UW Technology не может подтвердить доверие без учетной записи администратора домена и пароля в вашем домене.
13. На странице Завершение мастера создания доверия нажмите Готово .

После того, как вы выполните эти шаги, сообщите об этом инженеру UW-IT, чтобы мы знали, что процесс завершен. После этого ваши доверительные отношения должны заработать. Теперь вы можете использовать учетные записи пользователей NETID, как обычные учетные записи пользователей локального домена.

10 вещей, которые вы должны знать о доверии доменов AD

Создание доверительных отношений и управление ими может быть немного сложным, а неверно настроенное доверие может иметь серьезные последствия для вашей сети.ИТ-специалист Рик Вановер составил список фактов и указателей, которые следует учитывать при работе с доверительными отношениями доменов.

Эту статью также можно загрузить в формате PDF.

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

# 1: Определите, какое доверие вам следует использовать

Перед развертыванием доверия домена необходимо убедиться, что используемые типы соответствуют поставленным задачам. Рассмотрим следующие габариты траста:

• Тип: Определяет типы доменов, вовлеченных в доверительные отношения.
• Транзитивность: Определяет, может ли одно доверие пропускать доверенный домен к третьему домен.
• Направление: Определяет направление доступа и доверия (доверенные учетные записи и доверительные Ресурсы).

# 2: ознакомьтесь с доменами Active Directory Консоль и трасты

Доверительные отношения управляются через консоль доменов и доверительных отношений Active Directory. Это позволяет вам выполнять следующие основные задачи:

• Повысить функциональный уровень домена до
• Повысить функциональный уровень леса до
• Добавить суффиксы UPN
• Управление доверием домена
• Управление доверием леса

Подробнее об использовании этого инструмента см. «Экскурсия по TechRepublic: домены Active Directory и Консоль доверия.«

# 3: Изучите инструменты

Как и большинство других элементов семейства Windows Server, инструменты командной строки могут использоваться для написания повторяющихся задач или для обеспечения последовательность в случае создания доверия. Некоторые из лучших инструментов включают:

• NETDOM: Используется для устанавливать или разрушать типы доверия.
• NETDIAG: The Результаты этого инструмента могут дать базовый статус доверительных отношений.
• NLTEST: Может быть используется для проверки доверительных отношений.

Также можно использовать Проводник Windows для просмотра членства в общих ресурсах по мере их назначения из доверенные домены и / или леса. Пользователи и компьютеры Active Directory также могут предоставить сведения о членстве в объектах Active Directory, у которых есть члены из доверенные домены и / или леса.

# 4: Настройка тестовой среды

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

# 5: Просмотр привилегий

Когда трасты Создано, важно обеспечить достижение желаемой функциональности.Но обязательно просмотрите настроенное доверие, чтобы убедиться, что направление доступ правильный. Например, если домену A требуется доступ только к ограниченному количество ресурсов в домене B; двустороннего доверия было бы достаточно. Однако администратор из домена B может назначать доступ к ресурсам в домене А. Обеспечение желаемого направления, типа и транзитности трастов имеет решающее значение.

# 6: Составить карту трастов

Создать карту трасты с простыми стрелками и прямоугольниками, показывающими, какие домены будут доверять и доверенные, и какие трасты будут односторонними и двусторонними.Затем с помощью простого изображение (а) на месте, наметьте, какие домены будут доверять, а также определите транзитность. Эта простая диаграмма сделает больше понимание более важной задачи и позволит вам определить, какие домены нуждаются в направление доступа и в каком направлении. Некоторые домены будут просто действовать как шлюз для транзитивного доступа к другим доменам.

# 7: Документируйте доверительные отношения

Как организации жениться (и развестись) в современном деловом мире, важно четко документацию по доверительному инвентарю — и убедиться, что он доступен без доверие или домен.Например, если вы находитесь в Домене B и в вашей штаб-квартире в Домене А продает ваше подразделение и подрывает ваше доверие, ваша лаконичность документация, сохраненная на сервере в Домене А, не принесет вам пользы. Документируйте тип доверия, транзитивность, направление, деловая потребность в доверии, ожидаемая продолжительность доверия, учетные данные, субъект домена / леса информация (имя, DNS, IP-адреса, местоположения, имена компьютеров и т. д.), и контактное лицо (а) для соответствующих доменов.

# 8: Избегайте создания слишком глубокие доверительные отношения

В интересах всем, не вкладывайте членство более чем в одну глубину при использовании трастов в несколько доменов и лесов.Вложенное членство может объединить количество управляемые объекты Active Directory, но определяющие фактическое членство администрирование значительно увеличено.

# 9: Уметь управлять разными версиями Windows

При обкатке Собственный режим Windows 2000 и Windows Server 2003 для Active Directory, полный функциональность поддерживается для членских доменов и лесов. Если какие-либо домены NT или членские системы присутствуют на предприятии, их трастовая запись функциональность ограничена невозможностью распознать Active Directory объекты.Частой стратегией в этом сценарии является создание «доменных островов» из тех которые не подключаются к более распространенной корпоративной инфраструктуре.

# 10: Удалить истекшие или перекрывающиеся доверительные отношения

Изменения в организации бизнеса могли оставить неиспользованные трасты на месте ваш домен. Удалите все трасты, которые активно не используются. Вам следует также убедитесь, что ваши трасты настроены правильно для требуемых шаблоны доступа и использования. Аудит вашего доверительного инвентаря может быть сильным дополнение к вашей всесторонней политике безопасности.

Обзор консоли Active Directory Domains And Trusts

В Windows Server есть несколько инструментов для управления Active Directory во всех ее аспектах. В этой статье вы узнаете, как использовать и все тонкости консоли Active Directory Domains And Trusts.

Если вы какое-то время работали с Active Directory, вполне вероятно, что вы знакомы с доменами и доверительными отношениями (по крайней мере, в некоторой степени).Обе эти темы напрямую связаны с Active Directory, которая служит основным репозиторием для широкого спектра информации в Windows 2000 Server, Windows Server 2003 и Windows Server 2008. В Windows Server есть несколько инструментов для управления Active Directory в целом. его аспекты. В этой статье вы узнаете, как использовать и все тонкости консоли Active Directory Domains And Trusts.

Raison d’etre

Прежде чем углубляться в консоль Active Directory Domains And Trusts Console, важно понять, для чего служит этот инструмент администрирования.

Впервые представленная в Windows 2000 Server, Active Directory с тех пор служила центральным хранилищем значительного объема информации во всех версиях Windows. В Active Directory хранится множество битов информации, в том числе следующие:

• Пользователи и группы
• DNS зоны
• Общие принтеры
• Домены
• Доверительные отношения
• Объекты, относящиеся к приложению, например Exchange

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

Домены разделены на деревьев и лесов . Дерево доменов — это набор связанных доменов. Лес домена — это набор связанных деревьев доменов. Если вам интересно, что такое «дерево» домена, подумайте об этом так: когда вы думаете о структуре домена, вам необходимо учитывать возможность дочерних доменов, которые свисают с главного / родительского домена.Эти дочерние домены можно рассматривать как ветви. Отсюда и метафора дерева. Как только ваша инфраструктура выходит за пределы одного домена, в игру вступают доверительных отношений . Отношения доверия позволяют одному домену доверять объектам в другом для аутентификации и доступа к ресурсам.

Например, если домен A доверяет домену B, пользователь из домена B может получить доступ к ресурсам в домене A, если ему предоставлены необходимые разрешения на доступ в домене A. В лесу домена Windows 2000 или более поздней версии все доверительные отношения являются транзитивными, и двунаправленными. или двусторонний .Если вы помните время своего обучения в колледже, вспомните, что вы узнали на уроке логики в отношении транзитивных отношений. В транзитивном примере, если A доверяет B, а B доверяет C, то A также доверяет C. Та же логика применяется к доменам Windows. Транзитивное доверие — это доверие, которое передается из одного домена в другой, а затем в другой. Итак, если домен A доверяет домену B, а домен B доверяет домену C, то домен A доверяет домену C. Имеет смысл?

Двустороннее доверие — это доверие, которое проходит в обоих направлениях между двумя доменами.Например, домен A доверяет домену B, а домен B доверяет домену A. Доверие в Windows NT было немного сложным, но в Windows 2000 и более поздних версиях доверие является автоматическим; вам не нужно настраивать доверие между родительским и дочерним доменами, поскольку Windows Server устанавливает неявные доверительные отношения.

Наконец, рассмотрим вопрос о доверительных отношениях между лесами. Напомним, что лес — это набор доменов. Вы можете создать доверительные отношения между отдельными лесами доменов, чтобы разрешить доменам в одном лесу доверять доменам в другом.При двустороннем транзитивном доверии лесов все домены в каждом лесу доверяют всем доменам в другом лесу и наоборот. Доверительные отношения леса предлагают несколько преимуществ в крупных организациях, упрощая администрирование и проверку подлинности.

С учетом всего этого, какой цели служит консоль Active Directory Domains And Trusts? Прежде всего и, возможно, самое главное, консоль позволяет управлять доверительными отношениями между доменами и лесами. Консоль также позволяет вам устанавливать функциональные уровни домена и леса, а также управлять суффиксами имени участника-пользователя (UPN).

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

• Повысить функциональный уровень домена: Домен Windows Server 2008 может работать в одном из трех режимов: Windows 2000 Native, Windows Server 2003 или Windows Server 2008.Эти режимы более подробно описаны в моем сообщении о функциональных уровнях домена и леса Windows Server 2008.
• Повышение функционального уровня леса: Windows Server 2008 поддерживает три функциональных уровня леса, каждый из которых предлагает возрастающие уровни возможностей, хотя функциональный уровень леса Windows Server 208 фактически не добавляет дополнительных функций. Эти уровни включают Windows 2000, Windows Server 2003 и Windows Server 2008. Например, когда все контроллеры домена в домене работают под управлением Windows Server 2008 и каждый домен переведен в функциональный режим Windows Server 2008, вы можете повысить функциональность уровень для этого доменного леса до Windows Server 2008.
• Добавить суффиксы UPN: В домене Windows 2000 или более поздней версии пользователи могут входить в систему с UPN, связанным с их учетными записями. UPN принимает форму user @ upnsuffix, например [email protected]. Пользователи также могут входить в систему под именем пользователя до Windows 2000, которое в этом примере, скорее всего, будет именем пользователя (но не обязательно). Суффикс UPN обычно определяет домен, в котором находится учетная запись, но это может быть DNS-имя домена, DNS-имя другого домена в лесу или альтернативный суффикс, созданный администратором домена исключительно для входа в систему.
• Управление доверием домена: С помощью консоли можно выполнять несколько задач, включая проверку или удаление доверия, а также создание ярлыка, области и внешних доверительных отношений. Эти типы доверия будут объяснены позже.
• Управление доверием леса: Можно выполнить несколько задач, связанных с доверием леса, включая создание доверия леса и управление маршрутизацией для определенных суффиксов имен.

Взгляд под капот

Чтобы запустить консоль доменов и доверительных отношений Active Directory, выберите Пуск | Все программы | Инструменты администрирования | Домены и трасты Active Directory.Когда вы впервые открываете консоль, показанную на рис. A , вы видите относительно простой дисплей, на котором перечислены локальный домен и его дочерние домены, если таковые имеются.

Рисунок A

Консоль доменов и доверия Active Directory

Консоль доменов и доверительных отношений Active Directory — это стандартная консоль управления Microsoft (MMC) с обычным макетом и элементами. На левой панели отображается список доменов, а на правой панели отображаются объекты, например доверительные отношения, связанные с выбранным доменом.

Меню

Консоль доменов и доверительных отношений Active Directory включает четыре пункта меню:

• Файл: Используйте меню «Файл» для выхода из консоли. Вы также можете выбрать «Параметры» в меню «Файл», чтобы открыть диалоговое окно, в котором можно удалить файлы, в которых хранятся изменения, внесенные вами в консоль.
• Действие: Содержимое меню «Действие» изменяется в соответствии с объектом, выбранным в консоли. Выбрав ветвь Active Directory «Домены и доверие», вы можете подключиться к контроллеру домена, просмотреть или изменить мастеров операций с доменом, а также повысить функциональный уровень леса.Вы также можете обновить вид и экспортировать список доменов в нескольких текстовых форматах с разделителями. Выбор «Свойства» в меню «Действия» позволяет добавлять альтернативные суффиксы UPN. Вы также можете открыть справку из этого меню. Когда вы выбираете домен, вы можете выбрать Действие | Успейте открыть консоль пользователей и компьютеров Active Directory, ориентированную на выбранный домен. Выбор меню «Свойства» с выбранным доменом позволяет просматривать свойства домена, управлять доверительными отношениями и указывать пользователя или контактное лицо, отвечающее за управление доменом.
• Просмотр: Используйте меню «Просмотр» для добавления или удаления столбцов на правой панели или выберите режим просмотра (маленькие значки, большие значки, список или детали). Вы также можете настроить вид, добавляя или удаляя элементы интерфейса, такие как панель инструментов, строка состояния, вкладки навигации панели задач и другие элементы.
• Справка: Как и в случае с другими консолями на основе MMC, используйте это меню для доступа к содержимому справки для текущей MMC — в данном случае к консоли Active Directory Domains And Trusts Console — а также к общему содержимому справки MMC.

Панель инструментов В верхней части консоли Active Directory Domains And Trusts Console, показанной на рисунке , рис. A , вы заметите панель инструментов. Панель инструментов содержит следующие кнопки:

• Назад: Вернуться назад по консоли.
• Вперед: Переход вперед по консоли.
• На один уровень выше (не всегда отображается): Перейти на следующий более высокий уровень в дереве; доступно только при выборе домена.
• Показать / скрыть дерево консоли: Переключить отображение левой панели навигации.
• Свойства: Откройте свойства выбранного элемента.
• Обновить (не всегда отображается): Обновить текущий вид; доступно только при выборе ветки «Домены и доверие».
• Список экспорта: Экспорт выбранных объектов в виде списка с разделителями.
• Справка: Откройте содержимое справки.

Контекстные меню

Как и в случае с большинством инструментов, консоль предоставляет контекстное меню, когда вы щелкаете правой кнопкой мыши элемент в панели дерева консоли.Команды в контекстном меню соответствуют пунктам меню в меню «Действие», когда выбран тот же элемент.

Работа на уровне Domains And Trusts

Есть несколько задач, которые вы можете выполнить с помощью консоли Active Directory Domains And Trusts на уровне Active Directory Domains And Trusts. Я не буду описывать рутинные задачи, такие как обновление или настройка представления; вместо этого я сосредоточусь на задачах управления доменом и лесом.

Подключение к контроллеру домена

При работе с консолью Active Directory Domains And Trusts Console — особенно при работе с административной рабочей станции — вероятно, вам потребуется изменить фокус консоли.Вы делаете это, подключаясь к определенному контроллеру домена (DC). Для этого щелкните ветку Active Directory Domains And Trusts и выберите Action | Измените контроллер домена Active Directory. Или просто щелкните правой кнопкой мыши ветку Active Directory Domains And Trusts и выберите Change Active Directory Domain Controller.

На консоли отобразится диалоговое окно «Подключиться к серверу смены каталога» (, рис. B, ). Введите имя домена вручную в разделе «или щелкните стрелку вниз рядом с полем Искать в этом домене, чтобы найти другой контроллер домена.После выбора домена его контроллеры домена отображаются в нижней половине диалогового окна. Выберите вариант «Любой контроллер домена с возможностью записи», если вам не нужно работать с конкретным контроллером домена в домене. В противном случае выберите DC из списка и нажмите OK.

Рисунок B

Диалоговое окно «Изменить сервер каталогов»

Настройка мастера операций именования доменов

Хозяин операций по именованию доменов (одна из ролей FSMO) гарантирует, что все домены на предприятии имеют уникальные имена.Только один компьютер на предприятии выполняет функции хозяина операций. По умолчанию хозяином операций является первый созданный контроллер домена.

По разным причинам вам может потребоваться переместить роль хозяина операций на другой DC. Для этого откройте консоль Active Directory Domains And Trusts и щелкните ветку Active Directory Domains And Trusts. Выберите действие | Измените контроллер домена Active Directory. Найдите и выберите контроллер домена, который станет хозяином операций, и нажмите OK.Выберите действие | Мастер операций или щелкните ветку правой кнопкой мыши и выберите Мастер операций в контекстном меню. В диалоговом окне «Мастер операций» нажмите «Изменить».

Рисунок C

Измените сервер, на котором находится роль хозяина операций

Повышение функционального уровня леса

Как упоминалось ранее в этой статье, вы можете повысить функциональный уровень леса до Windows Server 2008, если все контроллеры домена в лесу были повышены до уровня Windows Server 2008.Чтобы повысить функциональный уровень леса, щелкните ветку Active Directory Domains And Trusts и выберите Action | Повышение функционального уровня леса. Если все домены в лесу были повышены до уровня Windows Server 2008, на консоли отобразится диалоговое окно «Повышение функционального уровня леса», показанное на рис. D .

Рисунок D

Функциональный уровень Raise Forest

Если не все домены в лесу были подняты до уровня Windows Server 2008, вы получите сообщение об ошибке, указывающее, что не все предварительные условия были выполнены для операции.

Добавление суффиксов UPN

При создании домена Windows предлагает имя корневого домена и текущего домена в качестве суффиксов UPN по умолчанию. Пользователи могут входить в систему с UPN, например [email protected], или с именем входа до Windows 2000, например с именем пользователя. В некоторых ситуациях может потребоваться добавить другие суффиксы UPN. Например, ваш домен для входа — example.com, но вся электронная почта пользователя отправляется на адреса в woodgrovebank.com. Чтобы помочь пользователям запомнить свои UPN, вы решили добавить суффикс UPN woodgrovebank.com в домен. Вы можете сделать это с помощью консоли Active Directory Domains And Trusts Console.

Откройте консоль, щелкните ветвь Active Directory Domains And Trusts и выберите Action, затем Properties, чтобы открыть вкладку UPN Suffixes. Щелкните поле Альтернативные суффиксы UPN и введите добавляемый суффикс (например, woodgrovebank.com) и щелкните Добавить. Повторите процесс, чтобы добавить в лес другие суффиксы UPN.

Рисунок E

При необходимости добавьте дополнительные суффиксы UPN

Работа на уровне домена

Некоторые задачи, которые вы можете выполнять на уровне домена с помощью консоли Active Directory Domains And Trusts Console, аналогичны тем, которые вы можете выполнять на уровне леса.Вы также можете выполнять некоторые дополнительные задачи, такие как управление доверительными отношениями.

Управление доменом

Когда вы работаете с локальным доменом, просто открыть консоль Active Directory Users And Computers, которая открывается с фокусом на локальном домене. Однако, когда вы работаете с этой консолью, вполне вероятно, что вы будете работать с другими доменами. Когда вам нужно управлять объектами в этих доменах и вы уже открыли консоль Active Directory Domains And Trusts Console, часто проще открыть домен и управлять им оттуда.Для управления доменом щелкните домен в дереве консоли и выберите «Действие», затем «Управление». Откроется консоль «Пользователи и компьютеры Active Directory» с фокусом на выбранном домене.

Просмотр и настройка общих свойств

Существует только одно общее свойство, которое вы можете установить для домена через консоль Active Directory Domains And Trusts Console: описание домена. Описание появляется в консоли, когда вы открываете свойства домена. Описание может помочь вам определить цель домена или отслеживать другую полезную информацию.

Чтобы задать описание, щелкните домен и затем выберите Действие | Характеристики. Щелкните поле Описание и введите описание. В диалоговом окне также отображается другая информация, такая как функциональный уровень домена, функциональный уровень леса и имя домена до Windows 2000. См. Рисунок F , чтобы увидеть это окно.

Рисунок F

Изменить метку домена

Управляющие трасты Одна из ключевых задач, которые вы будете выполнять с помощью консоли Active Directory Domains And Trusts Console, — это управление доверительными отношениями между доменами и лесами.Например, вы можете проверить доверительные отношения, существующие между доменами. Для этого щелкните домен, содержащий доверие, которое вы хотите проверить, и выберите «Действие», затем «Свойства». Щелкните вкладку Доверие и щелкните доверие, которое хотите проверить. Щелкните Свойства, чтобы открыть свойства доверия. Диалоговое окно на рис. G показывает направление доверия и транзитивность, а также позволяет проверить доверие.

Рисунок G

Здесь вы можете подтвердить доверие.

При нажатии кнопки «Проверить» консоль открывает диалоговое окно Active Directory, показанное на рис. , рис. H . Выберите Да, проверить входящее доверие, если вы хотите проверить доверительные отношения из другого домена. Выберите Нет, не проверять входящее доверие (по умолчанию), если вы хотите проверить только исходящее доверие. Если вы выбрали «Да», щелкните поле «Имя пользователя» и введите имя пользователя учетной записи с привилегиями в локальном домене, введите соответствующий пароль и нажмите «ОК».Затем консоль отображает информационное диалоговое окно, в котором указывается статус доверия (, рис. I, ).

Рисунок H

Предоставьте учетные данные для подтверждения доверия

Рисунок I

Проверка доверия прошла успешно.

Вы также можете использовать вкладку Trusts, чтобы добавить новые доверительные отношения. Вы можете создать следующие типы доверия:

• Ярлык доверия: Это доверие между двумя несмежными доменами в одном лесу.Сокращенное доверие может помочь сократить время входа в систему. Сокращенные доверительные отношения могут быть односторонними или двусторонними и являются транзитивными.
• Доверие области : Доверие области позволяет создавать доверительные отношения между областью Kerberos, отличной от Windows, и доменом Windows Server. Доверие областей может быть односторонним или двусторонним, транзитивным или непереходным.
• Внешнее доверие: Этот тип доверия связывает домен Windows Server с доменом Windows NT или доменом в другом лесу, для которого нет доверия леса.Внешние доверительные отношения могут быть односторонними или двусторонними и не являются транзитивными.
• Доверие леса: Используйте этот тип доверия, чтобы разрешить совместное использование ресурсов между лесами. Лесные трасты могут быть односторонними или двусторонними, а также транзитивными.

При нажатии кнопки «Новое доверие» на вкладке «Доверие» консоль доменов и доверительных отношений Active Directory запускает мастер создания доверия. После того, как вы нажмете «Далее», чтобы пропустить обязательную заставку, мастер предложит ввести имя домена, леса или области. Если мастер не распознает указанное имя как действительный домен Windows, он отображает страницу типа доверия, показанную на рисунке , рис. J , которая позволяет вам выбирать между доверием области и доменом Windows и вводить другое имя для домена. .

Рисунок J

Выберите подходящий тип траста

Если вы укажете домен, который является корнем внешнего леса, консоль предоставит вам возможность создать доверие леса или внешнее доверие. Вы можете создать доверие леса, только если уровень локального леса был повышен как минимум до уровня Windows Server 2003. Фактически, если уровень леса не был повышен, консоль автоматически рассматривает доверие как внешнее доверие и не отображает диалоговое окно.Если вы укажете домен ниже корня удаленного леса, консоль также будет рассматривать доверие как внешнее доверие.

Затем на странице «Направление доверия» мастер запрашивает направление доверия — двусторонний, односторонний входящий или односторонний исходящий. Затем вы указываете, где создается доверие, только локально или также в удаленном домене.

Затем вы указываете область аутентификации для доверия. Выберите «Общедоменная проверка подлинности», если вы хотите, чтобы Windows автоматически проверяла подлинность пользователей из удаленного домена для всех ресурсов в локальном домене.Выберите «Выборочная проверка подлинности», если вы хотите предоставить индивидуальные разрешения для пользователей в удаленном домене локальным ресурсам. (Вы можете изменить область проверки подлинности после создания доверия. Откройте свойства доверия и щелкните вкладку Проверка подлинности, затем выберите желаемую область.)

После выбора области проверки подлинности и нажатия кнопки «Далее» вы вводите и подтверждаете пароль, который Windows использует для проверки создания доверия. После страницы подтверждения мастер создает доверие, а затем дает вам возможность подтвердить доверие.Если вы создали двустороннее доверие, консоль дает вам возможность подтвердить доверие в обоих направлениях.

Управление маршрутизацией суффиксов имени

При работе с доверием леса следует учитывать одну проблему — маршрутизацию суффиксов имени между лесами. Маршрутизация с суффиксом имени позволяет направлять запросы аутентификации в другие домены. Вы найдете хорошее резюме маршрутизации суффиксов имен, обнаружения коллизий суффиксов имен и связанных тем в Active Directory Domains And Trusts / Concepts / Understanding Active Directory Domains And Trusts / Understanding Active Directory Domains And Trusts / Understanding Trust / Routing name Suffixes Across Forests topic in the Help content for Консоль доменов и доверительных отношений Active Directory.

Когда вы будете готовы настроить маршрутизацию суффиксов имен, откройте консоль Active Directory Domains And Trusts и щелкните корневой домен леса. Выберите действие | Свойства и щелкните вкладку Доверие. Щелкните доверие леса в списке доверия и щелкните Свойства, затем щелкните вкладку Маршрутизация суффикса имени. Здесь вы можете включить или отключить определенные суффиксы имен для маршрутизации. Вы также можете явно исключить суффиксы имен из маршрутизации в локальный лес. Щелкните суффикс имени в списке и нажмите кнопку «Изменить», чтобы открыть диалоговое окно «Изменить».Нажмите «Добавить», введите суффикс и нажмите «ОК». В диалоговом окне «Редактировать» вы также можете изменить статус маршрутизации суффикса имени.

Как вы можете заметить, консоль Active Directory Domains And Trusts Console, хотя и не используется так часто, как Active Directory Users And Computers, является важным инструментом в вашем административном арсенале.

Информационный бюллетень по серверам и хранилищам TechRepublic, который выходит в понедельник и среду, предлагает советы, которые помогут вам управлять своим центром обработки данных и оптимизировать его. Зарегистрируйтесь автоматически сегодня!

доверительные отношения между двумя лесами / доменами

Presentation

Доверительные отношения между двумя детализированными битами / доменами Active Directory — это надежная ссылка, которая позволяет аутентифицированным пользователям получать доступ к ресурсам в другом домене.

Отношения утверждения могут быть следующими:

• Однонаправленный: доступ к ресурсам доступен только в одном направлении (A) -> (B).
• Двунаправленный: доступ к ресурсам доступен в обоих направлениях (A) <-> (B).
• Transitive: Если (A) и (B) имеют транзитивные доверительные отношения, если (B) одобряет домен (C), он будет одобрен в (A).

В этом случае требуется отношение утверждения:

• Настройка дочернего домена.
• Приобретение / слияние бизнеса для обеспечения доступа к ресурсам.
• SI сегментация (география / сервис /…).

В этом руководстве мы увидим, как установить доверительные отношения между двумя лесами, как если бы мы только что приобрели компанию.

Предварительные требования

Чтобы иметь возможность правильно обсуждать упражнения между ними, необходимо настроить сервер условной пересылки на каждом DNS-сервере.

Настроить доверительные отношения

Манипуляции проводились на контроллере домена в лаборатории.внутри.

Откройте консоль Active Directory Domain and Trust, щелкните правой кнопкой мыши домен 1 и выберите Свойства 2.

Перейдите на вкладку «Утверждения» 1 и щелкните «Новое утверждение 2», чтобы запустить мастер.

При запуске мастера нажмите Далее 1.

Укажите домен 1, с которым установлены доверительные отношения, и нажмите Далее 2.

Выберите Тип утверждения: Утверждение леса 1 и нажмите Далее 2.

Настройте направление утверждения, в этом примере мы выберем Двунаправленное направление 1 и нажмем Далее 2 для подтверждения.

Выберите вариант Этот домен и указанный домен 1, это позволяет напрямую создавать утверждение для другого домена. Щелкните Далее 1.

Введите идентификаторы 1 учетной записи администратора в указанном домене и нажмите Далее 2.

Выберите параметр «Проверка подлинности» для всех ресурсов леса 1 и нажмите «Далее» 2.

Аутентификация для всех ресурсов леса позволит пользователям из обоих доменов входить во все доступные позиции. Если вы хотите настроить выборочную аутентификацию, я приглашаю вас прочитать эту статью.

Также выберите Проверка подлинности для всех ресурсов леса 1 для пользователей из локального леса в другой лес и нажмите Далее 2.

Отображается сводная информация о доверительных отношениях, щелкните Далее 1, чтобы создать отношения.

Доверительные отношения созданы, щелкните Далее 1.

Подтвердите исходящее и следующее утверждение, выбрав Да 1 и нажав Далее 2.

Нажмите Готово 1, чтобы закрыть мастер.

Мы видим, что доверительные отношения созданы.

На контроллере в другом лесу также убедитесь, что связь создана.

Проверить доверительные отношения

Для подтверждения утверждения мы проведем 2 теста:

• В записи участника домена lab.intra мы откроем сеанс с пользователем, который является участником old.lan домен
• Сделаем членом домена lab.intra из группы домена old.lan

Авторизуемся в посте в другом домене

На компе в лан.intra домен, измените пользователя и введите учетные данные пользователя из домена old.lan, указав его домен в идентификаторе.

После открытия сеанса запустите командную строку и введите SET. На снимке экрана ниже мы видим, что компьютер находится в домене lab.intra 1, а пользователь является членом старого домена. лан.

Присоединиться к группе в доверенном домене

Перейдите в свойства пользователя в домене lab.intra, чтобы добавить его в группу. В окне выбора группы щелкните Расположение 1.

Выберите утвержденный домен 1 и нажмите ОК 2.

Выберите группу 1 и нажмите OK 2, чтобы добавить ее в нее.

No related posts.