Я пытаюсь реализовать встроенную проверку подлинности Windows на Edge, но она всегда запрашивает у меня учетные данные, тогда как встроенная проверка подлинности Windows работает для IE, Chrome и Firefox. Я попытался добавить сайт в локальные сайты интрасети в параметрах безопасности и включил автоматический вход в систему, но мне не повезло в браузере Edge.
Поддерживает ли Edge встроенную проверку подлинности Windows?
Я попытался добавить сайт в локальные сайты интрасети в параметрах безопасности и включил автоматический вход в систему, а также вход с текущим именем пользователя и паролем.
4 ответа
Какую версию Microsoft Edge вы используете? Пожалуйста, проверьте следующую конфигурацию, чтобы включить встроенную проверку подлинности Windows:
- Откройте Internet Explorer и выберите раскрывающийся список « Инструменты «.
- Выберите вкладку « Дополнительно ».
- Прокрутите вниз до раздела « Безопасность », пока не увидите « Включить встроенную проверку подлинности Windows ». Установите флажок рядом с этим полем, чтобы включить.
- Выберите вкладку « Безопасность ».
- Выберите « Местная интрасеть » и нажмите кнопку « Другой » или « Расширенный ».
- Прокрутите вниз до « Аутентификация пользователя »> « Вход ».
- Установлен флажок « Автоматический вход с текущим именем пользователя и паролем ».
- На вкладке « Безопасность » выберите вариант « Местная интрасеть » и нажмите кнопку « Сайты ».
- Нажмите кнопку « Дополнительно » и добавьте свой веб-сайт в зону.
- Закройте окно и примените конфигурацию.
Если все еще не работает, я предлагаю вам отправить отзыв о своей проблеме в Microsoft Edge. форум платформы, например эта ветка.
3
TylerH
15 Июл 2019 в 18:42
Включение встроенной проверки подлинности Windows
Используйте следующую процедуру, чтобы включить автоматическую аутентификацию на каждом компьютере.
-
Откройте настройки Windows и выполните поиск в свойствах Интернета.
Откроется следующее окно.
-
Щелкните Местная интрасеть> Сайты.
-
Щелкните Advanced.
- Введите URL-адрес конкретного клиента в текстовое поле Веб-сайты.
- Нажмите Закрыть.
1
Joel Wiklund
14 Фев 2020 в 14:16
Насколько я могу судить и из того, что я прочитал, Edge не поддерживает встроенную проверку подлинности Windows; как минимум, начиная с версии 42.17134.1098.0.
0
steveareeno
23 Янв 2020 в 16:15
Это может быть из-за AuthServerAllowlist. Вы можете проверить свою политику на edge://policy/.
Указывает, какие серверы включить для встроенной проверки подлинности. Интегрированная проверка подлинности включается только тогда, когда Microsoft Edge получает запрос проверки подлинности от прокси-сервера или сервера из этого списка.
[…]
Если вы не настроите эту политику, Microsoft Edge попытается определить, находится ли сервер в интрасети — только тогда он будет отвечать на запросы IWA. Если сервер находится в Интернете, запросы IWA от него игнорируются Microsoft Edge.
Как указано в документации; если ваш сервер / сайт не включен в список AuthServerAllowlist и Edge не может идентифицировать ваш сайт как сайт интрасети, Edge не будет использовать встроенную проверку подлинности Windows.
2
smoksnes
21 Окт 2021 в 08:02
| title | ms.author | author | manager | ms.date | audience | ms.topic | ms.prod | ms.localizationpriority | ms.collection | description |
|---|---|---|---|---|---|---|---|---|---|---|
|
Microsoft Edge identity support and configuration |
v-danwesley |
dan-wesley |
srugh |
08/10/2022 |
ITPro |
conceptual |
microsoft-edge |
medium |
M365-modern-desktop |
Microsoft Edge identity support and configuration |
Microsoft Edge identity support and configuration
This article describes how Microsoft Edge uses identity to support features such as sync and single sign-on (SSO). Microsoft Edge supports signing in with Active Directory Domain Services (AD DS), Azure Active Directory (Azure AD), and Microsoft accounts (MSA). Currently, Microsoft Edge only supports Azure Active Directory (Azure AD) accounts belonging to the global cloud or the GCC sovereign cloud. We’re working on adding support for other sovereign clouds.
[!NOTE]
This applies to Microsoft Edge version 77 or later.
Browser sign-in and authenticated features
Microsoft Edge supports signing into a browser profile with an Azure AD, MSA, or a domain account. The type of account used for sign-in determines which authenticated features are available for the user in Microsoft Edge. The following table summarizes the feature support for each type of account.
| Feature | Azure AD Premium | Azure AD Free | On-premises AD DS | MSA |
|---|---|---|---|---|
| Sync | Yes | No | No | Yes |
| SSO with Primary Refresh Token | Yes | Yes | No | Yes |
| Seamless SSO | Yes | Yes | Yes | N/A |
| Integrated Windows Authentication | Yes | Yes | Yes | N/A |
| Enterprise New tab page | Requires O365 | Requires O365 | No | N/A |
| Microsoft Search | Requires O365 | Requires O365 | No | N/A |
How users can sign into Microsoft Edge
Automatic sign-in
Microsoft Edge uses the OS default account to auto sign into the browser. Depending on how a device is configured, users can get auto signed into Microsoft Edge using one of the following approaches.
- The device is hybrid/AAD-J: Available on Win10, down-level Windows, and corresponding server versions.
The user gets automatically signed in with their Azure AD account. - The device is domain joined: Available on Win10, down-level Windows, and corresponding server versions.
By default, the user won’t get automatically signed in. If you want to automatically sign in users with domain accounts, use the ConfigureOnPremisesAccountAutoSignIn policy. If you want to automatically sign in users with their Azure AD accounts, consider hybrid joining your devices. - OS default account is MSA: Win10 RS3 (Version 1709/Build 10.0.16299) and above. This scenario is unlikely on enterprise devices. But, if the OS default account is MSA, Microsoft Edge will sign in automatically with the MSA account.
Manual sign-in
If the user doesn’t get automatically signed into Microsoft Edge, they can manually sign into Microsoft Edge during the first run experience, browser settings, or by opening the identity flyout.
Managing browser sign-in
If you want to manage browser sign-in, you can use the following policies:
- Ensure that users always have a work profile on Microsoft Edge. See NonRemovableProfileEnabled
- Restrict sign-in to a trusted set of accounts. See RestrictSigninToPattern
- Disable or force browser sign-in. See BrowserSignin
Browser to Web Single Sign-On (SSO)
On some platforms, you can configure Microsoft Edge to automatically sign into websites for your users. This option saves them the trouble of reentering their credentials to access their work websites and increases their productivity.
SSO with Primary Refresh Token (PRT)
Microsoft Edge has native support for PRT-based SSO, and you don’t need an extension. On Windows 10 RS3 and above, if a user is signed into their browser profile, they’ll get SSO with the PRT mechanism to websites that support PRT-based SSO.
A Primary Refresh Token (PRT) is an Azure AD key that’s used for authentication on Windows 10, iOS, and Android devices. It enables single sign-on (SSO) across the applications used on those devices. For more information, see What is a Primary Refresh Token?.
Seamless SSO
Just like PRT SSO, Microsoft Edge has native Seamless SSO support without needing an extension. On Windows 10 RS3 and above, if a user is signed into their browser profile, they’ll get SSO with the PRT mechanism to websites that support PRT-based SSO.
Seamless Single Sign-On automatically signs users in when they’re on corporate devices connected to a corporate network. When enabled, users don’t need to type in their passwords to sign in to Azure AD. Typically they don’t even have to type in their usernames. For more information, see Active Directory Seamless Single Sign-On.
Windows Integrated Authentication (WIA)
Microsoft Edge also supports Windows Integrated Authentication for authentication requests within an organization’s internal network for any application that uses a browser for its authentication. This is supported on all versions of Windows 10 and down-level Windows. By default, Microsoft Edge uses the intranet zone as an allowlist for WIA. Alternatively, you can customize the list of servers that are enabled for Integrated Authentication by using the AuthServerAllowlist policy. On macOS, this policy is required to enable Integrated Authentication.
To support WIA-based SSO on Microsoft Edge (version 77 and later), you might also have to do some server-side configuration. You’ll probably have to configure the Active Directory Federation Services (AD FS) property WiaSupportedUserAgents to add support for the new Microsoft Edge user agent string. For instructions on how to do this, see View WIASupportedUserAgent settings and Change WIASupportedUserAgent settings. An example of the Microsoft Edge user agent string on Windows 10 is shown below, and you can learn more about the Microsoft Edge UA string here.
The following example of a UA string is for the latest Dev Channel build when this article was published:
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3951.0 Safari/537.36 Edg/80.0.334.2"
For services that require delegating Negotiate credentials, Microsoft Edge supports Constrained Delegation using the AuthNegotiateDelegateAllowlist policy.
Additional authentication concepts
Proactive Authentication
Proactive authentication is an optimization over browser to website SSO that front loads authentication to certain first party websites. This improves address bar performance if the user is using Bing as the search engine. This gives users personalized and Microsoft Search for Business (MSB) search results. It also enables allowing authentication to key services such as the Office New Tab Page.
[!NOTE]
If you want to configure browser sign in after version 90, use the BrowserSignin policy. For Microsoft Edge version 90 or lower, you can control this service using the ProactiveAuthEnabled policy.
Windows Hello CredUI for NTLM Authentication
When a website tries to sign users in using the NTLM or Negotiate mechanisms and SSO isn’t available, we offer users an experience where they can share their OS credentials with the website to satisfy the authentication challenge using Windows Hello Cred UI. This sign-in flow will only appear for users on Windows 10 who don’t get single-sign-on during an NTLM or Negotiate challenge.
Sign in automatically using saved passwords
If a user saves passwords in Microsoft Edge, they can enable a feature that automatically logs them into websites where they have saved credentials. Users can toggle this feature by navigating to edge://settings/passwords. If you want to configure this ability, you can use the password manager policies.
See also
- Microsoft Edge Enterprise landing page
- Video: Microsoft Edge and Identity
- Identity and access management
- Identity platform
- Four steps to a strong identity foundation with Azure Active Directory
| title | ms.author | author | manager | ms.date | audience | ms.topic | ms.prod | ms.localizationpriority | ms.collection | description |
|---|---|---|---|---|---|---|---|---|---|---|
|
Microsoft Edge identity support and configuration |
v-danwesley |
dan-wesley |
srugh |
08/10/2022 |
ITPro |
conceptual |
microsoft-edge |
medium |
M365-modern-desktop |
Microsoft Edge identity support and configuration |
Microsoft Edge identity support and configuration
This article describes how Microsoft Edge uses identity to support features such as sync and single sign-on (SSO). Microsoft Edge supports signing in with Active Directory Domain Services (AD DS), Azure Active Directory (Azure AD), and Microsoft accounts (MSA). Currently, Microsoft Edge only supports Azure Active Directory (Azure AD) accounts belonging to the global cloud or the GCC sovereign cloud. We’re working on adding support for other sovereign clouds.
[!NOTE]
This applies to Microsoft Edge version 77 or later.
Browser sign-in and authenticated features
Microsoft Edge supports signing into a browser profile with an Azure AD, MSA, or a domain account. The type of account used for sign-in determines which authenticated features are available for the user in Microsoft Edge. The following table summarizes the feature support for each type of account.
| Feature | Azure AD Premium | Azure AD Free | On-premises AD DS | MSA |
|---|---|---|---|---|
| Sync | Yes | No | No | Yes |
| SSO with Primary Refresh Token | Yes | Yes | No | Yes |
| Seamless SSO | Yes | Yes | Yes | N/A |
| Integrated Windows Authentication | Yes | Yes | Yes | N/A |
| Enterprise New tab page | Requires O365 | Requires O365 | No | N/A |
| Microsoft Search | Requires O365 | Requires O365 | No | N/A |
How users can sign into Microsoft Edge
Automatic sign-in
Microsoft Edge uses the OS default account to auto sign into the browser. Depending on how a device is configured, users can get auto signed into Microsoft Edge using one of the following approaches.
- The device is hybrid/AAD-J: Available on Win10, down-level Windows, and corresponding server versions.
The user gets automatically signed in with their Azure AD account. - The device is domain joined: Available on Win10, down-level Windows, and corresponding server versions.
By default, the user won’t get automatically signed in. If you want to automatically sign in users with domain accounts, use the ConfigureOnPremisesAccountAutoSignIn policy. If you want to automatically sign in users with their Azure AD accounts, consider hybrid joining your devices. - OS default account is MSA: Win10 RS3 (Version 1709/Build 10.0.16299) and above. This scenario is unlikely on enterprise devices. But, if the OS default account is MSA, Microsoft Edge will sign in automatically with the MSA account.
Manual sign-in
If the user doesn’t get automatically signed into Microsoft Edge, they can manually sign into Microsoft Edge during the first run experience, browser settings, or by opening the identity flyout.
Managing browser sign-in
If you want to manage browser sign-in, you can use the following policies:
- Ensure that users always have a work profile on Microsoft Edge. See NonRemovableProfileEnabled
- Restrict sign-in to a trusted set of accounts. See RestrictSigninToPattern
- Disable or force browser sign-in. See BrowserSignin
Browser to Web Single Sign-On (SSO)
On some platforms, you can configure Microsoft Edge to automatically sign into websites for your users. This option saves them the trouble of reentering their credentials to access their work websites and increases their productivity.
SSO with Primary Refresh Token (PRT)
Microsoft Edge has native support for PRT-based SSO, and you don’t need an extension. On Windows 10 RS3 and above, if a user is signed into their browser profile, they’ll get SSO with the PRT mechanism to websites that support PRT-based SSO.
A Primary Refresh Token (PRT) is an Azure AD key that’s used for authentication on Windows 10, iOS, and Android devices. It enables single sign-on (SSO) across the applications used on those devices. For more information, see What is a Primary Refresh Token?.
Seamless SSO
Just like PRT SSO, Microsoft Edge has native Seamless SSO support without needing an extension. On Windows 10 RS3 and above, if a user is signed into their browser profile, they’ll get SSO with the PRT mechanism to websites that support PRT-based SSO.
Seamless Single Sign-On automatically signs users in when they’re on corporate devices connected to a corporate network. When enabled, users don’t need to type in their passwords to sign in to Azure AD. Typically they don’t even have to type in their usernames. For more information, see Active Directory Seamless Single Sign-On.
Windows Integrated Authentication (WIA)
Microsoft Edge also supports Windows Integrated Authentication for authentication requests within an organization’s internal network for any application that uses a browser for its authentication. This is supported on all versions of Windows 10 and down-level Windows. By default, Microsoft Edge uses the intranet zone as an allowlist for WIA. Alternatively, you can customize the list of servers that are enabled for Integrated Authentication by using the AuthServerAllowlist policy. On macOS, this policy is required to enable Integrated Authentication.
To support WIA-based SSO on Microsoft Edge (version 77 and later), you might also have to do some server-side configuration. You’ll probably have to configure the Active Directory Federation Services (AD FS) property WiaSupportedUserAgents to add support for the new Microsoft Edge user agent string. For instructions on how to do this, see View WIASupportedUserAgent settings and Change WIASupportedUserAgent settings. An example of the Microsoft Edge user agent string on Windows 10 is shown below, and you can learn more about the Microsoft Edge UA string here.
The following example of a UA string is for the latest Dev Channel build when this article was published:
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3951.0 Safari/537.36 Edg/80.0.334.2"
For services that require delegating Negotiate credentials, Microsoft Edge supports Constrained Delegation using the AuthNegotiateDelegateAllowlist policy.
Additional authentication concepts
Proactive Authentication
Proactive authentication is an optimization over browser to website SSO that front loads authentication to certain first party websites. This improves address bar performance if the user is using Bing as the search engine. This gives users personalized and Microsoft Search for Business (MSB) search results. It also enables allowing authentication to key services such as the Office New Tab Page.
[!NOTE]
If you want to configure browser sign in after version 90, use the BrowserSignin policy. For Microsoft Edge version 90 or lower, you can control this service using the ProactiveAuthEnabled policy.
Windows Hello CredUI for NTLM Authentication
When a website tries to sign users in using the NTLM or Negotiate mechanisms and SSO isn’t available, we offer users an experience where they can share their OS credentials with the website to satisfy the authentication challenge using Windows Hello Cred UI. This sign-in flow will only appear for users on Windows 10 who don’t get single-sign-on during an NTLM or Negotiate challenge.
Sign in automatically using saved passwords
If a user saves passwords in Microsoft Edge, they can enable a feature that automatically logs them into websites where they have saved credentials. Users can toggle this feature by navigating to edge://settings/passwords. If you want to configure this ability, you can use the password manager policies.
See also
- Microsoft Edge Enterprise landing page
- Video: Microsoft Edge and Identity
- Identity and access management
- Identity platform
- Four steps to a strong identity foundation with Azure Active Directory
В этой статья, мы рассмотрим, как настроить Kerberos аутентификацию для различных браузеров в домене Windows для прозрачной и безопасной аутентификации на веб-серверах без необходимости повторного ввода пароля в корпоративной сети. В большинстве современных браузерах (IE, Chrome, Firefox) имеется поддержка Kerberos, однако, чтобы она работала, нужно выполнить несколько дополнительных действий.
Чтобы браузер мог авторизоваться на веб-сервере, нужно, чтобы были выполнены следующие условия:
- Поддержка Kerberos должны быть включена на стороне веб-сервера (пример настройки Kerberos авторизации на сайте IIS)
- Наличие у пользователя прав доступа к серверу
- Пользователь должен быть аутентифицирован на своем компьютере в Active Directory с помощью Kerberos (должен иметь TGT — Kerberos Ticket Granting Ticket).
К примеру, мы хотим разрешить клиентам Kerberos авторизацию через браузер на всех веб серверах домена winitpro.ru (нужно использовать именно DNS или FQDN, а не IP адрес веб сервера)
Содержание:
- Настройка Kerberos аутентификации в Internet Explorer
- Включаем Kerberos аутентификацию в Google Chrome
- Настройка Kerberos аутентификации в Mozilla Firefox
Настройка Kerberos аутентификации в Internet Explorer
Рассмотрим, как включить Kerberos аутентификацию в Internet Explorer 11.
Напомним, что с января 2016 года, единственная официально поддерживаемая версия Internet Explorer – это IE 11.
Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:
- https://*.winitpro.ru
- http://*.winitpro.ru
Добавить сайты в эту зону можно с помощью групповой политики: Computer Configuration ->Administrative Templates ->Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Site to Zone Assignment. Для каждого веб-сайта нужно добавить запись со значением 1. Пример смотри в статье об отключении предупреждения системы безопасности для загруженных из интернета файлов
Далее перейдите на вкладку Дополнительно (Advanced) и в разделе Безопасность (Security) убедитесь, что включена опция Разрешить встроенную проверку подлинности Windows (Enable Integrated Windows Authentication).
Важно. Убедитесь, что веб сайты, для которых включена поддержка Kerberos аутентификации приустают только в зоне Местная интрасеть. Для сайтов, включенных в зону Надежные сайты (Trusted sites), токен Kerberos не отправляется на соответствующий веб-сервер.
Включаем Kerberos аутентификацию в Google Chrome
Чтобы SSO работала в Google Chrome, нужно настроить Internet Explorer вышеописанным способом (Chrome использует данные настройки IE). Кроме того, нужно отметить, что все новые версии Chrome автоматически определяют наличие поддержки Kerberos. В том случае, если используется одна из старых версий Chrome (Chromium), для корректной авторизации на веб-серверах с помощью Kerberos, его нужно запустить с параметрами:
--auth-server-whitelist="*.winitpro.ru"
--auth-negotiate-delegate-whitelist="*.winitpro.ru"
Например,
"C:Program Files (x86)GoogleChromeApplicationchrome.exe” --auth-server-whitelist="*.winitpro.ru" --auth-negotiate-delegate-whitelist="*.winitpro.ru"
Либо эти параметры могут быть распространены через групповые политики для Chrome (политика AuthServerWhitelist) или строковый параметр реестра AuthNegotiateDelegateWhitelist (находится в ветке HKLMSOFTWAREPoliciesGoogleChrome).
Для вступления изменений в силу нужно перезагрузить браузер и сбросить тикеты Kerberos командой klist purge (см. статью).
Настройка Kerberos аутентификации в Mozilla Firefox
По умолчанию поддержка Kerberos в Firefox отключена, чтобы включить ее, откройте окно конфигурации браузера (в адресной строке перейдите на адрес about:config). Затем в следующих параметрах укажите адреса веб-серверов, для которых должна использоваться Kerberos аутентификация.
- network.negotiate-auth.trusted-uris
- network.automatic-ntlm-auth.trusted-uris
Для удобства, можно отключить обязательное указание FQDN адреса в адресной строке Mozilla Firefox, включив параметр network.negotiate-auth.allow-non-fqdn
Проверить, что ваш браузер работает через аутентифицировался на сервере с помощью Kerberos можно с помощью Fiddler или команды klist tickets.
Когда дело доходит до аутентификации, Microsoft Edge предлагает большую безопасность. Если вы используете функцию автозаполнения кредитной карты, вы, должно быть, заметили, что Edge просит вас ввести PIN-код или пароль Windows вашей учетной записи Microsoft. Сделав еще один шаг вперед, Microsoft Edge предлагает это для каждого пароля, который вы выбираете для автозаполнения, то есть для веб-сайтов.
- Откройте Microsoft Edge и нажмите Alt + F, чтобы открыть меню.
- Нажмите «Настройки», а затем нажмите «Профили»> «Пароли».
- В разделе «Предложение сохранить пароли» найдите «Войти».
- Здесь у вас есть два варианта
- Входить в меня автоматически — если этот параметр включен, мы не будем запрашивать ваше разрешение каждый раз, когда вы входите на сайт.
- Требовать аутентификацию — если этот параметр включен, мы будем запрашивать пароль вашего компьютера перед автоматическим заполнением полей пароля.
- Опция Требовать аутентификации предлагает дальнейшую настройку —Всегда, Раз в минуту, или Раз в каждую сессию.
- Выберите то, что вам подходит.
Если вы выберете «Всегда», Microsoft Edge потребует аутентификацию для входа с паролем. Это гарантирует, что никто, у кого есть доступ к вашему профилю Edge, не сможет автоматически войти на любой веб-сайт.
Я бы рекомендовал Раз в каждую сессию вариант, чтобы частоту можно было уменьшить, но если вам нужно часто покидать рабочий стол, выберите всегда или раз в минуту. Эта функция также работает с входом в Windows Hello, например с разблокировкой по отпечатку пальца и распознаванию лица.
Эта функция аналогична тому, как Microsoft Autneticator работает на смартфонах Android. Каждый раз, когда я вхожу в систему, мне нужно вводить свой PIN-код или отпечаток пальца для проверки.
Это невероятно полезная функция, поскольку она также обеспечивает защиту ваших паролей. В вашем аккаунте хранится много информации; использование этого гарантирует безопасность. Я надеюсь, что за публикацией было легко следить, и вы смогли включить эту функцию.
Эта функция все еще распространяется, и скоро вы увидите ее в своей стабильной версии.
.
Мы рады сообщить, что в Microsoft Edge появилась поддержка спецификации Web Authentication, благодаря которой обращаться к сайтам в Интернете стало проще и безопаснее, а вводить пароли не требуется.
Web Authentication дает пользователям Microsoft Edge возможность проходить проверку подлинности с помощью сканирования лица или отпечатков пальцев, ПИН-кода или портативных устройств FIDO2, используя вместо паролей учетные данные, надежно защищенные шифрованием с открытым ключом.
Интернет без паролей
Сегодня безопасность в Интернете важнее, чем когда-либо. Мы доверяем веб-сайтам номера кредитных карт, адреса, другую личную информацию и даже конфиденциальные медицинские записи. Для защиты всех этих данных используется старая модель безопасности — пароли. Однако пароли трудно запоминать, и они небезопасны по своей сути: часто используются повторно и уязвимы к фишингу и взлому.
Поэтому Microsoft решила отказаться от паролей в пользу таких инноваций, как биометрическая аутентификация Windows Hello, и совместно с FIDO Alliance начала работу по созданию открытого стандарта беспарольной проверки подлинности — Web Authentication.
Мы начали работу над этой спецификацией в 2016 году, опубликовав первую предварительную версию API Web Authentication в Microsoft Edge. С тех пор мы обновляем спецификацию и стандартизируем ее, сотрудничая с другими производителями и консорциумом FIDO Alliance. В марте FIDO Alliance объявил, что программные интерфейсы Web Authentication получили от W3C статус Candidate Recommendation (CR), и это очень важная веха на пути к зрелой и совместимой спецификации.
Начиная со сборки 17723, Microsoft Edge поддерживает CR-версию Web Authentication. Наша реализация обеспечивает наиболее полную на сегодняшний день поддержку Web Authentication, включая поддержку большего числа средств проверки подлинности по сравнению с другими браузерами.
Windows Hello на любом устройстве Windows 10 позволяет проходить на веб-сайтах проверку подлинности без пароля, используя биометрию — распознавание лица и отпечатков пальцев — или ПИН-код. Если веб-сайт поддерживает Web Authentication, то с помощью распознавания лица в Windows Hello можно войти в систему за считанные секунды, просто взглянув в камеру.
Можно также использовать внешние ключи безопасности FIDO2, чтобы проходить проверку подлинности с помощью портативного устройства и биометрии или ПИН-кода. Для веб-сайтов, не готовых полностью отказаться от использования паролей, обратная совместимость с устройствами FIDO U2F может обеспечить надежную двухфакторную аутентификацию в дополнение к паролям.
Мы работаем с отраслевыми партнерами, освещая первые опыты по переходу на модель без использования паролей в Интернете. На конференции RSA 2018 мы показали, как эти API можно использовать для повышения безопасности платежей с помощью распознавания лица. Такие способы проверки подлинности — основа для перехода к миру без паролей.
Начало работы
Мы рады передать нашу реализацию в руки независимых разработчиков и с нетерпением ждем, чтобы увидеть созданные ими продукты. Чтобы начать использовать Web Authentication в Microsoft Edge, изучите дополнительную информацию в руководстве разработчика Web Authentication или установите сборку 17723 Windows Insider Preview (или более позднюю), чтобы проверить все на собственном опыте!
Содержание
- Предварительная подготовка
- Процедура
- Exchange Server 2007 с пакетом обновления 1 (SP1)
- Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью консоли управления Exchange
- Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью среды управления Exchange
- Окончательная первоначальная (RTM) версия сервера Exchange Server 2007
- Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью консоли управления Exchange
- Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью среды управления Exchange
- Дополнительные сведения
- IIS — О проверке подлинности
- Методы для WWW
- Методы для FTP
- Анонимная проверка подлинности
- Обычная проверка подлинности
- Краткая проверка подлинности
- Встроенная проверка подлинности
- Проверка подлинности по сертификату
- Сопоставление сертификатов клиента
- Проверка подлинности для FTP
- Анонимная проверка подлинности для FTP
- Обычная проверка подлинности для FTP
Предварительная подготовка
Предварительная подготовкаДля выполнения описанных ниже действий используемой учетной записи необходимо делегировать роль администратора сервера Exchange и членство в локальной группе администраторов целевого сервера.
Дополнительные сведения о разрешениях, делегировании ролей и правах, необходимых для администрирования Exchange 2007, см. в разделе Вопросы, связанные с разрешениями.
Конкретные действия, производимые при выполнении этой процедуры с использованием консоли управления Exchange, зависят от следующих факторов:
- от используемой версии сервера Exchange 2007: окончательная первоначальная (RTM) версия Exchange 2007 или Exchange 2007 с пакетом обновления 1 (SP1);
от того, установлена ли роль сервера почтовых ящиков на компьютере, на котором установлена роль сервера клиентского доступа.
Процедура
Exchange Server 2007 с пакетом обновления 1 (SP1)
Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью консоли управления Exchange
В консоли управления Exchange перейдите к виртуальному каталогу, который необходимо настроить на использование встроенной проверки подлинности Windows с использованием сведений, приведенных в действии 2 или в действии 3.
Если на компьютере с установленной ролью сервера клиентского доступа также установлена роль сервера почтовых ящиков, выполните одно из указанных ниже действий.
- Чтобы изменить виртуальный каталог Exchange 2007 выберите пункты Настройка серверов и Клиентский доступ, а затем откройте вкладку Outlook Web Access. Виртуальный каталог Exchange 2007 по умолчанию — /owa.
Чтобы изменить виртуальный каталог предыдущей версии, выберите пункты Настройка серверов, Сервер почтовых ящиков и откройте вкладку WebDAV. По умолчанию имеются следующие виртуальные каталоги предыдущих версий: /Public, /Exchweb, /Exchange и /Exadmin.
Если на компьютере с установленной ролью сервера клиентского доступа не установлена роль сервера почтовых ящиков, выберите пункты Настройка серверов, Клиентский доступ и откройте вкладку Outlook Web Access.
В рабочей области выберите виртуальный каталог, который необходимо настроить на использование встроенной проверки подлинности Windows, и выберите пункт Свойства.
Откройте вкладку Проверка подлинности.
Выберите вариант Использовать один или несколько стандартных способов проверки подлинности.
Выберите Встроенная проверка подлинности Windows.
Нажмите кнопку ОК.
Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью среды управления Exchange
Чтобы настроить встроенную проверку подлинности Windows для виртуального каталога Outlook Web Access по умолчанию на веб-узле служб IIS локального сервера Exchange, откройте среду управления Exchange и выполните следующую команду:
 Копировать код |
