Accountexpires ad что это

Актуализируем учетные данные Active Directory

Многие помнят то чувство, когда компания расширяется до тех размеров, когда рабочих групп недостаточно, и поднимается первый домен Active Directory: «О, уж теперь-то все будет как следует!» Ан нет, домен потихонечку разрастается, создаются новые учетки, блокируются старые, добавляются, удаляются компьютеры, девушки выходят замуж, меняют фамилии и, в конце концов, база данных службы каталогов выглядит, как полный швах. В этом топике мы наладим связь между базой Active Directory и кадровой системой предприятия, а также создадим механизм для поддержания данных сотрудников в AD в актуальном состоянии.

Первым делом, мы опишем требования, которые мы должны предъявить к учетным записям сотрудников. А эти требования мы постараемся прикинуть, исходя из потребностей пользователя. Не секрет, что многие корпоративные системы, использующие аутентификацию через Active Directory, для отображения и в своих админках, и просто в ходе работы зачастую используют разнообразные поля учетных записей AD: это и Sharepoint, и Citrix, и многие-многие другие. В качестве примера такой системы я возьму известный всем MS Outlook, да не полностью, а лишь его адресную книгу, которая черпает свои данные напрямую из Active Directory.

Механизм

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

Сведения о пользователе Active Directory не исчерпываются сведениями, которые можно увидеть в оснастке Active Directory Users and Computers (устоявшееся сокращение ADUC), причем очень далеко не исчерпываются. На самом деле объект пользователя имеет триллион атрибутов, и эти атрибуты даже могут быть добавлены администратором схемы. Например, есть такой атрибут, как carLicense, содержащий информацию о водительском удостоверении, или drink, характеризующий любимый напиток пользователя. В общем, Microsoft в этом смысле предусмотрела многое.

Использовать в моем примере я буду атрибуты employeeID для хранения идентификатора пользователя, и flags, для чего именно, сообщу чуть позже.

К делу

Первым делом следует проставить employeeID, который у нас представляет табельный номер, всем пользователям. Если пользователей мало, то сделать это проще всего через ADSI Edit, если их чуть больше, то можно прикрутить скрипт для прописывания, например вот так. А если пользователей много, расстановку идентификаторов необходимо делегировать, хочется приятный интерфейс и используются дополнительные фенечки, то можно создать вот такую дополнительную вкладку в ADUC:

впрочем, создание такой вкладки это само по себе тема для отдельного топика.

Второе тонкое место в том, что иногда случается так, что для некоторых людей менять следует только некоторые атрибуты. Есть, например, у нас сотрудник, назовем его Кудрымунбеков Садруддин Фатхулларович, но все его называют просто Сан Саныч. А есть генеральный директор, должность которого в кадрах записана не иначе, как Генеральный Директор Открытого Акционерного Общества Дальней Космической Связи «Рога И Копыта», которого в AD лучше бы просто оставить точно со связью, но точно без рогов и копыт. Таким образом, мы видим необходимость в закладывании в логику работы нашего приложения некоторых исключений, а хранить эти исключения мы будем там же, в Active Directory в атрибуте flags. Этот атрибут имеет величину в четыре байта, а значит, устанавливая тот или иной бит в то или иное значение, мы сможем при необходимости запомнить аж 32 исключения. Впрочем, использовать мы все равно будем только шесть.

Переходим к реализации на powershell:

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

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

Как видим, после выполнения, мы получили хорошие читаемые имена, отличные должности и великолепные наименования компаний:

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

upd Подправил маленькую ошибочку, перенес обнуление флажков во внутрь цикла

Источник

Аудит учетных записей пользователей в Active Directory

Аудит учетных записей пользователей в Active Directory

