Что является операндами в операторах языка sql. Назначение языка SQL

В 2002 году, прогуливаясь по коридору кафедры информатики своего любимого университета, я увидел на двери кабинета «Системы NT» свежий плакат. На плакате были изображены иконки пользовательских аккаунтов, объединенные в группы, от которых в свою очередь отходили стрелки к другим иконкам. Все это схематично объединялось в некую структуру, было написано что-то про единую систему входа, авторизацию и тому подобное. Насколько сейчас понимаю на том плакате была изображена архитектура систем Windows NT 4.0 Domains и Windows 2000 Active Directory. С этого момента началось и сразу же закончилось мое первое знакомство с Active Directory, так как потом была тяжелая сессия, веселые каникулы, после которых друг поделился дисками FreeBSD 4 и Red Hat Linux, и на ближайшие несколько лет я погрузился в мир Unix-подобных систем, но содержимое плаката я так и не забыл.
К системам на платформе Windows Server мне пришлось вернуться и более тесно с ними познакомиться, когда я перешел работать в компанию, где управление всей ИТ-инфраструктурой было основано на Active Directory. Помню, что главный админ той компании на каждом совещании все время что-то твердил про какие-то Active Directory Best Practices. Теперь, после 8 лет периодического общения с Active Directory, я достаточно хорошо понимаю, как работает данная система и что такое Active Directory Best Practices.
Как вы уже, наверное, догадались, речь пойдет про Active Directory.
Всем, кому интересна данная тема, добро пожаловать по кат.

Данные рекомендации справедливы для клиентских систем начиная с Windows 7 и выше, для доменов и лесов уровня Windows Server 2008/R2 и выше.

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

• Название пользовательских групп должно начинаться с префикса GRUS_ (GR - Group, US - Users)
• Название компьютерных групп н должно начинаться с префикса GRCP_ (GR - Group, CP - Computers)
• Название групп делегирования полномочий должно начинаться с префикса GRDL_ (GR - Group, DL - Delegation)
• Название групп доступа к ресурсам должно начинаться с префикса GRRS_ (GR - Group, RS - resources)
• Название групп для политик должно начинаться с префиксов GPUS_, GPCP_ (GP - Group policy, US - Users, CP - Computers)
• Название клиентских компьютеров должно состоять из двух, трех букв от названия организации, за которыми через дефис должен следовать номер, например, nnt-01.
• Название серверов должно начинаться только из двух букв, за которыми через дефис должна следовать роль сервера и его номер, например, nn-dc01.

Рекомендую называть объекты Active Directory таким образом, чтобы вам не приходилось заполнять поле «Description». Например, из названия группы GPCP_Restricted_Groups понятно, что это группа для политики, которая применяется для компьютеров и выполняет работу механизма Restricted Groups.
Ваш подход к написанию документации должен быть очень основательным, это позволит сэкономить большое количество времени в дальнейшем.

Упрощайте все, что возможно, старайтесь достигнуть равновесия
При построении Active Directory необходимо следовать принципу достижения равновесия, делая выбор в пользу простых и понятных механизмов.
Принцип равновесия заключается в том, чтобы достигнуть необходимого функционала и безопасности при максимальной простоте решения.
Необходимо стараться построить систему так, чтобы ее устройство было понятно самому не искушенному администратору или даже пользователю. Например, в свое время была рекомендация создавать структуру леса из нескольких доменов. Более того рекомендовалось разворачивать не только мультидоменные структуры, но и структуры из нескольких лесов. Возможно, такая рекомендация существовала из-за принципа «разделяй и властвуй», либо потому-то Microsoft всем твердила, что домен - это граница безопасности и разделив организацию на домены, мы получим отдельные структуры, которые проще контролировать по отдельности. Но как показала практика, что более просто обслуживать и контролировать однодоменные системы, где границами безопасности являются организационные единицы (OU), а не домены. Поэтому избегайте создания сложных мультидоменных структур, лучше группируйте объекты по OU.
Конечно, следует действовать без фанатизма, - если невозможно обойтись без нескольких доменов, то нужно создавать несколько доменов, также и с лесами. Главное, чтобы вы понимали, что делаете, и к чему это может привести.
Важно понимать, что простую инфраструктуру Active Directory проще администрировать и контролировать. Я бы даже сказал, что чем проще, тем безопаснее.
Применяйте принцип упрощения. Старайтесь достигнуть равновесия.

Соблюдайте принцип – «объект - группа»
Начинайте создание объектов Active Directory с создания группы для данного объекта, и уже группе назначайте необходимые права. Рассмотрим на примере. Вам необходимо создать аккаунт главного администратора. Создайте сначала группу Head Admins и только потом создайте сам аккаунт и добавьте его в данную группу. Группе Head Admins назначьте права главного администратора, например, добавив ее в группу Domain Admins. Почти всегда получается так, что через некоторое время приходит на работу еще один сотрудник, которому нужны аналогичные права, и вместо того, чтобы заниматься делегированием прав на разные разделы Active Directory, будет возможно просто добавить его в необходимую группу, для которой в системе уже определена роль и делегированы необходимые полномочия.
Еще один пример. Вам необходимо делегировать права на OU с пользователями группе системных администраторов. Не делегируйте права напрямую группе администраторов, а создайте специальную группу вроде GRDL_OUName_Operator_Accounts, которой назначьте права. Потом просто добавьте в группу GRDL_OUName_Operator_Accounts группу ответственных администраторов. Обязательно получиться так, что в скором будущем, вам понадобиться делегировать другой группе администраторов права на данную OU. И в этом случае вы просто добавите группу данных администраторов в группу делегирования GRDL_OUName_Operator_Accounts.
Предлагаю следующую структуру групп.

• Группы пользователей (GRUS_)
• Группы администраторов (GRAD_)
• Группы делегирования (GRDL_)
• Группы политик (GRGP_)

Группы компьютеров

• Группы серверов (GRSR_)
• Группы клиентских компьютеров (GRCP_)

Группы доступа к ресурсам

• Группы доступа к общим ресурсам (GRRS_)
• Группы доступа к принтерам (GRPR_)

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

Архитектура OU.
Архитектуру OU в первую очередь следует продумывать с точки зрения безопасности и делегирования прав на данную OU системным администраторам. Не рекомендую планировать архитектуру OU с точки зрения привязки к ним групповых политик (хотя так чаще всего и делают). Для некоторых покажется немного странной моя рекомендация, но я не рекомендую вообще привязывать групповые политики к OU. Подробности читайте в секции Групповые политики.
OU Admins
Рекомендую выделить для административных аккаунтов и групп отдельную OU, куда поместить аккаунты и группы всех администраторов и инженеров технической поддержки. К данной OU следует ограничить доступ для обычных пользователей, а управление объектами из данной OU делегировать только главным администраторам.
OU Computers
OU для компьютеров лучше всего планировать с точки зрения географической принадлежности компьютеров и типов компьютеров. Распределите компьютеры с разных географических локаций по разным OU, а их в свою очередь разделите на клиентские компьютеры и серверы. Серверы можно еще поделить на Exchange, SQL и другие.

Пользователи, права в Active Directory
Пользовательским аккаунтам Active Directory следует уделять особое внимание. Как было сказано в секции про OU, пользовательские аккаунты следует группировать исходя из принципа делегирования полномочий на данные аккаунты. Также важно соблюдать принцип минимальных привилегий - чем меньше у пользователя прав в системе, тем лучше. Рекомендую сразу закладывать уровень привилегий пользователя в название его аккаунта. Аккаунт для повседневной работы должен состоять из Фамилии пользователя и инициалов на латинице (Например, IvanovIV или IVIvanov). Обязательными полями являются: First Name, Initials, Last Name, Display Name (на русском), email, mobile, Job Title, Manager.
Аккаунты администраторов должны быть следующих типов:

• С правами администратора на пользовательские компьютеры, но не серверы. Должны состоять из инициалов владельца и приставки local (Например, iivlocal)
• С правами на администрирование серверов и Active Directory. Должны состоять только из инициалов (Например, iiv).

Поле Surname обоих типов административных аккаунтов следует начинать с буквы I (Например, iPetrov P Vasily)
Поясню, зачем следует разделять административные аккаунты на администраторов серверов и администраторов клиентских компьютеров. Делать это необходимо, из соображений безопасности. Администраторы клиентских компьютеров будут иметь право на установку софта на клиентских компьютерах. Какой и для чего софт будет устанавливаться, сказать никогда точно нельзя. Поэтому запускать установку программы с правами доменного администратора небезопасно, можно скомпрометировать весь домен. Необходимо администрировать клиентские компьютеры только с правами локального администратора данного компьютера. Это сделает невозможным целый ряд атак на аккаунты доменных администраторов, вроде «Pass The Hash». Дополнительно администраторам клиентских компьютеров необходимо закрыть подключение через службу терминалов и подключение по сети к компьютеру. Компьютеры технической поддержки и администраторов следует поместить в отдельный VLAN, чтобы ограничить к ним доступ из сети клиентских компьютеров.
Выделение прав администратора пользователям
Если вам необходимо дать права администратора пользователю, ни в коем случае не помещайте его учетную запись для повседневной работы в группу локальных администраторов компьютера. Учетная запись для повседневной работы должна быть всегда ограничена в правах. Создайте для него отдельную административную учетную запись вида namelocal и добавьте данную учетную запись в группу локальных администраторов при помощи политики, ограничив ее применение только на компьютере пользователя при помощи item-level targeting. Данной учетной записью пользователь сможет пользоваться, используя механизм Run AS.
Политики паролей
Создайте отдельные политики паролей для пользователей и администраторов при помощи fine-grained password policy. Желательно, чтобы пользовательский пароль состоял минимум из 8 символов и менялся хотя бы раз в квартал. Администраторам желательно менять пароль каждые два месяца, и он должен быть минимум из 10-15 символов и отвечать требованиям сложности.

