Процедуры с учетными данными в проверке подлинности Windows
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016
В этом справочном разделе для ИТ-специалистов описывается, как проверка подлинности Windows обрабатывает учетные данные.
Windows управление учетными данными — это процесс, с помощью которого операционная система получает учетные данные от службы или пользователя и защищает эти сведения для будущей презентации в целевом объекте проверки подлинности. В случае компьютера, присоединенного к домену, целевым объектом проверки подлинности является контроллер домена. Учетные данные, используемые при проверке подлинности, — это цифровые документы, которые связывают удостоверение пользователя с какой-либо формой проверки подлинности, например сертификатом, паролем или ПИН-кодом.
По умолчанию Windows учетные данные проверяются в базе данных диспетчера учетных записей безопасности (SAM) на локальном компьютере или в Active Directory на компьютере, присоединенном к домену, через службу Winlogon. Учетные данные собираются с помощью пользовательского интерфейса входа в систему или программно через интерфейс программирования приложения (API), который будет представлен целевому объекту проверки подлинности.
Сведения о локальной безопасности хранятся в реестре в HKEY_LOCAL_MACHINE\SECURITY. Хранимые сведения включают параметры политики, значения безопасности по умолчанию и сведения об учетной записи, такие как кэшированные учетные данные для входа. Копия базы данных SAM также хранится здесь, хотя она защищена записью.
На следующей схеме показаны необходимые компоненты и пути, которые учетные данные проходят через систему для проверки подлинности пользователя или процесса успешного входа.
В следующей таблице описан каждый компонент, который управляет учетными данными в процессе проверки подлинности на момент входа.
Компоненты проверки подлинности для всех систем
| Компонент | Описание |
|---|---|
| Вход пользователя в систему | Winlogon.exe — это исполняемый файл, отвечающий за управление безопасным взаимодействием с пользователем. Служба Winlogon инициирует процесс входа в Windows операционных систем, передав учетные данные, собранные действием пользователя на защищенном рабочем столе (пользовательский интерфейс входа) в локальный центр безопасности (LSA) через Secur32.dll. |
| Вход в приложение | Входы в приложение или службу, для которых не требуется интерактивный вход. Большинство процессов, инициированных пользователем в пользовательском режиме, используют Secur32.dll тогда как процессы, инициированные при запуске, такие как службы, выполняются в режиме ядра с помощью Ksecdd.sys. Дополнительные сведения о пользовательском режиме и режиме ядра см. в разделе "Приложения", "Режим пользователя" или "Службы" и "Режим ядра" в этом разделе. |
| Secur32.dll | Несколько поставщиков проверки подлинности, образующих основу процесса проверки подлинности. |
| Lsasrv.dll | Служба сервера LSA, которая применяет политики безопасности и выступает в качестве диспетчера пакетов безопасности для LSA. LSA содержит функцию Negotiate, которая выбирает протокол NTLM или Kerberos после определения протокола, который должен быть успешным. |
| Поставщики поддержки безопасности | Набор поставщиков, которые могут вызывать один или несколько протоколов проверки подлинности по отдельности. Набор поставщиков по умолчанию может изменяться с каждой версией операционной системы Windows, а настраиваемые поставщики могут быть записаны. |
| Netlogon.dll | Службы, которые выполняет служба net Logon, приведены ниже. — поддерживает защищенный канал компьютера (не следует путать с Schannel) на контроллер домена. |
| Samsrv.dll | Диспетчер учетных записей безопасности (SAM), в котором хранятся локальные учетные записи безопасности, применяет локально хранимые политики и поддерживает API. |
| Реестр | Реестр содержит копию базы данных SAM, параметры локальной политики безопасности, значения безопасности по умолчанию и сведения об учетной записи, доступные только системе. |
Этот раздел состоит из следующих подразделов.
Ввод учетных данных для входа пользователя
В Windows Server 2008 и Windows Vista архитектура графической идентификации и проверки подлинности (GINA) была заменена моделью поставщика учетных данных, что позволило перечислить различные типы входа с помощью плиток входа. Обе модели описаны ниже.
Архитектура графической идентификации и проверки подлинности
Архитектура графической идентификации и проверки подлинности (GINA) применяется к операционным системам Windows Server 2003, Microsoft Windows 2000 Server, Windows XP и Windows 2000 Professional. В этих системах каждый интерактивный сеанс входа создает отдельный экземпляр службы Winlogon. Архитектура GINA загружается в пространство процессов, используемое Winlogon, получает и обрабатывает учетные данные, а также вызывает интерфейсы проверки подлинности через LSALogonUser.
Экземпляры Winlogon для интерактивного входа выполняются в сеансе 0. Сеанс 0 содержит системные службы и другие критически важные процессы, включая процесс локального центра безопасности (LSA).
На следующей схеме показан процесс учетных данных для Windows Server 2003, Microsoft Windows 2000 Server, Windows XP и Microsoft Windows 2000 Professional.
Архитектура поставщика учетных данных
Архитектура поставщика учетных данных применяется к этим версиям, указанным в списке "Применимо к " в начале этого раздела. В этих системах входная архитектура учетных данных изменилась на расширяемую структуру с помощью поставщиков учетных данных. Эти поставщики представлены различными плитками входа на защищенном рабочем столе, которые позволяют использовать любое количество сценариев входа — разные учетные записи для одного пользователя и различных методов проверки подлинности, таких как пароль, смарт-карта и биометрические данные.
При использовании архитектуры поставщика учетных данных Winlogon всегда запускает пользовательский интерфейс входа после получения события последовательности безопасного внимания. Пользовательский интерфейс входа запрашивает у каждого поставщика учетных данных количество различных типов учетных данных, для которых настроено перечисление. Поставщики учетных данных могут указать одну из этих плиток в качестве значения по умолчанию. После того как все поставщики перечислили плитки, пользовательский интерфейс входа отображает их пользователю. Пользователь взаимодействует с плиткой для предоставления учетных данных. Пользовательский интерфейс входа отправляет эти учетные данные для проверки подлинности.
Поставщики учетных данных не являются механизмами принудительного применения. Они используются для сбора и сериализации учетных данных. Локальный центр безопасности и пакеты проверки подлинности обеспечивают безопасность.
Поставщики учетных данных регистрируются на компьютере и отвечают за следующие действия:
Описание учетных данных, необходимых для проверки подлинности.
Обработка взаимодействия и логики с внешними центрами проверки подлинности.
Упаковка учетных данных для интерактивного входа в систему и входа в сеть.
Упаковка учетных данных для интерактивного входа в систему и входа в сеть включает процесс сериализации. Сериализуя учетные данные несколькими плитками входа, можно отобразить в пользовательском интерфейсе входа. Таким образом, ваша организация может управлять отображением входа, например пользователями, целевыми системами для входа, предварительного доступа к сети и политикам блокировки и разблокировки рабочих станций с помощью настраиваемых поставщиков учетных данных. Несколько поставщиков учетных данных могут совместно существовать на одном компьютере.
Поставщики единого входа (SSO) можно разрабатывать как стандартный поставщик учетных данных или как поставщик предварительного входа.
Каждая версия Windows содержит один поставщик учетных данных по умолчанию и один поставщик PLAP по умолчанию, также известный как поставщик единого входа. Поставщик единого входа позволяет пользователям установить подключение к сети перед входом на локальный компьютер. При реализации этого поставщика поставщик не перечисляет плитки в пользовательском интерфейсе входа.
Поставщик единого входа предназначен для использования в следующих сценариях:
Проверка подлинности сети и вход в систему компьютера обрабатываются различными поставщиками учетных данных. Варианты этого сценария:
Пользователь может подключиться к сети, например подключиться к виртуальной частной сети (VPN), перед входом на компьютер, но не требуется для этого подключения.
Для получения сведений, используемых во время интерактивной проверки подлинности на локальном компьютере, требуется проверка подлинности сети.
За несколькими сетевыми проверками подлинности следует один из других сценариев. Например, пользователь проходит проверку подлинности у поставщика услуг Интернета (ISP), выполняет проверку подлинности в VPN, а затем использует учетные данные учетной записи пользователя для локального входа.
Кэшированные учетные данные отключены, а для проверки подлинности пользователя требуется удаленное подключение службы Access через VPN.
У пользователя домена нет локальной учетной записи, настроенной на компьютере, присоединенном к домену, и перед завершением интерактивного входа необходимо установить удаленное подключение службы Access через VPN-подключение.
Проверка подлинности сети и вход в систему компьютера обрабатываются тем же поставщиком учетных данных. В этом сценарии пользователю необходимо подключиться к сети перед входом на компьютер.
Перечисление плитки входа
Поставщик учетных данных перечисляет плитки входа в следующие экземпляры:
Для этих операционных систем, указанных в списке "Область применения" в начале этого раздела.
Поставщик учетных данных перечисляет плитки для входа в рабочую станцию. Поставщик учетных данных обычно сериализует учетные данные для проверки подлинности в локальном органе безопасности. В этом процессе отображаются плитки, относящиеся к каждому пользователю и относящиеся к целевым системам каждого пользователя.
Архитектура входа и проверки подлинности позволяет пользователю использовать плитки, перечисленные поставщиком учетных данных, для разблокировки рабочей станции. Как правило, текущий пользователь, вошедший в систему, является плиткой по умолчанию, но если в систему входит несколько пользователей, отображаются многочисленные плитки.
Поставщик учетных данных перечисляет плитки в ответ на запрос пользователя на изменение пароля или другой частной информации, например ПИН-кода. Как правило, текущий вошедший в систему пользователь является плиткой по умолчанию; однако если в систему вошли несколько пользователей, отображаются многочисленные плитки.
Поставщик учетных данных перечисляет плитки на основе сериализованных учетных данных, которые будут использоваться для проверки подлинности на удаленных компьютерах. Пользовательский интерфейс учетных данных не использует тот же экземпляр поставщика, что и пользовательский интерфейс входа, разблокировка рабочей станции или изменение пароля. Таким образом, сведения о состоянии не могут храниться в поставщике между экземплярами пользовательского интерфейса учетных данных. Эта структура приводит к по одной плитке для каждого входа на удаленный компьютер, предполагая, что учетные данные были правильно сериализованы. Этот сценарий также используется в средстве контроля учетных записей (UAC), который может помочь предотвратить несанкционированные изменения на компьютере, запросив пользователю разрешение или пароль администратора, прежде чем разрешать действия, которые могут повлиять на работу компьютера или изменить параметры, влияющие на других пользователей компьютера.
На следующей схеме показан процесс учетных данных для операционных систем, указанных в списке "Область применения" в начале этого раздела.
Входные данные для входа в приложение и службу
проверка подлинности Windows предназначена для управления учетными данными для приложений или служб, которые не требуют взаимодействия с пользователем. Приложения в пользовательском режиме ограничены тем, к каким системным ресурсам у них есть доступ, в то время как службы могут иметь неограниченный доступ к системной памяти и внешним устройствам.
Системные службы и приложения уровня транспорта получают доступ к поставщику поддержки безопасности (SSP) через интерфейс поставщика поддержки безопасности (SSPI) в Windows, который предоставляет функции для перечисления пакетов безопасности, доступных в системе, выбора пакета и использования этого пакета для получения подключения с проверкой подлинности.
При проверке подлинности подключения клиента или сервера:
Приложение на стороне клиента подключения отправляет учетные данные на сервер с помощью функции
InitializeSecurityContext (General)SSPI.Приложение на стороне сервера подключения отвечает с помощью функции
AcceptSecurityContext (General)SSPI.Функции
InitializeSecurityContext (General)SSPI иAcceptSecurityContext (General)повторяются до тех пор, пока не будут обменены все необходимые сообщения проверки подлинности для успешной или неудачной проверки подлинности.После проверки подлинности подключения LSA на сервере использует сведения от клиента для создания контекста безопасности, содержащего маркер доступа.
Затем сервер может вызвать функцию
ImpersonateSecurityContextSSPI, чтобы подключить маркер доступа к потоку олицетворения для службы.
Приложения и пользовательский режим
Пользовательский режим в Windows состоит из двух систем, способных передавать запросы ввода-вывода соответствующим драйверам режима ядра: системе среды, которая запускает приложения, написанные для различных типов операционных систем, и целочисленной системы, которая управляет функциями, зависящими от системы среды.
Целочисленная система управляет функциями операционной системы от имени системы среды и состоит из процесса системы безопасности (LSA), службы рабочей станции и серверной службы. Процесс системы безопасности занимается маркерами безопасности, предоставляет или запрещает разрешения на доступ к учетным записям пользователей на основе разрешений ресурсов, обрабатывает запросы на вход и инициирует проверку подлинности входа, а также определяет, какие системные ресурсы операционной системы должны проверяться.
Приложения могут выполняться в пользовательском режиме, где приложение может работать как любой субъект, в том числе в контексте безопасности локальной системы (SYSTEM). Приложения также могут выполняться в режиме ядра, где приложение может выполняться в контексте безопасности локальной системы (SYSTEM).
SSPI доступен через модуль Secur32.dll, который используется для получения интегрированных служб безопасности для проверки подлинности, целостности сообщений и конфиденциальности сообщений. Он предоставляет уровень абстракции между протоколами уровня приложения и протоколами безопасности. Так как для разных приложений требуются разные способы идентификации или проверки подлинности пользователей и различные способы шифрования данных по сети, SSPI предоставляет способ доступа к библиотекам динамического канала (DLL), содержащим различные функции проверки подлинности и криптографические функции. Эти библиотеки DLL называются поставщиками поддержки безопасности (SSP).
Управляемые учетные записи служб и виртуальные учетные записи появились в Windows Server 2008 R2 и Windows 7 для предоставления важных приложений, таких как Microsoft SQL Server и службы IIS (IIS) с изоляцией собственных учетных записей домена, устраняя необходимость администратора вручную администрировать имя субъекта-службы (SPN) и учетные данные для этих учетных записей. Дополнительные сведения об этих функциях и их роли в проверке подлинности см. в документации по управляемым учетным записям служб для Windows 7 и Windows Server 2008 R2 и групповых управляемых учетных записей служб.
Службы и режим ядра
Несмотря на то, что большинство Windows приложений выполняются в контексте безопасности пользователя, который запускает их, это не относится к службам. Многие Windows службы, такие как сетевые и печатные службы, запускаются контроллером службы при запуске компьютера пользователем. Эти службы могут выполняться как локальная служба или локальная система и могут продолжать работать после выхода последнего пользователя из системы.
Примечание
Службы обычно выполняются в контекстах безопасности, известных как локальная система (SYSTEM), сетевая служба или локальная служба. Windows Server 2008 R2 появились службы, которые выполняются под управляемой учетной записью службы, которые являются субъектами домена.
Перед запуском службы контроллер службы входит в систему с помощью учетной записи, назначенной для службы, а затем представляет учетные данные службы для проверки подлинности с помощью LSA. Служба Windows реализует программный интерфейс, который диспетчер контроллеров служб может использовать для управления службой. Службу Windows можно запускать автоматически при запуске системы или вручную с помощью программы управления службами. Например, когда клиентский компьютер Windows присоединяется к домену, служба messenger на компьютере подключается к контроллеру домена и открывает к нему безопасный канал. Чтобы получить прошедшее проверку подлинности подключение, служба должна иметь учетные данные, которым доверяет локальный центр безопасности удаленного компьютера (LSA). При взаимодействии с другими компьютерами в сети LSA использует учетные данные для учетной записи домена локального компьютера, как и все остальные службы, работающие в контексте безопасности локальной системы и сетевой службы. Службы на локальном компьютере выполняются от имени SYSTEM, чтобы учетные данные не должны быть представлены в LSA.
Файл Ksecdd.sys управляет этими учетными данными и шифрует эти учетные данные и использует вызов локальной процедуры в LSA. Тип файла — DRV (драйвер) и называется поставщиком поддержки безопасности в режиме ядра (SSP) и в этих версиях, указанных в списке "Область применения" в начале этого раздела, соответствует стандарту FIPS 140-2 уровня 1.
Режим ядра имеет полный доступ к аппаратным и системным ресурсам компьютера. Режим ядра запрещает службам и приложениям пользовательского режима доступ к критически важным областям операционной системы, к которым у них не должно быть доступа.
Локальная система безопасности
Локальный центр безопасности (LSA) — это защищенный системный процесс, который проверяет подлинность и регистрирует пользователей на локальном компьютере. Кроме того, LSA поддерживает сведения обо всех аспектах локальной безопасности на компьютере (эти аспекты совместно называются локальной политикой безопасности), а также предоставляет различные службы для перевода имен и идентификаторов безопасности (SID). Процесс системы безопасности, служба сервера локального центра безопасности (LSASS), отслеживает политики безопасности и учетные записи, которые применяются в компьютерной системе.
LSA проверяет удостоверение пользователя на основе того, какие из следующих двух сущностей выдали учетную запись пользователя:
Местный центр безопасности. LSA может проверить сведения о пользователе, проверив базу данных диспетчера учетных записей безопасности (SAM), расположенную на том же компьютере. Любые рабочие станции или члены сервера могут хранить локальные учетные записи пользователей и сведения о локальных группах. Однако эти учетные записи можно использовать для доступа только к этой рабочей станции или компьютеру.
Центр безопасности для локального домена или доверенного домена. LSA обращается к сущности, выдавшей учетную запись, и запрашивает проверку того, что учетная запись действительна и что запрос поступил от владельца учетной записи.
Служба LSASS сохраняет в памяти учетные данные пользователей с активными сеансами Windows. Сохраненные учетные данные позволяют пользователям легко получать доступ к сетевым ресурсам, таким как общие папки, Exchange Server почтовые ящики и SharePoint сайты, не вводя учетные данные для каждой удаленной службы.
Служба LSASS способна хранить учетные данных в различных форматах, включая
Зашифрованный обычный текст с возможностью дешифровки
Билеты Kerberos (билеты на предоставление билетов (TGT), билеты на обслуживание)
NT-хэш
Хэш диспетчера локальной сети (LM)
Если пользователь входит в Windows с помощью смарт-карты, LSASS не сохраняет пароль открытого текста, но сохраняет соответствующее значение хэша NT для учетной записи и ПИН-код открытого текста для смарт-карты. Если для смарт-карты, необходимой для интерактивного входа, включается атрибут учетной записи, то для соответствующего профиля происходит автоматическая генерация произвольного NT-хэша, который используется вместо изначального хэша пароля. Хэш пароля, автоматически сгенерированный при установке атрибута, не изменяется.
Если пользователь входит на компьютер на основе Windows с паролем, совместимым с хэшами LAN Manager (LM), этот средство проверки подлинности присутствует в памяти.
Хранение учетных данных в памяти в виде обычного текста нельзя выключить, даже если этого требуют поставщики учетных данных.
Сохраненные учетные данные напрямую связаны с сеансами входа в систему службы подсистемы локального центра безопасности (LSASS), которые были запущены после последнего перезапуска и не были закрыты. Например, сеансы с сохраненными учетными данными LSA создаются, когда пользователь выполняет одно из следующих действий.
Вход в локальный сеанс или сеанс протокола удаленного рабочего стола (RDP) на компьютере
Запускает задание с помощью команды RunAs
Запускает на компьютере активную службу Windows
Запускает назначенное или пакетное задание
Запускает на локальном компьютере задание с помощью средства удаленного администрирования.
В некоторых случаях секреты LSA, которые являются секретными фрагментами данных, доступными только для процессов учетной записи SYSTEM, хранятся на жестком диске. Некоторые из этих секретов представляют собой учетные данные, которые должны сохраниться после перезагрузки и хранящиеся на жестком диске в зашифрованном виде. Учетные данные, хранящиеся в виде секретов LSA, могут включать
Пароль учетной записи для учетной записи доменные службы Active Directory компьютера (AD DS)
Пароли учетных записей служб Windows, настроенных на компьютере
Пароли учетных записей настроенных назначенных заданий
Пароли учетных записей для пулов приложений IIS и веб-сайтов.
Пароли для учетных записей Майкрософт
Представленная в Windows 8.1, клиентская операционная система обеспечивает дополнительную защиту для LSA, чтобы предотвратить чтение памяти и внедрения кода незащищенными процессами. Эта защита повышает безопасность учетных данных, которые LSA хранит и управляет ими.
Дополнительные сведения об этих дополнительных защитах см. в разделе "Настройка дополнительной защиты LSA".
Кэшированные учетные данные и проверка
Механизмы проверки зависят от представления учетных данных во время входа. Однако, если компьютер отключен от контроллера домена, а пользователь представляет учетные данные домена, Windows использует процесс кэшированных учетных данных в механизме проверки.
Каждый раз, когда пользователь входит в домен, Windows кэширует предоставленные учетные данные и сохраняет их в кусте безопасности в реестре операционной системы.
Используя кэшированные учетные данные, пользователь может войти в член домена без подключения к контроллеру домена в этом домене.
Хранилище учетных данных и проверка
Не всегда желательно использовать один набор учетных данных для доступа к разным ресурсам. Например, администратору может потребоваться использовать административные данные, а не учетные данные пользователя при доступе к удаленному серверу. Аналогичным образом, если пользователь обращается к внешним ресурсам, таким как банковский счет, он может использовать только учетные данные, отличные от учетных данных домена. В следующих разделах описываются различия в управлении учетными данными между текущими версиями операционных систем Windows и операционными системами Windows Vista и Windows XP.
Процессы учетных данных удаленного входа
Протокол удаленного рабочего стола (RDP) управляет учетными данными пользователя, который подключается к удаленному компьютеру с помощью клиента удаленного рабочего стола, который был представлен в Windows 8. Учетные данные в виде открытого текста отправляются на целевой узел, в котором узел пытается выполнить процесс проверки подлинности, а в случае успешного подключения пользователя к разрешенным ресурсам. RDP не сохраняет учетные данные на клиенте, но учетные данные домена пользователя хранятся в LSASS.
Представлено в Windows Server 2012 R2 и Windows 8.1 режим ограниченного администратора обеспечивает дополнительную безопасность для сценариев удаленного входа. Этот режим удаленного рабочего стола приводит к тому, что клиентское приложение будет выполнять вызов входа в сеть с помощью односторонней функции NT (NTOWF) или использовать билет службы Kerberos при проверке подлинности на удаленном узле. После проверки подлинности администратора администратор не имеет соответствующих учетных данных учетной записи в LSASS, так как они не были предоставлены удаленному узлу. Вместо этого администратор имеет учетные данные учетной записи компьютера для сеанса. Учетные данные администратора не предоставляются удаленному узлу, поэтому действия выполняются в качестве учетной записи компьютера. Ресурсы также ограничены учетной записью компьютера, а администратор не может получить доступ к ресурсам со своей учетной записью.
Процесс автоматического перезапуска учетных данных для входа
Когда пользователь входит на устройство Windows 8.1, LSA сохраняет учетные данные пользователя в зашифрованной памяти, доступные только LSASS.exe. Если клиентский компонент Центра обновления Windows инициирует автоматическую перезагрузку без присутствия пользователя, эти учетные данные используются для настройки автолога для пользователя.
При перезапуске пользователь автоматически войдет в систему с помощью механизма автолога, а затем компьютер дополнительно блокируется для защиты сеанса пользователя. Блокировка инициируется с помощью Winlogon, а управление учетными данными выполняется LSA. Автоматический вход и блокировка сеанса пользователя на консоли перезапускается и становится доступным.
Дополнительные сведения об ARSO см. в статье об автоматическом перезапуске Winlogon Sign-On (ARSO).
Сохраненные имена пользователей и пароли в Windows Vista и Windows XP
В Windows Server 2008, Windows Server 2003, Windows Vista и Windows XP сохраненные имена пользователей и пароли в панель управления упрощает управление и использование нескольких наборов учетных данных для входа, включая сертификаты X.509, используемые с смарт-картами и Windows Динамические учетные данные (теперь называется учетной записью Майкрософт). Учетные данные , часть профиля пользователя, сохраняются до тех пор, пока не потребуется. Это действие может повысить безопасность на основе каждого ресурса, гарантируя, что если один пароль скомпрометирован, он не скомпрометируют всю безопасность.
После входа пользователя и попытки доступа к дополнительным ресурсам, защищенным паролем, например к общей папке на сервере, и если учетные данные входа пользователя по умолчанию недостаточно для получения доступа, запрашиваются сохраненные имена пользователей и пароли . Если альтернативные учетные данные с правильными сведениями о входе были сохранены в сохраненных именах пользователей и паролях, эти учетные данные используются для получения доступа. В противном случае пользователю будет предложено указать новые учетные данные, которые затем можно сохранить для повторного использования либо позже в сеансе входа, либо во время последующего сеанса.
Применяются следующие ограничения:
Если сохраненные имена пользователей и пароли содержат недопустимые или неверные учетные данные для определенного ресурса, доступ к ресурсу запрещен, а диалоговое окно "Сохраненные имена пользователей и пароли " не отображается.
Сохраненные имена пользователей и пароли хранят учетные данные только для протокола NTLM, протокола Kerberos, учетной записи Майкрософт (ранее Windows Live ID) и проверки подлинности SSL. Некоторые версии Internet Explorer поддерживают собственный кэш для обычной проверки подлинности.
Эти учетные данные становятся зашифрованной частью локального профиля пользователя в каталоге \Documents and Параметры\Username\Application Data\Microsoft\Credentials. В результате эти учетные данные могут перемещаться вместе с пользователем, если политика сети пользователя поддерживает перемещаемые профили пользователей. Однако если пользователь имеет копии сохраненных имен пользователей и паролей на двух разных компьютерах и изменяет учетные данные, связанные с ресурсом на одном из этих компьютеров, изменение не распространяется на сохраненные имена пользователей и пароли на втором компьютере.
хранилище Windows и диспетчер учетных данных
Диспетчер учетных данных появился в Windows Server 2008 R2 и Windows 7 в качестве функции панель управления для хранения имен пользователей и паролей и управления ими. Диспетчер учетных данных позволяет пользователям хранить учетные данные, относящиеся к другим системам и веб-сайтам, в безопасном хранилище Windows. Некоторые версии Internet Explorer используют эту функцию для проверки подлинности на веб-сайтах.
Управление учетными данными с помощью диспетчера учетных данных контролируется пользователем локального компьютера. Чтобы пользователям было удобно регистрироваться в поддерживаемых браузерах и Windows-приложениях, они могут сохранять и хранить учетные данные с этих ресурсов. Учетные данные сохраняются в специальных зашифрованных папках на компьютере в профиле пользователя. Приложения, поддерживающие эту функцию (с помощью API диспетчера учетных данных), таких как веб-браузеры и приложения, могут представлять правильные учетные данные другим компьютерам и веб-сайтам во время входа.
Когда веб-сайт, приложение или другой компьютер запрашивает проверку подлинности через NTLM или протокол Kerberos, откроется диалоговое окно, в котором установлен флажок "Обновить учетные данные по умолчанию " или "Сохранить пароль ". Это диалоговое окно, позволяющее пользователю сохранять учетные данные локально, создается приложением, поддерживающим API диспетчера учетных данных. Если пользователь выбирает флажок "Сохранить пароль ", диспетчер учетных данных отслеживает имя пользователя, пароль и связанные сведения для используемой службы проверки подлинности.
При следующем использовании службы диспетчер учетных данных автоматически предоставляет учетные данные, хранящиеся в хранилище Windows. Если данные не принимаются, пользователю предлагается ввести правильную информацию для получения доступа. Если доступ предоставляется с новыми учетными данными, диспетчер учетных данных перезаписывает предыдущие учетные данные новым, а затем сохраняет новые учетные данные в хранилище Windows.
База данных диспетчера учетных записей безопасности
Диспетчер учетных записей безопасности (SAM) — это база данных, в которую хранятся учетные записи и группы локальных пользователей. Она присутствует в каждой операционной системе Windows. Однако при присоединении компьютера к домену Active Directory управляет учетными записями домена в доменах Active Directory.
Например, клиентские компьютеры под управлением Windows операционной системы участвуют в сетевом домене, взаимодействуя с контроллером домена, даже если пользователь не вошел в систему. Чтобы инициировать обмен данными, компьютер должен иметь активную учетную запись в домене. Перед приемом связи с компьютера LSA на контроллере домена проверяет подлинность удостоверения компьютера, а затем создает контекст безопасности компьютера так же, как и для субъекта безопасности человека. Этот контекст безопасности определяет удостоверение и возможности пользователя или службы на определенном компьютере или пользователе, службе или компьютере в сети. Например, маркер доступа, содержащийся в контексте безопасности, определяет ресурсы (например, общую папку или принтер), к которым можно получить доступ, и действия (например, чтение, запись или изменение), которые могут выполняться этим субъектом — пользователем, компьютером или службой в этом ресурсе.
Контекст безопасности пользователя или компьютера может отличаться от одного компьютера до другого, например, когда пользователь входит на сервер или рабочую станцию, кроме основной рабочей станции пользователя. Он также может отличаться от одного сеанса до другого, например, когда администратор изменяет права и разрешения пользователя. Кроме того, контекст безопасности обычно отличается, если пользователь или компьютер работает на автономной основе, в сети или в составе домена Active Directory.
Локальные домены и доверенные домены
Если отношение доверия существует между двумя доменами, механизмы проверки подлинности для каждого домена зависят от допустимости проверки подлинности, поступающих из другого домена. Отношения доверия помогают обеспечить управляемый доступ к общим ресурсам в домене ресурсов (домене доверия), убедившись, что входящие запросы проверки подлинности поступают из доверенного центра (доверенного домена). Таким образом, отношения доверия выполняют роль мостов, которые позволяют перемещаться только проверенные запросы проверки подлинности между доменами.
Способ передачи запросов проверки подлинности определенного доверия зависит от того, как оно настроено. Отношения доверия могут быть односторонними, предоставляя доступ из доверенного домена к ресурсам в доверенном домене или двумя способами, предоставляя доступ из каждого домена к ресурсам в другом домене. Отношения доверия также являются непереходными, в этом случае доверие существует только между двумя доменами партнеров доверия или транзитивным, в этом случае доверие автоматически распространяется на любые другие домены, которыми доверяет любой из партнеров.
Сведения о отношениях доверия между доменами и лесом, касающихся проверки подлинности, см. в разделе "Делегированная проверка подлинности и отношения доверия".
Сертификаты в проверка подлинности Windows
Инфраструктура открытых ключей (PKI) — это сочетание программного обеспечения, технологий шифрования, процессов и служб, которые позволяют организации защищать связь и бизнес-транзакции. Возможность PKI для защиты обмена данными и бизнес-транзакций основана на обмене цифровыми сертификатами между прошедшими проверку подлинности пользователями и доверенными ресурсами.
Цифровой сертификат — это электронный документ, содержащий сведения о сущности, к которой он принадлежит, сущность, которой она была выдана, уникальный серийный номер или другие уникальные даты идентификации, выдачи и окончания срока действия, а также цифровой отпечатк.
Проверка подлинности — это процесс определения того, можно ли доверять удаленному узлу. Чтобы установить надежность, удаленный узел должен предоставить допустимый сертификат проверки подлинности.
Удаленные узлы устанавливают их надежность путем получения сертификата из центра сертификации (ЦС). ЦС, в свою очередь, может иметь сертификацию от высшего центра, который создает цепочку доверия. Чтобы определить, является ли сертификат надежным, приложение должно определить удостоверение корневого ЦС, а затем определить, является ли он надежным.
Аналогичным образом удаленный узел или локальный компьютер должны определить, является ли сертификат, представленный пользователем или приложением, аутентичным. Сертификат, представленный пользователем через LSA и SSPI, оценивается для проверки подлинности на локальном компьютере для локального входа в систему, в сети или в домене через хранилища сертификатов в Active Directory.
Чтобы создать сертификат, данные проверки подлинности передаются через хэш-алгоритмы, такие как безопасный хэш-алгоритм 1 (SHA1), для создания дайджеста сообщения. Затем дайджест сообщения подписывается цифровой подписью с помощью закрытого ключа отправителя, чтобы доказать, что дайджест сообщения был создан отправителем.
Примечание
SHA1 — это значение по умолчанию в Windows 7 и Windows Vista, но в Windows 8 было изменено на SHA2.
Аутентификация по смарт-карте
Технология смарт-карт является примером проверки подлинности на основе сертификатов. Вход в сеть с помощью смарт-карты обеспечивает надежную форму проверки подлинности, так как она использует идентификацию на основе шифрования и подтверждение владения при проверке подлинности пользователя в домене. Службы сертификатов Active Directory (AD CS) предоставляют криптографическую идентификацию с помощью выдачи сертификата входа для каждой смарт-карты.
Сведения о проверке подлинности смарт-карт см. в техническом справочнике по Windows смарт-картам.
Технология виртуальной смарт-карты появилась в Windows 8. Он сохраняет сертификат смарт-карты на компьютере, а затем защищает его с помощью микросхемы безопасности доверенного платформенного модуля (TPM) устройства. Таким образом, компьютер фактически становится смарт-картой, которая должна получать ПИН-код пользователя для проверки подлинности.
Удаленная и беспроводная проверка подлинности
Удаленная и беспроводная проверка подлинности сети — это другая технология, которая использует сертификаты для проверки подлинности. Служба проверки подлинности Интернета (IAS) и серверы виртуальной частной сети используют расширяемую проверку подлинности Protocol-Transport уровня безопасности (EAP-TLS), защищенный расширяемый протокол проверки подлинности (PEAP) или протокол IPsec для проверки подлинности на основе сертификатов для многих типов сетевого доступа, включая виртуальную частную сеть (VPN) и беспроводные подключения.
Сведения о проверке подлинности на основе сертификатов в сети см. в разделе "Проверка подлинности и сертификаты сетевого доступа".