Authentification (BITS)

BITS prend en charge l’authentification de base, l’authentification Passport et plusieurs schémas d’authentification de défi/réponse. Si le serveur ou le proxy nécessite l’authentification de l’utilisateur, utilisez la fonction IBackgroundCopyJob2::SetCredentials pour spécifier les informations d’identification de l’utilisateur. BITS utilise cryptoAPI pour protéger les informations d’identification.

Pour définir les informations d’identification pour l’authentification de base, utilisez la fonction SetCredentials pour spécifier le nom d’utilisateur et le mot de passe. Vous ne devez utiliser l’authentification de base qu’avec https:// sites web sécurisés protégés ; sinon, le nom d’utilisateur et le mot de passe seront visibles par les utilisateurs.

Il est possible d’incorporer le nom d’utilisateur et le mot de passe dans l’URL. Cette pratique n’est pas considérée comme une bonne pratique de sécurité et est déconseillée dans la RFC 3986 (section 3.2.1).

Pour l’authentification Passport , BITS prend uniquement en charge les informations d’identification explicites, et non les informations d’identification implicites liées au compte.

Pour l’authentification de contestation/réponse, BITS emprunte l’identité de l’utilisateur et utilise Snego pour déterminer l’authentification de défi/réponse à utiliser, comme NTLM ou le protocole Kerberos. Pour obtenir la liste des schémas de défi/réponse pris en charge par BITS, consultez BG_AUTH_SCHEME.

Les travaux BITS peuvent échouer si l’authentification anonyme et un autre schéma d’authentification sont activés dans le répertoire virtuel du serveur et si les listes de contrôle d’accès protègent le répertoire virtuel ou téléchargent des fichiers. Par exemple, un travail échoue avec « accès refusé » si l’authentification anonyme et intégrée est activée dans le répertoire virtuel et si le fichier contient une liste de contrôle d’accès qui autorise uniquement Ben à lire le fichier. Cela se produit parce que le répertoire virtuel autorise l’accès anonyme, de sorte qu’IIS n’authentifie pas explicitement Ben (les informations d’identification de Ben ne sont pas utilisées pour accéder au fichier et l’accès est refusé).

Utilisation d’informations d’identification implicites

Pour utiliser les informations d’identification implicites (ouverture de session) de l’utilisateur pour l’authentification NTLM ou Kerberos, appelez la méthode IBackgroundCopyJob2::SetCredentials et définissez les membres UserName et Password de la structure BG_BASIC_CREDENTIALS sur NULL. Si vous spécifiez des informations d’identification implicites pour un proxy, BITS utilisera également les informations d’identification implicites pour l’authentification du serveur, sauf si vous spécifiez des informations d’identification de serveur explicites.

Pour plus d’informations sur les services, consultez Comptes de service et BITS.

Vous pouvez également modifier la valeur de Registre LMCompatibilityLevel ou UseLMCompat ; Toutefois, vous devez modifier ces valeurs uniquement si vous avez une application existante qui ne peut pas être modifiée pour appeler la méthode SetCredentials .

BITS utilise des informations d’identification implicites pour l’authentification si la valeur de Registre LMCompatibilityLevel est égale ou supérieure à deux et que vous n’avez pas appelé la méthode SetCredentials . Le chemin d’accès complet à la valeur de Registre LMCompatibilityLevel est HKEY_LOCAL_MACHINE\contrôle\CurrentControlSet\système\LSA\LmCompatibilityLevel.

Notez que la modification de la valeur de Registre LMCompatibilityLevel peut affecter d’autres applications et services en cours d’exécution sur l’ordinateur.

Si la définition de la valeur de Registre LMCompatibilityLevel est un problème, vous pouvez créer la valeur de Registre UseLMCompat sous HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\BITS. La valeur du Registre est un DWORD. Le tableau suivant répertorie les valeurs possibles pour UseLMCompat :

Valeur	Description
0	BITS envoie des informations d’identification implicites chaque fois que le serveur demande des informations d’identification NTLM ou Kerberos.
1	BITS envoie des informations d’identification implicites uniquement si la valeur de Registre LMCompatibilityLevel de l’ordinateur client est supérieure ou égale à 2.
2	BITS envoie des informations d’identification implicites uniquement si l’application a appelé la méthode SetCredentials .

BITS utilise la valeur par défaut « 2 » pour la valeur de Registre UseLMCompat si la valeur du Registre n’existe pas.

Utilisation de certificats pour l’authentification client/serveur

Dans la communication client/serveur sécurisée, les clients et les serveurs peuvent utiliser des certificats numériques pour s’authentifier mutuellement. BITS prend automatiquement en charge l’authentification de serveur basée sur des certificats pour des transports HTTP sécurisés. Pour fournir BITS le certificat client nécessaire pour l’authentification mutuelle, appelez la méthode IBackgroundCopyJobHttpOptions::SetClientCertificateByID ou IBackgroundCopyJobHttpOptions::SetClientCertificateByName .

Lorsqu’un site web accepte, mais n’a pas besoin d’un certificat client SSL, et que le travail BITS ne spécifie pas de certificat client, le travail échoue avec ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED (0x80072f0c).