Состав доменных и локальных групп. Механизм Restricted Groups
Состав доменных и локальных групп компьютерах домена должен контролироваться только в автоматическом режиме, при помощи механизма Restricted Groups. Почему это необходимо делать только таким образом, объясню на следующем примере. Обычно после того, как разрвенут домен Active Directory, администраторы добавляют себя в доменные группы вроде Domain admins, Enterprise admins, добавляют в нужные группы инженеров технической поддержки и остальных пользователей тоже распределяют по группам. В процессе администрирования данного домена процесс выдачи прав повторяется многократно и будет крайне сложно вспомнить, что ты вчера временно добавлял бухгалтера Нину Петровну в группу администраторов 1С и что сегодня необходимо ее из это группы убрать. Ситуация усугубится, если в компании работает несколько администраторов и каждый время от времени выдает права пользователям в подобно стиле. Уже через год будет почти невозможно разобраться в том, какие кому права назначены. Поэтому состав групп должен контролироваться только групповыми политиками, которые при каждом применении будут приводить все в порядок.
Состав встроенных групп
Стоит сказать, что встроенные группы вроде Account Operators, Backup operators, Crypt Operators, Guests, Print Operators, Server Operators должны быть пустыми, как в домене, так и на клиентских компьютерах. Эти группы в первую очередь необходимы для обеспечения обратной совместимости со старыми системами, и пользователи данных групп наделяются слишком большими правами в системе, и становятся возможны атаки на повышение привилегий.

Учетные записи локальных администраторов
При помощи механизма Restricted Groups необходимо блокировать учетные записи локальных администраторов на локальных компьютерах, блокировать гостевые учетные записи и очищать группу локальных администраторов на локальных компьютерах. Ни в коем случае не используйте групповые политики для установки паролей на учетные записи локальных администраторов. Этот механизм не безопасен, пароль можно извлечь прямо из политики. Но, если вы решили не блокировать учетные записи локальных администраторов, то для корректной установки паролей и их ротации используйте механизм LAPS. К сожалению, настройка LAPS не до конца автоматизирована, и поэтому нужно будет в ручном режиме добавлять атрибуты в схему Active Directory, выдавать на них права, назначать группы и так далее. Поэтому проще заблокировать аккаунты локальных администраторов.
Сервисные учетные записи.
Для запуска сервисов используйте сервисные учетные записи и механизм gMSA (доступен в системах Windows 2012 и выше)

Групповые Политики
Документируйте политики перед созданием/изменением.
При создании политики используйте принцип «Политика - группа». То есть перед созданием политики создайте сначала группу для данной политики, уберите из области применения политики группу Authenticated users и добавьте созданную группу. Политику привяжите не к OU, а к корню домена и регулируйте область ее применения при помощи добавления объектов в группу политики. Такой механизм я считаю более гибким и понятным, чем линковку политики к OU. (Именно про это я писал в секции про Архитектуру OU).
Всегда регулируйте область применения политики. Если вы создали политику только для пользователей, то отключайте структуру компьютер и наоборот, отключайте структуру пользователь, если создали политику только для компьютеров. Благодаря этим настройкам, политики будут более быстро применяться.
Настройте ежедневное резервное копирование политик при помощи Power Shell, чтобы в случае ошибок конфигурирования можно было всегда вернуть настройки к исходным.
Центральное хранилище шаблонов (Central Store)
Начиная с Windows 2008 стало возможным хранить ADMX-шаблоны групповых политик в центральном хранилище, в SYSVOL. До этого по умолчанию все шаблоны политик хранились локально, на клиентах. Чтобы разместить шаблоны ADMX в центральном хранилище, необходимо скопировать содержимое папки %SystemDrive%\Windows\PolicyDefinitions вместе с подпапками с клиентских систем (Windows 7/8/8.1) в директорию контроллера домена %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions со слиянием содержимого, но без замены. Далее следует сделать такое же копирование с серверных систем, начиная с самой старой. В последнюю очередь, при копировании папок и файлов с самой последней версии сервера, сделайте копирование со слиянием и ЗАМЕНОЙ.

Копирование ADMX-шаблонов

Дополнительно в центральном хранилище можно размещать ADMX-шаблоны для любых программных продуктов, например, таких как Microsoft Office, продукты Adobe, Google и других. Зайдите на сайт поставщика программного продукта, скачайте ADMX-шаблон групповой политики и распакуйте его в папку %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions на любом из контроллеров домена. Теперь вы сможете управлять нужным вам программным продуктом через групповые политики.
Фильтры WMI
Фильтры WMI не очень быстро работают, поэтому предпочтительнее использовать механизм item-level targeting. Но если item-level targeting использовать невозможно, и вы решили использовать WMI, то рекомендую сразу создать для себя несколько самых распространённых фильтров: фильтр «Только клиентские операционные системы», «Только серверные операционные системы», фильтры «Windows 7», фильтры «Windows 8», «Windows 8.1», «Windows 10». Если у вас будут готовые наборы WMI фильтров, то потом будет проще применить нужный фильтр к нужной политике.

Аудит событий Active Directory
Обязательно включите аудит событий на контроллерах домена и других серверах. Рекомендую включить аудит следующих объектов:

• Audit Computer Account Management - Success, Failure
• Audit Other Account Management Events - Success, Failure
• Audit Security Group Management - Success, Failure
• Audit User Account Management - Success, Failure

• Audit Kerberos Authentication Service - Failure
• Audit Other Account Logon Events - Failure
• Audit Audit Policy Change - Success, Failure

Аудит необходимо конфиругировать в разделе Advanced Audit Policy Configuration и обязательно включить настройку в разделел Local Policy/Security Options - Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings , которая отменит настройки верхнего уровня и применит расширенные.

Расширенные настройки аудита

Подробно останавливаться на настройках аудита не буду, так как в Сети есть достаточное количество статей, посвященных данной теме. Дополню только, что помимо включения аудита, следует настроить оповещения по e-mail о критических событиях безопасности. Стоит также учесть то, что в системах с обильным количеством событий стоит выделить отдельные серверы для сбора и анализа файлов журнала.

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

Ручное администрирование
Часть операций по администрированию вам и вашим коллегам будет необходимо делать в ручном режиме. Для этих целей рекомендую использовать консоль mmc с добавленными в нее оснастками.
Как будет сказано далее, контроллеры домена у вас должны функционировать в режиме Server Core, то есть администрирование всего окружения AD следует выполнять только со своего компьютера при помощи консолей. Для администрирования Active Directory необходимо на свой компьютер поставить Remote Server Administration Tools. Консоли следует запускать на вашем компьютере из-под пользователя с правами администратора Active Directory, которому делегировано управление.
Искусство управления Active Directory при помощи консолей требует отдельной статьи, а может быть даже и отдельного обучающего видео, поэтому здесь только говорю про сам принцип.

Контроллеры домена
В любом домене, контроллеров должно быть, как минимум два. На контроллерах домена должно быть, как можно меньше служб. Не стоит делать из контроллера домена файловый сервер или, упаси вас бог, поднять на нем роль сервера терминалов. Используйте на контроллерах домена операционные системы в режиме Server Core, удалив полностью поддержку WoW64, это значительно уменьшит количество необходимых обновлений и увеличит их безопасность.
Microsoft раньше не рекомендовала виртуализировать контроллеры домена в виду того, что при восстановлении из моментальных снимков были возможны трудноразрешимые конфликты репликации. Возможно, были еще причины, точно сказать не могу. Сейчас гипервизоры научились сообщать контроллерам о восстановлении их из моментальных снимков, и эта проблема исчезла. Я же все время виртуализировал контроллеры, не делая никаких моментальных снимков, так как не понимаю, зачем вообще может понадобиться делать таковые на контроллерах домена. По-моему, проще сделать резервную копию контроллера домена стандартными средствами. Поэтому, рекомендую виртуализировать все контроллеры домена, которые только возможно. Такая конфигурация будет более гибкой. При виртуализации контроллеров домена располагайте их на разных физических хостах.
Если вам необходимо разместить контроллер домена в незащищенной физической среде или в филиале вашей организации, то для этих целей используйте RODC.

Роли FSMO, первичные и вторичные контроллеры
Роли FSMO контроллеров домена продолжают порождать страх в головах начинающих администраторов. Часто новички изучают Active Directory по устаревшей документации или слушают рассказы других администраторов, которые что-то где-то когда-то читали.
По всем пяти + 1 ролям вкратце следует сказать следующее. Начиная с Windows Server 2008 больше не существует первичных и вторичных контроллеров домена. Все пять ролей контроллеров домена переносимы, но не могут размещаться одновременно более, чем на одном контроллере. Если мы возьмем один из контроллеров, который, к примеру, был хозяином 4 ролей и удалим его, то все эти роли мы без проблем сможем перенести на другие контроллеры, и в домене ничего страшного не произойдет, ничего не сломается. Такое возможно потому, что всю информацию по работе, связанной с той или иной ролью ее хозяин хранит прямо в Active Directory. И если мы передаем роль другому контроллеру, то он в первую очередь обращается за сохраненной информацией в Active Directory и приступает к несению службы. Домен может достаточно долгое время существовать без хозяев ролей. Единственная «роль», которая должна быть всегда в Active Directory и без которой будет все очень плохо, это роль глобального каталога (GC), ее могут нести на себе все контроллеры в домене. Рекомендую назначать роль GC каждому контроллеру в домене, чем их больше, тем лучше. Конечно, вы сможете найти случаи, когда на контроллер домена не стоить устанавливать роль GC. Что ж, если не надо, так не надо. Следуйте рекомендациям без фанатизма.

Служба DNS
Служба DNS критична для работы Active Directory и работать она должна без сбоев. Службу DNS лучше всего ставить на каждый контроллер домена и хранить DNS зоны в самой Active Directory. Если вы будете использовать Active Directory для хранения зон DNS, то вам следует настраивать свойства TCP/IP соединения на контроллерах домена, таким образом, чтобы на каждом контроллере в качестве первичного DNS-сервера был любой другой DNS-сервер, а в качестве вторичного можно поставить адрес 127.0.0.1. Такую настройку делать необходимо потому, что для нормального старта службы Active Directory требуется работающий DNS, а для старта DNS должна быть запущена служба Active Directory, так как в ней лежит сама зона DNS.
Обязательно настройте зоны обратного просмотра для всех своих сетей и включите автоматическое безопасное обновление записей PTR.
Рекомендую дополнительно включить автоматическую уборку зоны от устаревших записей DNS (dns scavenging).
В качестве DNS-Forwarders рекомендую указать защищенные серверы Яндекс, если нет других более быстрых в вашей географической локации.

