Настройка доверительных отношений между доменами 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).
О доменных пузомерках. Домен Ранк. Домен Траст. Домен Джус.
В преддверии другой публикации, более сложной, я решил провести подготовку, чтобы терминология была всем понятна. Это действительно нужно, ведь у нас впереди много интересных публикаций из буржунета с переводом от SEOM.info
Сегодня речь пойдет о пузомерках, но не обычных и привычных нашему слуху, будь то тИЦ или PR. Из статьи вы узнаете что такое домен ранк, домен траст, домен джус, хотя все это не догмы, а мнение экспертов.
Домен Ранк (уровень доменов)
Я всегда старался объяснять принципы SEO простым, доходчивым языком, но тем не менее в SEO есть еще часть вопросов которые можно считать сложными и не совсем понятными. Совсем не потому что они сложные сами по себе, а в большей мере в этом виноват Google c их недостаточно прозрачной информационной политикой.
Для того что бы хорошо разбираться в SEO нужно понимать как работают все ссылки (входящие, исходящие, внутренние, внешние), как они влияют на ранжирование в поисковых системах. Проще говоря, Google использует всю ссылочную массу для определения релевантности, популярности и трастовости вашего сайта к заданному поисковому запросу.
Сначала Google только устанавливал уровень страниц (Page Level Rank), в зависимости от количества и качества ссылок ведущих на страницу. Схематически это выглядит так:
С недавнего времени Google также начал учитывать эти показатели на уровне доменов. Таким образом Google будет отслеживать все ссылки на домен так же как он раньше это делал для отдельных страниц.
Например, если вы имеете 1000 входящих ссылок на разные страницы вашего сайта, все они будут автоматически считаться входящими для вашего домена и он также получит свой собственный вес.
Ниже на рисунке скриншот с SEOmoz панели (ранее мы уже писали о ресурсе SEOmoz и его создателе), на нем показан Домен Ранк (domain rank) и трастовость домена (domain trust). Этот инструмент всегда хорошо «иметь под рукой» полезным при выборе сайта для размещения ссылок.
Если при расчете Пейдж Ранка учитывались количество внутренних и внешних ссылок на страницу, то при расчете Домен Ранка учитываются все ссылки на домен но только с внешних источников.
Все это базируется на разных показателях домена (так называемые пузомерки Google для доменов) и Домен Ранк один из этих показателей. Чем выше Домен Ранк тем лучше будут позиции новых страниц вашего сайта в поисковой выдаче. Например, глубокие внутренние ссылки с PR 0 могут быть очень ценными, если сайт имеет высокий Домен Ранк. Лично я бы предпочел иметь ссылку с какой-нибудь глубокой страницы с нулевым Пейдж Ранком с сайта BBC, чем ссылку с морды сайта с PR3, у которого низкий Домен Ранк.
Кроме Домен Ранка также существуют и другие доменные показатели: Домен Траст и Домен Джус, остановимся на них поподробнее.
Домен Траст (уровень доверия для доменов)
Улучшая Домен Траст (уровень доверия) для своего домена вы показываете Google и другим поисковым серверам что сайт содержит действительно полезную информацию и не нарушает этических норм, поэтому его нужно проиндексировать в первую очередь. Какие факторы учитываются при расчете показателя Домен Траст? Предполагаю что их сотни, но есть несколько основных о которых я бы хотел рассказать:
Теоретически, ваши конкуренты могли бы этим воспользоваться, проспамив ваши ссылки на всяких сомнительных сайтах что бы специально навредить вам, но Google это предусмотрел, поэтому такой вариант невозможен, или очень сложно осуществим.
Если Google видит входящие ссылки на ваш сайт с таких авторитетных ресурсов как wikipedia, dmoz, yahoo directory или других сайтов с высоким уровнем доверия, то и ваш сайт обретет определенный уровень доверия. Если кто-то попытается проспамить такой сайт с высоким Домен Трастом ссылками из неблагонадежных ресурсов, то вряд ли это будет иметь хоть какой-то эффект.
Поэтому, для «свежих» сайтов первое о чем нужно позаботиться, это получение ссылок с авторитетных, надежных ресурсов, что бы противостоять ссылочным спам атакам в будущем.
Если вы ссылаетесь на сайты с сомнительной репутацией, это понижет показатели Домен Траст для вашего сайта. Вред от таких ссылок очень большой, т.к. Google считает, что вы полностью контролируете все происходящие у вас на сайте, исходящие ссылки в том числе.
Считается что спамеры ссылаются на спамеров, поэтому во что бы то не стало старайтесь соблюдать «чистоту» ваших исходящих ссылок. Если вы вынуждены ставить такие ссылки, по каким либо причинам, для защиты от падения уровня доверия к вашему домену прячьте их в nofollow.
Этот вопрос все еще остается предметом обсуждений. Много SEO экспертов склоняются к мысли что Google учитывает регистрационные данные доменов из следующих соображений:
С недавнего времени Google имеет механизмы отслеживания доменов с одинаковыми регистрационными данными. Поэтому если Вы владелец большого количества доменов, и 90% ваших доменов статические или помечены в Google как спам, тогда ваши «чистые» домены будут очень плохо индексироваться и с большой вероятностью попадут в песочницу.
Домен Джус (вес домена)
Это не сложный механизм, и работает точно так же как и Пейдж Ранк..
Входящие ссылки на страницу дают ей “Вес”, это позволяет передавать ссылочный вес от одной страницы к другой.
Тот же принцип работает и для доменов. Каждая ссылка на одну из страниц вашего сайта передает вес и для домена, так же происходит и «переливание» веса между доменами.
Ниже это наглядно изображено на рисунке:
Цифры на страничках обозначают их Пейдж Ранк, все они суммируются и из них рассчитывается общее количество доменного веса которое может передаваться другим доменам, т.е. на домены на которые ссылается ваш сайт.
И последнее на чем я бы хотел акцентировать ваше внимание, не старайтесь направлять все входящие ссылки на морду вашего сайта. Google с подозрением относиться к таким сайтам, естественно у них возникнет вопрос «почему все сайты ссылаются только на главную? неужели внутренние страницы не настолько важны что бы попасть в индекс что никто на них не ссылается».
Авторитетный домен, должен иметь внешние ссылки на все страницы сайта, естественно главная требует большего внимания, но и внутренние не должны быть обделены вниманием.
Атаки на трасты между доменами
Рано или поздно в ходе пентеста встает задача компрометации всего леса — при условии, что есть какие-либо права в одном из доменов. В такие моменты возникает куча вопросов о трастах, их свойствах и самих атаках. Попробуем во всем этом разобраться.
Доверие между доменами используется для прохождения аутентификации пользователей одного домена на контроллере другого домена. Иначе говоря, чтобы пользователи с домена А могли иметь доступ к ресурсам домена Б. Доменная структура может быть двух видов:
При создании дерева доменов между доменами по умолчанию устанавливаются транзитивные доверительные отношения. Все компьютеры имеют общие:
| № | Trust Type | Transitivity | Direction | Authentication Mechanism | Description |
| 1 | External | Non-transitive | One-way or two-way | NTLM Only | Устанавливаются между доменами, принадлежащими к разным лесам, либо c доменом Windows NT 4.0. |
| 2 | Realm | Transitive or non-transitive | One-way or two-way | Kerberos Only | Устанавливаются между Windows и не Windows доменами, использующими протокол Kerberos. Данный тип доверительных отношений может использоваться для обеспечения сквозной аутентификации на Windows и UNIX-системах. |
| 3 | Forest | Transitive | One-way or two-way | Kerberos or NTLM | Устанавливаются между лесами. При этом администраторы сами решают, какими будут отношения — двусторонними или односторонними. |
| 4 | Shortcut | Transitive | One-way or two-way | Kerberos or NTLM | Устанавливаются между доменами различных деревьев, принадлежащих к одному лесу. Используются для уменьшения пути доверия, тем самым повышая эффективность взаимодействия между двумя доменами. |
| 5 | Parent-Child | Transitive | Two-way | Kerberos or NTLM | Устанавливаются автоматически при создании в дереве нового домена. В рамках дерева доменов отношения описываются схемой Parent-Child. |
| 6 | Tree-Root Trust | Transitive | Two-way | Kerberos or NTLM | Устанавливаются автоматически при создании в существующем лесе нового дерева доменов. Фактически доверительные отношения устанавливаются между корневым доменом леса и создаваемым доменом, который будет являться корневым для нового дерева. |
Более наглядно типы доверий между доменами проиллюстрированы на картинке ниже.
Транзитивность (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 целевого домена, флаги и атрибуты, характеризующие текущие доверительные отношения в домене.
| DS_DOMAIN_DIRECT_INBOUND | Enumerate domains that directly trust the domain which has ServerName as a member. |
| DS_DOMAIN_DIRECT_OUTBOUND | Enumerate domains directly trusted by the domain which has ServerName as a member. |
| DS_DOMAIN_IN_FOREST | Enumerate domains that are a member of the same forest which has ServerName as a member. |
| DS_DOMAIN_NATIVE_MODE | Enumerate domains where the primary domain is running in Windows 2000 native mode. |
| DS_DOMAIN_PRIMARY | Enumerate domains that are the primary domain of the domain which has ServerName as a member. |
| DS_DOMAIN_TREE_ROOT | Enumerate domains that are at the root of the forest which has ServerName as a member. |
| TRUST_ATTRIBUTE_NON_TRANSITIVE | Disallow transitivity. |
| TRUST_ATTRIBUTE_UPLEVEL_ONLY | The trust link is not valid for client operating systems earlier than Windows 2000. |
| TRUST_ATTRIBUTE_FILTER_SIDS | Quarantine domains. |
| TRUST_ATTRIBUTE_FOREST_TRANSITIVE | The trust link may contain forest trust information. |
| TRUST_ATTRIBUTE_CROSS_ORGANIZATION | This trust is to a domain/forest that is not part of this enterprise. |
| TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL | Trust is treated as external for trust boundary purposes. |
| TRUST_ATTRIBUTE_WITHIN_FOREST | Trust is internal to this forest. |
BloodHound собирает информацию с помощью метода Win32 API.
Используется метод GetCurrentDomainиз пространства имен [System.DirectoryServices.ActiveDirectory.Domain], который возвращает экземпляр класса System.DirectoryServices.ActiveDirectory.Domain. В этом классе реализован метод GetAllTrustRelationships, который возвращает все доверительные отношения для текущего домена.
Использование данного метода реализовано в модуле Get-DomainTrust в PowerView.
Одним из преимуществ этого метода является его простота. Информацию легко читать и понимать, но ее объем значительно меньше, чем при выполнении перечисления другими методами.
Информация о доверительных отношениях домена хранится в Active Directory как objectClass класса trustedDomain.
PowerView по умолчанию использует данный метод.
Имея информацию о доменах и типах доверия, можно переходить непосредственно к самой атаке. Рассмотрим 2 варианта:
С правами администратора одного из доменов
В зависимости от домена, который был скомпрометирован, можно выделить несколько векторов атак:
| № | Стартовый домен. Позиция атакующего | Атакуемый домен | Техника атаки | Доверительные отношения |
| 1 | Root | Child | Golden Ticket + Enterprise Admin Group | Inter-realm (2-way) |
| 2 | Child | Child | Эксплуатация SID History | Inter-realm Parent-Child (2-way) |
| 3 | Child | Root | Эксплуатация SID History Эксплуатация билетов доверия | Inter-realm Tree-Root(2-way) |
| 4 | Forest 1 | Forest 2 | Printer Bug | Inter-realm Forest or External trust (2-way) |
Стоит отметить, что для успешной реализации всех векторов необходимо двустороннее доверие между доменами.
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.
Это важно учитывать при выполнении перечисления пользователей и групп.
