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

Настройка доверительных отношений между доменами Active Directory

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

Мы будем рассматривать процесс настройки на примере двустороннего транзитивного доверия между доменами primary.local (192.168.0.15) и secondary.local (192.168.0.16). Саму настройку разделим на 2 этапа — конфигурирование DNS и создания доверий. В качестве операционной системы по данной инструкции можно настроить Windows Server 2008 / 2012 / 2016 / 2019.

Определяемся с типом доверительных отношений

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

Одностороннее или двустороннее

Определяют направление доверия одного домена к другому.

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

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

Внешнее или доверие леса

Внешнее или нетранзитивное отношение устанавливается между двумя доменами напрямую вне леса.

Доверие леса или транзитивное отношение связывает леса и все их домены.

Настройка DNS

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

На DNS домена primary.local

Открываем командную строку и вводим команду:

Мы должны получить ответ на подобие:

Server: localhost
Address: 127.0.0.1

Non-authoritative answer:
Name: secondary.local
Address: 192.168.0.16

На DNS домена secondary.local

Действия, которые делаем на втором сервере DNS, во многом, аналогичны.

В командной строке второго сервера проверяем настройку:

Мы должны получить ответ на подобие:

Server: localhost
Address: 127.0.0.1

Non-authoritative answer:
Name: primary.local
Address: 192.168.0.15

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

После настройки DNS можно переходить к созданию доверительных отношений.

В окне «Направление отношения доверия» выбираем Двустороннее:

. и нажимаем Далее.

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

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

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

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

В окне «Подтверждение исходящего доверия» оставляем Нет, не подтверждаю это исходящее доверие, так как на другой стороне нами не создавалось доверия.

Тоже самое в окне «Подтверждение входящего доверия».

Нажимаем Готово — доверительные отношения созданы.

Источник

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

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

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

У многих 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 (вместо слова админ Вы можете добавить любое имя, которое Вас устраивает, по умолчанию ставится 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).

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

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

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

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

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

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

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

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

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

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

Пользователи и компьютеры Active Directory

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

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

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

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

Утилита Netdom

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

Разберем опции команды:

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

Командлет PowerShell 3.0

В отличие от утилиты Netdom, PowerShell 3.0 входит в состав системы начиная с Windows 8 / Server 2012, для более старых систем его можно установить вручную, поддерживаются Windows 7, Server 2008 и Server 2008 R2. В качестве зависимости требуется Net Framework не ниже 4.0.

Точно также войдите на системе, для которой нужно восстановить доверительные отношения, локальным администратором, запустите консоль PowerShell и выполните команду:

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

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

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

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

Этот форум закрыт. Спасибо за участие!

Лучший отвечающий

Вопрос

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

Оба домена имеют по два DC/DNS на 2008R2 SP1 EE, уровень леса также 2008R2.

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

Я так понимаю что начинать нужно с передачи DNS зон.

Для домена 1 разрешил передачу основной зоны на КД домена 2.

После этого на КД домена 2 создал дополнительную зону, указал что брать ее нужно с домена 1.

Зона появилась в консоли днс, пинг работает и по ип, и по имени (полному).

В домене 2 nslookup %домен1% показывает правильные результаты, (ip DNS серверов в домене 1).

Затем сделал то же самое для домена 1.

При потпытке с помощью мастера консоли «Домены и доверия» создания отношений доверия с доменом Windows (не со сферой Kerberos) выдает ошибку доступа, хотя пингуется имя домена нормально (10.2.0.10 это основной КД и ДНС того домена) :

Источник

Атаки на трасты между доменами

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

Доверие между доменами используется для прохождения аутентификации пользователей одного домена на контроллере другого домена. Иначе говоря, чтобы пользователи с домена А могли иметь доступ к ресурсам домена Б. Доменная структура может быть двух видов:

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

Более наглядно типы доверий между доменами проиллюстрированы на картинке ниже.

Транзитивность (Transitivity)

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

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

Направление (Direction)

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

Направление доверия бывает двух типов:

Двустороннее доверие — это комбинация двух однонаправленных доверительных отношений. В двунаправленном доверии между доменами A и B их пользователи имеют доступ к ресурсам обоих доменов. Такой тип доверия транзитивен.

Направление доверия всегда противоположно направлению доступа. Показательная схема от Microsoft ниже:

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

Kerberos между доверенными доменами

Рассмотрим пример. Client пытается получить доступ к Server.

