Autenticazione (BITS)

BITS supporta l'autenticazione di base, l'autenticazione Passport e diversi schemi di autenticazione di richiesta/risposta. Se il server o il proxy richiede l'autenticazione utente, usare la funzione IBackgroundCopyJob2::SetCredentials per specificare le credenziali dell'utente. BITS usa CryptoAPI per proteggere le credenziali.

Per impostare le credenziali per l'autenticazione di base, usare la funzione SetCredentials per specificare il nome utente e la password. È consigliabile usare solo l'autenticazione di base con https:// siti Web protetti; in caso contrario, il nome utente e la password saranno visibili agli utenti.

È possibile incorporare il nome utente e la password nell'URL. Questa procedura non è considerata una buona procedura di sicurezza ed è deprecata in RFC 3986 (sezione 3.2.1).

Per l'autenticazione Passport , BITS supporta solo le credenziali esplicite, non le credenziali implicite associate all'account.

Per l'autenticazione di richiesta/risposta, BITS rappresenta l'utente e usa Snego per determinare quale autenticazione di richiesta/risposta usare, ad esempio NTLM o il protocollo Kerberos. Per un elenco di schemi di richiesta/risposta supportati da BITS, vedere BG_AUTH_SCHEME.

I processi BITS possono avere esito negativo se la directory virtuale nel server dispone di autenticazione anonima e un altro schema di autenticazione abilitato e se gli ACL proteggono la directory virtuale o scaricano i file. Ad esempio, un processo non riesce con "accesso negato" se la directory virtuale ha l'autenticazione anonima e integrata abilitata e il file contiene un ACL che consente solo a Ben di leggere il file. Ciò si verifica perché la directory virtuale consente l'accesso anonimo, quindi IIS non autentica in modo esplicito Ben (le credenziali di Ben non vengono usate per accedere al file e l'accesso viene negato).

Uso di credenziali implicite

Per usare le credenziali implicite (di accesso) dell'utente per l'autenticazione NTLM o Kerberos, chiamare il metodo IBackgroundCopyJob2::SetCredentials e impostare i membri UserName e Password della struttura BG_BASIC_CREDENTIALS su NULL. Se si specificano credenziali implicite per un proxy, BITS userà anche le credenziali implicite per l'autenticazione del server, a meno che non si specifichino credenziali esplicite del server.

Per altre informazioni sui servizi, vedere Account di servizio e BITS.

È anche possibile modificare il valore del Registro di sistema LMCompatibilityLevel o UseLMCompat . È tuttavia necessario modificare questi valori solo se si dispone di un'applicazione esistente che non può essere modificata per chiamare il metodo SetCredentials .

BITS userà le credenziali implicite per l'autenticazione se il valore del Registro di sistema LMCompatibilityLevel è due o superiore e non è stato chiamato il metodo SetCredentials . Il percorso completo del valore del Registro di sistema LMCompatibilityLevel è HKEY_LOCAL_MACHINE\Controllo System\CurrentControlSet\\LSA\LmCompatibilityLevel.

Si noti che la modifica del valore del Registro di sistema LMCompatibilityLevel può influire su altre applicazioni e servizi in esecuzione nel computer.

Se l'impostazione del valore del Registro di sistema LMCompatibilityLevel è un problema, è possibile creare il valore del Registro di sistema UseLMCompat in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\BITS. Il valore del Registro di sistema è DWORD. Nella tabella seguente sono elencati i valori possibili per UseLMCompat:

Valore	Descrizione
0	BITS invierà credenziali implicite ogni volta che il server richiede le credenziali NTLM o Kerberos.
1	BITS invierà credenziali implicite solo se il valore del Registro di sistema LMCompatibilityLevel del computer client è maggiore o uguale a 2.
2	BITS invierà credenziali implicite solo se l'applicazione ha chiamato il metodo SetCredentials.

BITS userà un valore predefinito "2" per il valore del Registro di sistema UseLMCompat se il valore del Registro di sistema non esiste.

Uso dei certificati per l'autenticazione client/server

Nelle comunicazioni client/server sicure, i client e i server possono usare certificati digitali per autenticarsi reciprocamente. BITS supporta automaticamente l'autenticazione server basata su certificati per i trasporti HTTP sicuri. Per fornire BITS il certificato client necessario per l'autenticazione reciproca, chiamare il metodo IBackgroundCopyJobHttpOptions::SetClientCertificateByID o IBackgroundCopyJobHttpOptions::SetClientCertificateByName.

Quando un sito Web accetta ma non richiede un certificato client SSL e il processo BITS non specifica un certificato client, il processo avrà esito negativo con ERROR_WINHTTP_CLIENT_AUTH_CERT_Nedizione Enterprise DED (0x80072f0c).

Come gestire scenari proxy autenticati che richiedono impostazioni specifiche dell'utente

Se si usa BITS in un ambiente che richiede l'autenticazione proxy durante l'esecuzione come account senza credenziali NTLM o Kerberos utilizzabili nel dominio di rete del computer, è necessario eseguire passaggi aggiuntivi per eseguire correttamente l'autenticazione usando le credenziali di un altro account utente che dispone di credenziali nel dominio. Si tratta di uno scenario tipico in cui il codice BITS è in esecuzione come servizio di sistema, ad esempio LocalService, NetworkService o LocalSystem, in quanto tali account non dispongono di credenziali NTLM o Kerberos utilizzabili.

La logica di rilevamento proxy usata in BITS esegue le operazioni seguenti quando viene impostato un token helper di rete (BG_TOKEN_NETWORK):

• Se È stato chiamato IBackgroundCopyJob::SetProxy Impostazioni con BG_JOB_PROXY_USAGE_PRECONFIG, leggere le impostazioni proxy di Internet Explorer locali usando la rappresentazione del contesto del token del proprietario del processo tramite WinHttpGetIEProxyConfigForCurrentUser. A partire da Windows 10 versione 1809 (10.0; Build 17763), l'identità del token helper viene usata per questo passaggio.
• Se IBackgroundCopyJob::SetProxy Impostazioni è stato chiamato con BG_PROXY_USAGE_AUTODETECT o se le impostazioni di Internet Explorer del caso BG_JOB_PROXY_USAGE_PRECONFIG specificano il rilevamento automatico o un URL di configurazione automatica, eseguire il rilevamento automatico del proxy o il protocollo WPAD (Web Proxy Autodiscovery Protocol), usando la rappresentazione del token helper tramite WinHttpGetProxyForUrl.

Successivamente, la rappresentazione del token helper viene usata per l'autenticazione proxy o server.

A partire da Windows 10 versione 1809 (10.0; Build 17763), lo scenario proxy autenticato con credenziali specifiche dell'utente è semplificato.

1. Chiamare il metodo SetCredentials del processo BITS con BG_AUTH_SCHEME_NEGOTIATE, UserName impostato su NULL, Password impostato su NULL e Target impostato su BG_AUTH_TARGET_PROXY. In questo modo, le credenziali implicite dell'account utente verranno usate per l'autenticazione NTLM e Kerberos con il proxy e il server.
2. Chiamare IBackgroundCopyJob::SetProxy Impostazioni con BG_JOB_PROXY_USAGE_PRECONFIG.
3. QueryInterface per IBitsTokenOptions.
4. Rappresenta l'account utente usato per le credenziali NTLM/Kerberos.
5. Chiamare SetHelperToken.
6. Chiamare SetHelperTokenFlags con BG_TOKEN_NETWORK.
7. Ripristinare la rappresentazione.
8. Continuare l'installazione del processo.
9. Chiamare Resume sul processo.

Prima di Windows 10 versione 1809 (10.0; Build 17763, l'identità utente corretta (l'identità del token helper) viene usata per il rilevamento proxy basato sulla rete (WPAD) e per l'autenticazione proxy, ma il rilevamento effettivo delle impostazioni proxy locali (IE) viene sempre eseguito usando il token del proprietario del processo, anche quando viene configurato un token helper. Per risolvere questo problema, è possibile seguire questa procedura.

1. Rappresenta l'account utente usato per le credenziali NTLM/Kerberos.
2. Recuperare le impostazioni proxy di Internet Explorer dell'account utente chiamando WinHttpGetIEProxyConfigForCurrentUser.
3. Ripristinare la rappresentazione.
4. Chiamare il metodo SetCredentials del processo BITS con BG_AUTH_SCHEME_NEGOTIATE, UserName impostato su NULL, Password impostato su NULL e Target impostato su BG_AUTH_TARGET_PROXY. In questo modo, le credenziali implicite dell'account utente verranno usate per l'autenticazione NTLM e Kerberos con il proxy e il server.
5. Se il passaggio 2 ha restituito impostazioni proxy specifiche dell'utente (ad esempio lpszProxy o lpszProxyBypass non sono NULL), impostare manualmente le impostazioni del processo corrispondenti, usando SetProxy Impostazioni con l'impostazione BG_JOB_PROXY_USAGE_OVERRIDE.
6. Se il passaggio 2 non ha restituito impostazioni proxy specifiche dell'utente, chiamare SetProxy Impostazioni con BG_JOB_USAGE_PRECONFIG.
7. QueryInterface per IBitsTokenOptions.
8. Rappresentare nuovamente l'account utente.
9. Chiamare SetHelperToken.
10. Chiamare SetHelperTokenFlags con BG_TOKEN_NETWORK.
11. Ripristinare la rappresentazione.
12. Continuare l'installazione del processo.
13. Chiamare Resume sul processo.