認證 （BITS）

  • 發行項

BITS 支援基本身份驗證、Passport 驗證，以及數個挑戰/回應驗證配置。 如果伺服器或 Proxy 需要使用者驗證，請使用 IBackgroundCopyJob2：：SetCredentials 函式來指定使用者的認證。 BITS 使用 CryptoAPI 來保護認證。

若要設定基本身份驗證的認證， 請使用 SetCredentials 函式來指定使用者名稱和密碼。 您應該只使用基本身份驗證搭配 https:// 受保護的安全網站;否則使用者將會看見使用者名稱和密碼。

可以將使用者名稱和密碼內嵌在URL中。 這不是良好的安全性做法，而且在 RFC 3986 中已被取代（第 3.2.1 節）。

對於 Passport 驗證，BITS 僅支持明確認證，而不是系結至帳戶的隱含認證。

針對挑戰/響應驗證，BITS 會模擬使用者，並使用 Snego 來判斷要使用的挑戰/回應驗證，例如 NTLM 或 Kerberos 通訊協定。 如需 BITS 支援的挑戰/回應配置清單，請參閱 BG_AUTH_SCHEME。

如果伺服器上的虛擬目錄已啟用匿名驗證和另一個驗證配置，以及 ACL 保護虛擬目錄或下載檔，BITS 作業可能會失敗。 例如，如果虛擬目錄已啟用匿名和整合式驗證，且檔案包含僅允許 Ben 讀取檔案的 ACL，則作業會失敗並「拒絕存取」。 這是因為虛擬目錄允許匿名存取，因此 IIS 不會明確驗證 Ben （Ben 的認證不會用來存取檔案，而且拒絕存取權）。

使用隱含認證

若要使用使用者的隱含 （logon） 認證進行 NTLM 或 Kerberos 驗證，請呼叫 IBackgroundCopyJob2：：SetCredentials 方法，並將 BG_BASIC_CREDENTIALS 結構的 UserName 和 Password 成員設定為 NULL。 如果您指定 Proxy 的隱含認證，除非指定明確的伺服器認證，否則 BITS 也會使用隱含認證進行伺服器驗證。

如需服務的其他資訊，請參閱 服務帳戶和 BITS。

您也可以變更 LMCompatibilityLevel 或 UseLMCompat 登錄值;不過，只有在您現有的應用程式無法變更以呼叫 SetCredentials 方法時，才應該變更這些值。

如果 LMCompatibilityLevel 登錄值是兩個以上，而且您尚未呼叫 SetCredentials 方法，BITS 會使用隱含認證進行驗證。 LMCompatibilityLevel 登錄值的完整路徑HKEY_LOCAL_MACHINE\ System\CurrentControlSet\控件\LSA\LmCompatibilityLevel。

請注意，變更 LMCompatibilityLevel 登錄值可能會影響計算機上執行的其他應用程式和服務。

如果設定 LMCompatibilityLevel 登錄值是個問題，您可以在 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\BITS 下建立 UseLMCompat 登錄值。 登錄值為 DWORD。 下表列出 UseLMCompat 的可能值：

值 描述
0 每當伺服器提示 NTLM 或 Kerberos 認證時，BITS 就會傳送隱含認證。
1 只有在用戶端電腦的 LMCompatibilityLevel 登錄值大於或等於 2 時，BITS 才會傳送隱含認證。
2 只有在呼叫 SetCredentials 方法的應用程式時，BITS 才會傳送隱含認證。

如果登錄值不存在，BITS 會針對 UseLMCompat 登錄值使用預設值 「2」。。

使用憑證進行用戶端/伺服器驗證

在安全的用戶端/伺服器通訊中，客戶端和伺服器可以使用數位證書相互驗證。 BITS 會自動支援安全 HTTP 傳輸的憑證型伺服器驗證。 若要提供相互驗證所需的用戶端憑證，請呼叫 IBackgroundCopyJobHttpOptions：：SetClientCertificateByID 或 IBackgroundCopyJobHttpOptions：：SetClientCertificateByName 方法。

