Проблема старых рабочих станций в AD
Как происходит типичный процесс обеспечения нового сотрудника рабочей станцией:
- Со склада достается рабочая станция
- На рабочую станцию устанавливается операционная система и все необходимое ПО
- Рабочая станция заводится в домен по неким именем, подозрительно похожим на фамилию пользователя
- Запись о рабочей станции в структуре AD перемещается в необходимый OU
- Рабочая станция устанавливается на рабочее место нового сотрудника
Какие типовые сценарии обычно выполняются при увольнении сотрудника:
- Рабочая станция уволенного сотрудника передается на склад, а содержимое жесткого диска ждет одна из следующих судеб:
- Все необходимые документы переносятся на общеизвестный общий сетевой ресурс, доступ к папке, содержащей перенесенные документы дается для сотрудника, который принимает дела
- Все необходимые документы переносятся непосредственно на рабочую станцию сотрудника, принимающего дела увольняющегося коллеги
- Рабочая станция уволенного сотрудника не передается на склад, а вместо этого:
- Переименовывается в соответствии с чем-то, подозрительно похожим на фамилию уже нового пользователя
- Не переименовывается по причине халатного отношению к работе или по простой забывчивости
Таким образом, при солидном парке ПК и ненулевой текучести кадров, с течением времени в Active Directory накапливается масса записей о рабочих станциях, в точном статусе которых уже не уверен никто.
А выход на самом деле достаточно прост и изящен. Учетная запись рабочей станции с точки зрения каталога AD несильно отличается от учетной записи пользователя. То есть, в свойствах записи есть замечательное поле штампа времени последнего входа в домен. Более того, учетная запись компьютера для аутентификации в домене тоже использует пароль, который обязан автоматически меняться в соответствии с установленными политиками безопасности (по умолчанию, период равен 60 дням).
В базовом же комплекте средств администрирования AD уже есть замечательные консольные утилиты, как нельзя лучше подходящие для наших целей:
- dsquery — выводит список объектов AD, соответствующих заданному критерию
- dsmod — изменяет заданные атрибуты объекта
- dsmove — перемещает объект в рамках AD
- dsrm — удаляет текущий объект или полностью дерево дочерних объектов
- dsadd и dsget нам сейчас не понадобятся
Предположим, мы администрируем домен libertine.su. Итак, выполнив в командной строке простую команду
мы получим список из рабочих станций домена, которые не обновляли свой пароль в течении последнего 61 дня. Точнее, сказать, список из первых 100 записей, подпадающих под данное условие. Если же количество рабочих станций может превышать это значение, плюс мы хотим вывести список только для компьютеров из OU marketing, то нет ничего проще:
Мы также можем вывести список из компьютеров, которые не заходили в домен в течении заданного числа недель. Да, именно недель и об этом необходимо помнить, во избежании непонимания происходящего Description: ;). Как и о том, что, увы, команда работает только, если домен находится в 2003 native режиме.
Итак, выясним, какие компьютеры из OU Sales не регистрировались в домене за последние 7 недель:
Ок, мы выяснили. А что же с этим делать дальше? Логика подсказывает, что можно просто удалить. В принципе, без проблем. Но можно их сначала сделать неактивными. Для этого мы используем соответствующие утилиты командной строки. А найденные компьютеры из dsquery передадим туда при помощи механизма туннелирования команд (символ конвейера в командной строке).
Следующей командой мы выключим учетные записи найденных на предыдущем этапе компьютеров:
Что, у нас не получилось? Все правильно! Параметры в виде полных путей к найденным компьютерам, во вторую часть необходимо передавать по одной, а не сразу весь список.
Можно, конечно, написать глупый cmd файл, примерно такого содержания:
Таким образом мы в бесконечном цикле последовательно изменим атрибут каждой из находимых рабочих станций.
Но это как-то бесконечно некрасиво. Поэтому мы лучше напишем в этом файле следующую конструкцию:
Первая и третья строка на вкус. Лично мне такое поведение нравится больше.
Теперь предлагаю переместить все выключенные записи компьютеров домена в одну единую OU под именем disabled old computers. Создаем эту OU при помощи командной строки или оснастки Active Directory Users and Computers.
А теперь создаем еще один cmd файл:
Попутно можно задуматься о том, сколь бесконечным будет выглядеть результат, если в указанной OU уже содержатся выключенные записи рабочих станций домена. Хотя, разумеется, настоящие индейцы могут попробовать создать специального пользователя, который, имея полные права на модификацию и запись, не будет иметь прав на чтение одной конкретной OU в домене. И запускать в дальнейшем все скрипты от имени данного пользователя.
Да, поскольку я обещал упомянуть утилиту dsrm в контексте управления записями рабочих станций, я ее упоминаю: если создать следующий cmd файл:
а затем его еще и запустить, то у нас будет отличный повод поменять работу. А если рабочих станций было много, а резервное копирование настроено халатно, то вполне возможно, что нам придется поменять еще и профессию.
