Проблемы проверки подлинности пользователей с поставщиком WinNT в интерфейсах службы Active Directory
В этой статье описываются проблемы с проверкой подлинности пользователей с помощью поставщика WinNT в интерфейсах службы Active Directory (ADSI).
Применяется к: Windows 10 — все выпуски
Исходный номер базы знаний: 218497
Итоги
Метод ADSI OpenDsObject или вспомогательный компонент ADsOpenDsObject C позволяет предоставлять учетные данные проверки подлинности серверу каталогов при открытии объекта. Существует ряд проблем, которые следует учитывать при использовании этого метода с поставщиком WinNT интерфейсов служб Active Directory.
Дополнительная информация
Поставщик WinNT интерфейсов служб Active Directory использует функцию WNetAddConnection2 для подключения к \\servername\IPC$ для установки этих учетных данных с удаленным сервером. Этот метод полезен, так как он не требует специальных привилегий для клиентов NT и работает в Windows и поддерживает проверку подлинности в ненадежных доменах.
К сожалению, существует несколько недостатков, присущих функции WNetAddConnection2 , и они приведены следующим образом:
Если подключение уже установлено на целевом сервере любым процессом, выполняющимся на клиентском компьютере, функция WNetAddConnection2 не может создать новое подключение под учетными данными, кроме тех, которые используются для существующего подключения.
При попытке пройти проверку подлинности новой учетной записи вы получите конфликтующую ошибку учетных данных. Если вы попытаетесь выполнить проверку подлинности существующей учетной записи, любой пароль будет работать (допустимый или нет). Эта проблема возникает при получении объектов из контроллера домена, в котором многие системные процессы устанавливают подключения к контроллерам домена.
Если гостевая учетная запись включена на целевом компьютере, можно передать недопустимое имя пользователя и пароль, а также создать подключение.
Система не ссылается на подключения счетчиков, поэтому, если какой-либо процесс, включая клиентский процесс интерфейсов служб Active Directory, удаляет подключение, то все процессы, использующие это соединение, необходимо записать, чтобы повторно установить его при обнаружении его удаления.
При использовании поставщика WinNT рекомендуется пройти проверку подлинности с помощью целевого сервера, выполнив вход в учетную запись домена с соответствующими учетными данными или используя функцию LogonUser (которая требует повышенных привилегий) перед выполнением кода интерфейсов службы Active Directory. Мы также рекомендуем не использовать метод OpenDsObject интерфейса службы Active Directory для проверки учетных данных пользователя на любом домене, доверенном клиентским компьютером.
Если вы пытаетесь проверить учетные записи из ненадежных доменов, используйте метод OpenDsObject интерфейсов служб Active Directory, учитывая перечисленные выше проблемы и понимая, что вы будете отправлять незашифрованные пароли через сеть. Эти ограничения можно преодолеть, выполнив код проверки в качестве службы по крайней мере на одном сервере в каждом наборе ненадежных доменов с помощью подключения SSL (или HTTPS) для обеспечения шифрования. Это можно сделать с помощью файла проверки .asp на сервере IIS в каждом наборе недоверенных доменов и подключиться к нему по протоколу HTTPS с помощью базовой проверки подлинности.
Метод OpenDsObject интерфейсов служб Active Directory использует учетные данные пользователя, вошедшего в систему, для доступа к службам IIS. Имя пользователя и пароль, заданные в качестве параметров, игнорируются. Отображается следующее сообщение об ошибке:
доступ запрещен
Однако он работает после добавления пользователя клиента в группу администраторов сервера.
Он также работает при использовании следующего кода скрипта.
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