Постановка проблемных вопросов
В определенный момент времени наступает то критическое состояние для списка пользователей локальной сети предприятия, когда нежелание остановиться и провести анализ его содержимого может повлечь большие затраты и проблемы, нежели своевременное проведение работ по аудиту и устранению выявленных недостатков.
О чем идет речь? Речь о следующем. В организациях, где число сотрудников, работающих с компьютерной техникой, превышает 100 человек, администрированием занимаются, как правило, два-три сотрудника. Не все они в силу различных обстоятельств с достаточным педантизмом относятся к работе по внесению во вновь создаваемые учетные записи информации о владельцах. Кроме того, администраторы обычно:-) не включены в список тех сотрудников, которым обязаны сообщать об увольнениях. Два этих обстоятельства являются основными причинами, из-за которых и происходит накопление учетных записей «мертвых душ».
Попробуем провести некоторую систематизацию наиболее значимых и очевидных проблем для списка пользователей Active Directory.

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

Во-вторых, к недопустимым можно отнести те учетные записи, которые однозначно не идентифицируют владельца, т.е. дополнительная информация в которых не позволяет назвать человека, определить его должность и подразделение, выяснить, как с ним можно связаться (конечно же, речь здесь не идет о стандартных учетных записях типа «Администратор», «Administrator», «Guest», «Гость», и др).
И, в-третьих, выполнение требований политики безопасности предприятия подразумевает, что усилия и администраторов, и пользователей должны быть направлены на то, чтобы учетная запись использовалась только ее владельцем. То есть, если протокол выполнения операций работы с какой-либо из программ показал, что пользователь вошел под учетной записью Иванова Ивана Ивановича, то абсолютно нерационально будет тратить время на дополнительные разборки с ситуациями, когда выясняется, что учетной записью пользуются (из-за недостаточных знаний компьютера или обычной лени) все сотрудники отдела, в котором трудится пять человек.

Обзор возможностей по работе с учетными записями
Попробуем перечислить те возможности, которые есть под руками у администратора для работы с учетными записями пользователей в Active Directory, и то, насколько они могут быть использованы для проведения аудита.
Оснастка Active Directory — пользователи и компьютеры (которую можно найти в разделе Администрирование на сервере). Замечательная возможность для добавления, редактирования свойств и удаления пользователей домена, но, к сожалению, достаточно бесполезная в вопросах проведения ревизии и аудита. К положительным моментам можно отнести возможность проведения экспорта списка пользователей, в который можно включить такие поля, как Имя входа пользователя, Имя, Выводимое имя, Фамилия, Изменен. Отметим, что поле Изменен показывает время и дату последних изменений для учетной записи администратором (производилась коррекция настроек) или владельцем (смена пароля).
Системная утилита Net.exe. С помощью этой утилиты вы можете обеспечить работу с данными конкретного пользователя (вариант вызова — Net user) — получить дату и время последней регистрации в сети, а также определить, когда завершается срок действия пароля.

Программы-сканеры, задача которых заключается в сборе информации о состоянии локальной сети или конкретного компьютера. Среди наиболее интересных программ в плане получения информации о пользователях отметим CFI LANguard Network Security Scanner (ver 3.1.5). Она предоставляет возможность получения достаточно подробной информации об учетных записях: дата и время последней регистрации; данные о том, когда пароль будет просрочен; количество регистраций пользователя в сети; значение индекса попыток входа с некорректным паролем. Кроме того, программа позволяет на основании данных двух сохраненных протоколов сканирования сформировать отчет о расхождениях и получить перечень заведенных и удаленных учетных записей. Справедливости ради отметим, что программа имеет существенные недостатки особенно для русскоязычной категории пользователей, так как некорректно обрабатывает русские названия (в именах и дополнительных параметрах учетных записей и пр.). Кроме того, отсутствует возможность сохранить в отдельном файле информацию о найденных расхождениях в списках учетных записей.
Перейдем теперь к рассмотрению утилит, которые, на наш взгляд, предоставляют возможность получения наиболее полной информации по пользователям, — Ldifde.exe и Csvde.exe.

Первая утилита позволяет экспортировать данные из Active Directory в файл формата LDIF. Стандарт файла LDIF определен в рекомендациях RFC-2849 для импорта и экспорта данных из каталогов LDAP, таких, как Active Directory. После экспорта данных можно использовать LDIF-файл для импорта тех же объектов в другой каталог LDAP.
Csvde.exe — утилита, аналогичная Ldifde.exe (параметры вызова идентичны), в которой используется другой формат хранения данных в текстовом файле — значения разделяются запятыми (CSV-формат). Данный формат поддерживается программой Microsoft Excel, понимающей файлы в CSV-формате, а также Microsoft Access.

