Эта запись опубликована
09.04.2009 в 17:27. Рубрики: AD, управление компьютерами. Вы можете следить
за ответами к этой записи через RSS 2.0.
Вы можете оставить отзыв или трекбек со своего сайта.
Проблема старых рабочих станций в AD
Как происходит типичный процесс обеспечения нового сотрудника рабочей станцией:
- Со склада достается рабочая станция
- На рабочую станцию устанавливается операционная система и все необходимое ПО
- Рабочая станция заводится в домен по неким именем, подозрительно похожим на фамилию пользователя
- Запись о рабочей станции в структуре AD перемещается в необходимый OU
- Рабочая станция устанавливается на рабочее место нового сотрудника
Какие типовые сценарии обычно выполняются при увольнения сотрудника:
- Рабочая станция уволенного сотрудника передается на склад, а содержимое жесткого диска ждет одна из следующих судеб
- Все необходимые документы переносятся на общеизвестный общий сетевой ресурс, доступ к папке, содержащей перенесенные документы дается для сотрудника, который принимает дела
- Все необходимые документы переносятся непосредственно на рабочую станцию сотрудника, принимающего дела увольняющегося коллеги
- Рабочая станция уволенного сотрудника не передается на склад, а вместо этого
- Переименовывается в соответствии чем-то, подозрительно похожим на фамилию уже нового пользователя
- Не переименовывается по причине халатного отношению к работе или по простой забывчивости
Таким образом, при солидном парке ПК и ненулевой текучести кадров, с течением времени в Active Directory накапливается масса записей о рабочих станциях, в точном статусе которых уже не уверен никто.
А выход на самом деле достаточно прост и изящен. Учетная запись рабочей станции с точки зрения каталога AD несильно отличается от учетной записи пользователя. То есть, в свойствах записи есть замечательное поле штампа времени последнего входа в домен. Более того, учетная запись компьютера для аутентификации в домене тоже использует пароль, который обязан автоматически меняться в соответствии с установленными политиками безопасности (по умолчанию, период равен 60 дням).
В базовом же комплекте средств администрирования AD уже есть замечательные консольные утилиты, как нельзя лучше подходящие для наших целей.
- dsquery — выводит список объектов AD, соответствующих заданному критерию
- dsmod — изменяет заданные атрибуты объекта
- dsmove — перемещает объект в рамках AD
- dsrm — удаляет текущий объект или полностью дерево дочерних объектов
- dsadd и dsget нам сейчас не понадобятся
Предположим, мы администрируем домен libertine.su. Итак, выполнив в командной строке простую команду
dsquery computer «dc=libertine,dc=su» -stalepwd 61
мы получим список из рабочих станций домена, которые не обновляли свой пароль в течении последнего 61 дня. Точнее, сказать, список из первых 100 записей, подпадающих под данное условие.
Если же количество рабочих станций может превышать это значение, плюс мы хотим вывести список только для компьютеров из OU marketing, то нет ничего проще:
dsquery computer «ou=marketing,dc=libertine,dc=su» -stalepwd 61 -limit 0
Мы также можем вывести список из компьютеров, которые не заходили в домен в течении заданного числа недель. Да, именно недель и об этом необходимо помнить, во избежании непонимания происходящего 😉 Как и о том, что увы, команда работает только, если домен находится в 2003 native режиме.
Итак, выясним, какие компьютеры из OU Sales не регистрировались в домене за последние 7 недель:
dsquery computer «ou=sales,dc=libertine,dc=su» -inactive 7 -limit 0
Ок, мы выяснили. А что же с этим делать дальше? Логика подсказывает, что можно просто удалить. В принципе, без проблем. Но можно их сначала сделать неактивными. Для этого мы используем соответствующие утилиты командной строки. А найденные компьютеры из dsquery передадим туда при помощи механизма туннелирования команд (символ трубы в командной строке).
Следующей командой мы выключим учетные записи найденных на предыдущем этапе компьютеров:
dsquery computer «ou=sales,dc=libertine,dc=su» -inactive 7 -limit 0 | dsmod computer -disabled yes
Что, у нас не получилось? Все правильно! Параметры в виде полных путей к найденным компьютерам, во вторую часть необходимо передавать по одной, а не сразу весь список.
Можно, конечно, написать глупый cmd файл, примерно такого содержания:
:gost
dsquery computer «ou=sales,dc=libertine,dc=su» -inactive 7 -limit 1 | dsmod computer -disabled yes
goto gost
Таким образом мы в бесконечном цикле последовательно изменим атрибут каждой из находимых рабочих станций.
Но это как-то бесконечно некрасиво. Поэтому мы лучше напишем в этом файле следующую конструкцию:
@echo off
for /F «delims=» %%a in (‘dsquery computer «ou=sales,dc=libertine,dc=su» -inactive 7 -limit 0’) do dsmod computer %%a -disabled yes
pause
Первая и третья строка на вкус. Лично мне такое поведение нравится больше.
Теперь предлагаю переместить все выключенные записи компьютеров домена в одну единую OU под именем disabled old computers. Создаем эту OU при помощи командной строки или оснастки Active Directory Users and Computers.
А теперь создаем еще один cmd файл:
@echo off
for /F «delims=» %%a in (‘dsquery computer «dc=libertine,dc=su» -disabled -limit 0’) do dsmove %%a -newparent «ou=disabled old computers,dc=libertine,dc=su»
pause
Попутно можно задуматься о том, сколь бесконечным будет выглядеть результат, если в указанной OU уже содержатся выключенные записи рабочих станций домена. Хотя, разумеется, настоящие индейцы могут попробовать создать специального пользователя, который имея полные права на модификацию и запись, не будет иметь прав на чтение одной конкретной OU в домене. И запускать в дальнейшем все скрипты от имени данного пользователя.
Да, поскольку я обещал упомянуть утилиту dsrm в контексте управления записями рабочих станций, я ее упоминаю: если создать следующий cmd файл:
@echo off
for /F «delims=» %%a in (‘dsquery computer «dc=libertine,dc=su» -disabled -limit 0’) do dsrm -subtree -exclude -nopromt -c %%a
pause
А затем его еще и запустить, то у нас будет отличный повод поменять работу. А если рабочих станций было много, а резервное копирование настроено халатно, то вполне возможно, что нам придется поменять еще и профессию.
29 Апр 2009 в 23:44
[…] Отдельную группу, куда автоматически помещались бы все найденные рабочие станции, исключая станции в каком-либо доменном OU. Это может оказаться актуально при использовании AD discovery вкупе с регулярным применением определенной методики чистки домена от записей о стар