Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Проверка подлинности Windows является краеугольным камнем безопасного доступа в корпоративных средах, что позволяет пользователям и службам взаимодействовать с системами при защите конфиденциальной информации. В этой статье содержатся подробные сведения о том, как Windows обрабатывает учетные данные во время проверки подлинности. Он охватывает ключевые компоненты, механизмы и архитектуры, участвующие в управлении учетными данными, проверке и хранении, обеспечивая четкое понимание процесса проверки подлинности в различных операционных системах Windows.
В частности, эти компоненты рассматриваются:
Обзор проверки подлинности учетных данных Windows
Управление учетными данными Windows — это процесс, с помощью которого операционная система получает учетные данные от службы или пользователя и защищает эти сведения для будущей презентации в целевом объекте проверки подлинности. Если компьютер присоединен к домену, то целевой объект проверки подлинности является контроллером домена. Учетные данные, используемые в проверке подлинности, — это цифровые документы, которые связывают удостоверение пользователя с определенной формой проверки подлинности, например сертификатом, паролем или ПИН-кодом.
По умолчанию учетные данные Windows проверяются в базе данных диспетчера учетных записей безопасности (SAM) на локальном компьютере или active Directory на присоединенном к домену компьютере с помощью службы Winlogon. Учетные данные собираются с помощью входных данных пользователя в пользовательский интерфейс входа или программным способом с помощью интерфейса программирования приложения (API), который будет представлен целевому объекту проверки подлинности.
Сведения о локальной безопасности хранятся в реестре в разделе HKEY_LOCAL_MACHINE\SECURITY. Хранимая информация включает параметры политики, значения безопасности по умолчанию и сведения об учетной записи, такие как кэшированные учетные данные для входа. Копия базы данных SAM также хранится здесь, хотя она защищена от записи.
На следующей схеме показаны необходимые компоненты и пути, которые учетные данные принимают через систему для проверки подлинности пользователя или процесса для успешного входа.
В следующей таблице описывается каждый компонент, который управляет учетными данными в процессе проверки подлинности в точке входа во все системы.
| Component | 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, следующие:
|
samsrv.dll |
Диспетчер учетных записей безопасности (SAM), в котором хранятся локальные учетные записи безопасности, применяет локальные хранимые политики и поддерживает API. |
| Registry | Реестр содержит копию базы данных SAM, параметры локальной политики безопасности, значения безопасности по умолчанию и сведения об учетной записи, доступные только системе. |
Учетные данные для входа пользователя
Архитектура поставщика учетных данных, представленная в Windows Server 2008, является основным механизмом сбора учетных данных пользователей во время входа. Он позволяет гибко и расширяемо собирать учетные данные от пользователей, таких как пароли, смарт-карты или биометрические данные. Архитектура поставщика учетных данных заменяет старую архитектуру графической идентификации и проверки подлинности (GINA), используемую в более ранних версиях Windows.
Чтобы узнать об архитектуре графической идентификации и проверки подлинности (GINA) в более ранних версиях Windows, разверните этот раздел.
Архитектура графической идентификации и проверки подлинности (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 всегда запускает пользовательский интерфейс входа в процесс после получения события последовательности безопасного внимания. Пользовательский интерфейс входа запрашивает у каждого поставщика учетных данных количество различных типов учетных данных, для которых настроено перечисление. Поставщики учетных данных могут указать одну из этих плиток в качестве стандартной. Когда все поставщики перечисляют свои плитки, пользовательский интерфейс входа отображает их пользователю. Пользователь взаимодействует с плиткой для предоставления учетных данных. Пользовательский интерфейс входа отправляет эти учетные данные для проверки подлинности.
Поставщики учетных данных не являются механизмами принудительного контроля; они используются для сбора и сериализации учетных данных. Локальный центр безопасности и пакеты проверки подлинности обеспечивают безопасность.
Поставщики учетных данных зарегистрированы на компьютере и отвечают за следующие задачи:
Описание сведений о учетных данных, необходимых для проверки подлинности.
Управление взаимодействием и логической структурой с внешними органами проверки подлинности.
Упаковка учетных данных для интерактивного и сетевого входа.
Упаковка учетных данных для интерактивного и сетевого входа включает процесс сериализации. Сериализуя учетные данные, для пользователя можно отобразить несколько плиток входа. Таким образом, ваша организация может управлять интерфейсом входа, таким как пользователи, целевые системы для входа, доступ к сети до входа в систему, а также политиками блокировки и разблокировки рабочих станций, с помощью настраиваемых поставщиков удостоверений. Несколько поставщиков учетных данных могут сосуществовать на одном компьютере. Поставщики единого входа (SSO) могут быть разработаны как стандартный поставщик учетных данных или как поставщик доступа предварительного входа (PLAP).
Каждая версия Windows содержит один поставщик учетных данных по умолчанию и один поставщик доступа перед входом по умолчанию, также известный как поставщик единого входа. Поставщик единого входа позволяет пользователям подключиться к сети перед входом на локальный компьютер. При реализации этого поставщика поставщик не перечисляет плитки в пользовательском интерфейсе входа.
Провайдер SSO предназначен для использования в следующих сценариях:
Проверка подлинности сети и вход на компьютер обрабатываются различными поставщиками учетных данных, включая следующие варианты этого сценария:
У пользователя есть возможность подключения к сети, например подключение к виртуальной частной сети (VPN), перед входом на компьютер, но не требуется для этого подключения.
Для получения сведений, используемых во время интерактивной проверки подлинности на локальном компьютере, требуется проверка подлинности сети.
За несколькими сетевыми проверками подлинности следует один из других сценариев. Например, пользователь проходит проверку подлинности в поставщике услуг Интернета (ISP), выполняет проверку подлинности в VPN, а затем использует учетные данные учетной записи пользователя для локального входа.
Кэшированные учетные данные отключены, и для аутентификации пользователя требуется установить подключение к службам удаленного доступа через VPN перед локальным входом в систему.
У пользователя домена нет локальной учетной записи, настроенной на компьютере, присоединенном к домену, и необходимо установить подключение служб удаленного доступа через VPN-подключение перед завершением интерактивного входа.
Проверка подлинности сети и вход на компьютер обрабатываются тем же поставщиком учетных данных, где пользователю требуется подключиться к сети перед входом на компьютер.
Перечисление элементов входа
Поставщик учетных данных перечисляет логон плитки в следующих случаях:
Для входа на рабочую станцию. Поставщик учетных данных обычно сериализует учетные данные для проверки подлинности в локальном органе безопасности. В этом процессе отображаются плитки, относящиеся к каждому пользователю и относящиеся к целевым системам каждого пользователя.
Архитектура входа и проверки подлинности позволяет пользователю использовать плитки, перечисленные поставщиком учетных данных для разблокировки рабочей станции. Как правило, текущий пользователь является пользователем по умолчанию, но если в систему вошли несколько пользователей, отображаются плитки.
Поставщик учетных данных перечисляет плитки в ответ на запрос пользователя, чтобы изменить пароль или другую частную информацию, например ПИН-код. Как правило, текущий пользователь является пользователем по умолчанию, но если в систему вошли несколько пользователей, отображаются плитки.
Поставщик учетных данных перечисляет элементы на основе сериализованных учетных данных, которые будут использоваться для проверки подлинности на компьютерах по сети. Пользовательский интерфейс учетных данных не использует тот же экземпляр поставщика, что и пользовательский интерфейс входа, разблокировку рабочей станции или изменение пароля. Поэтому сведения о состоянии не могут храниться в поставщике между экземплярами пользовательского интерфейса учетных данных. Эта структура приводит к тому, что для каждого сеанса удаленного входа создается одна плитка, при условии корректной сериализации учетных данных. Этот сценарий также используется в области контроля учетных записей пользователей (UAC), что может помочь предотвратить несанкционированные изменения на компьютере, запрашивая пользователю разрешение или пароль администратора, прежде чем разрешать действия, которые могут повлиять на операцию компьютера или изменить параметры, влияющие на других пользователей компьютера.
Вход учетных данных для входа в систему приложений и служб
Проверка подлинности Windows предназначена для управления учетными данными для приложений или служб, которые не требуют взаимодействия с пользователем. Приложения в пользовательском режиме ограничены с точки зрения того, к каким системным ресурсам у них есть доступ, а службы могут иметь неограниченный доступ к системной памяти и внешним устройствам.
Системные службы и приложения уровня транспорта получают доступ к поставщику поддержки безопасности (SSP) через интерфейс поставщика поддержки безопасности (SSPI) в Windows, который предоставляет функции для перечисления пакетов безопасности, доступных в системе, выбора пакета и использования этого пакета для получения аутентифицированного подключения.
При проверке подлинности подключения клиента или сервера:
Приложение на стороне клиента подключения отправляет учетные данные серверу с помощью функции
InitializeSecurityContext (General)SSPI.Приложение на стороне сервера подключения реагирует на функцию
AcceptSecurityContext (General)SSPI.Функции SSPI
InitializeSecurityContext (General)и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, такими как сетевые и печатные службы, когда пользователь запускает компьютер. Эти службы могут выполняться как локальная служба или локальная система и могут продолжать выполняться после выхода последнего человека-пользователя.
Note
Службы обычно выполняются в контекстах безопасности, известных как локальная система (SYSTEM), сетевая служба или локальная служба. Windows Server 2008 R2 представила службы, которые выполняются под управляемой учетной записью службы, которые являются субъектами домена.
Перед запуском службы контроллер службы входит в систему с помощью учетной записи, назначенной для службы, а затем предоставляет учетные данные службы для проверки подлинности с помощью LSA. Служба Windows реализует программный интерфейс, который диспетчер контроллеров служб может использовать для управления службой. Служба Windows может запускаться автоматически при запуске системы или вручную с помощью программы управления службами. Например, когда клиентский компьютер Windows присоединяется к домену, служба messenger на компьютере подключается к контроллеру домена и открывает к нему безопасный канал. Чтобы получить прошедшее проверку подлинности подключение, служба должна иметь учетные данные, которыми доверяет локальный центр безопасности удаленного компьютера (LSA). При взаимодействии с другими компьютерами в сети LSA использует учетные данные для учетной записи домена локального компьютера, как и все остальные службы, работающие в контексте безопасности локальной системы и сетевой службы. Службы на локальном компьютере выполняются от имени SYSTEM, поэтому учетные данные не нужно передавать в LSA.
Файл ksecdd.sys управляет и шифрует эти учетные данные и использует локальный вызов процедуры в LSA. Тип файла — DRV (driver) и называется поставщиком поддержки безопасности в режиме ядра (SSP) и соответствует стандарту FIPS 140-2 уровня 1 , начиная с Windows Server 2008.
Режим ядра имеет полный доступ к аппаратным и системным ресурсам компьютера. Режим ядра останавливает службы и приложения пользовательского режима от доступа к критически важным областям операционной системы, к которым они не должны иметь доступа.
Локальная система безопасности
Локальный центр безопасности (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 с сохраненными учетными данными LSA создаются при выполнении пользователем любого из следующих действий:
Вход в локальный сеанс или сеанс через протокол удаленного рабочего стола (RDP) на компьютере.
Выполняет задачу с помощью параметра RunAs .
Запускает активную службу Windows на компьютере.
Выполняет запланированную задачу или пакетное задание.
Выполняет задачу на локальном компьютере с помощью средства удаленного администрирования.
В некоторых случаях секреты LSA, которые являются секретными фрагментами данных, доступными только для процессов учетной записи SYSTEM, хранятся на жестком диске. Некоторые из этих секретов — это учетные данные, которые должны сохраняться после перезагрузки, и они хранятся в зашифрованной форме на жестком диске. Учетные данные, хранящиеся в виде секретов LSA, могут включать:
Пароль для учетной записи службы доменных Active Directory (AD DS) на компьютере.
Пароли учетных записей для служб Windows, настроенных на компьютере.
Пароли учетных записей для настроенных запланированных задач.
Пароли учетных записей для пулов приложений IIS и веб-сайтов.
Пароли для учетных записей Майкрософт.
Операционная система клиента Windows обеспечивает дополнительную защиту для LSA, чтобы предотвратить чтение памяти и внедрения кода незащищенными процессами, которые появились в Windows 8.1. Эта защита повышает безопасность учетных данных, которые хранятся и управляются LSA.
Дополнительные сведения об этих дополнительных защитах см. в разделе "Настройка дополнительной защиты LSA".
Кэшированные учетные данные и проверка
Механизмы проверки зависят от представления учетных данных во время входа. Однако, если компьютер отключен от контроллера домена, а пользователь представляет учетные данные домена, Windows использует процесс кэшированных учетных данных в механизме проверки.
Каждый раз, когда пользователь входит в домен, Windows кэширует предоставленные учетные данные и сохраняет их в кусте безопасности в реестре операционной системы. С помощью кэшированных учетных данных пользователь может войти в член домена без подключения к контроллеру домена в этом домене.
Хранилище учетных данных и проверка
Не всегда желательно использовать один набор учетных данных для доступа к разным ресурсам. Например, администратор может использовать административные, а не учетные данные пользователя при доступе к удаленному серверу. Аналогичным образом, если пользователь обращается к внешним ресурсам, таким как банковский счет, он может использовать только учетные данные, отличные от учетных данных домена.
Процессы учетных данных удаленного входа
Протокол удаленного рабочего стола (RDP) управляет учетными данными пользователя, который подключается к удаленному компьютеру с помощью клиента удаленного рабочего стола, который появился в Windows 8. Учетные данные в виде обычного текста отправляются на целевой сервер, где он пытается выполнить процесс аутентификации и, если он проходит успешно, подключает пользователя к разрешенным ресурсам. RDP не сохраняет учетные данные на клиенте, но учетные данные домена пользователя хранятся в LSASS.
Режим ограниченного администратора обеспечивает дополнительную безопасность для сценариев удаленного входа, которые появились в Windows Server 2012 R2 и Windows 8.1. Этот режим удаленного рабочего стола приводит к тому, что клиентское приложение будет выполнять вызов входа в сеть с помощью односторонней функции NT (NTOWF) или использовать билет службы Kerberos при проверке подлинности на удаленном узле. После проверки подлинности администратора у администратора нет соответствующих учетных данных учетной записи в LSASS, так как они не были предоставлены удаленному узлу. Вместо этого администратор имеет учетные данные учетной записи компьютера для сеанса. Учетные данные администратора не предоставляются удаленному узлу, поэтому действия выполняются в качестве учетной записи компьютера. Ресурсы также ограничены учетной записью компьютера, а администратор не может получить доступ к ресурсам с собственной учетной записью.
Процесс автоматического перезапуска учетных данных для входа
При входе пользователя LSA сохраняет учетные данные пользователя в зашифрованной памяти, доступной только LSASS.exe, которая появилась в Windows 8.1. Когда Обновление Windows инициирует автоматическую перезагрузку без присутствия пользователя, эти учетные данные используются для настройки автоматического входа.
При перезапуске пользователь автоматически войдет в систему через механизм автологона, а затем компьютер также заблокирован для защиты сеанса пользователя. Блокировка инициируется с помощью Winlogon, а управление учетными данными выполняется LSA. Автоматическое выполнение входа и блокировки сессии пользователя на консоли обеспечивает перезапуск и доступность приложений на экране блокировки.
Подробную информацию об ARSO см. в разделе Автоматический повторный вход в систему Winlogon (ARSO).
Windows Vault и Диспетчер учетных данных
Диспетчер учетных данных — это функция панели управления для хранения имен пользователей и паролей и управления ими, которая появилась в Windows Server 2008 R2 и Windows 7. Диспетчер учетных данных позволяет пользователям хранить учетные данные, относящиеся к другим системам и веб-сайтам в защищенном хранилище Windows.
Пользователи могут сохранять и хранить учетные данные из поддерживаемых браузеров и приложений 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.
Чтобы создать сертификат, данные проверки подлинности проходят через хэш-алгоритмы, такие как безопасный хэш-алгоритм (SHA), чтобы создать дайджест сообщений. Затем дайджест сообщения подписывается цифровой подписью с помощью закрытого ключа отправителя, чтобы доказать, что отправитель создал дайджест сообщения.
Аутентификация по смарт-карте
Технология смарт-карты — это пример проверки подлинности на основе сертификатов. Вход в сеть с помощью смарт-карты обеспечивает надежную форму проверки подлинности, так как он использует идентификацию на основе шифрования и подтверждение владения при проверке подлинности пользователя в домене. Службы сертификатов Active Directory (AD CS) предоставляют идентификацию на основе шифрования путем выдачи сертификата входа для каждой смарт-карты.
Технология виртуальной смарт-карты появилась в Windows 8. Он хранит сертификат смарт-карты на компьютере, а затем защищает его с помощью микросхемы безопасности доверенного платформенного модуля (TPM) устройства. Таким образом, компьютер фактически становится смарт-картой, которая должна получать ПИН-код пользователя для проверки подлинности.
Сведения о проверке подлинности смарт-карт см. в техническом справочнике по Windows Smart Card.
Удаленная и беспроводная проверка подлинности
Удаленная и беспроводная проверка подлинности сети — это другая технология, которая использует сертификаты для проверки подлинности. Служба проверки подлинности в интернете (IAS) и серверы виртуальных частных сетей используют расширяемый протокол проверки подлинности с защитой транспортного уровня (EAP-TLS), защищённый расширяемый протокол проверки подлинности (PEAP) или защиту интернет-протокола (IPsec) для выполнения проверки подлинности на основе сертификатов для многих типов сетевого доступа, включая виртуальные частные сети (VPN) и беспроводные подключения.
Сведения о проверке подлинности на основе сертификатов в сети см. в разделе "Проверка подлинности и сертификаты доступа к сети".