Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом справочном обзоре описаны основные понятия, на которых основана проверка подлинности Windows.
Проверка подлинности — это процесс проверки удостоверения объекта или пользователя. Когда вы проверяете объект, цель заключается в подтверждении его подлинности. При проверке подлинности человека цель — убедиться, что человек не является самозванцем.
В сетевом контексте аутентификация — это процесс подтверждения личности для сетевого приложения или ресурса. Как правило, удостоверение подтверждается криптографической операцией, которая использует только ключ, который знает только пользователь (как с криптографией открытого ключа) или общим ключом. Во время обмена аутентификационной информацией на стороне сервера подписанные данные сравниваются с известным криптографическим ключом для подтверждения попытки аутентификации.
Благодаря тому что криптографические ключи хранятся в безопасном центральном местоположении, процесс проверки подлинности можно масштабировать и поддерживать. Active Directory — это рекомендуемая технология и по умолчанию для хранения сведений об удостоверениях, включая криптографические ключи, которые являются учетными данными пользователя. Служба каталогов Active Directory необходима для реализаций NTLM и Kerberos по умолчанию.
Методы проверки подлинности варьируются от простого входа в операционную систему или службу или приложение, которое определяет пользователей на основе того, что знает только пользователь, например пароль, и до более мощных механизмов безопасности, использующих такие средства, как маркеры, сертификаты открытого ключа, изображения или биологические атрибуты. В бизнес-среде пользователи могут открывать множество приложений на различных типах серверов из одного или многих местоположений. Поэтому проверка подлинности должна поддерживать среды для других платформ и других операционных систем Windows.
Проверка подлинности и авторизация: аналогия путешествия
Аналогия путешествия может помочь объяснить, как работает проверка подлинности. Некоторые подготовительные задачи, как правило, необходимы для начала пути. Путешественник должен доказать свою истинную личность своим хозяевам власти. Это доказательство может быть в виде подтверждения гражданства, места рождения, личного ваучера, фотографий или того, что требуется в соответствии с законом принимающей страны. Удостоверение путешественника проверяется путем выдачи паспорта, который аналогичен системной учетной записи, выданной организацией и администрируемой субъектом безопасности. Паспорт и предполагаемое назначение основаны на наборе правил и правил, выданных государственным органом.
Путешествие
Когда путешественник прибывает на международную границу, пограничный охранник запрашивает учетные данные, и путешественник представляет свой паспорт. Процесс двухэтапный.
Охранник подтверждает подлинность паспорта, проверяя, что он был выдан органом безопасности, которому доверяют местные власти (доверяющему, по крайней мере, выдачу паспортов), и убедившись, что паспорт не был изменен.
Охранник проходит проверку подлинности путешественника, убедившись, что лицо соответствует лицу человека, изображенного на паспорте, и что другие необходимые учетные данные находятся в хорошем порядке.
Если паспорт является действительным, и путешественник оказывается его владельцем, проверка подлинности успешна, и путешественник может быть разрешен доступ через границу.
Транзитивное доверие между органами безопасности является основой проверки подлинности; Тип проверки подлинности, который происходит на международной границе, основан на доверии. Местное правительство не знает путешественника, но оно доверяет, что принимающее правительство знает. Когда принимающее правительство выпустило паспорт, он тоже не знал путешественника. Оно доверяет агентству, которое выпустило сертификат о рождении или другую документацию. Агентство, выдавающее сертификат о рождении, в свою очередь, доверяет врачу, который подписал сертификат. Врач присутствовал при рождении путешественника и заверил сертификат, подтверждая личность отпечатком стопы новорожденного. Доверие, которое передается таким образом через доверенных посредников, является транзитивным.
Транзитивное доверие является основой сетевой безопасности в архитектуре клиента или сервера Windows. Отношения доверия передаются по всему набору доменов, например в дереве домена, и формируют связь между доменом и всеми доменами, которым доверяет этот домен. Например, если домен A имеет транзитное доверие с доменом B, и если домен B доверяет домену C, то домен A доверяет домену C.
Существует разница между проверкой подлинности и авторизацией. При проверке подлинности система доказывает, что вы являетесь тем, кто вы говорите, что вы. При авторизации система проверяет, есть ли у вас права на то, что вы хотите сделать. Чтобы развить аналогию с границей, простая проверка того, что путешественник является надлежащим владельцем действительного паспорта, не обязательно дает разрешение путешественнику на въезд в страну. Жители определенной страны могут въезжать в другую страну, просто предъявляя паспорт, только в тех случаях, когда принимающая страна предоставляет неограниченное разрешение на въезд всем гражданам той страны.
Аналогичным образом можно предоставить всем пользователям разрешения на доступ к ресурсу из определенного домена. Любой пользователь, принадлежащий этому домену, имеет доступ к ресурсу, так же как Канада позволяет гражданам США въехать в Канаду. Тем не менее, граждане США, пытающиеся въехать в Бразилию или Индию, находят, что они не могут входить в эти страны только путем представления паспорта, так как оба из этих стран требуют посещения граждан США, чтобы иметь действительную визу. Таким образом, проверка подлинности не гарантирует доступ к ресурсам или авторизации для использования ресурсов.
Подтверждение компетенции
Внимание
Когда пользователь осуществляет локальный вход, его учетные данные проверяются локально с кэшированной копией перед подтверждением подлинности с помощью поставщика удостоверений через сеть. Если проверка кэша выполнена успешно, пользователь получает доступ к рабочему столу, даже если устройство находится в автономном режиме. Однако, если пользователь изменяет пароль в облаке, кэшированный проверяющий объект не обновляется, это означает, что он по-прежнему может получить доступ к локальному компьютеру с помощью старого пароля.
Паспорт и, возможно, связанные визы являются принятыми учетными данными для путешественника. Однако эти учетные данные могут не позволить путешественнику входить или получать доступ ко всем ресурсам в стране. Например, для участия в конференции требуются дополнительные документы. В Windows учетные данные можно управлять, чтобы владельцы учетных записей могли получать доступ к ресурсам по сети без многократного предоставления учетных данных. Этот тип доступа позволяет пользователям проходить проверку подлинности один раз системой для доступа ко всем приложениям и источникам данных, которым они разрешены использовать без ввода другого идентификатора учетной записи или пароля. Платформа Windows пользуется возможностью использовать единую пользовательскую идентификацию (поддерживаемую Active Directory) в сети, путем локального кэширования учетных данных пользователя в Локальной службе безопасности (LSA) операционной системы. Когда пользователь входит в домен, проверка подлинности Windows пакеты прозрачно используют учетные данные для предоставления единого входа при проверке подлинности учетных данных в сетевых ресурсах. Дополнительные сведения об учетных данных см. в разделе "Процессы учетных данных в проверке подлинности Windows".
Форма многофакторной проверки подлинности для путешественника может предполагать необходимость иметь при себе и предъявлять несколько документов для удостоверения личности, таких как паспорт и информация о регистрации на конференцию. Windows реализует эту форму или проверку подлинности с помощью смарт-карт, виртуальных смарт-карт и биометрических технологий.
Субъекты безопасности и учетные записи
В Windows любой пользователь, служба, группа или компьютер, который может инициировать действие, является субъектом безопасности. Субъекты безопасности имеют учетные записи, которые могут быть локальными для компьютера или на основе домена. Например, компьютеры, присоединенные к домену клиента Windows, могут участвовать в сетевом домене, взаимодействуя с контроллером домена, даже если пользователь не вошел в систему. Чтобы инициировать обмен данными, компьютер должен иметь активную учетную запись в домене. Прежде чем принимать сообщения от компьютера, локальная служба безопасности на контроллере домена проверяет подлинность удостоверения компьютера и затем определяет контекст безопасности компьютера так же, как для человеческого субъекта безопасности. Этот контекст безопасности определяет удостоверение и возможности пользователя или службы на определенном компьютере, службе, группе или компьютере в сети. Например, он определяет ресурсы, например общую папку или принтер, к которым можно получить доступ, а также действия, такие как чтение, запись или изменение, которые могут выполняться пользователем, службой или компьютером на этом ресурсе. Дополнительные сведения см. в разделе "Субъекты безопасности".
Учетная запись — это средство для идентификации истца-пользователя или службы, запрашивающего доступ или ресурсы. Путешественник, имеющий подлинный паспорт, обладает учетной записью с принимающей страной. Пользователи, группы пользователей, объектов и служб могут иметь отдельные учетные записи или общие учетные записи. Учетные записи могут состоять в группах и могут получать определенные права и разрешения. Учетные записи могут быть ограничены локальным компьютером, рабочей группой, сетью или назначать членство в домене.
Встроенные учетные записи и группы безопасности, из которых они являются членами, определяются в каждой версии Windows. С помощью групп безопасности можно назначить одинаковые разрешения безопасности многим пользователям, успешно прошедшим проверку подлинности, что упрощает администрирование доступа. Для выдачи паспортов может потребоваться, чтобы путешественник был назначен определенным группам, таким как бизнес, или турист, или правительство. Этот процесс обеспечивает согласованные разрешения безопасности для всех членов группы. С помощью групп безопасности для назначения разрешений управление доступом ресурсов остается постоянным и простым для управления и аудита. Добавляя и удаляя пользователей, которым требуется доступ из соответствующих групп безопасности, можно свести к минимуму частоту изменений списков управления доступом (ACL).
Автономные управляемые учетные записи служб и виртуальные учетные записи были представлены в Windows Server 2008 R2 и Windows 7 для предоставления необходимым приложениям, таким как Microsoft Exchange Server и IIS, возможности изоляции их собственных доменных учетных записей, исключая необходимость ручного администрирования имени основной службы (SPN) и учетных данных этих учетных записей. Учетные записи управляемых служб групп появились в Windows Server 2012 и предоставляют одинаковые функциональные возможности в домене, но также расширяют эту функцию на нескольких серверах. При подключении к службе, размещенной на ферме серверов, например, к службе балансировки сетевой нагрузки, протоколы аутентификации, поддерживающие взаимную проверку подлинности, требуют, чтобы всеми экземплярами служб использовался один и тот же субъект.
Дополнительные сведения об учетных записях см. в следующем разделе:
Делегированная аутентификация
Чтобы использовать аналогию с путешествием, страны могут предоставлять одинаковый доступ всем членам официальной правительственной делегации при условии, что делегаты хорошо известны. Это делегирование позволяет одному участнику действовать под авторитетом другого участника. В Windows делегированная проверка подлинности возникает, когда сетевая служба принимает запрос проверки подлинности от пользователя и предполагает удостоверение этого пользователя, чтобы инициировать новое подключение ко второй сетевой службе. Для поддержки делегированной проверки подлинности необходимо установить внешний или первый уровень серверы, такие как веб-серверы, которые отвечают за обработку запросов на проверку подлинности клиента и серверных или n-уровневых серверов, таких как большие базы данных, которые отвечают за хранение информации. Вы можете делегировать право на настройку делегированной проверки подлинности пользователям в организации, чтобы уменьшить административную нагрузку на администраторов.
Установив службу или компьютер как доверенный для делегирования, вы можете разрешить этой службе или компьютеру завершить делегированную проверку подлинности, получить билет для пользователя, выполняющего запрос, а затем получить доступ к данным для этого пользователя. Эта модель ограничивает доступ к данным на внутренних серверах только тем пользователям или службам, которые представляют учетные данные с правильными маркерами управления доступом. Кроме того, он позволяет выполнять аудит доступа к этим внутренним ресурсам. Требуя доступа ко всем данным с помощью учетных данных, делегированных серверу для использования от имени клиента, необходимо убедиться, что сервер не может быть скомпрометирован и что вы можете получить доступ к конфиденциальной информации, хранящейся на других серверах. Делегированная проверка подлинности полезна для многоуровневых приложений, предназначенных для использования возможностей единого входа на нескольких компьютерах.
Проверка подлинности в отношениях доверия между доменами
Большинство организаций с несколькими доменами имеют законную потребность пользователей в доступе к общим ресурсам, расположенным в другом домене, так же, как путешественник может путешествовать по разным регионам в стране. Для управления этим доступом требуется, чтобы пользователи в одном домене также могли пройти проверку подлинности и авторизованы для использования ресурсов в другом домене. Чтобы обеспечить возможности проверки подлинности и авторизации между клиентами и серверами в разных доменах, между двумя доменами должно быть доверие. Доверие — это базовая технология, с помощью которой происходит защищенное взаимодействие Active Directory и является неотъемлемой компонентом безопасности сетевой архитектуры Windows Server.
Если между двумя доменами существует доверие, механизмы аутентификации каждого домена доверяют аутентификации, поступающей из другого домена. Доверие помогает обеспечить контролируемый доступ к общим ресурсам в домене ресурсов — доверяющем домене — проверяя, что входящие запросы аутентификации приходят из доверенного домена. Таким образом, доверительные отношения выступают в качестве мостов, которые позволяют передавать только проверенные запросы аутентификации между доменами.
Способ, которым передаются запросы на аутентификацию для конкретного доверия, зависит от того, как оно настроено. Отношения доверия могут быть односторонними, предоставляя доступ из доверенного домена к ресурсам в доверенном домене или двумя способами, предоставляя доступ из каждого домена к ресурсам в другом домене. Доверия также являются нетрансляционными, в этом случае доверие существует только между двумя доменами партнеров доверия или транзитивным, в этом случае доверие автоматически распространяется на любые другие домены, которыми доверяет любой из партнеров.
Для получения информации о том, как работают доверительные отношения, см. в разделе "Как работают доменные и лесные доверительные отношения".
Переход по протоколу
Переход протокола помогает конструкторам приложений, позволяя приложениям поддерживать различные механизмы проверки подлинности на уровне проверки подлинности пользователей и переключаясь на протокол Kerberos для функций безопасности, таких как взаимная проверка подлинности и ограниченное делегирование, на последующих уровнях приложений.
Дополнительные сведения о переходе протокола см. в разделе "Переход протокола Kerberos" и "Ограниченное делегирование".
Ограниченное делегирование
Ограниченное делегирование дает администраторам возможность указывать и применять границы доверия приложений путем ограничения области, в которой службы приложений могут действовать от имени пользователя. Можно указать определенные службы, из которых компьютер, доверенный для делегирования, может запрашивать ресурсы. Гибкость ограничения прав авторизации для служб помогает улучшить структуру безопасности приложений, уменьшая возможности компрометации ненадежными службами.
Дополнительные сведения об ограниченном делегировании см. в статье Обзор ограниченного делегирования Kerberos.