Freigeben über

Authentifizierung (BITS)

  • Artikel

BITS unterstützt die Standardauthentifizierung, die Passport-Authentifizierung und mehrere Abfrage-/Antwortauthentifizierungsschemas. Wenn der Server oder Proxy eine Benutzerauthentifizierung erfordert, verwenden Sie die IBackgroundCopyJob2::SetCredentials-Funktion, um die Anmeldeinformationen des Benutzers anzugeben. BITS verwendet die CryptoAPI- zum Schutz der Anmeldeinformationen.

Verwenden Sie zum Festlegen von Anmeldeinformationen für die Standardauthentifizierung die SetCredentials--Funktion, um den Benutzernamen und das Kennwort anzugeben. Sie sollten die Standardauthentifizierung nur mit https:// geschützten sicheren Websites verwenden; andernfalls ist der Benutzername und das Kennwort für Benutzer sichtbar.

Es ist möglich, den Benutzernamen und das Kennwort in die URL einzubetten. Dies gilt nicht als bewährte Sicherheitspraxis und ist in RFC 3986 (Abschnitt 3.2.1) veraltet.

Für Passport--Authentifizierung unterstützt BITS nur explizite Anmeldeinformationen, nicht implizite Anmeldeinformationen, die mit dem Konto verknüpft sind.

Bei der Abfrage-/Antwortauthentifizierung stellt BITS den Identitätswechsel des Benutzers dar und verwendet Snego, um zu bestimmen, welche Abfrage-/Antwortauthentifizierung verwendet werden soll, z. B. NTLM oder das Kerberos-Protokoll. Eine Liste der von BITS unterstützten Abfrage-/Antwortschemas finden Sie unter BG_AUTH_SCHEME.

BITS-Aufträge können fehlschlagen, wenn das virtuelle Verzeichnis auf dem Server anonyme Authentifizierung und ein anderes Authentifizierungsschema aktiviert ist und ACLs das virtuelle Verzeichnis schützen oder Dateien herunterladen. Beispielsweise schlägt ein Auftrag mit "Zugriff verweigert" fehl, wenn das virtuelle Verzeichnis anonyme und integrierte Authentifizierung aktiviert hat und die Datei eine ACL enthält, mit der nur Ben die Datei lesen kann. Dies geschieht, da das virtuelle Verzeichnis anonymen Zugriff zulässt, sodass IIS Ben nicht explizit authentifiziert (Die Anmeldeinformationen von Ben werden nicht für den Zugriff auf die Datei verwendet und der Zugriff verweigert).

Verwenden impliziter Anmeldeinformationen

Rufen Sie die IBackgroundCopyJob2::SetCredentials-Methode auf, um die impliziten Anmeldeinformationen (Anmeldeinformationen) des Benutzers für DIE NTLM- oder Kerberos-Authentifizierung zu verwenden, und legen Sie die UserName- und Password Member der BG_BASIC_CREDENTIALS Struktur auf NULL-fest. Wenn Sie implizite Anmeldeinformationen für einen Proxy angeben, verwendet BITS auch die impliziten Anmeldeinformationen für die Serverauthentifizierung, es sei denn, Sie geben explizite Serveranmeldeinformationen an.

Weitere Informationen zu Diensten finden Sie unter Dienstkonten und BITS-.

Sie können auch den LMCompatibilityLevel- oder UseLMCompat Registrierungswert ändern; Sie sollten diese Werte jedoch nur ändern, wenn Sie über eine vorhandene Anwendung verfügen, die nicht geändert werden kann, um die SetCredentials--Methode aufzurufen.

BITS verwendet implizite Anmeldeinformationen für die Authentifizierung, wenn der LMCompatibilityLevel Registrierungswert zwei oder mehr ist und Sie die SetCredentials--Methode nicht aufgerufen haben. Der vollständige Pfad zum registrierungswert LMCompatibilityLevel ist HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LmCompatibilityLevel.