Comment gérer des scénarios de proxy authentifiés qui nécessitent des paramètres spécifiques à l’utilisateur

Si vous utilisez BITS dans un environnement qui nécessite l’authentification proxy tout en exécutant en tant que compte sans informations d’identification NTLM ou Kerberos utilisables dans le domaine réseau de l’ordinateur, vous devez prendre des mesures supplémentaires pour vous authentifier correctement en utilisant les informations d’identification d’un autre compte d’utilisateur disposant d’informations d’identification sur le domaine. Il s’agit d’un scénario classique lorsque votre code BITS s’exécute en tant que service système tel que LocalService, NetworkService ou LocalSystem, car ces comptes ne disposent pas d’informations d’identification NTLM ou Kerberos utilisables.

La logique de détection de proxy utilisée dans BITS effectue les opérations suivantes lorsqu’un jeton d’assistance réseau (BG_TOKEN_NETWORK) est défini :

• Si IBackgroundCopyJob::SetProxySettings a été appelé avec BG_JOB_PROXY_USAGE_PRECONFIG, lisez les paramètres de proxy IE local à l’aide de l’emprunt d’identité du contexte de jeton du propriétaire du travail via WinHttpGetIEProxyConfigForCurrentUser. À partir de Windows 10, version 1809 (10.0 ; Build 17763), l’identité de jeton d’assistance est utilisée pour cette étape.
• Si IBackgroundCopyJob::SetProxySettings a été appelé avec BG_PROXY_USAGE_AUTODETECT ou si les paramètres IE du cas BG_JOB_PROXY_USAGE_PRECONFIG spécifient la détection automatique ou une URL de configuration automatique, effectuez la détection automatique du proxy ou le protocole WPAD (Web Proxy Autodiscovery Protocol), à l’aide de l’emprunt d’identité de jeton d’assistance via WinHttpGetProxyForUrl.

Après cela, l’emprunt d’identité de jeton d’assistance est utilisé pour l’authentification du proxy ou du serveur.

À partir de Windows 10, version 1809 (10.0 ; Build 17763), le scénario de proxy authentifié avec des informations d’identification spécifiques à l’utilisateur est simplifié.

1. Appelez la méthode SetCredentials du travail BITS avec BG_AUTH_SCHEME_NEGOTIATE, UserName défini sur NULL, Password défini sur NULL et Target défini sur BG_AUTH_TARGET_PROXY. Cela entraîne l’utilisation des informations d’identification implicites du compte d’utilisateur pour l’authentification NTLM et Kerberos avec le proxy et le serveur.
2. Appelez IBackgroundCopyJob::SetProxySettings avec BG_JOB_PROXY_USAGE_PRECONFIG.
3. QueryInterface pour IBitsTokenOptions.
4. Empruntez l’identité du compte d’utilisateur que vous utilisez pour les informations d’identification NTLM/Kerberos.
5. Appelez SetHelperToken.
6. Appelez SetHelperTokenFlags avec BG_TOKEN_NETWORK.
7. Rétablir l’emprunt d’identité.
8. Poursuivez la configuration du travail.
9. Appelez CV sur le travail.

Avant Windows 10, version 1809 (10.0 ; Build 17763), l’identité utilisateur correcte (l’identité du jeton d’assistance) est utilisée pour la détection de proxy basée sur le réseau (WPAD) et pour l’authentification proxy, mais la détection réelle des paramètres de proxy locaux (IE) est toujours effectuée à l’aide du jeton du propriétaire du travail, même lorsqu’un jeton d’assistance est configuré. Pour contourner cette lacune, vous pouvez suivre ces étapes.

1. Empruntez l’identité du compte d’utilisateur que vous utilisez pour les informations d’identification NTLM/Kerberos.
2. Récupérez les paramètres de proxy IE du compte d’utilisateur en appelant WinHttpGetIEProxyConfigForCurrentUser.
3. Rétablir l’emprunt d’identité.
4. Appelez la méthode SetCredentials du travail BITS avec BG_AUTH_SCHEME_NEGOTIATE, UserName défini sur NULL, Password défini sur NULL et Target défini sur BG_AUTH_TARGET_PROXY. Cela entraîne l’utilisation des informations d’identification implicites du compte d’utilisateur pour l’authentification NTLM et Kerberos avec le proxy et le serveur.
5. Si l’étape 2 a généré des paramètres de proxy spécifiques à l’utilisateur (par exemple , lpszProxy ou lpszProxyBypass ne sont pas NULL), définissez manuellement les paramètres de travail correspondants à l’aide de SetProxySettings avec le paramètre BG_JOB_PROXY_USAGE_OVERRIDE .
6. Si l’étape 2 n’a pas donné de paramètres proxy spécifiques à l’utilisateur, appelez SetProxySettings avec BG_JOB_USAGE_PRECONFIG.
7. QueryInterface pour IBitsTokenOptions.
8. Empruntez à nouveau l’identité du compte d’utilisateur.
9. Appelez SetHelperToken.
10. Appelez SetHelperTokenFlags avec BG_TOKEN_NETWORK.
11. Rétablir l’emprunt d’identité.
12. Poursuivez la configuration du travail.
13. Appelez CV sur le travail.