Процедуры с учетными данными в проверке подлинности Windows
В этом справочном разделе ИТ-специалистов описывается, как проверка подлинности Windows обрабатывает учетные данные.
Управление учетными данными Windows — это процесс, с помощью которого операционная система получает учетные данные от службы или пользователя и защищает эти сведения для будущей презентации в целевом объекте проверки подлинности. В случае компьютера, присоединенного к домену, целевой объект проверки подлинности является контроллером домена. Учетные данные, используемые в проверке подлинности, — это цифровые документы, которые связывают удостоверение пользователя с определенной формой проверки подлинности, например сертификатом, паролем или ПИН-кодом.
По умолчанию учетные данные Windows проверяются в базе данных диспетчера учетных записей безопасности (SAM) на локальном компьютере или active Directory на присоединенном к домену компьютере с помощью службы Winlogon. Учетные данные собираются с помощью входных данных пользователя в пользовательский интерфейс входа или программным способом с помощью интерфейса программирования приложения (API), который будет представлен целевому объекту проверки подлинности.
Сведения о локальной безопасности хранятся в реестре в разделе HKEY_LOCAL_MACHINE\SECURITY. Хранимая информация включает параметры политики, значения безопасности по умолчанию и сведения об учетной записи, такие как кэшированные учетные данные для входа. Копия базы данных SAM также хранится здесь, хотя она защищена записью.
На следующей схеме показаны необходимые компоненты и пути, которые учетные данные принимают через систему для проверки подлинности пользователя или процесса для успешного входа.
В следующей таблице описывается каждый компонент, который управляет учетными данными в процессе проверки подлинности в точке входа.
Компоненты проверки подлинности для всех систем
| Компонент | Description |
|---|---|
| Вход пользователя в систему | Winlogon.exe — это исполняемый файл, отвечающий за управление безопасным взаимодействием с пользователем. Служба Winlogon инициирует процесс входа в операционные системы Windows, передав учетные данные, собранные действием пользователя на защищенном рабочем столе (пользовательский интерфейс входа) в локальный центр безопасности (LSA) через Secur32.dll. |
| Вход в приложение | Для входа в приложение или службу, для которых не требуется интерактивный вход. Большинство процессов, инициируемых пользователем в пользовательском режиме, используют Secur32.dll в то время как процессы, инициированные при запуске, такие как службы, выполняются в режиме ядра с помощью Ksecdd.sys. Дополнительные сведения о пользовательском режиме и режиме ядра см. в разделе "Приложения" и "Режим пользователя" или "Службы" и "Режим ядра" в этом разделе. |
| Secur32.dll | Несколько поставщиков проверки подлинности, которые формируют основу процесса проверки подлинности. |
| Lsasrv.dll | Служба сервера LSA, которая применяет политики безопасности и выступает в качестве диспетчера пакетов безопасности для LSA. LSA содержит функцию "Согласование", которая выбирает протокол 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 Профессиональный. В этих системах каждый интерактивный сеанс входа создает отдельный экземпляр службы Winlogon. Архитектура GINA загружается в пространство процесса, используемое Winlogon, получает и обрабатывает учетные данные, а также вызывает интерфейсы проверки подлинности через LSALogonUser.
Экземпляры Winlogon для интерактивного входа в сеансе 0. Сеанс 0 содержит системные службы и другие критически важные процессы, включая процесс локального центра безопасности (LSA).
На следующей схеме показан процесс учетных данных для Windows Server 2003, Microsoft Windows 2000 Server, Windows XP и Microsoft Windows 2000 Professional.
Архитектура поставщика учетных данных
Архитектура поставщика учетных данных применяется к этим версиям, указанным в списке "Область применения" в начале этого раздела. В этих системах входная архитектура учетных данных изменилась на расширяемую структуру с помощью поставщиков учетных данных. Эти поставщики представлены различными плитками входа на безопасном рабочем столе, разрешающим любое количество сценариев входа в систему — разные учетные записи для одного пользователя и различных методов проверки подлинности, таких как пароль, смарт-карта и биометрические данные.
С архитектурой поставщика учетных данных Winlogon всегда запускает пользовательский интерфейс входа после получения события последовательности безопасного внимания. Пользовательский интерфейс входа запрашивает каждый поставщик учетных данных для количества различных типов учетных данных, для которых настроено перечисление поставщика. Поставщики учетных данных могут указать одну из этих плиток в качестве стандартной. Когда все поставщики перечислили свои плитки, пользовательский интерфейс входа отображает их пользователю. Пользователь взаимодействует с плиткой для предоставления учетных данных. Пользовательский интерфейс входа отправляет эти учетные данные для проверки подлинности.
Поставщики учетных данных не являются механизмами принудительного применения. Они используются для сбора и сериализации учетных данных. Локальный центр безопасности и пакеты проверки подлинности обеспечивают безопасность.
Поставщики учетных данных зарегистрированы на компьютере и отвечают за следующие действия:
Описание сведений о учетных данных, необходимых для проверки подлинности.
Обработка взаимодействия и логики с помощью внешних центров проверки подлинности.
Упаковка учетных данных для интерактивного и сетевого входа.
Упаковка учетных данных для интерактивного и сетевого входа включает процесс сериализации. Сериализуя учетные данные несколькими плитками входа, можно отобразить в пользовательском интерфейсе входа. Таким образом, ваша организация может управлять отображением входа, например пользователями, целевыми системами для входа, предварительного входа в систему к политикам блокировки и разблокировки рабочих станций через использование настраиваемых поставщиков учетных данных. Несколько поставщиков учетных данных могут совместно существовать на одном компьютере.
Поставщики единого входа можно разрабатывать как стандартный поставщик учетных данных или как поставщик предварительного входа.
Каждая версия 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 называются поставщиками поддержки безопасности (SSPS).
Управляемые учетные записи служб и виртуальные учетные записи были представлены в 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 (driver) и называется поставщиком поддержки безопасности в режиме ядра (SSP), и в этих версиях, указанных в списке "Область применения" в начале этого раздела, соответствует FIPS 140-2 уровня 1.
Режим ядра имеет полный доступ к аппаратным и системным ресурсам компьютера. В режиме ядра службы и приложения пользовательского режима перестают получать доступ к критически важным областям операционной системы, к которым они не должны иметь доступа.
Локальная система безопасности
Локальный центр безопасности (LSA) — это защищенный системный процесс, который проходит проверку подлинности и регистрирует пользователей на локальном компьютере. Кроме того, LSA поддерживает сведения обо всех аспектах локальной безопасности на компьютере (эти аспекты совместно называются локальной политикой безопасности), а также предоставляет различные службы для перевода имен и идентификаторов безопасности (SID). Процесс системы безопасности, служба сервера локального центра безопасности (LSASS), отслеживает политики безопасности и учетные записи, действующие в компьютерной системе.
LSA проверяет удостоверение пользователя на основе следующих двух сущностей, выданных учетной записью пользователя:
Локальный центр безопасности. LSA может проверить сведения о пользователе, проверив базу данных диспетчера учетных записей безопасности (SAM), расположенную на том же компьютере. Любые рабочие станции или сервер-члены могут хранить локальные учетные записи пользователей и сведения о локальных группах. Однако эти учетные записи можно использовать для доступа только к этой рабочей станции или компьютеру.
Центр безопасности для локального домена или доверенного домена. LSA обращается к сущности, которая выдала учетную запись и запрашивает проверку подлинности учетной записи и что запрос был получен от владельца учетной записи.
Служба LSASS сохраняет в памяти учетные данные пользователей с активными сеансами Windows. Сохраненные учетные данные позволяют пользователям легко получать доступ к сетевым ресурсам, таким как общие папки, почтовые ящики Exchange Server и сайты SharePoint, без повторного ввода учетных данных для каждой удаленной службы.
Служба LSASS способна хранить учетные данных в различных форматах, включая
Зашифрованный обычный текст с возможностью дешифровки
Билеты Kerberos (билеты на предоставление билетов (TGTs), сервисные билеты)
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 (ARSO).
Сохраненные имена пользователей и пароли в Windows Vista и Windows XP
В Windows Server 2008, Windows Server 2003, Windows Vista и Windows XP, сохраненные имена пользователей и пароли в панель управления упрощает управление и использование нескольких наборов учетных данных входа, включая сертификаты X.509, используемые с смарт-картами и учетными данными Windows Live (теперь называется учетной записью Майкрософт). Учетные данные — часть профиля пользователя — хранятся до тех пор, пока не потребуется. Это действие может повысить безопасность на основе каждого ресурса, гарантируя, что если один пароль скомпрометирован, он не компрометируют всю безопасность.
После входа и попытки доступа к дополнительным ресурсам, защищенным паролем, таким как общий доступ на сервере, и если учетные данные входа пользователя по умолчанию недостаточно для получения доступа, запрашиваются сохраненные имена пользователей и пароли . Если альтернативные учетные данные с правильными сведениями о входе были сохранены в сохраненных именах пользователей и паролях, эти учетные данные используются для получения доступа. В противном случае пользователю будет предложено указать новые учетные данные, которые затем можно сохранить для повторного использования, позже в сеансе входа или во время последующего сеанса.
Применяются следующие ограничения:
Если сохраненные имена пользователей и пароли содержат недопустимые или неверные учетные данные для определенного ресурса, доступ к ресурсу запрещен, а диалоговое окно "Сохраненные имена пользователей и пароли " не отображается.
Сохраненные имена пользователей и пароли хранят учетные данные только для протокола NTLM, протокола Kerberos, учетной записи Майкрософт (прежнее название — Windows Live ID) и проверки подлинности SSL. Некоторые версии Internet Explorer поддерживают собственный кэш для базовой проверки подлинности.
Эти учетные данные становятся зашифрованной частью локального профиля пользователя в каталоге \Documents and Settings\Username\Application Data\Microsoft\Credentials. В результате эти учетные данные могут перемещаться с пользователем, если политика сети пользователя поддерживает перемещаемые профили пользователей. Однако если пользователь имеет копии сохраненных имен пользователей и паролей на двух разных компьютерах и изменяет учетные данные, связанные с ресурсом на одном из этих компьютеров, изменение не распространяется на сохраненные имена пользователей и пароли на втором компьютере.
Windows Vault и Диспетчер учетных данных
Диспетчер учетных данных появился в Windows Server 2008 R2 и Windows 7 в качестве функции панель управления для хранения имен пользователей и паролей и управления ими. Диспетчер учетных данных позволяет пользователям хранить учетные данные, относящиеся к другим системам и веб-сайтам в защищенном хранилище Windows. Некоторые версии Internet Explorer используют эту функцию для проверки подлинности на веб-сайтах.
Управление учетными данными с помощью диспетчера учетных данных контролируется пользователем локального компьютера. Чтобы пользователям было удобно регистрироваться в поддерживаемых браузерах и Windows-приложениях, они могут сохранять и хранить учетные данные с этих ресурсов. Учетные данные сохраняются в специальных зашифрованных папках на компьютере под профилем пользователя. Приложения, поддерживающие эту функцию (с помощью API диспетчера учетных данных), например веб-браузеры и приложения, могут представлять правильные учетные данные другим компьютерам и веб-сайтам во время входа.
Когда веб-сайт, приложение или другой компьютер запрашивает проверку подлинности через NTLM или протокол Kerberos, появится диалоговое окно, в котором установлен флажок "Обновить учетные данные по умолчанию" или "Сохранить пароль ". Это диалоговое окно, позволяющее пользователю сохранять учетные данные локально, создается приложением, поддерживающим API диспетчера учетных данных. Если пользователь выбирает флажок "Сохранить пароль" , диспетчер учетных данных отслеживает имя пользователя, пароль и связанные сведения для используемой службы проверки подлинности.
При следующем использовании службы диспетчер учетных данных автоматически предоставляет учетные данные, хранящиеся в Хранилище Windows. Если данные не принимаются, пользователю предлагается ввести правильную информацию для получения доступа. Если доступ предоставляется с новыми учетными данными, диспетчер учетных данных перезаписывает предыдущие учетные данные новым и сохраняет новые учетные данные в Windows Vault.
База данных диспетчера учетных записей безопасности
Диспетчер учетных записей безопасности (SAM) — это база данных, в которой хранятся учетные записи и группы локальных пользователей. Он присутствует в каждой операционной системе Windows; Однако при присоединении компьютера к домену Active Directory управляет учетными записями домена в доменах Active Directory.
Например, клиентские компьютеры под управлением операционной системы Windows участвуют в сетевом домене, взаимодействуя с контроллером домена, даже если пользователь не вошел в систему. Чтобы инициировать обмен данными, компьютер должен иметь активную учетную запись в домене. Прежде чем принимать обмен данными с компьютера, LSA на контроллере домена проверяет подлинность удостоверения компьютера, а затем создает контекст безопасности компьютера так же, как и для субъекта безопасности человека. Этот контекст безопасности определяет удостоверение и возможности пользователя или службы на определенном компьютере или пользователе, службе или компьютере в сети. Например, маркер доступа, содержащийся в контексте безопасности, определяет ресурсы (например, общую папку или принтер), к которым можно получить доступ, а также действия (например, чтение, запись или изменение), которые могут выполняться этим субъектом — пользователем, компьютером или службой на этом ресурсе.
Контекст безопасности пользователя или компьютера может отличаться от одного компьютера к другому, например, когда пользователь входит на сервер или рабочую станцию, отличной от основной рабочей станции пользователя. Он также может отличаться от одного сеанса к другому, например, когда администратор изменяет права и разрешения пользователя. Кроме того, контекст безопасности обычно отличается, если пользователь или компьютер работает на автономной основе, в сети или в составе домена Active Directory.
Локальные домены и доверенные домены
Если доверие существует между двумя доменами, механизмы проверки подлинности для каждого домена зависят от действительности проверки подлинности, поступающих из другого домена. Доверия помогают обеспечить управляемый доступ к общим ресурсам в домене ресурсов (доверенном домене), убедившись, что входящие запросы проверки подлинности приходят из доверенного центра (доверенного домена). Таким образом, доверие выступает в качестве мостов, которые позволяют выполнять только проверенные запросы проверки подлинности между доменами.
Способ передачи запросов проверки подлинности определенного доверия зависит от того, как он настроен. Отношения доверия могут быть односторонними, предоставляя доступ из доверенного домена к ресурсам в доверенном домене или двумя способами, предоставляя доступ из каждого домена к ресурсам в другом домене. Отношения доверия также являются нетрансляционными, в этом случае доверие существует только между двумя доменами партнеров доверия или транзитивным, в этом случае доверие автоматически распространяется на любые другие домены, которыми доверяет любой из партнеров.
Сведения о отношениях доверия между доменами и лесом относительно проверки подлинности см. в разделе "Делегированная проверка подлинности и отношения доверия".
Сертификаты в проверка подлинности Windows
Инфраструктура открытых ключей (PKI) — это сочетание программного обеспечения, технологий шифрования, процессов и служб, которые позволяют организации обеспечить безопасность связи и бизнес-транзакций. Возможность PKI для защиты обмена данными и бизнес-транзакций основана на обмене цифровыми сертификатами между прошедшими проверку подлинности пользователями и доверенными ресурсами.
Цифровой сертификат — это электронный документ, содержащий сведения о сущности, к которой он принадлежит, сущность, которую она выдала, уникальный серийный номер или другие уникальные даты идентификации, выдачи и окончания срока действия, а также цифровой отпечатк.
Проверка подлинности — это процесс определения того, может ли удаленный узел быть доверенным. Чтобы установить надежность, удаленный узел должен предоставить допустимый сертификат проверки подлинности.
Удаленные узлы устанавливают свою надежность путем получения сертификата из центра сертификации (ЦС). ЦС, в свою очередь, может иметь сертификацию от высшего органа, который создает цепочку доверия. Чтобы определить, является ли сертификат надежным, приложение должно определить удостоверение корневого ЦС, а затем определить, является ли он надежным.
Аналогичным образом удаленный узел или локальный компьютер должны определить, является ли сертификат, представленный пользователем или приложением, аутентичным. Сертификат, представленный пользователем через LSA и SSPI, оценивается для проверки подлинности на локальном компьютере для локального входа в систему, в сети или в домене через хранилища сертификатов в Active Directory.
Чтобы создать сертификат, данные проверки подлинности передаются через хэш-алгоритмы, такие как безопасный хэш-алгоритм 1 (SHA1), для создания дайджеста сообщений. Затем дайджест сообщения подписывается с помощью закрытого ключа отправителя, чтобы доказать, что дайджест сообщения был создан отправителем.
Примечание.
SHA1 — это значение по умолчанию в Windows 7 и Windows Vista, но было изменено на SHA2 в Windows 8.
Проверка подлинности смарт-карты
Технология смарт-карты — это пример проверки подлинности на основе сертификатов. Вход в сеть с помощью смарт-карты обеспечивает надежную форму проверки подлинности, так как он использует идентификацию на основе шифрования и подтверждение владения при проверке подлинности пользователя в домене. Службы сертификатов Active Directory (AD CS) предоставляют идентификацию на основе шифрования путем выдачи сертификата входа для каждой смарт-карты.
Сведения о проверке подлинности смарт-карт см. в техническом справочнике по Windows Smart Card.
Технология виртуальной смарт-карты появилась в Windows 8. Он хранит сертификат смарт-карты на компьютере, а затем защищает его с помощью микросхемы безопасности доверенного платформенного модуля (TPM) устройства. Таким образом, компьютер фактически становится смарт-картой, которая должна получать ПИН-код пользователя для проверки подлинности.
Удаленная и беспроводная проверка подлинности
Удаленная и беспроводная проверка подлинности сети — это другая технология, которая использует сертификаты для проверки подлинности. Служба проверки подлинности Интернета (IAS) и серверы виртуальной частной сети используют расширяемую проверку подлинности протокол-транспорт безопасности (EAP-TLS), защищенный расширяемый протокол проверки подлинности (PEAP) или безопасность протокола Интернета (IPsec) для выполнения проверки подлинности на основе сертификатов для многих типов сетевого доступа, включая виртуальную частную сеть (VPN) и беспроводные подключения.
Сведения о проверке подлинности на основе сертификатов в сети см. в разделе "Проверка подлинности и сертификаты доступа к сети".