Сайты и репликация
Многие администраторы привыкли считать, что сайты - это географическое объединение компьютеров. Например, сайт Москва, сайт Петербург. Такое представление появилось из-за того, что первоначально деление Active Directory на сайты было сделано с целью балансировки и разделения сетевого трафика репликации. Контроллерам домена в Москве не обязательно знать, что в Петербурге было сейчас создано десять учетных записей компьютеров. И поэтому подобную информацию об изменениях можно передавать раз в час по расписанию. Или вообще производить репликацию изменений один раз в сутки и только ночью, для экономии полосы пропускания.
Про сайты я бы сказал так: сайты - это логические группы компьютеров. Компьютеров, которые соединены между собой хорошим сетевым соединением. А сами сайты соединены между собой соединением с малой пропускной способность, что в наше время большая редкость. Поэтому, я делю Active Directory на сайты не для балансировки трафика репликации, а для балансировки сетевой нагрузки вообще и для более быстрой обработки клиентских запросов компьютеров сайта. Поясню на примере. Есть 100-мегабитная локальная сеть организации, которую обслуживают два контроллера домена и есть облако, где располагаются серверы приложений этой организации с двумя другими облачными контроллерами. Такую сеть я поделю на два сайта для того, чтобы контроллеры в локальной сети обрабатывали запросы клиентов из локальной сети, а контроллеры в облаке запросы от серверов приложений. Дополнительно это позволит разделить запросы к службам DFS и Exchange. И так как сейчас я редко где встречаю канал в Интернет менее 10 мегабит в секунду, то я включу Notify Based Replication, это когда репликация данных происходит сразу, как только появились какие-либо изменения в Active Directory.

Заключение
Сегодня утром я думал о том, почему человеческий эгоизм не приветствуется в обществе и где-то на глубинном уровне восприятия вызывает крайне отрицательные эмоции. И единственный ответ, который пришел мне в голову, это то, что человеческая раса не выжила бы на этой планете, если бы не научилась совместному использованию физических и интеллектуальных ресурсов. Именно поэтому я и делюсь данной статьей с вами и, надеюсь, что мои рекомендации помогут вам улучшить свои системы, и вы станете значительно меньше тратить времени на поиск и устранение неисправностей. Все это приведет к освобождению большего количества времени и энергии для творчества. Гораздо приятнее жить в мире творческих и свободных людей.
Хорошо, если в комментариях вы по возможности поделитесь своими знаниями и практиками построения Active Directory.
Всем мира и добра!

Вы можете помочь и перевести немного средств на развитие сайта

Основы управления доменом Active Directory

Ряд средств в оснастках Microsoft Management Console (MMC) упрощает работу с Active Directory.

Оснастка Active Directory Users and Computers (Active Directory – пользователи и компьютеры) является консолью управления MMC, которую можно использовать для администрирования и публикации сведений в каталоге. Это главное средство администрирования Active Directory, которое используется для выполнения всех задач, связанных с пользователями, группами и компьютерами, а также для управления организационными подразделениями. Для запуска оснастки Active Directory Users and Computers (Active Directory – пользователи и компьютеры) выберите одноименную команду в меню Administrative Tools (Администрирование).

Active Directory Users and Computers

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

Получив доступ к домену вы увидите стандартный набор папок:

• S aved Queries (Сохраненныезапросы) – сохраненные критерии поиска, позволяющие оперативно повторить выполненный ранее поиск в Active Directory;
• B uiltin – список встроенных учетных записей пользователей;
• C omputers – контейнер по умолчанию для учетных записей компьютеров;
• D omain Controllers – контейнер по умолчанию для контроллеров домена;
• F oreignSecurityPrincipals – содержит информацию об объектах из доверенного внешнего домена. Обычно эти объекты создаются при добавлении в группу текущего домена объекта из внешнего домена;
• U sers – контейнер по умолчанию для пользователей.

Некоторые папки консоли по умолчанию не отображаются. Чтобы вывести их на экран, выберите в меню View (Вид) команду Advanced Features (Дополнительные функции). Вот эти дополнительные папки:

• L ostAndFound – потерявшие владельца, объекты каталога;
• N TDS Quotas – данные о квотировании службы каталогов;
• P rogram Data – сохраненные в службе каталогов данные для приложений Microsoft;
• S ystem – встроенные параметры системы.

Вы можете самостоятельно добавлять папки для организационных подразделений в дерево AD.

Рассмотрим пример создания учётной записи пользователя домена. Чтобы создать учётную запись пользователя щелкните правой кнопкой контейнер, в который вы хотите поместить учетную запись пользователя, выберите в контекстном меню New (Создать), а затем – User (Пользователь). Откроется окно мастера New Object – User (Новый объект – Пользователь):

1. Введите имя, инициал и фамилию пользователя в соответствующих полях. Эти данные потребуются для создания отображаемого имени пользователя.
2. Отредактируйте полное имя. Оно должно быть уникальным в домене и иметь длину не более 64 символов.
3. Введите имя для входа. С помощью раскрывающегося списка выберите домен, с которым будет связана учетная запись.
4. При необходимости измените имя пользователя для входа в системы с ОС Windows NT 4.0 или более ранними версиями. По умолчанию в качестве имени для входа в системы с предыдущими версиями Windows используются первые 20 символов полного имени пользователя. Это имя также должно быть уникальным в домене.
5. Щёлкните Next (Далее). Укажите пароль для пользователя. Его параметры должны соответствовать вашей политике паролей;
   C onfirm Password (Подтверждение) – поле, используемое для подтверждения правильности введенного пароля;
   U ser must change password at next logon (Требовать смену пароля при следующем входе в систему) – если этот флажок установлен, пользователю придется изменить пароль при следующем входе в систему;
   U ser cannot change password (Запретить смену пароля пользователем) – если этот флажок установлен, пользователь не может изменить пароль;
   P assword never expires (Срок действия пароля не ограничен) – если этот флажок установлен, время действия пароля для этой учетной записи не ограничено (этот параметр перекрывает доменную политику учетных записей);
   A ccount is disabled (Отключить учетную запись) – если этот флажок установлен, учетная запись не действует (параметр удобен для временного запрета использования кем-либо этой учетной записи).

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

Сценарии входа определяют команды, выполняемые при каждом входе в систему. Они позволяют настроить системное время, сетевые принтеры, пути к сетевым дискам и т.д. Сценарии применяются для разового запуска команд, при этом параметры среды, задаваемые сценариями, не сохраняются для последующего использования. Сценариями входа могут быть файлы сервера сценариев Windows с расширениями.VBS, .JS и другие, пакетные файлы с расширением.ВАТ, командные файлы с расширением.CMD, программы с расширением.ЕХЕ.

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

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

• создавать централизованно управляемые специальные папки, например My Documents (Мои документы);
• управлять доступом к компонентам Windows, системным и сетевым ресурсам, инструментам панели управления, рабочему столу и меню Start (Пуск);
• настроить сценарии пользователей и компьютеров на выполнение задачи в заданное время;
• настраивать политики паролей и блокировки учетных записей, аудита, присвоения пользовательских прав и безопасности.

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

Оснастка Active Directory Domains and Trusts (Active Directory – домены и доверие) служит для работы с доменами, деревьями доменов и лесами доменов.

Оснастка Active Directory Sites and Services (Active Directory – сайты и службы) позволяет управлять сайтами и подсетями, а так же межсайтовой репликацией.

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

• D sadd – добавляет в Active Directory компьютеры, контакты, группы, организационные подразделения и пользователей. Для получения справочной информации введите dsadd /? , например dsadd computer/?
• D smod – изменяет свойства компьютеров, контактов, групп, организационных подразделений, пользователей и серверов, зарегистрированных в Active Directory. Для получения справочной информации введите dsmod /? , например dsmod server /?
• D smove – перемещает одиночный объект в новое расположение в пределах домена или переименовывает объект без перемещения.
• D sget – отображает свойства компьютеров, контактов, групп, организационных подразделений, пользователей, сайтов, подсетей и серверов, зарегистрированных в Active Directory. Для получения справочной информации введите dsget /? , например dsget subnet /?
• D squery – осуществляет поиск компьютеров, контактов, групп, организационных подразделений, пользователей, сайтов, подсетей и серверов в Active Directory по заданным критериям.

17.03.2014 Даррен Мар-Элиа

Когда Windows PowerShell только появился, многие стали спрашивать, можно ли управлять Active Directory (AD) с использованием PowerShell. В те времена ответ Microsoft был не таким, какой хотелось бы услышать большинству администраторов. В PowerShell имелся встроенный "акселератор типов" Active Directory Service Interfaces (ADSI) для доступа к объектам AD, но пользователю приходилось в основном самостоятельно выяснять, как применить PowerShell для решения задач администрирования AD. Значительные изменения произошли с выпуском Windows Server 2008 R2, в котором появился модуль PowerShell для Active Directory. В модуль AD входит набор команд для управления AD, а также AD Provider, с помощью которого можно перемещаться по AD, как по диску с символьным обозначением. В этой статье я покажу, как установить модуль AD, и подробно опишу его функционирование

Когда Windows PowerShell только появился, многие стали спрашивать, можно ли управлять Active Directory (AD) с использованием PowerShell. В те времена ответ Microsoft был не таким, какой хотелось бы услышать большинству администраторов. В PowerShell имелся встроенный «акселератор типов» Active Directory Service Interfaces (ADSI) для доступа к объектам AD, но пользователю приходилось в основном самостоятельно выяснять, как применить PowerShell для решения задач администрирования AD. Спустя некоторое время компания Quest Software предоставила бесплатный набор команд для административных задач AD, в том числе создания, изменения и удаления объектов AD, и поиска объектов в AD. В течение длительного периода состояние PowerShell и управления AD было таким.

Значительные изменения произошли с выпуском Windows Server 2008 R2, в котором появился модуль PowerShell для Active Directory. В модуль AD входит набор команд для управления AD, а также AD Provider, с помощью которого можно перемещаться по AD, как по диску с символьным обозначением. В этой статье я покажу, как установить модуль AD, и подробно опишу его функционирование.

Установка Active Directory Module

В отличие от предыдущих инструментов, в которых для связи с AD применялся протокол LDAP, модуль AD использует протоколы Active Directory Web Services (ADWS) для обмена данными с контроллером домена (DC) AD. Эти протоколы подробно описаны в блоге MSDN «Active Directory Web Services Overview», но достаточно отметить, что команды PowerShell в модуле AD и Active Directory Administrative Center (ADAC) используют ADWS для связи и получения информации из AD.