Beachten Sie, dass sich das Ändern des LMCompatibilityLevel Registrierungswerts auf andere Anwendungen und Dienste auswirken kann, die auf dem Computer ausgeführt werden.

Wenn das Festlegen des LMCompatibilityLevel Registrierungswerts ein Problem ist, können Sie den Registrierungswert UseLMCompat unter HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\BITSerstellen. Der Registrierungswert ist ein DWORD. In der folgenden Tabelle sind die möglichen Werte für UseLMCompataufgeführt:

Wert Beschreibung
0 BITS sendet implizite Anmeldeinformationen, wenn der Server zur Eingabe von NTLM- oder Kerberos-Anmeldeinformationen auffordert.
1 BITS sendet implizite Anmeldeinformationen nur, wenn der LMCompatibilityLevel Registrierungswert des Clientcomputers größer oder gleich 2 ist.
2 BITS sendet implizite Anmeldeinformationen nur, wenn die Anwendung die methode SetCredentials aufgerufen hat.

BITS verwendet einen Standardwert von "2" für den UseLMCompat Registrierungswert, wenn der Registrierungswert nicht vorhanden ist.

Verwenden von Zertifikaten für die Client-/Serverauthentifizierung

Bei der sicheren Client-/Serverkommunikation können Clients und Server digitale Zertifikate verwenden, um sich gegenseitig zu authentifizieren. BITS unterstützt automatisch die zertifikatbasierte Serverauthentifizierung für sichere HTTP-Transporte. Rufen Sie zum Bereitstellen von BITS das für die gegenseitige Authentifizierung erforderliche Clientzertifikat entweder die IBackgroundCopyJobHttpOptions::SetClientCertificateByID oder IBackgroundCopyJobHttpOptions::SetClientCertificateByName Methode auf.

Wenn eine Website ein SSL-Clientzertifikat akzeptiert, aber kein SSL-Clientzertifikat erfordert und der BITS-Auftrag kein Clientzertifikat angibt, schlägt der Auftrag mit ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED (0x80072f0c) fehl.

So behandeln Sie authentifizierte Proxyszenarien, für die benutzerspezifische Einstellungen erforderlich sind

Wenn Sie BITS in einer Umgebung verwenden, die proxyauthentifizierung erfordert, während sie als Konto ohne verwendbare NTLM- oder Kerberos-Anmeldeinformationen in der Netzwerkdomäne des Computers ausgeführt wird, müssen Sie zusätzliche Schritte ausführen, um sich ordnungsgemäß zu authentifizieren, indem Sie die Anmeldeinformationen eines anderen Benutzerkontos verwenden, das über Anmeldeinformationen für die Domäne verfügt. Dies ist ein typisches Szenario, wenn Ihr BITS-Code als Systemdienst wie LocalService, NetworkService oder LocalSystem ausgeführt wird, da diese Konten keine verwendbaren NTLM- oder Kerberos-Anmeldeinformationen haben.

Die in BITS verwendete Proxyerkennungslogik führt Folgendes aus, wenn ein Netzwerkhilfstoken (BG_TOKEN_NETWORK) festgelegt wird:

  • Wenn IBackgroundCopyJob::SetProxySettings mit BG_JOB_PROXY_USAGE_PRECONFIGaufgerufen wurde, lesen Sie lokale IE-Proxyeinstellungen mithilfe des Identitätswechsels des Auftragsbesitzertokens über WinHttpGetIEProxyConfigForCurrentUser. Ab Windows 10, Version 1809 (10.0; Build 17763), die Hilfstokenidentität wird für diesen Schritt verwendet.
  • Wenn IBackgroundCopyJob::SetProxySettings mit BG_PROXY_USAGE_AUTODETECT aufgerufen wurde oder wenn die IE-Einstellungen aus dem BG_JOB_PROXY_USAGE_PRECONFIG Fall die automatische Erkennung oder eine Autokonfigurations-URL angeben, führen Sie dann die Autoproxyerkennung oder das WebProxy AutoDiscovery-Protokoll (WPAD) mithilfe des Hilfstokenwechsels über WinHttpGetProxyForUrlaus.

