Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом справочном разделе для ИТ-специалистов рассказывается, как проверка подлинности 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 содержит функцию "Согласование", которая выбирает протокол 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), также известного как поставщик единого входа. Поставщик единого входа позволяет пользователям подключиться к сети перед входом на локальный компьютер. При внедрении этого поставщика он не перечисляет плитки на экране входа.
Поставщик единого входа (SSO) предназначен для использования в следующих сценариях:
Проверка подлинности сети и вход на компьютер обрабатываются различными поставщиками учетных данных. К этому сценарию относятся следующие варианты:
Пользователь может подключиться к сети, например подключиться к виртуальной частной сети (VPN), прежде чем входить на компьютер, но не требуется для этого подключения.
Для получения сведений, используемых во время интерактивной проверки подлинности на локальном компьютере, требуется проверка подлинности сети.
За несколькими сетевыми проверками подлинности следует один из других сценариев. Например, пользователь проходит проверку подлинности в поставщике услуг Интернета (ISP), выполняет проверку подлинности в VPN, а затем использует учетные данные учетной записи пользователя для локального входа.
Кэшированные учетные данные отключены, и для аутентификации пользователя требуется установить подключение к службам удаленного доступа через VPN перед локальным входом в систему.
У пользователя домена нет локальной учетной записи, настроенной на компьютере, присоединенном к домену, и необходимо установить удаленное подключение службы Access через VPN-подключение перед завершением интерактивного входа.
Проверка подлинности сети и вход на компьютер обрабатываются тем же поставщиком учетных данных. В этом сценарии пользователю необходимо подключиться к сети перед входом на компьютер.
Перечисление элементов входа
Поставщик учетных данных перечисляет логон плитки в следующих случаях:
Для тех операционных систем, перечисленных в списке "Область применения" в начале этого раздела.
Поставщик учетных данных перечисляет элементы для входа на рабочую станцию. Поставщик учетных данных обычно сериализует учетные данные для проверки подлинности в локальном органе безопасности. В этом процессе отображаются плитки, относящиеся к каждому пользователю и относящиеся к целевым системам каждого пользователя.
Архитектура входа и проверки подлинности позволяет пользователю использовать плитки, перечисленные поставщиком учетных данных для разблокировки рабочей станции. Как правило, текущий пользователь является пользователем по умолчанию, но если в систему вошли несколько пользователей, отображаются плитки.
Поставщик учетных данных перечисляет плитки в ответ на запрос пользователя, чтобы изменить пароль или другую частную информацию, например ПИН-код. Обычно плиткой по умолчанию является пользователь, вошедший в систему. Однако если в систему вошли несколько пользователей, отображаются несколько плиток.
Поставщик учетных данных перечисляет элементы на основе сериализованных учетных данных, которые будут использоваться для проверки подлинности на компьютерах по сети. Пользовательский интерфейс учетных данных не использует тот же экземпляр поставщика, что и пользовательский интерфейс входа, разблокировка рабочей станции или изменение пароля. Таким образом, сведения о состоянии данных не могут храниться в провайдере между экземплярами интерфейса Credential UI. Эта структура приводит к созданию одной плитки для каждого входа на удалённый компьютер, при условии, что учетные данные были правильно сериализованы. Этот сценарий также используется в области контроля учетных записей пользователей (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, который является API для обеспечения интегрированных служб безопасности по аутентификации, сохранению целостности и конфиденциальности сообщений. Он предоставляет уровень абстракции между протоколами уровня приложения и протоколами безопасности. Так как для различных приложений требуются различные способы идентификации или проверки подлинности пользователей и различные способы шифрования данных по сети, SSPI предоставляет способ доступа к библиотекам динамического канала (DLL), содержащим различные функции проверки подлинности и криптографические функции. Эти библиотеки DLL называются поставщиками поддержки безопасности (SSPS).
Управляемые учетные записи служб и виртуальные учетные записи были представлены в Windows Server 2008 R2 и Windows 7 для обеспечения работы важных приложений, таких как Microsoft SQL Server и Internet Information Services (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 (билеты для выдачи билетов (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 (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) и беспроводные подключения.
Сведения о проверке подлинности на основе сертификатов в сети см. в разделе "Проверка подлинности и сертификаты доступа к сети".