При установке контроллеров домена Windows Server 2012 или Server 2008 R2 в домене AD протокол ADWS устанавливается и запускается по умолчанию на каждом из них. Если ваш домен состоит целиком из контроллеров домена Windows Server 2008 или Windows Server 2003, необходимо установить ADWS отдельно. Microsoft бесплатно предоставляет пакет Active Directory Management Gateway Service для этой цели. Если установить пакет по крайней мере на одном контроллере домена AD Server 2008 или Server 2003, то можно использовать модуль AD для PowerShell наряду с ADAC.

Собственно модуль AD устанавливается по умолчанию на любом DC с операционной системой Server 2012 или Server 2008 R2. На компьютерах Windows 8 и Windows 7 (или любом компьютере, кроме DC, работающем с Server 2012 или Server 2008 R2), необходимо установить средства удаленного администрирования сервера Remote Server Administration Tools из центра загрузки Microsoft.

Независимо от того, установлены Remote Server Administration Tools на компьютере заранее или отдельно, следующий шаг - открыть раздел установки и удаления программ Add/Remove Programs в панели управления и выбрать пункт включения или отключения компонентов Windows - Turn Windows features on or off - в меню слева. Прокрутите диалоговое окно компонентов Windows Feature вниз до раздела Remote Server Administration Tools. Найдите флажок Active Directory Module for Windows PowerShell в папке \Remote Server Administration Tools\Role Administration Tools\AD DS and AD LDS Tools, как показано на экране 1. Установите флажок и нажмите кнопку OK, чтобы установить модуль.

После этого вы должны увидеть ярлык Active Directory Module for Windows PowerShell в разделе Administrative Tools меню Start. Щелкните этот ярлык, чтобы запустить PowerShell с загруженным модулем AD. Если вы уже работаете в PowerShell и хотите просто загрузить модуль, чтобы он стал доступным для использования, можно ввести следующую команду и получить доступ к командам AD и AD Provider:

Import-Module ActiveDirectory

Теперь посмотрим, как перемещаться по AD с помощью AD Provider.

Использование Active Directory Provider

В PowerShell реализована концепция дисков PowerShell, которые я буду называть просто дисками PS. Упрощенно можно назвать диск PS представлением ресурса, такого как пригодная для навигации файловая система, состоящая из папок и конечных элементов. Не каждый ресурс можно представить таким образом, но многие (в том числе AD и реестр) хорошо вписываются в эту модель. Модуль AD содержит провайдера для диска PS AD. Соответственно, можно перемещаться и даже изменять AD, как будто это файловая система.

Как же перемещаться по AD, используя AD Provider? Предполагается, что PowerShell открыт и модуль AD загружен. В этом случае первый шаг - запустить команду Set-Location, которая имеет несколько псевдонимов, в том числе sl и cd:

Set-Location AD:

Эта команда изменяет текущее рабочее положение диска PS AD. В результате приглашение PowerShell покажет AD:\ вместо C:\. Затем, чтобы увидеть элементы в диске PS AD, можно применить команду Get-ChildItem с псевдонимом dir:

Get-ChildItem

На экране 2 показан пример результата на моем компьютере.

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

Set-Location «dc=cpandl,dc=com»

Обратите внимание, что используется команда Set-Location с различающимся именем (DN) моего домена AD. Это требуется для корректной навигации. После перехода в каталог домена (на что указывает приглашение AD:\dc=cpandl,dc=com в PowerShell), можно использовать команду Get-ChildItem, чтобы увидеть структуру AD верхнего уровня (экран 3).

Экран 3. Просмотр верхнего уровня иерархии AD

Если нужно взглянуть на пользователей в организационной единице (OU) SDM, то для перехода в эту OU достаточно ввести:

Set-Location «OU=SDM»

Командная строка PowerShell будет иметь вид AD:\ou=SDM,dc=cpandl,dc=com. На данном этапе можно использовать команду Get-ChildItem, чтобы увидеть все объекты пользователя в этом OU. Если нужно изменить свойство Description на объекте пользователя, представляющем мою учетную запись пользователя Darren Mar-Elia. Для этого есть команда! Команда Set-ItemProperty позволяет изменить свойство в объекте AD. Если нужно изменить описание учетной записи пользователя на Chief Techie, следует выполнить команду:

Set-ItemProperty -Path ".\CN=Darren Mar-Elia" ` -Name «Description» -Value «Chief Techie»

Как мы видим, здесь используется параметр –Path для указания моей учетной записи пользователя в текущем каталоге. Я также использую параметр -Name, дабы указать, что нужно изменить свойство Description, и параметр –Value, для указания описания Chief Techie.

Обратите внимание, что если нужно найти все объекты с определенным значением свойства, можно задействовать Get-ItemProperty. Если требуется просто получить ссылку на объект AD, используйте Get-Item.

Как видите, работать с AD таким образом довольно просто. Механизм вряд ли подходит для массовых изменений, однако он удобен для работы с AD как с файловой системой. При этом, как я выяснил, большинство администраторов использует команды вместо диска PS AD для управления AD. Посмотрим, как действуют некоторые из этих команд.

Применение команд Active Directory

Модуль для AD, поставляемый с Windows 7, содержит 76 команд для управления AD. Их можно использовать почти для любых целей, в том числе поиска объектов AD, создания и удаления объектов AD и манипуляций с информацией о настройках AD (например, режим леса и детальная политика паролей). Обычно команды группируются по глаголам, таким как Add-, Remove-, Get- и Set-. Обратите внимание, что не каждая команда Get- имеет соответствующую команду Set- и наоборот, поэтому иногда приходится потратить усилия, чтобы найти нужную команду для задачи. Например, можно установить уровень функциональности леса AD с использованием Set-ADForestMode, но чтобы выяснить текущий уровень функциональности леса, необходимо задействовать команду Get-ADForest и посмотреть свойство ForestMode на возвращенном объекте.

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

Добавление учетных записей пользователя

Команда New-ADUser обеспечивает простой способ добавлять учетные записи пользователя в AD. Если нужно добавить новую учетную запись пользователя с именем Bill Smith в организационную единицу SDM, то в самом простом случае можно создать учетную запись нового пользователя с помощью команды:

New-ADUser -Name «Bill Smith» -SamAccountName «bsmith» ` -GivenName «Bill» -Surname «Smith» ` -DisplayName «Bill Smith» -Path «OU=SDM,DC=cpandl,DC=com»

В этой команде вводится основная информация об учетной записи пользователя. В частности, параметр -SamAccountName служит для предоставления имени учетной записи SAM, необходимой для создания объекта пользователя. Также применяется параметр –Path, чтобы сообщить команде место, куда следует поместить объект - в данном случае в организационную единицу SDM в домене cpandl.com. Кроме того, указано имя пользователя (параметр -GivenName), фамилия (параметр -Surname) и отображаемое имя (параметр -DisplayName).

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

Чтобы избежать необходимости активировать учетную запись и назначать пароль отдельно, можно изменить команду New-ADUser. New-ADUser автоматически активирует учетную запись, если указать параметр -Enabled $true в команде. Для активирования требуется пароль, поэтому необходимо также указать его в команде.

Чтобы предоставить пароль, можно использовать параметр –AccountPassword. Однако нельзя ввести пароль простым текстом в командной строке. Этот параметр требует, чтобы пароль был введен в защищенной строке (то есть имел тип данных SecureString). Существует два способа преобразовать пароль в защищенную строку, и в обоих случаях используется переменная.

В первом методе применяется команда ConvertTo-SecureString, которая преобразует строки простого текста в защищенные строки. Например, если нужно преобразовать пароль P@ssw0rd12 в защищенную строку и назначить его переменной $pwd, следует выполнить команду:

$pwd = ConvertTo-SecureString -string «P@ssw0rd12» ` -AsPlainText –force

Это не самый безопасный метод назначения пароля, так как кто-то может заглянуть вам через плечо при вводе команды. Более надежный способ, если команда New-ADUser запросит пароль и будет скрывать вводимые символы. Это можно сделать с помощью команды Read-Hostcmdlet с параметром –AsSecureString:

$pwd = Read-Host -AsSecureString

После выполнения этой команды вы увидите на экране знакомый символ «*" при вводе пароля. Завершив ввод, нажмите клавишу Enter.

После того, как пароль сохранен в переменной $pwd, можно передать его в команду New-ADUser:

New-ADUser -Name»Bill Smith«-SamAccountName»bsmith«` -GivenName»Bill«-Surname»Smith«` -DisplayName»Bill Smith«` -Path»OU=SDM,DC=cpandl,DC=com«` -Enabled $true -AccountPassword $pwd

Как мы видим, команда содержит параметры -Enabled и –AccountPassword, которые активируют учетную запись и безопасно назначают ей пароль.

Создание пользовательских учетных записей по одной - аккуратный способ, но иногда требуется создать несколько учетных записей одновременно. PowerShell прекрасно подходит для этой цели. Например, если нужно создать три учетных записи пользователя, то можно подготовить файл с разделением запятыми (CSV), который содержит информацию об учетной записи, а затем использовать команду Import-CSV для передачи этой информации в New-ADUser.

На экране 4 показан файл CSV с именем userlist.csv.

Обратите внимание, что в этом файле заголовки столбцов соответствуют именам параметров, предоставленных в предыдущей команде New-ADUser. Это сделано специально. Когда данные CSV передаются в New-ADUser, команда выберет эти имена параметров из конвейера PowerShell и их не придется указывать в самой команде. Вот команда, применявшаяся для создания трех учетных записей пользователя:

Import-CSV -Path C:\data\userlist.csv | New-ADUser -Enabled $true -AccountPassword $pwd

Как можно заметить, выходные строки команды Import-CSV поступают в команду New-ADUser. Конвейер распознает, что заголовки столбца в CSV-файле представляют собой имена параметров, а остальные строки содержат значения, поэтому нужно лишь предоставить параметры -Enabled и –AccountPassword. Это превосходная возможность конвейера. Благодаря ей удается гораздо эффективнее использовать PowerShell для задач автоматизации такого типа.

Управление членством в группах

Добавление учетных записей пользователей и компьютеров - типичная задача управления AD. С помощью модуля AD выполнить ее сравнительно несложно. Используя команду Add-ADGroupMember, можно добавить в группу одну или несколько учетных записей. Например, если нужно добавить трех новых пользователей в группу Marketing Users. Самый простой способ - использовать команду:

Add-ADGroupMember -Identity»Marketing Users«` -Members jadams,tthumb,mtwain

В этой команде параметр -Identity служит для того, чтобы предоставить имя группы. Также применяется параметр -Members для предоставления имен учетных записей SAM пользователей. Если имеется несколько имен учетных записей SAM, то их следует указать в файле с разделителями в виде запятых.

Можно объединить операции создания трех учетных записей и их добавления в группу Marketing Users в одной команде, чтобы решить задачу одним действием. Однако команда Add-ADGroupMember не поддерживает передачу имен членов группы в конвейер. Поэтому необходимо использовать команду Add-ADPrincipalGroupMembership, если требуется задействовать конвейер. Эта команда может принимать объекты пользователя, компьютера или группы как входные из конвейера и добавлять эти объекты в указанную группу.

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

Import-CSV -Path C:\data\userlist.csv | New-ADUser -Enabled $true -AccountPassword $pass ` -PassThru | Add-ADPrincipalGroupMembership ` -MemberOf»Marketing Users«

Обратите внимание, что к части New-ADUser команды добавлен параметр –PassThru. Этот параметр указывает New-ADUser, что нужно передать созданные объекты пользователя в конвейер. Если данный параметр не указан, то выполнение команды Add-ADPrincipalGroupMembership завершится неудачей.

Также примечательно, что используется только параметр -MemberOf для указания имени группы в разделе Add-ADPrincipalGroupMembership команды. Конвейер обеспечивает остальное, добавляя каждого из трех пользователей в группу Marketing Users.

Итак, с помощью одной команды PowerShell было создано три новых пользователя, они были размещены в OU, получили пароли и были добавлены в группу Marketing Users. Теперь рассмотрим некоторые другие типичные задачи обслуживания AD, которые можно автоматизировать с использованием PowerShell и модуля AD.

Сброс паролей учетных записей пользователя

Иногда пользователям требуется сбросить пароль учетной записи. Эту задачу легко автоматизировать с помощью команды Set-ADAccountPassword, изменив или сбросив пароль учетной записи. Чтобы изменить пароль, необходимо знать старый пароль и ввести новый. Чтобы сбросить пароль, достаточно предоставить новый пароль. Однако необходимо разрешение Reset Password на объект пользователя в AD, чтобы выполнить сброс пароля.

Как и параметр -AccountPassword команды New-ADUser, команда Set-ADAccountPassword использует тип данных SecureString для паролей, поэтому необходимо задействовать один из методов преобразования простых текстовых паролей в защищенные строки. Например, если нужно сбросить пароль для учетной записи пользователя Tom Thumb, то после сохранения нового пароля как защищенной строки в переменной $pass можно выполнить команду:

Set-ADAccountPassword -Identity»tthumb«` -NewPassword $pass –Reset

В этой команде я использую параметр –Identity, чтобы назначить имя учетной записи SAM для учетной записи пользователя Tom Thumb. Я также ввожу параметр -NewPassword с переменной $pass, чтобы предоставить новый пароль. Наконец, задается параметр –Reset, дабы указать, что выполняется сброс, а не изменение пароля.

Еще одна дополнительная задача: переключить флаг учетной записи пользователя Tom Thumb, чтобы заставить его изменить пароль при следующей регистрации. Это обычный прием, когда нужно сбросить пароль пользователя. Данную задачу можно выполнить с помощью команды Set-ADUser, присвоив параметру -ChangePasswordAtLogon значение $true:

Set-ADUser -Identity tthumb -ChangePasswordAtLogon $true

Возникает вопрос, почему не был использован конвейер для передачи вывода команды Set-ADAccountPassword в команду Set-ADUser, чтобы выполнить обе операции в одной команде PowerShell. Я попробовал этот подход, он не работает. Вероятно, в команде Set-ADAccountPassword есть какое-то ограничение, не позволяющее успешно выполнить единую команду. В любом случае, достаточно просто переключить флаг с использованием команды Set-ADUser, как показано выше.

Поиск объектов Active Directory

Другая типичная задача AD - поиск объектов AD, соответствующих определенным критериям. Например, можно найти все компьютеры с определенной версией операционной системы Windows в домене AD. Команда Get-ADObject - самая удобная для поиска LDAP. Например, чтобы найти компьютеры Server 2008 R2 в домене cpandl.com, была применена команда:

Get-ADObject -LDAPFilter ` »(&(operatingSystem=Windows Server 2008 R2 Enterprise)` (objectClass=computer))«-SearchBase»dc=cpandl,dc=com«` -SearchScope Subtree

Эта команда использует три параметра для выполнения задачи: -LDAPFilter, -SearchBase и -SearchScope. Параметр -LDAPFilter принимает в качестве входного стандартный запрос LDAP. В этом примере запрашиваются все объекты компьютера, у которых атрибут OperatingSystem имеет значение Windows Server 2008 R2 Enterprise. Параметр -SearchBase указывает команде, где начать поиск в иерархии AD. В данном случае выполняется поиск из корневого каталога домена AD, но не составляет труда ограничить поиск определенной OU. Параметр –SearchScope указывает команде, следует ли обходить все контейнеры под базой поиска, обнаруживая указанные объекты. В этом случае используется параметр Subtree, чтобы команда проверяла все нижележащие контейнеры.

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

Обратите внимание, что для масштабных поисков полезно задействовать параметр –ResultPageSize, чтобы управлять разбиением результатов поиска на страницы. Обычно я присваиваю этому параметру значение 1000, и команда Get-ADObject возвращает 1000 объектов за один раз. В противном случае можно не получить ожидаемый результат, так как число возвращаемых объектов превышает максимально предусмотренное политикой, установленной для одного запроса поиска.

Другая команда для поиска, предоставленная компанией Microsoft, - Search-ADAccount. Эта команда особенно полезна для поиска с различными заранее заданными условиями, например отключенных учетных записей, учетных записей с просроченными паролями и блокированных учетных записей. Так, следующая команда отыскивает все учетные записи пользователя с просроченными паролями в OU SDM:

Search-ADAccount -PasswordExpired -UsersOnly ` -SearchBase»OU=sdm,dc=cpandl,dc=com«` -SearchScope OneLevel Search-ADAccount -PasswordExpired -UsersOnly ` -SearchBase»OU=sdm,dc=cpandl,dc=com" ` -SearchScope OneLevel

В этой команде используется параметр –PasswordExpired, указывающий, что нужны учетные записи с просроченными паролями. Параметр -UsersOnly указывает, что нужно искать только объекты пользователя (то есть исключить объекты «компьютер»). Как в предыдущем примере, используются параметры -SearchBase и –SearchScope, чтобы указать область поиска. Но в данном случае я использую параметр OneLevel для поиска только в ближайшем OU (то есть исключая любые дочерние организационные единицы).

Это лишь поверхностный рассказ о модуле AD, но надеюсь, вы получили представление о заложенных в нем возможностях. Как отмечалось выше, в модуле более 70 команд. Среди тем, которые не были затронуты в статье, - удаление объектов с использованием команды Remove-, восстановление удаленных объектов с помощью команды Restore-ADObject и удаление свойств UAC на объектах пользователя посредством команды Set-ADAccountControl. Существуют команды почти для любых административных задач AD.

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

1. Сбросить пароль пользователя
2. Активировать и деактивировать учетные записи
3. Разблокировать учетную запись пользователя
4. Удалить учетную запись
5. Найти пустые группы
6. Добавить пользователей в группу
7. Вывести список членов группы
8. Найти устаревшие учетные записи компьютеров
9. Деактивировать учетную запись компьютера
10. Найти компьютеры по типу

Помимо этого автор ведет блог (по PowerShell, конечно), рекомендуем заглянуть - jdhitsolutions.com/blog . А самое актуальное Вы можете получить из его твиттера twitter.com/jeffhicks .
Итак, ниже приводим перевод статьи “Top 10 Active Directory Tasks Solved with PowerShell”.

Управление Active Directory (AD) с помощью Windows PowerShell – это проще, чем Вы думаете, и я хочу доказать Вам это. Вы можете просто взять приведенные ниже скрипты и с их помощью решить ряд задач по управлению AD.

Требования

Чтобы использовать PowerShell для управления AD, нужно соблюсти несколько требований. Я собираюсь продемонстрировать, как командлеты для AD работают на примере компьютера на Windows 7.
Чтобы использовать командлеты, контроллер домена у Вас должен быть уровня Windows Server 2008 R2, или же Вы можете скачать и установить Active Directory Management Gateway Service на наследуемых контроллерах домена (legacy DCs). Внимательно прочитайте документацию перед установкой; требуется перезагрузка КД.
На стороне клиента, скачайте и установите (RSAT) либо для Windows 7 , либо для Windows 8 . В Windows 7, Вам необходимо будет открыть в Панели управления (Control Panel) раздел Программы (Programs) и выбрать Включить или выключить функции Windows (Turn Windows Features On or Off) . Найдите Remote Server Administration Tools и раскройте раздел Role Administration Tools . Выберите подходящие пункты для AD DS and AD LDS Tools, особенно обратите внимание на то, что должен быть выбран пункт Active Directory Module for Windows PowerShell , как показано на рисунке 1. (В Windows 8 все инструменты выбраны по умолчанию). Теперь мы готовы работать.

Рис.1 Включение AD DS и AD LDS Tools

Я вошел в систему под учетной записью с правами доменного администратора. Большинство командлетов, которые я буду показывать, позволят Вам уточнить альтернативные полномочия (credentials). В любом случае я рекомендую прочитать справку (Get-Help ) и примеры, которые я буду демонстрировать ниже.
Начните сессию PowerShell и импортируйте модуль:

PS C:\> Import-Module ActiveDirectory

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

PS C:\> get-command -module ActiveDirectory

Прелесть этих команд в том, что если я могу использовать команду для одного объекта AD, то ее можно использовать для 10, 100 и даже 1000. Посмотрим, как некоторые из этих командлетов работают.

Задача 1: Сброс пароля пользователя

