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