Таблица 1. Описание некоторых полей учетных записей LDAP-каталога

Примечание: Команда Net user некорректно обрабатывает данные поля pwdLastSet, а также некоторые значения времени. Для поля pwdLastSet в случае, если пароль не был задан, выводятся текущие дата и время. Для данных времени вместо значений вида 00:mm AM и 00:mm PM выводятся значения 12:mm AM и 12:mm PM соответственно.

Форматы представления данных даты и времени
Если вы были наблюдательны, то заметили, что в таблице 1 имеются два различных варианта представления значений даты и времени. Если формат вида ГГГГММДДЧЧММСС.0Z (тип GeneralizedTime для ASN.1-кодирования), используемый для полей whenChanged, whenCreated по Гринвичу достаточно понятен, то такие параметры, как lastLogon, pwdLastSet, accountExpires, представляют информацию о дате и времени в 32-битном UNIX-формате и содержат значения секунд, прошедших начиная с 1 января 1970 г., GMT. Для наглядности приведем некоторые значения, которые могут содержаться в файле выгруженных значений для параметров даты и времени в Unix-формате:
126858492000000000 — соответствует 1.01.2003 00:00
127014876000000000 — соответствует 1.07.2003 00:00
127014912000000000 — соответствует 1.07.2003 01:00

Использование функций преобразований для данных CSV-формата
Информацию по учетным записям, которая выгружена с помощью команды, аналогичной указанной в начале раздела «Использование утилиты Csvde.exe», можно попытаться загрузить в Microsoft Access, однако в связи с тем, что программа некорректно обрабатывает символ-разделитель «,» в структурах типа «CN=Bill Gates,CN=Users,DC=Microsoft,DC=com», лучше воспользоваться аналогичными возможностями программы Microsoft Excel (см. рис.1). Далее информацию для удобства использования можно обработать с помощью имеющихся в Microsoft Excel возможностей (макросы, функции).
На рисунках приведена информация CVS-файла сразу после проведения его загрузки в Microsoft Excel (рис.1) и после проведенных преобразований (рис.2). Примеры таких преобразований приведены ниже. Предлагаемые варианты преобразований не претендуют на логическую законченность, но могут являться той основной, с помощью которой за короткий срок может быть разработан необходимый механизм обработки под каждый конкретный случай.

Обработка данных даты и времени Unix-формата
Получение даты в формате ДД.ММ.ГГГГ на основании данных в Unix-формате предлагаем производить в два этапа. На первом этапе вычисляется количество дней, прошедших с 1 января 2003 г. На втором формируется строка даты в стандартном формате.
Для получения количества дней, прошедших с 1 января 2003 г., на основании данных в ячейке F2, заданных в Unix-формате даты и времени, может быть использована следующая формула преобразования:

= ЕСЛИ(
ЗНАЧЕН(ЛЕВСИМВ(F2;11))=0;
-1;
ОКРУГЛВНИЗ( (ЗНАЧЕН(ЛЕВСИМВ (F2;11))-12685849200)/24/3600; 0)
)

Полученное на первом этапе значение сдвига дней относительно 1 января 2003 г. (в ячейке E2) используется для формирования даты в стандартном формате.

=ЕСЛИ( E2=-1;
«Отсутствует»;
СЦЕПИТЬ(
ДЕНЬ(ДАТАЗНАЧ(«1/1/2003»)+E2);
«.»;
МЕСЯЦ(ДАТАЗНАЧ(«1/1/2003»)+E2);
«.»;
ГОД(ДАТАЗНАЧ(«1/1/2003»)+E2)
)
Обработка данных даты и времени формата GeneralizedTime для ASN.1-кодирования
Преобразование числа в формате ГГГГММДДММСС.0Z в формат ДД.ММ.ГГГГ ЧЧ:ММ
=СЦЕПИТЬ(
ПСТР(N2;7;2); «.»; ПСТР(N2; 5;2); «.»; ПСТР(N2;1;4); » «;
ПСТР(N2;9;2); «:»; ПСТР(N2; 11;2)
)

Обработка значения поля userAccountControl о блокированности записи
Получение данных о состоянии учетной записи по значению поля userAccontControl, содержащемуся в ячейке G2:
=ЕСЛИ(ЕПУСТО(G2);»»;
ЕСЛИ(ИЛИG2=514; G2=66050);»За-блокированная»; «Действующая»)
)

