Active directory windows 2003 не кэширует данные
Обновлено: 04.07.2024
Каждый корневой сервер или кластер сертификации и сервер лицензирования службы управления правами имеет локальный кэш Active Directory, который содержит результаты запросов на членство в группе к глобальному каталогу Active Directory. Кроме кэша, который имеется на каждом сервере, существует общий кэш для каждого кластера, который хранится в базе данных служб каталогов. Назначение этих кэшей - снижение числа запросов, передаваемых в глобальный каталог, а также сокращение времени ответа для запросов на лицензирование.
Когда пользователь запрашивает лицензию на использование, отвечающий сервер должен оценить, имеет ли этот пользователь достаточные права в лицензии на публикацию. В самой простой ситуации пользователь, запрашивающий лицензию, явно указан в лицензии на публикацию. Однако во многих сценариях автор предоставляет права группе, а не отдельным пользователям.
Если лицензия на публикацию не содержит явного указания на запрашивающего пользователя, а вместо этого предоставляет права для группы, сервер должен оценить членства в группе пользователя, чтобы определить, является ли он членом группы, которой были выданы права. Для этого сервер посылает запрос LDAP в глобальный каталог.
Серверы управления правами кэшируют все результаты запросов "группа-членство" в локальном кэше Active Directory и базе данных службы каталогов кластера. Серверы могут затем получать данные о членстве в группе из этих кэшей, что уменьшает число запросов, которые они должны предоставить в глобальный каталог. По умолчанию запрашивается ближайший сервер. Однако в ключе реестра GC можно указать серверы глобального каталога для запросов. Дополнительные сведения об этом параметре можно найти в разделе "Изменение параметров реестра для пула подключений" документа "Работа с сервером службы управления правами" данного комплекта.
Чтобы оценить членства в группе пользователя, сервер сначала проверяет кэш, чтобы определить, нет ли в нем данных о членстве пользователя в группе. В противном случае сервер выполнит проверку базы данных служб каталогов для этого кластера. Если данные о членстве в группе отсутствуют в этой базе данных, сервер сделает запрос в глобальный каталог.
Для пользователей и групп кэшируются следующие атрибуты Active Directory.
- ProxyAddresses (только адреса электронной почты SMTP)
- objectSID
- sidHistory
- memberOf (GUID группы, в которую входит пользователь или группа)
Для элементов в локальном кэше Active Directory устанавливаются отметки времени. Параметры реестра задают срок действия для элементов, находящихся в кэше, а также общее число элементов, которые можно кэшировать. Эти параметры могут влиять на производительность серверов. Дополнительные сведения можно найти в разделе "Изменение параметров кэша Active Directory" документа "Работа с сервером службы управления правами" данного комплекта.
Когда доменный пользователь входит в Windows, по умолчанию его учетные данные (Cached Credentials: имя пользователя и хэш пароля) сохраняются на локальном компьютере. Благодаря этому, пользователь сможет войти на локальный компьютер, даже если контроллеры домена AD недоступны, выключены или на компьютере отключен сетевой кабель. Функционал кэширования учетных данных доменных аккаунтов удобен для пользователей ноутбуков, которые могут получить доступ к своим локальным данным на компьютере, когда нет доступа к корпоративной сети.
Сохраненный кэш доменной учетной записи в Windows
Если домен Active Directory недоступен, Windows проверяет, что введенные имя пользователя и пароль соответствуют сохраненному локальному хэшу и разрешает локальный вход на компьютер.
Сохраненные пароли хранятся в ветке реестра HKEY_LOCAL_MACHINE\Security\Cache (файл %systemroot%\System32\config\SECURITY). Каждый сохранённый хэш содержится в Reg_Binary параметре NL$x (где x – индекс кэшированных данных). По умолчанию даже у администратора нет прав на просмотр содержимого этой ветки реестра, но при желании их можно легко получить.
В реестр сохраняет хэш пароля, модифицированный с помощь salt, созданной на основе имени пользователя.
Настройка Cached Credentials с помощью групповых политик
С помощью параметров групповых политик вы можете задать количество уникальных пользователей, чьи учетные данные могут быть сохранены в локальный кэш на компьютерах домена. Чтобы данные попали в кэш, пользователь должен хотя бы один раз залогиниться на компьютер.
По-умолчанию в Windows 10 /Windows Server 2016 сохраняются учетные данные для 10 пользователей. Чтобы изменить это количество, используется параметр GPO Interactive logon: Number of previous logons to cache (in case domain controller is not available) (Интерактивный вход в систему: количество предыдущих подключений к кэшу в случае отсутствия доступа к контроллеру домена), который находится в разделе Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Можно задать значение от 0 до 50.
Если задать 0, это запретит Windows кэшировать учетные данные пользователей. В этом случае при недоступности домена, при входе пользователя появится ошибка “There are currently no logon servers available to service the logon request”.
При входе под сохраненными данными, пользователь не видит, что контроллер домена не доступен. С помощью GPO можно вывести уведомление о входе под кэшированными данными. Для этого нужно включить политику Report when logon server was not available during user logon (Сообщать, когда сервер входа недоступен при входе пользователя) в разделе Compute configuration -> Policies -> Administrative templates -> Windows Components -> Windows Logon Options.
В этом случае при входе пользователя в трее будет появляться уведомление:
Эту настройку можно включить через реестр:HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/Current Version/Winlogon
- ValueName: ReportControllerMissing
- Data Type: REG_SZ
- Values: TRUE
Безопасность кэшированных учетных данных в Windows
Локальное кэширование учетных данных несет ряд рисков безопасности. Злоумышленник, получив физический доступ к компьютеру/ноутбуку с кэшированными данными, может с помощью брутфорса расшифровать хэш пароля (тут все зависит от сложности и длины пароля, для сложных паролей время подбора огромное). Поэтому не рекомендуется использовать кеширование для учетных записей с правами локального администратора (или, тем более, доменного администратора).
Для уменьшения рисков безопасности, можно отключить кэширование учетных записей на офисных компьютерах и компьютерах администраторов. Для мобильных устройств желательно уменьшить количество кэшируемых аккаунтов до 1. Т.е. даже если администратор заходил на компьютер и его учетные данные попали в кэш, при входе пользователя-владельца устройства, хэш пароля администратора будет удален.
Для доменов с функциональным уровнем Windows Server 2012 R2 или выше можно добавить учетные записи администраторов домена в группу Protected Users. Для таких пользователей запрещено локальное сохранение кэшированных данных для входа.
Можно создать в домене отдельные политики по использованию кэшированных учетных данных для разных устройств и категорий пользователей (например, с помощью GPO Security filters, WMI фильтров, или распространению настроек параметра реестра CashedLogonsCount через GPP Item level targeting).
Для мобильных пользователей – CashedLogonsCount = 1
Для обычных компьютеров – CashedLogonsCount = 0
Такие политики снизят вероятность получения хэша привелигированных пользователей с персональных компьютеров.
Многие помнят то чувство, когда компания расширяется до тех размеров, когда рабочих групп недостаточно, и поднимается первый домен 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, для чего именно, сообщу чуть позже.
- displayName и CN для хранения ФИО
- department для хранения подразделения
- company для хранения организации
- title для хранения должности
- employeeType для хранения типа сотрудника
- postalCode для хранения индекса
- Перечислять учетные записи, у которых заполнен employeeID
- Искать в кадровой системе для каждой учетной записи изменившиеся данные
- Обновлять данные в Active Directory
- Протоколировать изменения в файле
К делу
Первым делом следует проставить employeeID, который у нас представляет табельный номер, всем пользователям. Если пользователей мало, то сделать это проще всего через ADSI Edit, если их чуть больше, то можно прикрутить скрипт для прописывания, например вот так. А если пользователей много, расстановку идентификаторов необходимо делегировать, хочется приятный интерфейс и используются дополнительные фенечки, то можно создать вот такую дополнительную вкладку в ADUC:
впрочем, создание такой вкладки это само по себе тема для отдельного топика.
Второе тонкое место в том, что иногда случается так, что для некоторых людей менять следует только некоторые атрибуты. Есть, например, у нас сотрудник, назовем его Кудрымунбеков Садруддин Фатхулларович, но все его называют просто Сан Саныч. А есть генеральный директор, должность которого в кадрах записана не иначе, как Генеральный Директор Открытого Акционерного Общества Дальней Космической Связи «Рога И Копыта», которого в AD лучше бы просто оставить точно со связью, но точно без рогов и копыт. Таким образом, мы видим необходимость в закладывании в логику работы нашего приложения некоторых исключений, а хранить эти исключения мы будем там же, в Active Directory в атрибуте flags. Этот атрибут имеет величину в четыре байта, а значит, устанавливая тот или иной бит в то или иное значение, мы сможем при необходимости запомнить аж 32 исключения. Впрочем, использовать мы все равно будем только шесть.
Переходим к реализации на powershell:
Создадим тестовую среду, абсолютно произвольно присвоим имена учетным записям:
Теперь запускаем скрипт с параметрами. Разумеется, его можно зашедулить и выполнять по расписанию, только не забыть учетной записи, от имени которой выполняется задание, присвоить право входа в качестве пакетного задания:
Как видим, после выполнения, мы получили хорошие читаемые имена, отличные должности и великолепные наименования компаний:
Конечно, путем неглубокой модификации скрипта, мы можем заполнять пользователю все: от телефонов и адресов до пресловутых любимых напитков, был бы источник. А если скрипт запускать с определенной регулярностью, то мы добиваемся того, что все данные о пользователях будут актуальны.
upd Подправил маленькую ошибочку, перенес обнуление флажков во внутрь цикла
При входе на компьютер с доменной учетной записью пользователь вводит свои учетные данные, которые передаются на ближайший контроллер домена для проверки подлинности. Если в сетевом окружении отсутствуют доступные контроллеры домена, то учетные данные проверить некому и в систему пользователь войти не сможет.
Чтобы избежать подобной ситуации, после успешного входа в систему учетные данные пользователя сохраняются в кэш на локальном компьютере. Это позволяет войти в систему с доменными учетными данными и получить доступ к ресурсам локального компьютера даже при отсутствии подключения к домену.
Примечание. Если быть точным, то кэшируются не сами учетные данные (логин и пароль), а результат их проверки. Еще точнее система хранит хэш пароля, модифицированный при помощи соли (salt), которая в свою очередь, генерируется на основе имени пользователя. Кэшированные данные хранятся в разделе реестра HKLM\SECURITY\Cache, доступ к которому имеет только система.
За возможность кэширования отвечает параметр реестра CashedLogonsCount, находящийся в разделе HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Этот параметр определяет количество уникальных пользователей, чьи учетные данные сохраняются локально. По умолчанию значение параметра равно 10, что означает следующее: учетные данные сохраняются для последних 10 пользователей, заходивших в систему, а при входе на компьютер одиннадцатого пользователя учетные данные первого пользователя будут перезаписаны.
Управлять значением CashedLogonsCount можно централизованно, с помощью групповых политик. Для этого необходимо создать новый GPO (или открыть существующий), перейти в раздел Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options и найти параметр Interactive logon: Number of previous logons to cache (in case domain controller is not available).
По умолчанию данный параметр не определен (Not Defined), соответственно на всех компьютерах используется дефолтное значение. Для его изменения надо включить параметр и указать необходимое значение в пределах от 0 до 50. Значение, равное 0, означает запрет на кэширование учетных данных, соответственно при этом значении вход в систему при недоступности контроллера домена невозможен.
Поскольку теоретически при наличии физического доступа к компьютеру у злоумышленника есть возможность воспользоваться сохраненными учетными данными, то для повышения безопасности рекомендуется отключать локальное кэширование. Исключение могут составить пользователи мобильных устройств (ноутбуков, планшетов и т.п.), которые пользуются устройствами как на работе, так и вне ее. Для таких пользователей количество кэшированных входов можно задать в пределах 1-2. Этого вполне достаточно для работы.
И в завершение пара важных моментов:
• Для того, чтобы учетные данные были закешированы необходимо, чтобы пользователь хотя-бы раз зашел на компьютер под своей доменной учетной записью при доступном контроллере домена.
• Довольно часто параметр CashedLogonsCount трактуют как количество входов в систему при отсутствии доступа к домену. Это не так, и если учетные данные пользователя закешированы локально, то он сможет заходить в систему неограниченное количество раз.
Читайте также: