認証 (BITS)
BITS は、基本認証、パスポート認証、およびいくつかのチャレンジ/レスポンス認証方式をサポートしています。 サーバーまたはプロキシでユーザー認証が必要な場合は、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 レジストリ値への完全なパスは、HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LmCompatibilityLevel です。
LMCompatibilityLevel レジストリ値を変更すると、コンピューター上で実行されている他のアプリケーションやサービスに影響する可能性があることに注意してください。
LMCompatibilityLevel レジストリ値の設定に問題がある場合は、HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\BITS の下に、UseLMCompat レジストリ値を作成できます。 レジストリ値は DWORD です。 次の表に、UseLMCompat として使用できる値の一覧を示します。
Value | 内容 |
---|---|
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) 以降では、ユーザー固有の資格情報を使用した認証プロキシ シナリオが簡素化されています。
- BITS ジョブの SetCredentialsメソッドを BG_AUTH_SCHEME_NEGOTIATE で呼び出し、UserName を NULL に設定し、Passwordを NULL に設定し、Target を BG_AUTH_TARGET_PROXY に設定します。 これにより、ユーザー アカウントの暗黙的な資格情報がプロキシとサーバーでの NTLM および Kerberos 認証に使用されます。
- BG_JOB_PROXY_USAGE_PRECONFIG を使用して IBackgroundCopyJob::SetProxySettings を呼び出します。
- IBitsTokenOptions の QueryInterface。
- NTLM/Kerberos 資格情報に使用しているユーザー アカウントを偽装します。
- SetHelperToken を呼び出します。
- BG_TOKEN_NETWORK を使用して SetHelperTokenFlags を呼び出します。
- 偽装を元に戻します。
- ジョブのセットアップを続行します。
- ジョブで Resume を呼び出します。
Windows 10 バージョン 1809 (10.0; ビルド 17763) より前では、ネットワーク ベースのプロキシ検出 (WPAD) とプロキシ認証には正しいユーザー ID (ヘルパー トークンの ID) が使用されますが、ローカル (IE) プロキシ設定の実際の検出は行われません。ヘルパー トークンが構成されている場合でも、常にジョブ所有者のトークンを使用して実行されます。 この欠点を回避するには、次の手順に従います。
- NTLM/Kerberos 資格情報に使用しているユーザー アカウントを偽装します。
- WinHttpGetIEProxyConfigForCurrentUser を呼び出して、ユーザー アカウントの IE プロキシ設定を取得します。
- 偽装を元に戻します。
- BITS ジョブの SetCredentialsメソッドを BG_AUTH_SCHEME_NEGOTIATE で呼び出し、UserName を NULL に設定し、Passwordを NULL に設定し、Target を BG_AUTH_TARGET_PROXY に設定します。 これにより、ユーザー アカウントの暗黙的な資格情報がプロキシとサーバーでの NTLM および Kerberos 認証に使用されます。
- 手順 2 でユーザー固有のプロキシ設定 (lpszProxy または lpszProxyBypass が NULL ではない) が発生した場合は、BG_JOB_PROXY_USAGE_OVERRIDE で SetProxySettings を使用して、対応するジョブ設定を手動で設定します。
- 手順 2 でユーザー固有のプロキシ設定が生成されなかった場合は、BG_JOB_USAGE_PRECONFIG を使用して SetProxySettings を呼び出します。
- IBitsTokenOptions の QueryInterface。
- もう一度ユーザー アカウントを偽装します。
- SetHelperToken を呼び出します。
- BG_TOKEN_NETWORK を使用して SetHelperTokenFlags を呼び出します。
- 偽装を元に戻します。
- ジョブのセットアップを続行します。
- ジョブで Resume を呼び出します。