認証 (BITS)

BITS では、基本認証、Passport 認証、およびいくつかのチャレンジ/応答認証スキームがサポートされています。 サーバーまたはプロキシでユーザー認証が必要な場合は、IBackgroundCopyJob2::SetCredentials 関数を使用して、ユーザーの資格情報を指定します。 BITS では、CryptoAPI を使用して資格情報を保護します。

基本認証の資格情報を設定するには、SetCredentials 関数を使用して、ユーザー名とパスワードを指定します。 基本認証は、保護されたセキュリティで保護された Web サイト https:// 使用する必要があります。それ以外の場合は、ユーザー名とパスワードがユーザーに表示されます。

URL にユーザー名とパスワードを埋め込むことができます。 これは適切なセキュリティプラクティスとは見なされず、RFC 3986 (セクション 3.2.1) では非推奨です。

Passport 認証の場合、BITS では明示的な資格情報のみがサポートされ、アカウントに関連付けられている暗黙的な資格情報はサポートされません。

チャレンジ/応答認証の場合、BITS はユーザーを偽装し、Snego を使用して、NTLM や Kerberos プロトコルなど、使用するチャレンジ/応答認証を決定します。 BITS がサポートするチャレンジ/応答スキームの一覧については、BG_AUTH_SCHEMEを参照してください。

サーバー上の仮想ディレクトリに匿名認証と別の認証スキームが有効になっている場合、および ACL が仮想ディレクトリまたはダウンロード ファイルを保護している場合、BITS ジョブは失敗する可能性があります。 たとえば、仮想ディレクトリで匿名認証と統合認証が有効になっていて、ファイルに Ben のみがファイルを読み取る ACL が含まれている場合、ジョブは "アクセス拒否" で失敗します。 これは、仮想ディレクトリが匿名アクセスを許可するため、IIS が Ben を明示的に認証しないために発生します (Ben の資格情報はファイルへのアクセスに使用されず、アクセスは拒否されます)。

暗黙的な資格情報の使用

NTLM または Kerberos 認証にユーザーの暗黙的な (ログオン) 資格情報を使用するには、IBackgroundCopyJob2::SetCredentials メソッドを呼び出し、BG_BASIC_CREDENTIALS 構造体の UserName メンバーと Password メンバーを NULL 設定します。 プロキシに暗黙的な資格情報を指定した場合、明示的なサーバー資格情報を指定しない限り、BITS はサーバー認証にも暗黙的な資格情報を使用します。

サービスの詳細については、「サービス アカウントと BITS」を参照してください。

また、LMCompatibilityLevel または UseLMCompat レジストリ値 変更することもできます。ただし、SetCredentials メソッドを呼び出すために変更できない既存のアプリケーションがある場合にのみ、これらの値を変更する必要があります。

LMCompatibilityLevel レジストリ値が 2 つ以上で、SetCredentials メソッドを呼び出していない場合、BITS は認証に暗黙的な資格情報を使用します。 LMCompatibilityLevel レジストリ値への完全なパスは、System\CurrentControlSet\Control\LSA\LmCompatibilityLevelHKEY_LOCAL_MACHINE\です。

LMCompatibilityLevel レジストリ値を変更すると、コンピューター上で実行されている他のアプリケーションやサービスに影響する可能性があることに注意してください。

LMCompatibilityLevel レジストリ値の設定が問題である場合は、Microsoft\Windows\CurrentVersion\BITSHKEY_LOCAL_MACHINE\Software\で UseLMCompat レジストリ値を作成できます。 レジストリ値は DWORD です。 次の表に、UseLMCompat 使用できる値を示します。

価値	形容
0	BITS は、サーバーが NTLM または Kerberos 資格情報を要求するたびに暗黙的な資格情報を送信します。
1	BITS は、クライアント コンピューターの LMCompatibilityLevel レジストリ値が 2 以上の場合にのみ、暗黙的な資格情報を送信します。
2	BITS は、アプリケーションが SetCredentials メソッドを呼び出した場合にのみ、暗黙的な資格情報を送信します。

レジストリ値が存在しない場合、BITS は UseLMCompat レジストリ値に既定値 "2" を使用します。

クライアント/サーバー認証に証明書を使用する

セキュリティで保護されたクライアント/サーバー通信では、クライアントとサーバーはデジタル証明書を使用して相互に認証を行うことができます。 BITS では、セキュリティで保護された HTTP トランスポート用の証明書ベースのサーバー認証が自動的にサポートされます。 相互認証に必要なクライアント証明書を BITS に提供するには、IBackgroundCopyJobHttpOptions::SetClientCertificateByID または IBackgroundCopyJobHttpOptions::SetClientCertificateByNameメソッドをします。

Web サイトが SSL クライアント証明書を受け入れるが不要で、BITS ジョブでクライアント証明書が指定されていない場合、ジョブは ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED (0x80072f0c) で失敗します。