Давайте начнем с типичной задачи: сброс пароля пользователя. Сделать это легко и просто можно через командлет Set-ADAccountPassword . Сложная часть заключается в том, что новый пароль должен быть уточнен как защищенная строка: фрагмент текста, который зашифрован и хранится в памяти на протяжении PowerShell сессии. Во-первых, создадим переменную с новым паролем:
PS C:\> $new=Read-Host "Enter the new password" -AsSecureString

Затем, введем новый пароль:

Теперь мы можем извлечь учетную запись (использование samAccountname – лучший вариант) и задать новый пароль. Вот пример для пользователя Jack Frost:

PS C:\> Set-ADAccountPassword jfrost -NewPassword $new

К сожалению, в случае с этим командлетом наблюдается баг: -Passthru , -Whatif , и –Confirm не работают. Если Вы предпочитаете короткий путь, попробуйте следующее:

PS C:\> Set-ADAccountPassword jfrost -NewPassword (ConvertTo-SecureString -AsPlainText -String "P@ssw0rd1z3" -force)

В итоге мне необходимо, чтобы Jack сменил пароль при следующем входе в систему, и я модифицирую учетную запись используя Set-ADUser .

PS C:\> Set-ADUser jfrost -ChangePasswordAtLogon $True

Результаты выполнения командлета не пишутся в консоль. Если это необходимо сделать, используйте –True . Но я могу узнать, успешно или нет прошла операция, произведя извлечения имени пользователя с помощью командлета Get-ADUser и уточнив свойство PasswordExpired , как показано на рисунке 2.

Рис. 2. Результаты работы командлета Get-ADUser Cmdlet со свойством PasswordExpired

Итог: сбросить пароль пользователя с помощью PowerShell совсем не сложно. Признаюсь, что сбросить пароль также просто через оснастку Active Directory Users and Computers консоли Microsoft Management Console (MMC). Но использование PowerShell подходит в том случае, если Вам необходимо делегировать задачу, Вы не хотите разворачивать вышеупомянутую оснастку или сбрасываете пароль в ходе большого автоматизированного ИТ-процесса.

Задача 2: Активировать и деактивировать учетные записи

А теперь давайте деактивируем учетную запись. Продолжим работать с Jack Frost. Этот код использует параметр –Whatif , который Вы можете встретить в других комадлетах, которые осуществляют изменения, чтобы проверить мою команду не запуская ее.

PS C:\> Disable-ADAccount jfrost -whatif What if: Performing operation "Set" on Target "CN=Jack Frost, OU=staff,OU=Testing,DC=GLOBOMANTICS,DC=local".

А теперь деактивируем по-настоящему:

PS C:\> Disable-ADAccount jfrost

А когда настанет время активировать учетную запись, какой командлет нам поможет?

PS C:\> Enable-ADAccount jfrost

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

PS C:\> get-aduser -filter "department -eq "sales"" | disable-adaccount

Конечно, писать фильтр для Get-ADUser довольно-таки сложно, но именно здесь использование параметра –Whatif вместе с командлетом Disable-ADAccount приходит на помощь.

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

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

PS C:\> Unlock-ADAccount jfrost

Командлет также поддерживает параметры -Whatif и -Confirm .

Задача 4: Удалить учетную запись

Неважно, сколько пользователей Вы удаляете, - это просто осуществить с помощью командлета Remove-ADUser . Мне не хочется удалять Jack Frost, но если бы я захотел, то использовал бы такой код:

PS C:\> Remove-ADUser jfrost -whatif What if: Performing operation "Remove" on Target "CN=Jack Frost,OU=staff,OU=Testing,DC=GLOBOMANTICS,DC=local".

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

PS C:\> get-aduser -filter "enabled -eq "false"" -property WhenChanged -SearchBase "OU=Employees, DC=Globomantics,DC=Local" | where {$_.WhenChanged -le (Get-Date).AddDays(-180)} | Remove-ADuser -whatif

С помощью этой команды будут найдены и удалены все деактивованные учетные записи подразделения (OU) Employees, которые не менялись в течение 180 и более дней.

Задача 5: Поиск пустых групп

Управление группами – занятие бесконечное и неблагодарное. Существует множество способов найти пустые группы. Некоторые выражения могут работать лучше, чем другие, в зависимости от Вашей организации. Код, приведенный ниже, позволит найти все группы в домене, включая встроенные (built-in).

PS C:\> get-adgroup -filter * | where {-Not ($_ | get-adgroupmember)} | Select Name

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

PS C:\> get-adgroup -filter "members -notlike "*" -AND GroupScope -eq "Universal"" -SearchBase "OU=Groups,OU=Employees,DC=Globomantics, DC=local" | Select Name,Group*

Эта команда находит все универсальные группы (Universal groups), которые не имеют членство в OU Groups и выводит некоторые из свойств. Результат приведен на рисунке 3.


Рис. 3. Поиск и фильтрация универсальных групп

Задача 6: Добавление пользователей в группу

Давайте добавим Jack Frost в группу Chicago IT:

PS C:\> add-adgroupmember "chicago IT" -Members jfrost

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

PS C:\> Add-ADGroupMember "Chicago Employees" -member (get-aduser -filter "city -eq "Chicago"")

Я использовал вводное конвейерное выражение (parenthetical pipelined expression), чтобы найти всех пользователей, у которых имеется свойство City в Chicago. Код в скобках выполняется, и полученные объекты передаются в параметр –Member. Каждый пользовательский объект добавляется в группу Chicago Employees. Неважно, имеем ли мы дело с 5 или 5000 пользователей, обновление членства в группах занимает всего несколько секунд. Это выражение может также быть написано с использованием ForEach-Object , что может быть удобнее:

PS C:\> Get-ADUser -filter "city -eq "Chicago"" | foreach {Add-ADGroupMember "Chicago Employees" -Member $_}

Задача 7: Выводим список членов группы

Вы возможно захотите узнать, кто находится в определенной группе. Например, Вы должны периодически узнавать, кто входит в группу доменных администраторов (Domain Admins):

PS C:\> Get-ADGroupMember "Domain Admins"

На рисунке 4 приведен результат.

Рис. 4. Члены группы Domain Admins

Командлет выводит объект AD для каждого члена группы. А что делать с вложенными группами? Моя группа Chicago All Users является коллекцией вложенных групп. Чтобы получить список всех учетных записей, я всего лишь должен использовать параметр –Recursive .

PS C:\> Get-ADGroupMember "Chicago All Users" -Recursive | Select DistinguishedName

Если Вы хотите пойти другим путем – найти, в каких группах пользователь состоит, - используйте свойство пользователя MemberOf :

PS C:\> get-aduser jfrost -property Memberof | Select -ExpandProperty memberOf CN=NewTest,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local CN=Chicago Test,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local CN=Chicago IT,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local CN=Chicago Sales Users,OU=Groups,OU=Employees, DC=GLOBOMANTICS,DC=local

Я использовал параметр -ExpandProperty , чтобы вывести имена MemberOf как строки.

Задача 8: Найти устаревшие учетные записи компьютеров

Мне часто задают этот вопрос: “Как найти устаревшие учетные записи компьютеров?”. И я всегда отвечаю: “А что для вас является устаревшим?” Компании по-разному определяют то, когда учетная запись компьютера (или пользователя, неважно), признается устаревшей и не подлежит дальнейшему использованию. Что касается меня, то я обращаю внимание на те учетные записи, у которых пароли не менялись в течение определенного периода времени. Этот период для меня составляет 90 дней – если компьютер не сменил пароль вместе с доменом за этот период, скорее всего он находится оффлайн и является устаревшим. Используется командлет Get-ADComputer :

PS C:\> get-adcomputer -filter "Passwordlastset -lt "1/1/2012"" -properties *| Select name,passwordlastset

Фильтр замечательно работает с жестким значением, но этот код будет обновляться для всех учетных записей компьютеров, которые не изменили своих паролей с 1 января 2012 года. Результаты приведены на рисунке 5.

Рис. 5. Находим устаревшие учетные записи компьютеров

Другой вариант: предположим, вы хотя бы на функциональном уровне домена Windows 2003. Поставьте фильтр по свойству LastLogontimeStamp . Это значение – число 100 наносекундных интервалов с 1 января, 1601 года, и храниться в GMT, поэтому работа с этим значением слегка сложно:

PS C:\> get-adcomputer -filter "LastlogonTimestamp -gt 0" -properties * | select name,lastlogontimestamp, @{Name="LastLogon";Expression={::FromFileTime ($_.Lastlogontimestamp)}},passwordlastset | Sort LastLogonTimeStamp

Рис. 6. Конвертируем значение LastLogonTimeStamp в привычный формат

Чтобы создать фильтр, мне необходимо конвертировать дату, например, 1 января 2012, в корректный формат. Конвертация осуществляется в FileTime:

PS C:\> $cutoff=(Get-Date "1/1/2012").ToFileTime() PS C:\> $cutoff 129698676000000000

Теперь я могу использовать эту переменную в фильтре для Get-ADComputer :

PS C:\> Get-ADComputer -Filter "(lastlogontimestamp -lt $cutoff) -or (lastlogontimestamp -notlike "*")" -property * | Select Name,LastlogonTimestamp,PasswordLastSet

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

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

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

PS C:\> Disable-ADAccount -Identity "chi-srv01$" -whatif What if: Performing operation "Set" on Target "CN=CHI-SRV01, CN=Computers,DC=GLOBOMANTICS,DC=local".

Или же использовав конвейерное выражение:

PS C:\> get-adcomputer "chi-srv01" | Disable-ADAccount

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

PS C:\> get-adcomputer -filter "Passwordlastset -lt "1/1/2012"" -properties *| Disable-ADAccount

Задача 10: Найти компьютеры по типу

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

PS C:\> Get-ADComputer -Filter * -Properties OperatingSystem | Select OperatingSystem -unique | Sort OperatingSystem

Результаты показаны на рисунке 7.

Рис. 7. Извлечение списка ОС

Я хочу найти все компьютеры, на которых стоит серверная ОС:

PS C:\> Get-ADComputer -Filter "OperatingSystem -like "*Server*"" -properties OperatingSystem,OperatingSystem ServicePack | Select Name,Op* | format-list

Результаты приведены на рисунке 8.

