Ударь крота GPO: вот оно! Нет, это не так!

Опубликовано: 17 Марта, 2023
Ударь крота GPO: вот оно! Нет, это не так!

Вы когда-нибудь посещали город и пытались найти главное почтовое отделение, чтобы отправить посылку? Или вы когда-нибудь задумывались о том, какой может быть ваша компенсация государственной пенсии, когда вы достигнете пенсионного возраста? Или, если вы пишете какой-то код приложения и хотите направить вывод команды в вывод общего назначения, что вам делать? И этот старый Corvette, который пылится в вашем гараже — может быть, вам стоит стиснуть зубы и отнести его в магазин металлолома, разрезать и продать как «Только на запчасти». Я думаю, вы поняли идею. Очевидно, что поскольку это технический сайт, мы не говорим здесь ни о каком старом объекте групповой политики. Нет, я говорю об объекте групповой политики (GPO), с которым должен быть знаком любой администратор Windows Server.

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

Все это хорошо известно и понятно любому достойному администратору Windows. Проблема, однако, в том, что объекты групповой политики очень похожи на кроликов. Я имею в виду, что они, как правило, размножаются и размножаются до тех пор, пока не станут вредителями и помехой для управления сетью вашей организации на базе Windows Server. Типичное предприятие с несколькими сайтами и многими сотнями или тысячами компьютеров может в конечном итоге иметь десятки и десятки объектов групповой политики или, возможно, даже много сотен, поскольку утомленный администратор пытается контролировать или блокировать доступ пользователей к различным аспектам сети в постоянно растущей сложности. гранулированная игра «Ударь крота». В результате может быстро получиться огромная куча того, что вы знаете, где администратор больше не знает, например, какие клиентские компьютеры на данном сайте имеют перенаправление папок, настроенное для перенаправления сохранения документов пользователя в центральный файловый репозиторий. Недавно я столкнулся именно с такой проблемой, с которой столкнулся мой друг, который занимается администрированием крупной инфраструктуры AD. Другими словами, его насущный вопрос заключался в следующем: какие объекты групповой политики в моей среде AD используются для настройки перенаправления папок для пользователей?

Поиск объекта групповой политики

Его решение заключалось в том, чтобы запросить в Active Directory глобальный уникальный идентификатор (GUID) клиентского расширения (CSE) для перенаправления папок в групповой политике. Инструментом, который он использовал для этого, была команда Dsquery — инструмент командной строки, встроенный в Windows Server 2008 и более поздние версии. Эта команда доступна на любом сервере Windows, на котором установлена роль сервера доменных служб Active Directory (AD DS). Dsquery существует во множестве разновидностей, таких как компьютер Dsquery, пользователь Dsquery, группа Dsquery и так далее, но конкретная разновидность, необходимая здесь, была самой общей: Dsquery *, которую можно использовать для поиска объектов в каталоге на основе критерии, заданные с помощью запроса протокола облегченного доступа к каталогам (LDAP).

Чтобы использовать эту команду, моему другу сначала понадобился GUID для CSE перенаправления папок. Эту информацию можно найти в очень старой, но все еще точной статье базы знаний Майкрософт KB216357, и в ней он сообщил, что GUID для компонента перенаправления папок объекта групповой политики — 25537BA6-77A8-11D2-9B6C-0000F8080861. Затем он просто выполнил следующую команду Dsquery *:

dsquery * <Object DN> -scope base -attr objectGUID

Здесь параметр <Object DN> может иметь значение forestroot, если вы хотите, чтобы поиск начинался в корне вашего леса Active Directory; domainroot, если вы хотите начать с текущего домена; или различающееся имя (DN) определенного узла контейнера в Active Directory. Базовая часть -scope указывает, что областью поиска является указанный единственный объект. Оставшаяся часть -attr objectGUID используется для указания того, что атрибут objectGUID является конкретным искомым атрибутом Active Directory. После запуска команды он отфильтровал результаты по конкретному GUID 25537BA6-77A8-11D2-9B6C-0000F8080861 и смог использовать это, чтобы найти все объекты GPO в Active Directory, которые имели расширение перенаправления папок.

Переход на PowerShell

Dsquery* — чрезвычайно полезный инструмент, который вы можете использовать в своем наборе инструментов Active Directory, когда он вам понадобится. Например, предположим, что вы быстро хотели узнать, сколько групп безопасности вы создали в своей среде Active Directory. Простая команда, подобная этой, может сообщить вам эту информацию:

dsquery * -filter "(&(groupType:1.2.840.113556.1.4.803:=-2147483646))"

Строка «(&(groupType:1.2.840.113556.1.4.803:=-2147483646))» в этом примере соответствует формату фильтра поиска LDAP. В этой статье MSDN подробно объясняется синтаксис поискового фильтра LDAP, и я настоятельно рекомендую прочитать ее, если вы обнаружите, что у вас бессонница.

Конечно, Windows PowerShell также можно использовать для извлечения такого рода информации из Active Directory, и конкретный командлет PowerShell, который вы хотели бы использовать здесь, будет Get-ADObject, который можно использовать либо для извлечения определенного объекта из Active Directory для вас или для выполнения поиска в Active Directory, который извлекает несколько объектов. К сожалению, если вы хотите получить несколько объектов из Active Directory, вам все равно придется указать некоторый синтаксис для этого. Но с Get-ADObject теперь у вас есть два варианта снотворного. Вы можете указать LDAPFilter, используя тот же синтаксис, который вы изучили при использовании Dsquery *, или вы можете использовать более новый язык выражений PowerShell (PEL) для написания строк запроса, которые вы можете использовать для запроса Active Directory.

Язык выражений PowerShell более подробно описан на странице справки about_ActiveDirectory_Filter для командлета Get-ADObject, и его можно найти на этой странице TechNet.

На самом деле это не так — эта страница просто указывает на другую страницу справки под названием about_Regular_Expressions, которую можно найти на этой странице MSDN. Меня всегда восхищало то, как Microsoft продолжает вот так перемещать документацию из TechNet в MSDN и неизвестно куда в будущем.

В любом случае, если у вас проблемы со сном и синтаксис поискового фильтра LDAP не помогает, вы всегда можете пройти PEL.