ユーザー固有の設定を必要とする認証済みプロキシ シナリオを処理する方法

コンピューターのネットワーク ドメインで使用可能な NTLM または Kerberos 資格情報を持たないアカウントとして実行中にプロキシ認証が必要な環境で BITS を使用している場合は、ドメインに資格情報を持つ別のユーザー アカウントの資格情報を使用して適切に認証するための追加の手順を実行する必要があります。 これは、BITS コードが LocalService、NetworkService、LocalSystem などのシステム サービスとして実行されている一般的なシナリオです。これらのアカウントには使用可能な NTLM または Kerberos 資格情報がないためです。

BITS で使用されるプロキシ検出ロジックは、ネットワーク ヘルパー トークン (BG_TOKEN_NETWORK) が設定されている場合に次の処理を行います。

• IBackgroundCopyJob::SetProxySettings が BG_JOB_PROXY_USAGE_PRECONFIGで呼び出された場合は、WinHttpGetIEProxyConfigForCurrentUserを使用して、ジョブ所有者トークン コンテキストの偽装使用してローカル IE プロキシ設定を読み取ります。 Windows 10 バージョン 1809 以降 (10.0;ビルド 17763)、ヘルパー トークン ID がこの手順で使用されます。
• IBackgroundCopyJob::SetProxySettings が BG_PROXY_USAGE_AUTODETECT で呼び出された場合、または BG_JOB_PROXY_USAGE_PRECONFIG ケースの IE 設定で自動検出または自動構成 URL が指定されている場合は、WinHttpGetProxyForUrlを介してヘルパー トークンの偽装使用して、自動検出または Web プロキシ自動検出プロトコル (WPAD) を実行します。

その後、ヘルパー トークンの偽装は、全体を通じてプロキシまたはサーバー認証に使用されます。

Windows 10 バージョン 1809 以降 (10.0;ビルド 17763) では、ユーザー固有の資格情報を使用して認証されたプロキシ シナリオが簡略化されます。

1. BITS ジョブの SetCredentials メソッドを呼び出します。BG_AUTH_SCHEME_NEGOTIATE、UserName が NULL に設定、パスワード が NULL に設定され、ターゲット が BG_AUTH_TARGET_PROXYに設定。 これにより、ユーザー アカウントの暗黙的な資格情報が、プロキシとサーバーでの NTLM および Kerberos 認証に使用されます。
2. BG_JOB_PROXY_USAGE_PRECONFIGIBackgroundCopyJob::SetProxySettings を呼び出します。
3. IBitsTokenOptionsの QueryInterface。
4. NTLM/Kerberos 資格情報に使用しているユーザー アカウントを偽装します。
5. SetHelperToken呼び出します。
6. BG_TOKEN_NETWORKSetHelperTokenFlags を呼び出します。
7. 偽装を元に戻します。
8. ジョブのセットアップを続行します。
9. ジョブ Resume を呼び出します。

Windows 10 より前のバージョン 1809 (10.0;ビルド 17763) では、ネットワーク ベースのプロキシ検出 (WPAD) とプロキシ認証に正しいユーザー ID (ヘルパー トークンの ID) が使用されますが、ローカル (IE) プロキシ設定の実際の検出は、ヘルパー トークンが構成されている場合でも、常にジョブ所有者のトークンを使用して行われます。 この欠点を回避するには、次の手順に従います。

1. NTLM/Kerberos 資格情報に使用しているユーザー アカウントを偽装します。
2. WinHttpGetIEProxyConfigForCurrentUser呼び出して、ユーザー アカウントの IE プロキシ設定を取得します。
3. 偽装を元に戻します。
4. BITS ジョブの SetCredentials メソッドを呼び出します。BG_AUTH_SCHEME_NEGOTIATE、UserName が NULL に設定、パスワード が NULL に設定され、ターゲット が BG_AUTH_TARGET_PROXYに設定。 これにより、ユーザー アカウントの暗黙的な資格情報が、プロキシとサーバーでの NTLM および Kerberos 認証に使用されます。
5. 手順 2 でユーザー固有のプロキシ設定 (lpszProxy または lpszProxyBypass が NULL されていない場合) は、SetProxySettings と BG_JOB_PROXY_USAGE_OVERRIDE 設定を使用して、対応するジョブ設定を手動で設定します。
6. 手順 2 でユーザー固有のプロキシ設定が生成されなかった場合は、BG_JOB_USAGE_PRECONFIGで SetProxySettings呼び出します。
7. IBitsTokenOptionsの QueryInterface。
8. もう一度ユーザー アカウントを偽装します。
9. SetHelperToken呼び出します。
10. BG_TOKEN_NETWORKSetHelperTokenFlags を呼び出します。
11. 偽装を元に戻します。
12. ジョブのセットアップを続行します。
13. ジョブ Resume を呼び出します。