Изменения начинаются с пункта 4: появляется inter-realm TGT-тикет, так называемый реферальный тикет, который шифруется/подписывается inter-realm ключом, создаваемым из доверенного пароля. Доверенный пароль задается при установке доверительных отношений и известен обоим контроллерам домена. Используя inter-realm TGT-тикет, пользователь домена 1 может запросить TGS-тикет для доступа к ресурсам домена 2.

NTLM между доверенными доменами

Атаки на трасты между доменами

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

Перечисление трастов

Существует 3 основных метода для перечисления трастов в домене:

Перечисление осуществляется с помощью вызова функции DsEnumerateDomainTrusts, которая возвращает структуру DS_DOMAIN_TRUSTSA. При использовании данного метода возвращается SID и GUID целевого домена, флаги и атрибуты, характеризующие текущие доверительные отношения в домене.

BloodHound собирает информацию с помощью метода Win32 API.

Используется метод GetCurrentDomainиз пространства имен [System.DirectoryServices.ActiveDirectory.Domain], который возвращает экземпляр класса System.DirectoryServices.ActiveDirectory.Domain. В этом классе реализован метод GetAllTrustRelationships, который возвращает все доверительные отношения для текущего домена.

Использование данного метода реализовано в модуле Get-DomainTrust в PowerView.

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

Информация о доверительных отношениях домена хранится в Active Directory как objectClass класса trustedDomain.

PowerView по умолчанию использует данный метод.

Имея информацию о доменах и типах доверия, можно переходить непосредственно к самой атаке. Рассмотрим 2 варианта:

С правами администратора одного из доменов

В зависимости от домена, который был скомпрометирован, можно выделить несколько векторов атак:

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

1. Эксплуатация SID History

SID History был введен для облегчения миграции пользователей из одного домена в другой. Атрибут cодержит в себе предыдущие SID объекты. Каждый раз, когда объект перемещается из одного домена в другой, создается новый SID, который становится objectSID. Предыдущий SID добавляется в свойство sIDHistory.

В каждом лесу есть группа пользователей Enterprise Admins, которая существует только в root-домене и имеет права локального администратора на контроллерах домена всех Child-доменов леса. Впервые данная атака был продемонстрирована Sean Metcalf на BlackHat USA 2015. Суть атаки в том, что мы выпускаем Golden-тикет с добавлением дополнительного SID группы Enterprise Admins. Это выполняется путем добавления ExtraSids в структуре KERB_SID_AND_ATTRIBUTES, которая отправляется в структуре KERB_VALIDATION_INFO.

В impacket есть скрипт, который все это автоматизирует.

2. Golden Ticket + Enterprise Admin Group

Имея права администратора в Root-домене, мы можем создать Golden Ticket с добавлением пользователя в группу Enterprise Admins (519).

Как было написано выше, Enterprise Admin имеет права локального администратора на DC Child-доменов. Таким образом нам удастся скомпрометировать в лесу все Child-домены.

3. Эксплуатация билетов доверия

Атака особенно актуальна, когда служба ИБ заметила угрозу и сменила пароль krbtgt 2 раза. В этом случае мы сможем создавать golden-тикеты, используя доверенный пароль между доменами.

4. Printer Bug

В Windows Print System Remote Protocol (MS-RPRN) есть метод RpcRemoteFindFirstPrinterChangeNotification(Ex), включенный по умолчанию, который позволяет принудительно выполнить аутентификацию на любом компьютере с запущенной службой Spooler на указанном хосте по протоколу Kerberos либо NTLM. В случае c NTLM мы можем выполнить NTLM-relay, либо начать брутить пароль компьютера (никогда не сбрутите). В случае с Kerberos необходима скомпрометированная машина с неограниченным делегированием. Тогда мы сможем забрать TGT-тикет и развить атаку.

Рисунок ниже демонстрирует этапы, показанные на видео.

У нас нет прав администратора домена

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

Because of the way that groups are enumerated by the Global Catalog, the results of a back-link [i.e. memb search can vary, depending on whether you search the Global Catalog (port 3268) or the domain (port 389), the kind of groups the user belongs to (global groups vs. domain local groups).

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

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

2. Пользователи из других доменов, состоящие в группах домена пользователя. Группы, содержащие пользователей из другого домена

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

При выполнении запроса к глобальному каталогу, мы видим только одну группу Universal Group c типом AD Universal из домена one.jet.lab.

Если мы выполним прямой LDAP-запрос к домену one.jet.lab, то увидим другие группы с типом AD Domain local и AD Global.

Это важно учитывать при выполнении перечисления пользователей и групп.

Источник