Проверка подлинности (BITS)
BITS поддерживает обычную проверку подлинности, проверку подлинности Passport и несколько схем проверки подлинности в ответе. Если для сервера или прокси-сервера требуется проверка подлинности пользователя, используйте функцию IBackgroundCopyJob2::SetCredentials , чтобы указать учетные данные пользователя. BITS использует CryptoAPI для защиты учетных данных.
Чтобы задать учетные данные для базовой проверки подлинности, используйте функцию SetCredentials , чтобы указать имя пользователя и пароль. Вы должны использовать только обычную проверку подлинности с https:// защищенных веб-сайтов; в противном случае имя пользователя и пароль будут отображаться пользователям.
Можно внедрить имя пользователя и пароль в URL-адрес. Это не считается хорошей практикой безопасности и не рекомендуется использовать в RFC 3986 (раздел 3.2.1).
Для проверки подлинности Passport BITS поддерживает только явные учетные данные, а не неявные учетные данные, привязанные к учетной записи.
При проверке подлинности на запросе и ответе BITS олицетворяет пользователя и использует Snego для определения используемой проверки подлинности на вызов или ответ, например NTLM или протокола Kerberos. Список схем вызовов и ответов, поддерживаемых BITS, см . в BG_AUTH_SCHEME.
Задания BITS могут завершиться ошибкой, если виртуальный каталог на сервере имеет анонимную проверку подлинности, а также включена другая схема проверки подлинности и если списки управления доступом защищают виртуальный каталог или скачивают файлы. Например, задание завершается сбоем с "отказано в доступе", если в виртуальном каталоге включена анонимная и встроенная проверка подлинности, а файл содержит ACL, позволяющий только Бену читать файл. Это происходит из-за того, что виртуальный каталог разрешает анонимный доступ, поэтому службы IIS явно не проходят проверку подлинности Бена (учетные данные Бена не используются для доступа к файлу и доступу запрещены).
Использование неявных учетных данных
Чтобы использовать неявные учетные данные пользователя для проверки подлинности NTLM или Kerberos, вызовите метод IBackgroundCopyJob2::SetCredentials и задайте для членов структуры BG_BASIC_CREDENTIALS значение NULL. Если указать неявные учетные данные для прокси-сервера, BITS также будет использовать неявные учетные данные для проверки подлинности сервера, если вы не указали явные учетные данные сервера.
Дополнительные сведения о службах см. в разделе "Учетные записи службы" и "BITS".
Можно также изменить значение реестра LMCompatibilityLevel или UseLMCompat . Однако эти значения следует изменить только в том случае, если у вас есть существующее приложение, которое не может быть изменено для вызова метода SetCredentials .
BITS будет использовать неявные учетные данные для проверки подлинности, если значение реестра LMCompatibilityLevel равно двум или больше, и вы не назвали метод SetCredentials . Полный путь к значению реестра LMCompatibilityLevel — HKEY_LOCAL_MACHINE \\System CurrentControlSet\Control\LSA\LmCompatibilityLevel.
Обратите внимание, что изменение значения реестра LMCompatibilityLevel может повлиять на другие приложения и службы, работающие на компьютере.
Если задать значение реестра LMCompatibilityLevel является проблемой, можно создать значение реестра UseLMCompat в разделе HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\BITS. Значение реестра — DWORD. В следующей таблице перечислены возможные значения useLMCompat:
| значение | Описание |
|---|---|
| 0 | BITS отправляет неявные учетные данные всякий раз, когда сервер запрашивает учетные данные NTLM или Kerberos. |
| 1 | BITS отправляет неявные учетные данные только в том случае, если значение реестра LMCompatibilityLevel клиентского компьютера больше или равно 2. |
| 2 | BITS отправляет неявные учетные данные, только если приложение называется методом SetCredentials . |
BITS будет использовать значение по умолчанию "2" для значения реестра UseLMCompat , если значение реестра не существует.
Использование сертификатов для проверки подлинности клиента или сервера
В безопасном обмене данными между клиентами и серверами клиенты и серверы могут использовать цифровые сертификаты для взаимной проверки подлинности друг друга. BITS автоматически поддерживает проверку подлинности сервера на основе сертификатов для безопасных транспортных данных HTTP. Чтобы предоставить BITS сертификат клиента, необходимый для взаимной проверки подлинности, вызовите метод IBackgroundCopyJobHttpOptions::SetClientCertificateByID или IBackgroundCopyJobHttpOptions::SetClientCertificateByName.
Если веб-сайт принимает, но не требует SSL-сертификата клиента, а задание BITS не указывает сертификат клиента, задание завершится ошибкой с ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED (0x80072f0c).
Обработка сценариев прокси-сервера с проверкой подлинности, для которых требуются параметры конкретного пользователя
Если вы используете BITS в среде, требующей проверки подлинности прокси-сервера во время выполнения в качестве учетной записи без учетных данных NTLM или Kerberos в сетевом домене компьютера, необходимо выполнить дополнительные действия для правильной проверки подлинности с помощью учетных данных другой учетной записи пользователя, которая имеет учетные данные в домене. Это типичный сценарий, когда код BITS выполняется как системная служба, например LocalService, NetworkService или LocalSystem, так как эти учетные записи не имеют доступных учетных данных NTLM или Kerberos.
Логика обнаружения прокси-сервера, используемая в BITS, выполняет следующие действия при установке вспомогательного маркера сети (BG_TOKEN_NETWORK):
- Если метод IBackgroundCopyJob::SetProxy Параметры был вызван с помощью BG_JOB_PROXY_USAGE_PRECONFIG, считывание локальных параметров прокси-сервера IE с помощью олицетворения контекста маркера владельца задания через WinHttpGetIEProxyConfigForCurrentUser. Начиная с Windows 10 версии 1809 (10.0; Сборка 17763), вспомогательное удостоверение маркера используется для этого шага.
- Если IBackgroundCopyJob::SetProxy Параметры был вызван с BG_PROXY_USAGE_AUTODETECT или если параметры IE из BG_JOB_PROXY_USAGE_PRECONFIG случае указывают автоматический обнаружение или URL-адрес автоконфигурации, а затем проводите автоматическое обнаружение прокси-сервера или протокол автообнаружения веб-прокси (WPAD), используя олицетворение вспомогательного маркера через WinHttpGetProxyForUrl.
После этого вспомогательное олицетворение маркера используется для проверки подлинности прокси-сервера или сервера на протяжении всего периода.
Начиная с Windows 10 версии 1809 (10.0; Сборка 17763), сценарий аутентификации прокси с учетными данными пользователя упрощен.
- Вызовите метод SetCredentials задания BITS с BG_AUTH_SCHEME_NEGOTIATE, UserName, равным NULL, парольу, равным NULL, и целевому набору для BG_AUTH_TARGET_PROXY. Это приводит к тому, что неявные учетные данные учетной записи пользователя будут использоваться для проверки подлинности NTLM и Kerberos с прокси-сервером.
- Вызовите IBackgroundCopyJob::SetProxy Параметры с BG_JOB_PROXY_USAGE_PRECONFIG.
- QueryInterface для IBitsTokenOptions.
- Олицетворите учетную запись пользователя, используемую для учетных данных NTLM/Kerberos.
- Вызов SetHelperToken.
- Вызов SetHelperTokenFlags с BG_TOKEN_NETWORK.
- Возврат олицетворения.
- Продолжить настройку задания.
- Вызов резюме задания.
До Windows 10 версии 1809 (10.0; Сборка 17763), правильное удостоверение пользователя (удостоверение вспомогательного маркера) используется для обнаружения прокси-сервера на основе сети (WPAD) и проверки подлинности прокси-сервера, но фактическое обнаружение локальных параметров прокси-сервера (IE) всегда выполняется с помощью маркера владельца задания, даже если настроен вспомогательный маркер. Чтобы обойти этот недостаток, вы можете выполнить следующие действия.
- Олицетворите учетную запись пользователя, используемую для учетных данных NTLM/Kerberos.
- Получите параметры прокси-сервера IE учетной записи пользователя, вызвав WinHttpGetIEProxyConfigForCurrentUser.
- Возврат олицетворения.
- Вызовите метод SetCredentials задания BITS с BG_AUTH_SCHEME_NEGOTIATE, UserName, равным NULL, парольу, равным NULL, и целевому набору для BG_AUTH_TARGET_PROXY. Это приводит к тому, что неявные учетные данные учетной записи пользователя будут использоваться для проверки подлинности NTLM и Kerberos с прокси-сервером.
- Если шаг 2 дал какие-либо параметры прокси-сервера для конкретного пользователя (т. е. lpszProxy или lpszProxyBypass не равны NULL), задайте соответствующие параметры задания вручную с помощью SetProxy Параметры с параметром BG_JOB_PROXY_USAGE_OVERRIDE.
- Если шаг 2 не дал никаких параметров прокси-сервера для конкретного пользователя, вызовите SetProxy Параметры с BG_JOB_USAGE_PRECONFIG.
- QueryInterface для IBitsTokenOptions.
- Снова олицетворите учетную запись пользователя.
- Вызов SetHelperToken.
- Вызов SetHelperTokenFlags с BG_TOKEN_NETWORK.
- Возврат олицетворения.
- Продолжить настройку задания.
- Вызов резюме задания.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по