Authentifizierung (BITS)

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

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

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

Für die Passport-Authentifizierung unterstützt BITS nur explizite Anmeldeinformationen, nicht implizite Anmeldeinformationen, die an das Konto gebunden sind.

Bei der Abfrage-/Antwortauthentifizierung nimmt BITS die Identität des Benutzers an und verwendet Snego, um zu bestimmen, welche Abfrage-/Antwortauthentifizierung verwendet werden soll, z. B. NTLM oder das Kerberos-Protokoll. Eine Liste der Abfrage-/Antwortschemas, die BITS unterstützt, finden Sie unter BG _ AUTH _ SCHEME.

BITS-Aufträge können fehlschlagen, wenn für das virtuelle Verzeichnis auf dem Server die anonyme Authentifizierung und ein anderes Authentifizierungsschema aktiviert ist und ACLs das virtuelle Verzeichnis schützen oder Dateien herunterladen. Ein Auftrag schlägt beispielsweise mit "Zugriff verweigert" fehl, wenn für das virtuelle Verzeichnis die anonyme und integrierte Authentifizierung aktiviert ist und die Datei eine Zugriffssteuerungsliste enthält, mit der nur Ben die Datei lesen kann. Dies liegt daran, dass 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 wird verweigert).

Verwenden impliziter Anmeldeinformationen

Um die impliziten Anmeldeinformationen des Benutzers für die NTLM- oder Kerberos-Authentifizierung zu verwenden, rufen Sie die IBackgroundCopyJob2::SetCredentials-Methode auf, und legen Sie die Member UserName und Password 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 Registrierungswert LMCompatibilityLevel oder UseLMCompat ä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 größer ist und Sie die SetCredentials-Methode nicht aufgerufen haben. Der vollständige Pfad zum LmCompatibilityLevel-Registrierungswert lautet 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 \ BITS erstellen. Der Registrierungswert ist ein DWORD. In der folgenden Tabelle sind die möglichen Werte für UseLMCompat aufgefü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 SetCredentials-Methode aufgerufen hat.

BITS verwendet den Standardwert "2" für den Registrierungswert UseLMCompat, 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 entweder die Methode IBackgroundCopyJobHttpOptions::SetClientCertificateByID oder IBackgroundCopyJobHttpOptions::SetClientCertificateByName auf, um BITS für die gegenseitige Authentifizierung bereitzustellen.

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.

Behandeln authentifizierter Proxyszenarien, die benutzerspezifische Einstellungen erfordern

Wenn Sie BITS in einer Umgebung verwenden, die eine Proxyauthentifizierung erfordert, während Sie als Konto ohne verwendbare NTLM- oder Kerberos-Anmeldeinformationen in der Netzwerkdomäne des Computers ausgeführt werden, 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 nicht über verwendbare NTLM- oder Kerberos-Anmeldeinformationen verfügen.

Die in BITS verwendete Proxyerkennungslogik führt folgende Schritte aus, wenn ein Netzwerkhilfstoken (BG _ TOKEN _ NETWORK) festgelegt ist:

  • Wenn IBackgroundCopyJob::SetProxySettings mit BG JOB PROXY USAGE _ _ _ _ PRECONFIG aufgerufen wurde, lesen Sie lokale IE-Proxyeinstellungen mithilfe des Kontextidentitätswechsels des Auftragsbesitzertokens über WinHttpGetIEProxyConfigForCurrentUser. Ab Windows 10, Version 1809 (10.0; Build 17763), wird die Hilfstokenidentität für diesen Schritt verwendet.
  • Wenn IBackgroundCopyJob::SetProxySettings mit BG PROXY USAGE _ _ _ AUTODETECT aufgerufen wurde oder wenn die IE-Einstellungen aus dem _ _ _ _ PRECONFIG-Fall BG JOB PROXY USAGE auto-detect oder eine URL für die automatische Konfiguration angeben, führen Sie die automatische Proxyerkennung oder das WebProxy Autodiscovery Protocol (WPAD) mithilfe des Hilfstokenidentitätswechsels über WinHttpGetProxyForUrldurch.

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

Ab Windows 10, Version 1809 (10.0; Build 17763), das Szenario für authentifizierte Proxys mit benutzerspezifischen Anmeldeinformationen wird vereinfacht.

  1. Rufen Sie die SetCredentials-Methode des BITS-Auftrags auf, wobei BG _ AUTH _ SCHEME _ NEGOTIATE, UserName auf NULL, Password set to NULL und Target auf BG _ AUTH TARGET _ _ PROXY festgelegt ist. Dies bewirkt, dass die impliziten Anmeldeinformationen des Benutzerkontos für die NTLM- und Kerberos-Authentifizierung beim Proxy und Server verwendet werden.
  2. Rufen Sie IBackgroundCopyJob::SetProxySettings mit BG JOB PROXY USAGE _ _ _ _ PRECONFIG auf.
  3. QueryInterface für IBitsTokenOptions.
  4. Annehmen der Identität des Benutzerkontos, das Sie für NTLM-/Kerberos-Anmeldeinformationen verwenden.
  5. Rufen Sie SetHelperToken auf.
  6. Rufen Sie SetHelperTokenFlags mit BG TOKEN NETWORK _ _ auf.
  7. Kehren Sie den Identitätswechsel zurück.
  8. Setzen Sie die Auftragseinrichtung fort.
  9. Rufen Sie Resume für den Auftrag auf.

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

  1. Annehmen der 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. Kehren Sie den Identitätswechsel zurück.
  4. Rufen Sie die SetCredentials-Methode des BITS-Auftrags auf, wobei BG _ AUTH _ SCHEME _ NEGOTIATE, UserName auf NULL, Password set to NULL und Target auf BG _ AUTH TARGET _ _ PROXY festgelegt ist. Dies bewirkt, dass die impliziten Anmeldeinformationen des Benutzerkontos für die NTLM- und Kerberos-Authentifizierung beim Proxy und Server verwendet werden.
  5. Wenn Schritt 2 benutzerspezifische Proxyeinstellungen ergeben hat (d. h. lpszProxy oder lpszProxyBypass sind nicht NULL), 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 ergibt, rufen Sie SetProxySettings mit BG JOB USAGE _ _ _ PRECONFIG auf.
  7. QueryInterface für IBitsTokenOptions.
  8. Identität des Benutzerkontos erneut annehmen.
  9. Rufen Sie SetHelperToken auf.
  10. Rufen Sie SetHelperTokenFlags mit BG TOKEN NETWORK _ _ auf.
  11. Kehren Sie den Identitätswechsel zurück.
  12. Setzen Sie die Auftragseinrichtung fort.
  13. Rufen Sie Resume für den Auftrag auf.