|---|
Дополнительные сведения о синтаксисе и параметрах см. в разделе Set-OwaVirtualDirectory.
Окончательная первоначальная (RTM) версия сервера Exchange Server 2007
Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью консоли управления Exchange
Откройте консоль управления Exchange.
Откройте раздел Конфигурация сервераКлиентский доступ.
На вкладке Outlook Web Access откройте свойства виртуального каталога, который необходимо настроить на использование встроенной проверки подлинности Windows.
Откройте вкладку Проверка подлинности.
Выберите вариант Использовать один или несколько стандартных способов проверки подлинности.
Выберите Встроенная проверка подлинности Windows.
Нажмите кнопку ОК.
Чтобы настроить встроенную проверку подлинности Windows для веб-клиента Outlook с помощью среды управления Exchange
Чтобы настроить встроенную проверку подлинности Windows для виртуального каталога Outlook Web Access по умолчанию на веб-узле служб IIS локального сервера Exchange, откройте командную консоль Exchange и выполните следующую команду:
| Копировать код |
|---|
Для получения дополнительных сведений о синтаксисе и параметрах см. раздел Командлет Set-OwaVirtualDirectory (окончательная первоначальная версия).
Дополнительные сведения
Дополнительные сведения о методах проверки подлинности, которые можно использовать в Outlook Web Access, см. в следующих разделах:
Дополнительные сведения о повышении безопасности связи между клиентскими компьютерами и сервером клиентского доступа см. в разделе Управление безопасностью клиентского доступа.
IIS — О проверке подлинности
Перед предоставлением доступа к информации на сервере можно потребовать от пользователя ввести действительную учетную запись пользователя Windows и пароль. Этот процесс идентификации часто называют проверкой подлинности. Проверка подлинности, как и большинство возможностей IIS, может быть установлена на уровне веб-узла, каталога или файла. IIS предлагает следующие способы проверки подлинности для управления доступом к содержимому сервера:
Методы для WWW
Методы для FTP
Для получения дополнительной информации об установке проверки подлинности см. раздел Включение и конфигурирование проверки подлинности.
Обзор методов проверки подлинности
| Метод | Уровень безопасности | Требования к серверу | Требования к клиенту | Примечания |
| Анонимная | Отсутствует | Учетная запись IUSR_ИмяКомпьютера | Любой обозреватель | Используется для общих областей узлов Интернета. |
| Обычная | Низкий | Действительные учетные записи | Вводит имя пользователя и пароль | Пароль передается незашифрованным. |
| Краткая | Высокий | Все пароли в виде неформатированного текста. Действительные учетные записи. | Совместимость | Применима при работе через прокси-серверы и другие брандмауэры. |
| Встроенная Windows | Высокий | Действительные учетные записи | Поддержка обозревателя | Используется в личных областях внутренних сетей. |
| Сертификаты | Высокий | Получение сертификатов сервера. Настройка списка доверенных сертификатов (CTL) (только при первом использовании). | Поддержка обозревателя | Широко используется для обеспечения безопасности транзакций через Интернет. |
| Анонимная FTP | Отсутствует | Учетная запись IUSR_ИмяКомпьютера | Отсутствует | Используется для общих областей узлов FTP. |
| Основная FTP | Низкий | Действительные учетные записи | Вводит имя пользователя и пароль | Пароль передается незашифрованным. |
Анонимная проверка подлинности
Анонимная проверка подлинности дает пользователям доступ к общим областям веб- или FTP-узлов без запроса имени пользователя или пароля. Когда пользователь пытается присоединиться к общему веб- или FTP-узлу, веб-сервер назначает пользователю учетную запись IUSR_ИмяКомпьютера, где ИмяКомпьютера — это имя сервера, на котором запущен IIS.
По умолчанию пользователь IUSR_ИмяКомпьютера включается Windows в группу пользователей Guests. Эта группа имеет ограничения по безопасности, налагаемые разрешениями NTFS, которые устанавливают уровень доступа и тип содержимого, доступные обычным пользователям.
Если на сервере размещено несколько узлов или на узле имеется ряд областей, требующих различных прав доступа, можно создать несколько анонимных учетных записей (по одной на каждый веб- или FTP-узел, каталог или файл). Предоставляя этим учетным записям различные права на доступ или назначая эти учетные записи разным группам пользователей, можно предоставить анонимным пользователям доступ к различным областям веб- и FTP-узлов.
IIS использует учетную запись IUSR_ИмяКомпьютера следующим образом:
- Учетная запись IUSR_ИмяКомпьютера добавляется в группу пользователей Guests.
- Когда запрос получен, IIS исполняет роль пользователя с учетной записью IUSR_ИмяКомпьютера перед выполнением любой программы или доступом к любому файлу. IIS в состоянии исполнить роль пользователя IUSR_ИмяКомпьютера, поскольку и имя пользователя, и пароль известны IIS.
- Перед возвратом страницы клиенту IIS проверяет файл NTFS и разрешения для каталога, чтобы проверить возможность доступа к файлу для пользователя с учетной записью IUSR_ИмяКомпьютера.
- Если доступ разрешен, проверка подлинности завершается и ресурсы становятся доступными пользователю.
- Если доступ не разрешен, IIS попытается использовать другой способ проверки подлинности. Если не один из методов не выбран, IIS возвращает в обозреватель сообщение об ошибке «HTTP 403 Access Denied».
Примечание
- Если анонимная проверка подлинности включена, IIS всегда будет пытаться сначала использовать ее, даже если другие методы включены.
- В некоторых случаях обозреватель запрашивает имя пользователя и пароль.
Учетная запись, используемая для анонимной проверки подлинности, может быть изменена в оснастке IIS на уровне служб веб-сервера или для отдельных виртуальных каталогов и файлов. Учетная запись анонимного пользователя должна давать пользователю права локального подключения. Если учетная запись не имеет разрешения «Локальный вход в систему», IIS не сможет обслуживать никакие анонимные запросы. При установке IIS учетная запись IUSR_ИмяКомпьютера получает разрешение «Локальный вход в систему». В контроллерах домена учетная запись IUSR_ИмяКомпьютера по умолчанию не включена в гостевые учетные записи. Она должна быть изменена (предоставлено разрешение «Локальный вход в систему»), чтобы разрешить анонимные подключения.
Примечание Требования к носителю права локального входа в систему могут быть изменены с помощью Active Directory Service Interfaces (ADSI). Для получения дополнительной информации см. раздел LogonMethod в руководстве по Active Server Pages.
Также можно изменить привилегии для учетной записи IUSR_ИмяКомпьютера в Windows с помощью оснастки-диспетчера групповой политики в MMC. Однако если учетная запись анонимного пользователя не дает права доступа к определенному файлу или ресурсу, веб-сервер не установит анонимное соединение с этим ресурсом. Дополнительные сведения см. в разделе Задание разрешений для веб-сервера.
Важно! Если изменена учетная запись IUSR_ИмяКомпьютера, изменения коснутся каждого анонимного запроса HTTP, который обслуживается веб-сервером. Будьте внимательны при изменении этой учетной записи.
Обычная проверка подлинности
Обычная проверка подлинности является широко используемым стандартным методом получения сведений об имени пользователя и пароле. Обычная проверка подлинности проходит следующим образом:
- В веб-обозревателе пользователя открывается диалоговое окно, в которое пользователь должен ввести ранее назначенные ему имя учетной записи пользователя Windows 2000 и пароль.
- После этого веб-обозреватель предпринимает попытку установить подключение с использованием введенных данных. (Перед передачей через сеть пароль зашифровывается по схеме Base64).
- Если сервер отвергает эту информацию, веб-обозреватель продолжает отображать диалоговое окно до тех пор, пока пользователь не введет действительное имя пользователя и пароль или не закроет диалоговое окно.
- Веб-сервер проверяет, что имя пользователя и пароль соответствуют действительной учетной записи Windows, и устанавливает соединение.
Для получения дополнительной информации об установке обычной проверки подлинности см. раздел Включение и конфигурирование проверки подлинности.
Преимуществом обычной проверки подлинности является то, что она является частью спецификации HTTP и поддерживается большинством обозревателей. К недостаткам относится то, что веб-обозреватели при использовании этого метода передают пароли в незашифрованном виде. Наблюдая за передачей информации в сети, можно легко перехватить и расшифровать эти пароли с помощью общедоступных средств. Следовательно, обычный способ проверки подлинности не рекомендуется использовать, за исключением тех случаев, когда есть полная уверенность в безопасности соединения пользователя и веб-сервера (например, прямое кабельное соединение или выделенная линия). Дополнительные сведения см. в разделе Шифрование.
Примечание Встроенная проверка подлинности имеет приоритет перед обычной проверкой подлинности. Обозреватель выберет встроенную проверку подлинности Windows и будет пытаться использовать текущую учетную информацию Windows перед тем, как запросить имя пользователя и пароль. В настоящий момент только Internet Explorer версии 2.0 и более поздней поддерживает встроенную проверку подлинности.
Краткая проверка подлинности
Новая возможность IIS 5.0. Краткая проверка подлинности предлагает те же возможности, что и обычная, но включает различные способы передачи информации, удостоверяющей пользователя. Сведения, подтверждающие подлинность пользователя, передаются путем однонаправленного процесса, часто называемого хэшированием. Результат этого процесса называется хэшем или выборкой сообщения. Расшифровать его практически невозможно. Иными словами, по хэшу нельзя восстановить исходный текст.
Краткая проверка подлинности проходит следующим образом:
- Сервер посылает обозревателю некоторую информацию, которая будет использована при проверке подлинности.
- Обозреватель добавляет эту информацию к имени пользователя, паролю и некоторой другой информации и выполняет хэширование. Дополнительная информация помогает предотвратить повторное использование значения хэша посторонними лицами.
- Хэш передается на сервер через сеть вместе с дополнительной информацией, передаваемой открытым текстом.
- Сервер добавляет дополнительную информацию к паролю клиента, полученному в виде неформатированного текста, и хэширует всю информацию.
- Сервер сравнивает переданное значение хэша с вычисленным им.
- Доступ предоставляется только при полном совпадении чисел.
Дополнительная информация добавляется к паролю перед хэшированием, поэтому никто не может перехватить хэшированный пароль и использовать его, чтобы выдать себя за настоящего клиента. Добавляемые значения помогают идентифицировать клиента, его компьютер и область, или домен, к которой принадлежит клиент. Отметка времени добавляется для предотвращения использования клиентом пароля после его аннулирования.
Это является явным преимуществом перед обычной проверкой подлинности, при которой пароль может быть перехвачен и использован пользователем, не имеющим соответствующих полномочий. Структура краткой проверки подлинности позволяет использовать ее через прокси-серверы и другие брандмауэры. Этот способ проверки подлинности доступен для WebDAV (Web Distributed Authoring and Versioning). Поскольку краткая проверка подлинности является новой возможностью HTTP 1.1, не все обозреватели поддерживают ее. Если несовместимый обозреватель выполняет запрос к серверу, требующему краткой проверки подлинности, сервер отвергает запрос и посылает клиенту сообщение об ошибке. Краткая проверка подлинности поддерживается только доменами с контроллерами домена, управляемыми операционной системой Windows 2000.
Важно! Краткая проверка подлинности будет завершена, если только сервер домена, к которому был сделан запрос, имеет пароль пользователя в виде неформатированного текста. Поскольку контроллер домена имеет копии паролей в виде неформатированного текста, он должен быть защищен от физической и сетевой атак. Для получения более подробной информации о защите контроллера домена см. пакет Microsoft Windows 2000 Server Resource Kit.
Примечание Значение хэша состоит из небольшого количества двоичных данных, обычно не более 160 бит. Это значение получается с помощью алгоритма хэширования. Все значения хэша имеют следующие свойства, независимо от используемого алгоритма:
- Длина хэша Длина значения хэша определяется типом используемого алгоритма и не меняется при изменении размера сообщения. Длина сообщения может составлять и несколько килобайт, и несколько гигабайт; это не скажется на длине значения хэша. Наиболее часто используется хэш длиной 128 или 160 бит.
- Нераскрываемость Каждая пара неидентичных сообщений будет преобразована в два совершенно различных значения хэша, даже если эти два сообщения отличаются только одним битом. Используя современные технологии, невозможно обнаружить пару сообщений, которые преобразуются в одно и то же значений хэша.
- Повторяемость При каждом хэшировании одного и того же сообщения с помощью одного алгоритма получается одно и то же значение хэша.
- Необратимость Все алгоритмы хэширования являются однонаправленными. По заданному значению хэша, даже при известном алгоритме, невозможно восстановить исходное сообщение. Фактически, ни одно из свойств исходного сообщения не может быть определено только по значению хэша.
Встроенная проверка подлинности
Встроенная проверка подлинности (раньше называвшаяся NTLM или проверка подлинности «запрос/ответ») является безопасной формой проверки подлинности, поскольку имя пользователя и пароль не передаются по сети. При включенной встроенной проверке подлинности обозреватель на компьютере пользователя доказывает знание пароля через криптографический обмен с веб-сервером, используя хэширование.
Встроенная проверка подлинности может использовать протокол проверки подлинности Kerberos v5 или собственный протокол проверки подлинности «запрос/ответ». Если Служба Каталогов установлена на сервере, а обозреватель совместим с протоколом проверки подлинности Kerberos v5, используются и протокол Kerberos v5, и протокол «запрос/ответ». В противном случае используется протокол «запрос/ответ».
Протокол проверки подлинности Kerberos v5 является возможностью архитектуры Windows 2000 Distributed Services. Чтобы проверка подлинности по протоколу Kerberos v5 была успешной, компьютеры и клиента, и сервера должны иметь надежное соединение с Key Distribution Center (KDC) и быть совместимыми со Службой Каталогов. Для получения информации о протоколе см. документацию по Windows.
Встроенная проверка подлинности проходит следующим образом:
- В отличие от обычной проверки подлинности, пользователю не предлагают ввести имя пользователя и пароль. Текущая информация о пользователе Windows на компьютере клиента используется для встроенной проверки подлинности.
Примечание Internet Explorer версии 4.0 или поздней может быть сконфигурирован, чтобы запрашивать в случае необходимости информацию о пользователе. Дополнительные сведения см. в документации по Internet Explorer.
Хотя встроенная проверка подлинности безопасна, она имеет два ограничения.
- Только Microsoft Internet Explorer версии 2.0 или поздней поддерживает этот способ проверки подлинности.
- Встроенная проверка подлинности Windows не работает через прокси-соединения HTTP.
Следовательно, встроенная проверка подлинности Windows лучше всего подходит для внутренних сетей предприятия, в которых компьютеры пользователя и веб-сервера находятся в одном домене и администратор может проверить использование на каждом компьютере Microsoft Internet Explorer версии 2.0 или более поздней.
Проверка подлинности по сертификату
Для двух типов проверки подлинности можно также использовать возможности защиты по протоколу SSL (Secure Sockets Layer) для веб-сервера. Можно использовать сертификат сервера для выполнения пользователями проверки подлинности сервера до передачи персональной информации, например номера кредитной карты. Также можно использовать сертификаты клиентов для проверки подлинности пользователей, запрашивающих информацию с веб-узла. SSL проверяет подлинность по содержимому зашифрованного цифрового идентификатора, который отправляется веб-обозревателем пользователя в процессе входа в систему. (Пользователи получают сертификаты клиента от независимой организации, доверенной для обеих сторон.) Сертификаты сервера обычно содержат сведения о компании и об организации, выдавшей сертификат. Сертификаты клиентов обычно содержат подробные сведения о пользователе и об организации, выдавшей сертификат. Дополнительные сведения см. в разделе О сертификатах.
Сопоставление сертификатов клиента
Можно связать, или сопоставить, сертификаты клиента и учетные записи пользователя Windows на веб-сервере. После создания и включения сопоставления при каждом входе пользователя с клиентским сертификатом веб-сервер автоматически сопоставляет этого пользователя с соответствующей учетной записью Windows. Таким образом можно автоматически проверять подлинность пользователей, входящих в систему с сертификатами клиента, не требуя основной, краткой или встроенной проверки подлинности. Можно или сопоставить один сертификат клиента одной учетной записи пользователя Windows, или несколько сертификатов — одной учетной записи. Например, если на сервере присутствует несколько подразделений, каждое на своем веб-узле, можно использовать сопоставление «многие-к-одному» для установления соответствия сертификатов клиента каждого подразделения соответствующему веб-узлу. В этом случае каждый узел обеспечивает доступ только для своих клиентов. Дополнительные сведения см. в разделе Сопоставление клиентских сертификатов учетным записям пользователей.
Проверка подлинности для FTP
Анонимная проверка подлинности для FTP
Сервер FTP может быть сконфигурирован, чтобы разрешать анонимный доступ к своим ресурсам. Если анонимная проверка подлинности включена, IIS всегда будет пытаться сначала использовать ее, даже если другие методы включены. Если для ресурса выбрана анонимная проверка подлинности, все запросы к этому ресурсу будут выполняться без предложения ввести имя пользователя или пароль. Это возможно, поскольку IIS автоматически создает учетную запись пользователя Windows с именем IUSR_ИмяКомпьютера, где ИмяКомпьютера — имя сервера, на котором запущен IIS. Это очень похоже на анонимную проверку подлинности для WWW. Дополнительные сведения см. в разделе Анонимная проверка подлинности.
Обычная проверка подлинности для FTP
Чтобы установить FTP-подключение к веб-серверу с помощью обычной проверки подлинности, пользователи должны представить при входе имя пользователя и пароль, соответствующие допустимой учетной записи Windows. Если веб-сервер не может подтвердить личность пользователя, то сервер возвращает сообщение об ошибке. Эта проверка подлинности для FTP не является безопасной, поскольку пользователь передает пароль и имя пользователя по сети в незашифрованном виде. Дополнительные сведения см. в разделе Об управлении доступом.