Знаете ли вы, какие объекты в вашем каталоге AD уже не нужны? А к кому обращаться, если требуется изменить содержимое или структуру лесов AD?
Оказывая консультационные услуги по вопросам управления AD, я часто сталкиваюсь с ситуацией, когда в организации в течение длительного времени каталог AD развивался стихийно. Как правило, при этом накапливается огромное число неиспользуемых объектов, а также объектов, которые, по-видимому, для чего-то применяются, но трудно понять, кому именно и для чего они нужны. Содержать такие объекты довольно накладно: периодическая очистка AD — операция трудоемкая и дорогостоящая, реструктуризация или миграция AD становятся более трудоемкими, даже незначительное управление изменениями начинает требовать значительных усилий.
Чтобы разобраться и взять управление AD под контроль, необходимо установить три правила жизненного цикла объектов. Во-первых, следует установить правила создания, изменения и удаления объектов. Во-вторых, надо установить процедуры, обеспечивающие соблюдение этих правил для всех вновь создаваемых объектов. В-третьих, требуется совершить трудную, но необходимую работу по наведению порядка в уже существующих объектах AD, так что либо объект будет соответствовать установленным правилам, либо, после выполнения соответствующих процедур, он должен быть удален из каталога AD.
Ниже приводятся приемы и советы, как все это сделать. Для этого вводится концепция ответственных за объекты AD. Объектам AD назначаются ответственные — реальные сотрудники, которые помогут обеспечить регулярный контроль и порядок в среде AD.
Уточнение терминологии
Ответственный за объект AD — это конкретный человек, который непосредственно отвечает за объект или хотя бы просто знает, для чего служит данный объект. Можно было бы использовать термин «контакт», но это слово уже применяется для обозначения определенного типа объектов в AD. Можно было бы воспользоваться термином «владелец», но он тоже уже задействован в модели безопасности AD для обозначения создателя/владельца объекта.
Было бы замечательно, если бы в AD был предусмотрен атрибут «ответственный», который можно заполнять для указания ответственных за различные типы объектов AD. К сожалению, такого атрибута нет, и нам потребуется либо его создать, либо воспользоваться другими атрибутами, предусмотренными в схеме AD по умолчанию. Для простоты, а также потому, что многие компании придерживаются похвальной практики не расширять схему AD без необходимости, я воспользуюсь некоторыми из имеющихся атрибутов.
Зачем нужны ответственные?
Идентификация и удаление неиспользуемых объектов AD может оказаться делом неблагодарным и трудоемким. Некоторые полезные инструменты могут помочь обнаружить неиспользуемые объекты (например, утилита командной строки dsquery, а также AdFind и OldCmp от компании Joeware), но, поскольку удаление объектов потенциально опасно для систем и приложений, использующих AD, важно быть уверенным в том, что удаляемый объект действительно никем не используется. Как правило, для этого лучше всего переговорить с сотрудником, который отвечает за данный объект.
Во многих случаях этого человека трудно найти по атрибутам объекта. Часто у вас есть только имя объекта, с которым надо разобраться, например группа с названием OKP100 Staff. Хорошо, если название OKP100 вам о чем-то говорит, в противном случае разобраться будет трудно. Описание объекта может содержать некоторую полезную информацию («Прежде чем вносить изменения, свяжитесь с Дж. П. Картером»), но может оказаться, что нужный сотрудник уже не работает в организации.
Как можно убедиться, встроенная функциональность позволяет определить владельца объекта AD. Для этого мы введем концепцию ответственных за объекты.
Ответственные могут пригодиться и при работе с активными объектами. Например, при обработке запроса на включение пользователя в состав группы, сотрудники могут обратиться к ответственному для подтверждения или отклонения запроса.
Я рекомендую, чтобы вся информация о назначенных ответственных размещалась в самом каталоге AD. Впрочем, это не строгое требование.
Назначение ответственных за объекты пользователя
В реальной практике пользовательские объекты могут применяться для различных целей. Помимо стандартного применения — хранения учетных записей реальных людей, объекты пользователей могут создаваться для «должностных» учетных записей, используемых несколькими лицами (например, оператор автоматизированной системы), ресурсных учетных записей (почтовые ящики для переговорных комнат). Кроме того, это могут быть учетные записи системных служб или вспомогательные учетные записи для целей администрирования.
Я рекомендую назначать ответственных за все объекты пользовательских учетных данных, к какому бы виду они ни относились. Рассмотрим пример ресурсной учетной записи для почтового ящика переговорной комнаты Meeting Room C. Назначим хранителем учетной записи, скажем, Мэри Тейлор.
В оснастке Active Directory Users and Computers консоли MMC находим учетную запись Meeting Room C, открываем ее свойства и переходим на вкладку Organization. В разделе Manager нажимаем Change и с помощью выбора объектов находим и добавляем учетную запись пользователя Мэри Тейлор (см. экран 1).
Атрибут Manager является связанным атрибутом. Он представляет собой прямую ссылку, а парный ему атрибут directReports представляет собой соответствующую обратную ссылку.
Поскольку эти атрибуты являются связанными, после назначения Мэри менеджером учетной записи Meeting Room C при просмотре объекта Мэри Тейлор объект Meeting Room C будет отображаться в списке Direct reports (прямое подчинение; см. экран 2). Главное преимущество использования связанных атрибутов заключается в автоматическом поддержании целостности, так что объект может быть переименован или перемещен в AD, но связь при этом сохраняется. Она разрывается только в том случае, если объект, указанный в прямой или обратной ссылке удален. Другим преимуществом связанных атрибутов является возможность поиска средствами AD ответственного или объектов, за которые данный сотрудник отвечает.
Ниже приведены примеры результатов поиска с помощью средства AdFind, доступного на сайте www.joeware.net. В первом примере приведен запрос на выдачу всех пользовательских учетных записей, для которых Мэри Тейлор является хранителем.
C:>adfind -list -b "CN=Mary
Taylor, OU=
Standard User Accounts,
DC=ad, DC=
fisheagle, DC=net" directReports
На экране 3 приведен результат выполнения этого поискового запроса.
Следующий пример показывает, как найти ответственного за переговорную комнату:
C:>adfind -list -b "CN=Meeting
Room
C, OU=
Resource Accounts, DC=ad, DC=fisheagle,
DC=net" manager
Результат выполнения этого запроса будет выглядеть примерно следующим образом: CN=Mary Taylor, OU=Standard User Accounts, DC=ad, DC=fisheagle, DC=net.
Назначение ответственных за объекты групп
К сожалению, для объектов групп атрибуты manager и directReports не поддерживаются. Вместо них я рекомендую использовать аналогичную пару атрибутов managedBy и managedObjects.
Рассмотрим сказанное на примере группы Consulting Team, ответственным за которую мы назначим ту же Мэри Тейлор. Для этого в оснастке AD Users and Computers выберите данную группу, откройте свойства и перейдите на вкладку Managed By. В разделе Name нажмите Change и воспользуйтесь выбором объекта для поиска и добавления учетной записи Мэри Тейлор, как показано на экране 4.
Когда вы вносите изменения в оснастку AD Users and Computers, AD присваивает атрибуту managedBy группового объекта значение полного имени (DN) учетной записи Мэри Тейлор. Обратите внимание, что при установке значения параметра Managed By вы можете установить флажок Manager can update membership list для изменения менеджером состава группы, см. экран 4. Если вы назначаете ответственных за объект только для информационных целей, вероятно, следует убрать этот флажок. С другой стороны, это быстрый способ делегирования ответственному реальные полномочия по управлению составом группы.
Нужно иметь в виду, что в отличие от directReports, обратная ссылка managedObjects недоступна в оснастке Active Directory Users and Computers. Для просмотра обратной ссылки потребуется выполнить запрос LDAP или воспользоваться инструментарием типа ADSIEdit; отмечу, что необходимой возможностью обладает новая утилита Attribute Editor из комплекта Windows Server 2008.
Как и в случае атрибутов manager и directReport объектов пользователя, для просмотра взаимосвязей между группой и хранителем можно выполнить запрос к AD с помощью утилиты AdFind, как показано в следующем примере:
C:>adfind -list -b «CN=Consulting
Team,
OU=Groups, DC=ad, DC=fisheagle,
DC=
net» managedBy
На экране 5 приведен результат выполнения запроса.
Чтобы определить ответственного для данного объекта, выполните следующий запрос AdFind:
C:>adfind -list -b «CN=Mary Taylor, OU=
Standard User Accounts, DC=ad, DC=
fisheagle, DC=net» managedObjects
Результатом его исполнения будет CN=Mary Taylor, OU=Standard User Accounts, DC=ad, DC=fisheagle, DC=net.
Указание ответственных для других типов объектов
Нетрудно распространить концепцию ответственных и на другие типы объектов AD. Например, компьютеры и организационные подразделения (OU) — следующие типы объектов, которые первыми приходят на ум. Они также поддерживают атрибуты связывания managedBy и managedObjects, так что можно задавать ответственного точно так же, как и для групп.
Ответственные и управление жизненным циклом объектов
Концепция ответственных будет работать хорошо только в том случае, когда она прописана в принятых в организации процедурах создания и удаления объектов. Очень важно, чтобы ответственный назначался сразу при создании всех объектов AD, для которых требуется вести учет.
Аналогично, при удалении стандартной учетной записи пользователя необходимо убедиться, что указание ответственного должно быть также удалено или перенесено на другого пользователя. Например, если наша Мэри Тейлор захочет покинуть компанию, необходимо решить, что делать с объектами, за которые она является ответственной. В случае с группами и переговорными комнатами разумно назначить новых ответственных за эти объекты. Если у Мэри была вторая учетная запись для выполнения административных задач, я бы сразу удалил ее.
Следует также помнить, что роль сотрудников в организации может меняться. Если такое происходит, ваши процедуры изменения должны предусматривать случаи, когда сотрудник перестает играть роль ответственного для объекта AD.
Наведение порядка в действующей инфраструктуре AD
Когда концепция ответственных для вновь создаваемых объектов будет внедрена, понадобится назначить ответственных за уже имеющиеся бесхозные объекты, а также установить соответствующие взаимосвязи между объектами. Перед этим, кстати, следует удалить неиспользуемые объекты AD.
Довольно часто встречается ситуация, когда объект AD создается для решения какой-то временной задачи, а потом про него все забывают. Например, для работы с новой системой управления документами часто создаются новые учетные записи и группы. Когда же через пару лет от этой системы управления документами отказываются, созданные для нее объекты продолжают оставаться в AD. Это может продолжаться сколь угодно долго, пока кто-нибудь не обратит на них внимание и не спросит, зачем они нужны.
Ниже приведены примеры применения средств командной строки для обнаружения неиспользуемых объектов. Эти примеры никоим образом не претендуют на полноту, но могут послужить хорошей отправной точкой. Из соображений единообразия для поиска неактивных пользователей и компьютеров я использую AdFind, хотя тех же результатов можно достичь с использованием OldCMP или dsquery.
Поиск неактивных пользователей
Приведенный ниже запрос (пишется в одну строку) использует AdFind для поиска учетных записей пользователей, которые никогда не выполняли регистрацию в домене или не регистрировались в домене с начала 2008 года. Результат выполнения запроса будет выдан в формате CSV.
adfind -csv -default -tdca -utc –binenc
-bit -f " (& (samaccounttype=805306368)
(| (lastLogonTimestamp<={{utc:
2008/01/01}})
(! (lastLogonTimestamp=*)))
(! (userAccountControl: AND:=2)))" last
logontimestamp pwdlastset account
expires whencreated
При этом из поиска исключаются отключенные учетные записи пользователей, поскольку в большинстве организаций отключенные пользователи не удаляются сразу, а сохраняются некоторое время в отключенном состоянии. При поиске используется атрибут lastLogonTimestamp (это реплицируемый атрибут, который периодически обновляется и который не так точен, как нереплицируемый атрибут lastLogon). Поиск по реплицируемому атрибуту позволяет опрашивать один контроллер домена (DC) и не пытаться консолидировать значения lastLogon для всех имеющихся в домене контроллеров. Атрибут lastLogonTimestamp появился, начиная с Windows Server 2003, и используется во всех более новых версиях.
Поиск неактивных объектов компьютера
Как и при поиске неактивных учетных записей пользователей, приведенный ниже запрос (пишется в одну строку) использует AdFind для поиска учетных записей компьютеров, которые никогда не регистрировались в домене или не регистрировались с начала 2008 года.
adfind -csv -default -tdca -utc –binenc
-f " (& (objectcategory=computer)
(| (last
LogonTimestamp<={{utc:2008/01/01}}) (!
(lastLogonTimestamp=*))))" name
operatingSystem
operatingSystemServicePack la
stlogontimestamp pwdlastset
whencreated
Поиск групп, не содержащих никаких объектов
Бывает очень трудно определить, используется ли группа в AD. В случае с пользователями и компьютерами вы можете определить, когда последний раз менялся пароль объекта в домене (атрибут pwdLastSet) или когда пользователь или компьютер в последний раз регистрировался в домене (атрибут lastLogonTimestamp). Но у групп нет паролей, они не регистрируются в AD и у них нет атрибутов, которые могли бы ответить, используется ли данная группа.
Отсутствие членов группе — это верный признак, что группа не используется, но в реальности более надежным и действенным методом является назначение ответственного. Можно установить правило и процедуру регулярного опроса ответственных об актуальности вверенных им групп. Если подтверждение не получено в течение N дней, можно начинать процедуру удаления данной группы.
В приведенном ниже запросе AdFind используется для обнаружения всех групп, не имеющих членов, что, как отмечалось ранее, является признаком неиспользуемой группы. Обратите внимание, что из поиска исключаются критически важные системные объекты (такие, как встроенная группа Enterprise Admins), которые могут быть пустыми и никогда не должны удаляться из AD.
adfind -csv -default -f " (& (object
category=group) (! member=*)
(! isCritical
SystemObject=TRUE))" samaccount
name description managedby
Обратите внимание: очень важно проверять правильность результатов этих поисковых запросов. Поиск через LDAP объектов AD, как в приведенных выше примерах, — только один аспект общей задачи. Необходимо также тщательно проверить полученные результаты.
Например, абсолютно легальная пользовательская учетная запись для ресурсных почтовых ящиков (например, переговорных комнат) может не выполнять регистрацию в домене годами. В качестве другого примера можно привести пустую группу, которая необходима для работы какой-либо специфической прикладной системы.
Максимальный результат при минимуме усилий
Какую бы терминологию вы ни использовали — менеджер, владелец, контакт или ответственный, концепция связывания объектов AD с реальными людьми не нова. В конце концов, разработчики Microsoft предусмотрели эти взаимосвязи в AD через связанные пары атрибутов managedBy и managedObjects для определенных типов объектов.
Я очень рекомендую подумать о реализации концепции ответственных в вашей компании. Усилия, потраченные на настройку необходимых для этого процедур, не идут ни в какое сравнение с затратами на сопровождение неконтролируемой сетевой инфраструктуры. Чем раньше вы их введете, тем меньше придется в дальнейшем потратить усилий на наведение порядка.
Тони Мюррей (tony@activedir.org) — специалист по службам каталогов и почтовым системам, поддерживает сайт ActiveDir.org. Имеет звание MVP и сертификат MCSE