Как и другими командлетами AD Get, Вы можете настроить поисковые параметры и ограничить запрос отдельными OU, если это необходимо. Все выражения, которые я показал, могут быть интегрированы в большие PowerShell выражения. Например, Вы можете сортировать, группировать, применять фильтры, экспортировать в CSV или создавать и отправлять на почту HTML отчеты – и все это из PowerShell! При этом Вам не придется писать ни единого скрипа.
Вот Вам бонус: отчет о возрасте пароля пользователя (user password-age report), сохраненный в HTML файле:

PS C:\> Get-ADUser -Filter "Enabled -eq "True" -AND PasswordNeverExpires -eq "False"" -Properties PasswordLastSet,PasswordNeverExpires,PasswordExpired | Select DistinguishedName,Name,pass*,@{Name="PasswordAge"; Expression={(Get-Date)-$_.PasswordLastSet}} |sort PasswordAge -Descending | ConvertTo-Html -Title "Password Age Report" | Out-File c:\Work\pwage.htm

Хотя это выражение может выглядеть слегка пугающим, при минимальном знании PowerShell им легко воспользоваться. И остается лишь последний совет: как определить кастомное свойство под названием PasswordAge . Значение представляет собой промежуток между сегодняшним днем и свойством PasswordLastSet. Затем я сортирую результаты для моего нового свойства. На рисунке 9 показан выход для моего небольшого тестового домена.

Upd:
В посте приведен перевод статьи на портале

Те, кому приходилось иметь дело с такими вещами, как таблица Excel, перечисляющая 200 новых сотрудников, начинающих работать со следующей недели, или учетные записи пользователей, настроенные неверно, потому что кто-то в службе поддержки щелкнул то, чего щелкать не следовало, а также те, кому интересен более простой способ управления Active Directory®, помимо открытия папок «Пользователи» и «Компьютеры» каждый раз, могут воспользоваться одним из бесплатных средств администрирования. Некоторые из них встроены прямо в операционную систему Windows, некоторые поставляются в пакете Resource Kit или в наборе средств поддержки Windows, а некоторые являются бесплатной продукцией сторонних производителей. Что это за удобные средства и где их можно достать? Давайте выясним.
Начнем со встроенных средств командной строки в Windows Server 2003, позволяющих создавать, удалять, модифицировать и искать объекты в Active Directory.

Средство CSVDE позволяет импортировать новые объекты в Active Directory, используя исходный CSV-файл; оно также дает возможность экспортировать существующие объекты в файл CSV. CSVDE нельзя использовать для изменения существующих объектов; при использовании этого средства в режиме импорта можно лишь создавать новые объекты.

Экспорт списка существующих объектов с помощью CSVDE довольно прост. Ниже показано, как экспортировать объекты Active Directory в файл под названием ad.csv:

csvde –f ad.csv

Параметр –f указывает, что за ним следует имя выходного файла. Но следует понимать, что, в зависимости от среды, этот базовый синтаксис может привести к выводу огромного и неудобного файла. Чтобы ограничить средство экспортом лишь объектов внутри определенного структурного подразделения (OU), команду можно изменить следующим образом:

csvde –f UsersOU.csv –d ou=Users,dc=contoso,dc=com

Предположим далее, что мне необходимо экспортировать лишь объекты пользователя в мой файл CSV. В таком случае можно добавить параметр –r, позволяющий указать фильтр протокола LDAP для данного поиска, который ограничит число экспортируемых атрибутов (заметьте, что все нижеследующее является одной строкой):

csvde –f UsersOnly.csv –d ou=Users,dc=contoso,dc=com –r
"(&(objectcategory=person)(objectclass=user))" –l
DN,objectClass,description

Параметр –i позволяет импортировать объекты в Active Directory из исходного файла CSV. Однако создание объектов пользователя с помощью CSVDE имеет один важный недостаток: с помощью этого средства нельзя устанавливать пароли пользователей, поэтому я бы не стала использовать CSVDE для создания объектов пользователей.

Active Directory предоставляет второе встроенное средство для пакетных операций пользователей, именуемое LDIFDE и обладающее более широкими и гибкими возможностями, чем CSVDE. Помимо создания новых объектов, LDIFDE позволяет модифицировать и удалять существующие объекты и даже расширять схему Active Directory. Платой за гибкость LDIFDE является то, что необходимый входной файл (файл LDIF) с расширением.ldf использует более сложный формат, чем простой файл CSV. (Немного поработав, можно также настраивать пароли пользователей, но об этом чуть позже.)

Начнем с простого примера - экспорта пользователей в структурном подразделении в файл LDF (отметьте, что все нижеследующее является одной строкой):

ldifde -f users.ldf -s DC1.contoso.com -d "ou=UsersOU,dc=contoso,dc=com"
–r "(&(objectcategory=person)(objectclass=user))"

Как и в случае большинства средств командной строки, полное описание параметров LDIFDE можно получить, запустив команду LDIFDE /? . показаны те, что я использовала здесь. (Заметьте, что параметры для команд CSVDE и LDIFDE одинаковы.)

По-настоящему возможности LDIFDE раскрываются при создании объектов и управлении ими. Однако перед этим необходимо создать входной файл. Нижеследующий код создает две новых учетных записи пользователя - afuller и rking; для создания входного файла введите текст в блокноте (или другом редакторе открытого текста) и сохраните его как NewUsers.ldf:

dn: CN=afuller, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: afuller
objectClass: user
samAccountName: afuller dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: rking
objectClass: user
samAccountName: rking

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

ldifde –i –f NewUsers.ldf –s DC1.contoso.com

Единственный новый параметр здесь - это -i, который, как несложно догадаться, указывает, что выполняется операция импорта, а не экспорта.

При модификации или удалении существующих объектов синтаксис команды LDIFDE не меняется; вместо этого изменяется содержимое файла LDF. Для изменения поля описания учетных записей пользователей создайте текстовый файл, именуемый ModifyUsers.ldf, такой как показано на Рис. 2.

Рис. 2 Файл LDF ModifyUsers

Изменения импортируются путем запуска того же синтаксиса команды LDIFDE, что и раньше, с указанием нового файла LDF после параметры -f. Формат LDF для удаления объектов еще проще; для удаления пользователей, с которыми вы работали, создайте файл, именуемый DeleteUsers.ldf, и введите следующее:

dn: CN=afuller OU=UsersOU, DC=contoso, DC=com
changetype: delete dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: delete

Отметьте, что, в отличие от CSVDE, LDIFDE может настраивать пароли пользователей. Однако перед настройкой атрибута unicodePWD для учетной записи пользователя необходимо настроить шифрование SSL/TLS на контроллерах домена.Вдобавок, LDIFDE может создавать и модифицировать любые объекты Active Directory, а не только учетные записи пользователей. Например, нижеследующий файл LDF создаст новое расширение схемы, именеуемое EmployeeID-example, в схеме леса contoso.com:
dn: cn=EmployeeID-example,cn=Schema,
cn=Configuration,dc=contoso,dc=com
changetype: add
adminDisplayName: EmployeeID-Example
attributeID: 1.2.3.4.5.6.6.6.7
attributeSyntax: 2.5.5.6
cn: Employee-ID
instanceType: 4
isSingleValued: True
lDAPDisplayName: employeeID-example

Поскольку в файлах LDIFDE используется стандартный отраслевой формат файла LDAP, приложения от сторонних производителей, которым необходимо модифицировать схему Active Directory, часто поставляют файлы LDF, с помощью которых можно изучить и одобрить изменения, прежде чем применять их к производственной среде.

Помимо средств для операций пакетного импорта и экспорта, в состав Windows Server 2003 входит встроенный набор средств, позволяющий создавать, удалять и изменять различные объекты Active Directory, а также выполнять запросы к объектам, отвечающим определенным критериям. (Следует отметить, что данные средства, dsadd, dsrm, dsget, and dsquery, не поддерживаются Active Directory в Windows 2000.)

Dsadd используется для создания экземпляра класса объектов Active Directory в определенном разделе каталога. В число данных классов входят «пользователи», «компьютеры», «контакты», «группы», «структурные подразделения» и «квоты». Замечу, что каждый создаваемый тип объектов требует особого набора параметров, соотносящихся с атрибутами, доступными для этого типа. Эта команда создает один объект пользователя с различными заполненными атрибутами (отметьте, что все нижеследующее является одной строкой):

dsadd user cn=afuller,ou=IT,dc=contoso,dc=com
–samID afuller –fn Andrew –ln Fuller –pwd *
-memberOf cn=IT,ou=Groups,dc=contoso,dc=com "cn=Help Desk,ou=Groups,
dc=contoso,dc=com"
–desc "Marketing Director"
Параметр -memberOf требует полного различающегося имени (DN) каждой группы, к которой следует добавить пользователя, если его нужно добавить в несколько групп, можно добавить несколько DN, разделенных пробелами.Если элемент, скажем DN группы «Служба поддержки», содержит пробел, этот элемент надо поместить в двойные кавычки. Если элемент, скажем структурное подразделение IT\EMEA, содержит обратную косую черту, эту черту нужно ввести дважды: IT\\EMEA. (Эти требования относятся ко всем средствам ds*.)При использовании параметра -pwd * последует запрос на ввод пароля для пользователя в командной строке. Пароль можно указать внутри самой команды (-pwd P@ssword1), но тогда он будет отображен открытым текстом на экране или в любом текстовом файле либо файле сценария, в который вставлена команда.

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

dsadd computer cn=WKS1,ou=Workstations,dc=contoso,dc=com
dsadd ou "ou=Training OU,dc=contoso,dc=com"

Dsmod используется для изменения существующих объектов, а работают с ним почти так же, как с dsadd, используя различные подменю и синтаксис, зависящие от типа изменяемого объекта. Нижеследующая команда dsmod изменяет пароль пользователя и модифицирует его учетную запись так, чтобы при следующем входе в систему ему был выдан запрос на смену пароля:

dsmod user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
–mustchpwd yes

Чтобы увидеть, насколько похожи эти параметры, взгляните на синтаксис dsadd, используемый для создания пользователя с теми же настроенными атрибутами:

dsadd user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
–mustchpwd yes

Очевидно, что, зная параметры для создания объектов при помощи dsadd, можно использовать их же для изменения пользователей при помощи dsmod.

Противоположностью dsadd является dsrm; как несложно вообразить, это средство используется для удаления объектов из командной строки. Базовый синтаксис dsrm достаточно прямолинеен: просто введите dsrm, а за ним - различающееся имя объекта, который следует удалить, примерно так:

dsrm cn=WKS1,ou=Workstations,dc=contoso,dc=com

По умолчанию dsrm выдаст запрос «Вы действительно хотите удалить этот объект?». Введите Y и нажмите кнопку Enter. Этот запрос можно отключить с помощью параметра –noprompt, но, очевидно, что в таком случае исчезнет шанс подтвердить перед удалением, что объект выбран верно,. Два дополнительных параметра могут быть полезны при удалении объекта-контейнера, то есть структурного подразделения, которое потенциально может содержать другие объекты. Следующая команда удаляет структурное подразделение TrainingOU и все содержащиеся в нем объекты:

А эта удаляет все дочерние объекты в TrainingOU, но не трогает само структурное подразделение:

dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
–exclude

Для перемещения или переименования объекта в Active Directory используется средство dsmove, но следует отметить, что его можно использовать лишь для перемещения объектов внутри домена. Для переноса объектов между доменами или лесами используйте средство переноса Active Directory Migration Tool (ADMT), бесплатно загружаемое с веб-узла Майкрософт. Dsmove полагается на два параметра, которые можно использовать отдельно или вместе. Даная команда изменяет фамилию в учетной записи пользователя Steve Conn:

dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com"
–newname "Steve Conn"

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

dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newparent
ou=Training,dc=contoso,dc=com

Переименование и перенос можно произвести в рамках одной операции, указав оба параметра разом:

dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newname
"Steve Conn" –newparent ou=Training,dc=contoso,dc=com

Dsget и Dsquery

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

Dsget получает на входе различающееся имя (DN) объекта и выдает значение указанного атрибута или атрибутов. Dsget использует те же подменю, что dsadd и dsmod - «пользователь», «компьютер», «контакт», «группа», «структурное подразделение» и «квота».

Чтобы получить имя учетной записи SAM и код безопасности (SID) учетной записи пользователя, введите следующую команду (отметьте, что все нижеследующее является одной строкой):

dsget user cn=afuller,ou=IT,dc=contoso,dc=com
–samAccountName –sid

Результаты будут подобны показанным на Рис. 3.

Рис. 3 Работа dsget

Dsquery возвращает список объектов Active Directory, отвечающих указанным критериям.

Dsquery может использовать следующие подменю, каждое со своим синтаксисом, для ObjectType: «компьютер», «контакт», «подсеть», «группа», «структурное подразделение», «веб-узел», «сервер» (следует отметить, что подменю сервера извлекает данные о контроллерах домена, а не о серверах в вашей среде), «пользователь», «квота» и «раздел». А если один из данных типов запросов не является тем, чем нужно, можно использовать подменю *, позволяющее ввести запрос LDAP свободной формы.StartNode указывает местонахождение дерева Active Directory, в котором начнется поиск. Можно использовать конкретное DN, такое как ou=IT,dc=contoso,dc=com, или один из следующих описателей краткого пути: domainroot, начинающийся с корня определенного домена, или forestroot, начинающийся с корня корневого домена леса, используя сервер глобального каталога для выполнения поиска.Наконец, параметр области поиска указывает, как средство dsquery должно производить поиск в дереве Active Directory. Опросы поддерева (вариант по умолчанию) обращаются к указанному StartNode и всем его дочерним объектам, одноуровневые опросы обращаются только к непосредственным дочерним объектам StartNode, и базовые опросы обращаются только к объекту StartNode.Для лучшего понимания областей поиска представьте структурное подразделение (OU), содержащее как объекты пользователя, так и дочернее OU, которое также содержит дополнительные объекты. При использовании поддерева в качестве ообласти будет запрошено OU, все пользовательские объекты внутри него, дочернее OU и его содержимое. При одноуровневой области будет запрошены только пользователи, содержащие в OU, но не дочернее OU и его содержимое. При базовом запросе будет запрошено только само OU без запроса содержащихся в ней объектов.Наконец, можно использовать выходной формат, чтобы контролировать форматирование результатов dsquery. По умолчанию dsquery возвращает различающиеся имена всех объектов, совпадающих с запросом, примерно так:

"cn=afuller,ou=Training,dc=contoso,dc=com"
"cn=rking,ou=ITTraining,ou=Training,dc=contoso,dc=com" Чтобы запросить все объекты пользователей, содержащиеся в структурном подразделении IT и его дочерних OU, используйте следующее:

dsquery user ou=IT,dc=contoso,dc=com

Запрос можно сделать еще более точным, добавляя дополнительные параметры, такие как -disabled, возвращающий только отключенные учетные записи пользователей; -inactive x, возвращающий только пользователей, не подключавшихся в течении x или более недель; или -stalepwd x, возвращающий только пользователей, которые не меняли свои пароли в течении x или более дней.

В зависимости от числа объектов в каталоге может возникнуть необходимость указать параметр -limit x при запуске запроса. По умолчанию dsquery возвращает до 100 объектов, совпадающих с параметрами запроса; но можно указать и большее число, такое как -limit 500, или использовать -limit 0, чтобы dsquery возвратило все совпадающие объекты.

Можно также использовать другие подменю для выполнения полезных запросов других типов объектов. Рассмотрим следующий запрос, возвращающий каждую подсеть, определенную в «Active Directory - узлы и службы», и входящую в пространство адресов 10.1.x.x:

dsquery subnet –name 10.1.*

А следующую команду можно использовать для возвращения каждой подсети, находящейся на веб-узле Corp:

dsquery subnet –site Corp

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

dsquery server –forest –isgc

Можно также использовать данный синтаксис, чтобы упростить определение контроллера домена в определенном домене, содержащего роль FSMO эмулятора основного контроллера домена (PDC):

dsquery server –hasfsmo pdc

Как и в случае с другими командами ds*, включающими подменю, все параметры, доступные в конкретном подменю dsquery, можно просмотреть, войдя в командную строку и введя dsquery user /?, dsquery computer /?, dsquery subnet /?, и так далее.

Дополнительным хитрым приемом является передача исходящих данных dsquery по конвейеру в другое средство, такое как dsmod, при помощи знака | (SHIFT+обратная косая черта при английской раскладке клавиатуры). К примеру, компания переименовала отдел из «Подготовка» во «Внутреннее развитие», и теперь нужно обновить поле описания каждого относящегося к этому отделу пользователя. Одной командной строкой можно запросить все объекты пользователей, имеющие поле описания «Подготовка», и затем заменить это поле описания для всего пакета следующим образом:

dsquery user –description "Training" | dsmod
-description "Internal Development"

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

Поскольку Active Directory основана на стандартах LDAP, в ней можно создавать запросы и вносить изменения при помощи любого инструмента, понимающего LDAP. Многие сторонние поставщики выпустили платные средства для помощи в администрировании Active Directory, но порой можно найти и настоящие сокровища, которые распространяются бесплатно. Это, в частности, можно сказать про коллекцию, созданную обладателем звания MVP по службам каталогов Джо Ричардсом (Joe Richards) и доступной для загрузки на joeware.net/freetools. В ней можно найти многочисленные средства, служащие для решения различных задач. К трем из них я возвращаюсь постоянно - это adfind, admod и oldcmp.

Adfind и Admod

Adfind и admod подобны dsquery и dsmod; adfind является средством запроса с помощью командной строки для Active Directory, а admod может создавать, удалять или изменять объекты Active Directory.

В отличие от средств ds*, имеющих несколько подменю и различные параметры в зависимости от типа объекта, adfind и admod пользуются единым синтаксисом вне зависимости от типа выполняемого запроса или изменения. Базовый синтаксис для adfind:

adfind –b -s -f
attributesDesired

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

adfind –b dc=contoso,dc=com –s subtree –f (objectclass=computer) dn
description

Запрос всех объектов пользователей будет выглядеть как:

adfind –b dc=contoso,dc=com –s subtree –f "(&(objectcategory=person)
(objectclass=user))" dn description

Отметьте, что за исключением запроса содержимого LDAP, синтаксис не менялся.

Работая с adfind, можно найти несколько сокращенных вариантов записи параметров, которые избавляют от лишней работы по вводу. Например, параметр -default может заменить -b dc=contoso,dc=com в предыдущем примере и провести поиск по всему домену; -gc ищет, основываясь на сборке мусора (GC), и возвращает всех пользователей в вашем лесу Active Directory. Параметр -rb также можно использовать для установки относительной базы для поиска; если, скажем, необходимо найти структурное подразделение «Подготовка» в домене phl.east.us.contoso.com, то можно заметно сэкономить время, просто указав –default –rb ou=Training, вместо –b ou=Training, dc=phl,dc=east,dc=us,dc=contoso,dc=com.

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

Пример, использующий параметр -asq, будет запрашивать «Покажи мне членство в группах членов HelpDesk» следующим образом:

adfind –default –rb cn=HelpDesk,ou=IT –asq member memberOf

Admod, как следует из названия программы, используется для изменения объектов в Active Directory. Как и в случае adfind, в нем нет специализированных подменю со своими синтаксисами, которые надо запоминать; admod использует один и тот же синтаксис вне зависимости от типа обрабатываемого объекта. Admod также можно использовать для добавления, перемещения, переименования удаления и даже восстановления объектов путем простого добавления соответствующего параметра, скажем -add, -rm, -move, -undel. И точно так же, как в dsquery и dsmod, знак | можно использовать для передачи данных запроса adfind по конвейеру в admod.

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

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

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

Отмечу, что поскольку oldcmp может устроить серьезный разгром в каталоге, он снабжен несколькими встроенными функциями безопасности. Он не удаляет учетные записи, которые не были отключены ранее (если в командной строке вы не сказали: «Нет, я действительно хочу это сделать!»). Он не изменяет более 10 объектов за раз (если, опять же, обратное не указано особо), и он никогда не будет ничего делать с учетной записью компьютера контроллера домена.

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

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

Лора Хантер (Laura E. Hunter) является четырехкратным лауреатом премии Microsoft MVP в области средств для работы с сетью Windows Server. Она автор второго издания «Справочного руководства по Active Directory» (изд-во O"Reilly, 2006). Имея десять лет стажа в отрасли ИТ, Лора работает сейчас проектировщиком Active Directory в инженерно-технической фирме мирового уровня. Она также является обладательницей нескольких отраслевых сертификатов, а также часто выступает на встречах групп пользователей и отраслевых конференциях.