Partager via

Problèmes d’authentification utilisateur avec le fournisseur WinNT des interfaces de service Active Directory

  • Article

Cet article décrit les problèmes d’authentification des utilisateurs avec le fournisseur WinNT (Active Directory Service Interfaces) WinNT.

Applicabilité : Windows 10 - Toutes les éditions
Numéro de base de connaissances d’origine : 218497

Résumé

La méthode ADSI OpenDsObject ou la fonction d’assistance C ADsOpenDsObject vous permet de fournir des informations d’identification d’authentification au serveur d’annuaire lorsque vous ouvrez un objet. Il existe un certain nombre de problèmes que vous devez connaître lorsque vous utilisez cette technique avec le fournisseur WinNT des interfaces de service Active Directory.

Plus d’informations

Le fournisseur WinNT des interfaces de service Active Directory utilise la fonction WNetAddConnection2 pour établir une connexion à \\servername\IPC$ afin d’établir ces informations d’identification avec le serveur distant. Cette méthode est utile, car elle ne nécessite pas de privilèges spéciaux pour les clients NT et fonctionne sur Windows et prend en charge l’authentification entre les domaines non approuvés.

Malheureusement, il existe plusieurs inconvénients inhérents à la fonction WNetAddConnection2 et sont les suivants :

  • Si une connexion a déjà été établie sur le serveur cible par un processus exécuté sur l’ordinateur client, la fonction WNetAddConnection2 ne peut pas établir une nouvelle connexion sous des informations d’identification autres que celles utilisées pour la connexion existante.

    Si vous essayez d’authentifier un nouveau compte, vous obtenez une erreur d’informations d’identification en conflit. Si vous essayez d’authentifier le compte existant, tout mot de passe fonctionne (valide ou non). Il s’agit d’un problème particulier lorsque vous obtenez des objets à partir d’un contrôleur de domaine où de nombreux processus système établissent des connexions aux contrôleurs de domaine.

  • Si le compte invité est activé sur l’ordinateur de destination, il est possible de transmettre un nom d’utilisateur et un mot de passe non valides et de créer une connexion.

  • Le système ne fait pas référence aux connexions. Par conséquent, si un processus, y compris votre processus client Active Directory Service Interfaces, supprime la connexion, tous les processus utilisant cette connexion doivent être écrits pour le rétablir lorsqu’ils le trouvent supprimés.

Lorsque vous utilisez le fournisseur WinNT, nous vous recommandons de vous authentifier auprès du serveur cible en vous connectant à un compte de domaine avec les informations d’identification appropriées ou en utilisant la fonction LogonUser (qui nécessite des privilèges élevés) avant d’exécuter votre code d’interfaces de service Active Directory. Nous vous recommandons également de ne pas utiliser la méthode OpenDsObject des interfaces de service Active Directory pour valider les informations d’identification d’un utilisateur sur n’importe quel domaine approuvé par votre ordinateur client.

Si vous tentez de valider des comptes à partir de domaines non approuvés, utilisez la méthode OpenDsObject des interfaces de service Active Directory, en conservant les problèmes répertoriés ci-dessus et en comprenant que vous envoyez des mots de passe non chiffrés sur le réseau. Vous pouvez surmonter ces restrictions en exécutant le code de validation en tant que service sur au moins un serveur dans chaque ensemble de domaines non approuvés à l’aide d’une connexion SSL (ou HTTPS) pour fournir le chiffrement. Pour ce faire, utilisez un fichier de validation .asp sur un serveur IIS dans chaque ensemble de domaines non approuvés et connectez-vous à celui-ci via HTTPS à l’aide de l’authentification de base.

La méthode OpenDsObject des interfaces de service Active Directory utilise les informations d’identification de l’utilisateur connecté pour accéder à IIS. Nom d’utilisateur et mot de passe donnés en tant que paramètres ignorés. Vous recevez le message d’erreur suivant :

Accès refusé

Toutefois, elle fonctionne après l’ajout de l’utilisateur connecté du client au groupe Administrateurs du serveur.

Cela fonctionne également si vous utilisez le code de script suivant.

Set objLogon = CreateObject("LoginAdmin.ImpersonateUser")  
objLogon.Logon "Administrator", "AdminPassword", "Machinename"  
Set oNS = GetObject("IIS:")
Set oRoot = oNS.OpenDSObject("IIS://SERVER/SHARE", "Mordor\administrator", "Gollum", 1)'User credentials are ignored  
objLogon.Logoff
Set objLogon = Nothing