當網站接受但不需要 SSL 用戶端憑證，且 BITS 作業未指定用戶端憑證時，作業將會失敗併產生 ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED （0x80072f0c）。

如何處理需要使用者特定設定的已驗證 Proxy 案例

如果您在環境中使用 BITS，而該環境中在執行時需要 Proxy 驗證，但計算機網路網域中沒有可用 NTLM 或 Kerberos 認證的帳戶，您必須使用具有網域認證的另一個使用者帳戶認證，採取額外的步驟來正確進行驗證。 當您的 BITS 程式代碼以 LocalService、NetworkService 或 LocalSystem 等系統服務的形式執行時，這是典型的案例，因為這些帳戶沒有可使用的 NTLM 或 Kerberos 認證。

設定網路協助程式令牌 BG_TOKEN_NETWORK時，BITS 中使用的 Proxy 偵測邏輯會執行下列動作：

之後，協助程式令牌模擬會用於整個 Proxy 或伺服器驗證。

從 Windows 10 版本 1809 開始（10.0;組建 17763），使用使用者特定認證的已驗證 Proxy 案例會簡化。

  1. 呼叫 BITS 作業的 SetCredentials 方法，並將 BG_AUTH_SCHEME_NEGOTIATE、UserName 設定為 NULL、密碼設定為 NULL，並將 [目標] 設定為 [BG_AUTH_TARGET_PROXY]。 這會導致使用者帳戶的隱含認證用於使用 Proxy 和伺服器的NTLM和 Kerberos 驗證。
  2. 使用 BG_JOB_PROXY_USAGE_PRECONFIG 呼叫 IBackgroundCopyJob：：SetProxy 設定。
  3. IBitsTokenOptions 的 QueryInterface。
  4. 模擬您用於 NTLM/Kerberos 認證的用戶帳戶。
  5. 呼叫 SetHelperToken。
  6. 使用 BG_TOKEN_NETWORK 呼叫 SetHelperTokenFlags。
  7. 還原模擬。
  8. 繼續作業設定。
  9. 在作業上呼叫 Resume。

在 Windows 10 版本 1809 之前 （10.0;組建 17763）、正確的使用者身分識別（協助程式令牌的身分識別）用於網路型 Proxy 偵測 （WPAD） 和 Proxy 驗證，但本機 （IE） Proxy 設定的實際偵測一律會使用作業擁有者的令牌來完成，即使已設定協助程式令牌也一樣。 若要解決此問題，您可以遵循下列步驟。

  1. 模擬您用於 NTLM/Kerberos 認證的用戶帳戶。
  2. 呼叫 WinHttpGetIEProxyConfigForCurrentUser 來擷取使用者帳戶的 IE Proxy 設定。
  3. 還原模擬。
  4. 呼叫 BITS 作業的 SetCredentials 方法，並將 BG_AUTH_SCHEME_NEGOTIATE、UserName 設定為 NULL、密碼設定為 NULL，並將 [目標] 設定為 [BG_AUTH_TARGET_PROXY]。 這會導致使用者帳戶的隱含認證用於使用 Proxy 和伺服器的NTLM和 Kerberos 驗證。
  5. 如果步驟 2 產生任何使用者特定的 Proxy 設定（例如 lpszProxy 或 lpszProxyBypass 不是 NULL），請使用 SetProxy 手動設定對應的作業設定 設定 搭配BG_JOB_PROXY_USAGE_OVERRIDE設定。
  6. 如果步驟 2 未產生任何使用者特定的 Proxy 設定，請使用 BG_JOB_USAGE_PRECONFIG 呼叫 SetProxy 設定。
  7. IBitsTokenOptions 的 QueryInterface。
  8. 再次模擬用戶帳戶。
  9. 呼叫 SetHelperToken。
  10. 使用 BG_TOKEN_NETWORK 呼叫 SetHelperTokenFlags。
  11. 還原模擬。
  12. 繼續作業設定。
  13. 在作業上呼叫 Resume。