Подробные пояснения и описание формата хранения данных в поле userAccountControl можно найти в статье Microsoft «How to Use the User AccountControl Flags to Manipulate User Account Properties» (http://support.microsoft.com/?kbid=305144). Отметим только, что, если параметры учетной записи не заданы, то десятичное значение userAccountControl равно 512; десятичное значение для блокированной учетной записи при отсутствии других параметров — 514.

Заключение
В статье был предложен достаточно простой метод получения данных для аудита учетных записей пользователей в Active Directory, не требующий специальных навыков и знаний языков программирования.
Отметим, что, кроме изложенного метода, может быть использован вариант, рекомендуемый Microsoft, предполагающий использование интерфейсов службы Active Directory (ADSI), которые предоставляют простой, мощный, объектно-ориентированный доступ к ресурсам Active Directory. Интерфейсы ADSI позволяют программистам и администраторам создавать программы каталога с использованием инструментальных средств высокого уровня, например, Microsoft Visual Basic, Java, C или Visual C++, не заботясь о различиях в пространствах имен. Интерфейсы ADSI полностью поддерживают сценарии, что облегчает их использование администраторами.
И напоследок в качестве рекомендаций перечислим те нюансы, на которые следует обратить внимание при проведении анализа данных списка пользователей, которые могут указывать на существующие проблемы при использовании учетных записей:
• заблокированные учетные записи (после анализа последней даты регистрации могут быть удалены в случае, если необходимость в них отсутствует);
• данные учетной записи о том, что последняя регистрации в сети происходила три и более месяцев назад, могут указывать на то, что сотрудник, которому принадлежала учетная запись, уже уволен;
• если количество регистраций в сети для учетной записи равно нулю, а со времени ее создания прошло больше одного месяца, то это может говорить о том, что созданная учетная запись оказалась невостребованной;
• большое количество регистраций в сети может указывать на то, что учетная запись используется для входа в сеть не только владельцем.

Компьютерная газета. Статья была опубликована в номере 39 за 2003 год в рубрике безопасность :: разное

Источник

LDAP-фильтры для поиска объектов в Active Directory. Часть 3

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

PowerShell

У командлетов Get-ADUser, Get-ADComputer, Get-ADGroup и Get-ADObject имеется параметр LdapFilter, специально предназначенный для использования LDAP-фильтров при поиске объектов в Active Directory. Для примера найдем всех пользователей с именем Vasya с помощью такой команды:

Большинство командлетов для поиска являются узкоспециализированными, т.е. предназначены только для определенного типа объектов (пользователи, компьютеры и т.п.). Исключение составляет командлет Get-ADObject, который может искать любые объекты. Например:

При использовании Get-ADObject мы получили не только пользователей, а все объекты с указанным в фильтре именем. Если требуется найти только пользователей, то надо в фильтре добавлять дополнительные параметры. Например:

При помощи LDAP-фильтра нельзя указать область поиска. Для примера найдем всех пользователей, у которых в описании (Description) имеется слово Руководитель:

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

Для уточнения области поиска есть параметр SearchBase, с помощью которого можно указать для поиска конкретное подразделение (OU), например:

Еще один полезный параметр Subtree, с помощью которого можно ограничить глубину поиска. Этот параметр может принимать 3 значения:

• Base (0) — поиск только по указанному в запросе объекту. В результате поиска возвращается либо один объект, либо ничего. Данная область, как правило, используется для проверки наличия объекта.
• One level (1) — поиск только по дочерним объектам указанного объекта. Поиск по вложенным объектам не производится, также в результаты поиск не попадает сам базовый объект.
• Subtree (2) — поиск по всем дочерним объектам, включая вложенные. Сам базовый объект в поиск не попадает. Это значение используется по умолчанию.

Для примера возьмем предыдущую команду и ограничим поиск верхним уровнем (OneLevel):

А затем зададим поиск по всем вложенным объектам (Subtree):

Как видите, разница очевидна.

Для работы с Active Directory из командной строки существует великое множество различных утилит. Мы рассмотрим две наиболее часто используемые для поиска — dsquery и dsget.

Утилита dsquery возвращает различающееся имя (Distinquished Name) объекта, подходящего под заданные параметры, а для LDAP-фильтров у нее имеется параметр filter. К примеру, предыдущий запрос с использованием dsquery будет выглядеть так:

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

ADSIEdit

Переходим к графическим утилитам. Оснастка ADSIEdit поддерживает использование LDAP-фильтров. Для добавления фильтра надо кликнуть по выбраному контексту именования (NC) и в контекстном меню выбрать пункт New — Query…

В открывшемся окне указываем имя запроса, выбираем область поиска (Root of Search) и в поле Query String добавляем нужный фильтр. Для примера отберем всех отключенных пользователей. Дополнительно можно выбрать глубину поиска Subtree или One level.

В результате получим что то вроде этого.

Active Directory Users and Computers

В оснастке Active Directory Users and Computers (ADUC) имеется функция Saved Queries, которая представляет из себя сохраненные LDAP-фильтры. Для создания сохраненного запроса кликаем правой клавишей мыши и выбираем New — Query.

Даем запросу понятное имя и описание, в Query root выбираем область поиска и отмечаем пункт Include subconteiners (аналог Subtree) для поиска по всем вложенным объектам. Затем жмем кнопку Define Query.

Оснастка поддерживает несколько режимов и в принципе вовсе не обязательно писать текст фильтра вручную. Для наиболее часто встречающихся ситуаций достаточно выбрать нужный пункт и\или поставить галочку. Например, для показа всех пользователей с бессрочным паролем можно просто отметить чекбокс Non expiring passwords

Но мы не ищем легких путей, поэтому зададим фильтр руками. Для этого выбираем режим Custom Search и на вкладке Advanced вводим текст фильтра.

В результате в папке Saved Queries появляется список пользователей, у которых пароль не истекает. Таким же образом можно отслеживать множестао различных параметров пользователей, компьютеров и т.д.

А полученные результаты можно экспортировать в виде списка. Очень удобный и полезный функционал.

Примеры LDAP-фильтров

В заключение приведу примеры наиболее часто используемых LDAP-фильтров. Для удобства фильтры сгруппированы по типу объектов (пользователи, компьютеры, группы и прочие непонятные сущности).

Все пользователи:

Фильтр с использованием sAMAccountType более эффективен для объекта пользователь.

Все отключенные (Disabled) пользователи:

Все пользователи кроме отключенных:

Заблокированные (Locked) пользователи:

Здесь используется атрибут badPwdCount, в котором хранится количество неудачных попыток ввода пароля пользователем. Значение нужно указывать в соответствии с политиками безопасности вашего домена.

Пользователи, не менявшие пароль более 3 месяцев:

Атрибут pwdlastSet содержит в себе дату и время последней смены пароля пользователем. Он имеет тип Integer8 и представляет собой число временных интервалов длительностью 100 наносекунд, прошедших с 12:00 01.01.1601 (UTC). Получить требуемое значение можно с помощью PowerShell, например:

Пользователи, у которых пароль не истекает (Password newer expires):

Пользователи, обязанные сменить пароль при следующем входе в систему:

Если значение атрибута pwdlastSet равно 0 и при этом в свойствах учетной записи не отмечен пункт Password newer expires, то пользователь должен сменить пароль при следующем входе.

Пользователи, у которых не требуется пароль:

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

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

Атрибут accountExpires содержит дату истечения срока действия учетной записи и тоже представляет из себя число 100нс интервалов, прошедших с 01.01.1601 (UTC). Значение 0 или 9223372036854775807 (максимально возможное 64-битное число) означает, что срок действия учетной записи никогда не истечет.

Пользователи, созданные за определенный период:

В первом случае мы указываем только начальный период, во втором ограничиваем и начальный и конечный. Формат даты используется следующий:

YYYY MM DD HH mm ss.s Z

2020 01 01 00 00 00.0 Z

Кстати, таким образом можно искать не только пользователей, но и любые другие объекты в AD (компьютеры, группы и т.п.).

Пользователи, не заходившие в систему более чем 3 месяца:

Атрибуты lastLogon и lastLogonTimeStamp имеют такой же кривой тип, как pwdLastSet, и вычисляются таким же образом. Но между ними есть кардинальные различия, о которых необходимо знать.

lastLogon изменяется при входе пользователя только на том контроллере домена, на котором происходила аутентификация, на другие контроллеры он не реплицируется. Поэтому для получения точной информации необходимо произвести поиск на всех контроллерах домена, а потом сравнить полученные данные.

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

Пользователи, никогда не заходившие в систему:

Пользователи с почтовыми ящиками:

Пользователи, скрытые из адресной книги:

Все компьютеры:

Все компьютеры с определенной ОС:

Вместо Windows 7 можно поставить любую требуемую ОС.

Все серверы (компьютеры с серверной ОС):

Все контроллеры домена:

Контроллеры домена, доступные только для чтения:

Все серверы, не являющиеся контроллерами домена:

SQL серверы:

Exchange серверы:

Все группы:

Все локальные (Domain local) группы:

Все глобальные (Global) группы:

Все универсальные (Universal) группы:

Все группы безопасности (Security):

Все группы рассылки (Distribution):

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

Все локальные группы безопасности:

Теоретически правильно использовать отрицательное значение, на практике работают оба.

Все глобальные группы безопасности:

Все универсальные группы безопасности:

Все встроенные группы (BuiltIn):

Все глобальные группы рассылки:

У группы безопасности восьмой бит должен быть установлен в 1, соответственно значение маски равно 2147483648. У группы рассылки этот бит установлен в о, соответственно и значение маски равно 0. Отсюда получаем значение 0 (Distribution) + 2 (Global) = 2 (Global Distribution Group).

Все локальные группы рассылки:

Все универсальные группы рассылки:

Все члены группы (без учета вложенности):

Все члены группы с учетом вложенности:

Все пользователи, не являющиеся членами группы (с учетом вложенности):

Все группы, в которые входит пользователь:

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

Все пустые группы:

Все подразделения (OU):

Все контейнеры (CN):

Все встроенные контейнеры:

Все объекты групповой политики:

Все отношения доверия:

Все связи между сайтами в контейнере конфигурации:

Для запросов к атрибутам конфигурации нужно использовать поиск по контейнеру Configuration (напр. cn=Configuration,dc=test,dc=local).

Объекты, защищенные AdminSDHolder:

AdminSDHolder — это механизм защиты административных учетных записей. Если пользователь является членом защищенной группы (Domain Admins, Enterprise Admins и т.п.) то его учетной записи назначаются разрешения, установленные в объекте AdminSDHolder, а атрибуту adminCount пользователя присваивается значение 1.

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

Объекты, которые не могут быть удалены:

Атрибут systemFlags определяет дополнительные свойства объекта и представляет из себя битовую маску.

Объекты, которые не могут быть перенесены:

Объекты, которые не могут быть переименованы:

Атрибуты, помеченные в схеме как конфиденциальные:

Атрибут searchFlags определяет правила поиска и индексации для атрибута и представляет из себя битовую маску.

Атрибуты, сохраняемые в объекте захоронении (tombstone) при удалении объекта:

Объекты nTDSDSA связанные с глобальным каталогом:

С помощью этого запроса можно найти серверы глобального каталога. Поиск нужно проводить по контейнеру конфигурации. Подробнее об объектах nTDSDSA и их атрибутах.

Объекты nTDSDSA связанные с ролями FSMO:

Для ролей PDC Emulator, RID Master и Infrastructure Master нужно опрашивать домен. Владельца роли Schema Master нужно искать в контейнере Schema (напр. cn=Schema,cn=Configuration,dc=test,dc=local), а владельца Domain Naming Master — в контейнере Configuration (напр. cn=Configuration,dc=test,dc=local).

Источник