Danach wird der Identitätswechsel des Hilfstokens für die Proxy- oder Serverauthentifizierung verwendet.

Ab Windows 10, Version 1809 (10.0; Build 17763), das authentifizierte Proxyszenario mit benutzerspezifischen Anmeldeinformationen wird vereinfacht.

  1. Rufen Sie die SetCredentials-Methode des BITS-Auftrags mit BG_AUTH_SCHEME_NEGOTIATE, UserName- auf NULL-festgelegt, Kennwort auf NULL-festgelegt und Ziel- auf BG_AUTH_TARGET_PROXYfestgelegt ist. Dies bewirkt, dass die impliziten Anmeldeinformationen des Benutzerkontos für die NTLM- und Kerberos-Authentifizierung mit dem Proxy und dem Server verwendet werden.
  2. Rufen Sie IBackgroundCopyJob::SetProxySettings mit BG_JOB_PROXY_USAGE_PRECONFIGauf.
  3. QueryInterface für IBitsTokenOptions.
  4. Identität des Benutzerkontos, das Sie für NTLM/Kerberos-Anmeldeinformationen verwenden.
  5. Rufen Sie SetHelperTokenauf.
  6. Rufen Sie SetHelperTokenFlags mit BG_TOKEN_NETWORKauf.
  7. Identitätswechsel wiederherstellen.
  8. Setzen Sie die Auftragseinrichtung fort.
  9. Rufen Sie " fortsetzen" für den Auftrag auf.

Vor Windows 10, Version 1809 (10.0; Build 17763), die richtige Benutzeridentität (die Identität des Hilfstokens) wird für die netzwerkbasierte Proxyerkennung (WPAD) und für die Proxyauthentifizierung verwendet, aber die tatsächliche Erkennung lokaler (IE)-Proxyeinstellungen erfolgt immer mithilfe des Token des Auftragsbesitzers, auch wenn ein Hilfstoken konfiguriert ist. Um diesen Kurzschluss zu umgehen, können Sie die folgenden Schritte ausführen.

  1. Identität des Benutzerkontos, das Sie für NTLM/Kerberos-Anmeldeinformationen verwenden.
  2. Rufen Sie die IE-Proxyeinstellungen des Benutzerkontos ab, indem Sie WinHttpGetIEProxyConfigForCurrentUseraufrufen.
  3. Identitätswechsel wiederherstellen.
  4. Rufen Sie die SetCredentials-Methode des BITS-Auftrags mit BG_AUTH_SCHEME_NEGOTIATE, UserName- auf NULL-festgelegt, Kennwort auf NULL-festgelegt und Ziel- auf BG_AUTH_TARGET_PROXYfestgelegt ist. Dies bewirkt, dass die impliziten Anmeldeinformationen des Benutzerkontos für die NTLM- und Kerberos-Authentifizierung mit dem Proxy und dem Server verwendet werden.
  5. Wenn Schritt 2 benutzerspezifische Proxyeinstellungen (d. h. lpszProxy oder lpszProxyBypass nicht NULL-sind), legen Sie die entsprechenden Auftragseinstellungen manuell fest, indem Sie SetProxySettings mit der einstellung BG_JOB_PROXY_USAGE_OVERRIDE verwenden.
  6. Wenn Schritt 2 keine benutzerspezifischen Proxyeinstellungen lieferte, rufen Sie SetProxySettings mit BG_JOB_USAGE_PRECONFIGauf.
  7. QueryInterface für IBitsTokenOptions.
  8. Identitätswechsel des Benutzerkontos erneut.
  9. Rufen Sie SetHelperTokenauf.
  10. Rufen Sie SetHelperTokenFlags mit BG_TOKEN_NETWORKauf.
  11. Identitätswechsel wiederherstellen.
  12. Setzen Sie die Auftragseinrichtung fort.
  13. Rufen Sie " fortsetzen" für den Auftrag auf.