Microsoft Way

Проблема старых учетных записей в AD

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

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

Какие типовые сценарии обычно выполняются при увольнения сотрудника:

1. Для учетной записи пользователя меняется пароль.
2. • к почтовому ящику увольняющегося пользователя дается доступ сотруднику, принимающему дела
   • вся деловая переписка архивируется и архив затем подключается к почтовому клиенту сотрудника, принимающего дела увольняющегося коллеги
3. • с почтового ящика увольняющегося пользователя ставится пересылка всей входящей корреспонденции на адрес коллеги, принимающего дела
   • почтовый smtp адрес переназначается с ящика увольняющегося сотрудника на ящик сотрудника, принимающего дела

Причем, надо отметить, если при приеме на работу, в целом, сценарии всегда одинаковы. То при увольнении могут отличаться совершенно разительно. Это может быть обусловлено необходимость дать доступ к архиву почты нескольким пользователям, что порождает действия, противоречащие обычному регламенту. А может быть обусловлено и простым отсутствием самих четких регламентов.

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

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

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

Например, для того, чтобы понять, кто из пользователей, находящихся в OU marketing не входил в сеть в течении 6 недель, необходимо выполнить следующий запрос:
‘dsquery user «ou=marketing,dc=libertine,dc=su» -inactive 6 -limit 0’

Можно, конечно, точно также сделать запрос о просроченных паролях на вход.
‘dsquery computer «ou=marketing,dc=libertine,dc=su» -stalepwd 61 -limit 0’
Но это даст очень много ложных срабатываний, если в домене нет ограничения на срок действия пароля пользователя. Или же персонально для какой-либо учетной записи задано свойство «password newer expires«. Поэтому предыдущий способ все же надежнее.

Ок, предположим, мы получили список записей о пользователях домена, которые давным давно не выполняли вход. Но что нам это дает?

• Если к ящику пользователя для кого-либо назначен доступ, удалять данную учетную запись нельзя
• Если к ящику пользователя кому-либо дан доступ, но это уже давно не актуально, запись пользователя можно удалить
• Если в организации используется какая-либо система, хранящая некие данные, основанные на доменных записях пользователей (например, CRM), удалять учетную запись пользователя крайне нежелательно.

Ладно, предлагаю решать проблемы по порядку.
Для начала предлагаю перенести все записи неактивных пользователей в отдельный OU. Для этого создадим новый OU old users в корне домена и этого напишем командный сценарий:
@echo off
for /F «delims=» %%a in (‘dsquery user «ou=marketing,dc=libertine,dc=su» -inactive 6 -limit 0’) dsmove %%a -newparent «ou=old users,dc=libertine,dc=su»
pause

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

А продолжение я напишу в следующем посте 😉