ActiveDirectoryMembershipProvider "Не удалось связаться с указанным доменом или сервером".
У меня есть приложение, использующее ActiveDirectoryMembershipProvider для предоставления доступа пользователям. Приложение размещено на машине без домена, с межсетевым экраном между сервером приложений и контроллером домена.
Мы открыли порт LDAP для DC во внутренней сети, но независимо от того, что мы пытаемся, мы получаем ошибку, в которой говорится: "Не удалось связаться с указанным доменом или сервером".
Есть ли у кого-нибудь предложения о том, как я могу это решить? Мы пробовали все, о чем мы можем думать, и просто ничего не получаем.
Моя строка подключения:
<add name="ADConnectionString"
connectionString="LDAP://10.5.3.7:389/DC=MyTestDomain,DC=local"/>
И мой провайдер:
<add name="ActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider"
connectionStringName="ADConnectionString"
attributeMapUsername="SAMAccountName"
connectionProtection="None"
connectionUsername="LdapUser"
connectionPassword="LdapPassword" />
Ответы
Ответ 1
Приложение размещено на машине без домена, с межсетевым экраном между сервером приложений и контроллером домена.
Поскольку вы можете напрямую запросить инструмент LDAP, это говорит о том, что брандмауэр открыт правильно. Однако имейте в виду, что ActiveDirectoryMembershipProvider
не использует простой старый LDAP, используя технологии Microsoft. Например, если вы установите connectionProtection="Secure"
, ADMP попытается использовать SSL и порт 636, если это не удастся, он будет использовать встроенную подпись IPSec Microsoft (см. эту статью для получения более подробной информации).
В любом случае, это заставляет меня задуматься о нескольких вещах:
- Существует ли в домене AD "требуемая" политика IPSec, которая отказывает подключениям от не-доменных/неконфигурированных компьютеров? (Наверное, нет, поскольку вы связаны с простым LDAP, но это стоит исследовать.)
- Вы добавили имя NetBIOS контроллера домена в свой файл lmhosts и его DNS-имя в свой файл hosts? (Многие протоколы проверяют, что имя их целевого имени совпадает с именем, к которому вы пытались подключиться.)
- Многие люди отмечают проблемы с использованием ADMP между разными доменами, а решение требует создания одностороннего доверия. Поскольку это похоже на то, что ваш клиентский компьютер не находится в домене, у вас не может быть этого доверия - если только он не является членом другого домена с односторонним доверием или (b) он является членом тот же домен и, следовательно, доверие клиент-сервер неявно.
Ответ 2
Кажется, что решение состоит в том, чтобы открыть порт 445.
Прочтите эту тему
Нам не разрешено открывать, поэтому я думаю, что застрял.
Ответ 3
Вы можете использовать эти две статьи, может решить вашу проблему
www.ddj.com/windows/184406424
forums.asp.net/t/1408268.aspx
и проверьте свои брандмауэры
Ответ 4
У меня была эта ошибка, и мне удалось ее исправить. Существует несколько причин, которые могут привести к этому, вот список дел для выявления проблемы с exect:
-
Создайте микроприложение с помощью единого метода Membership.GetAllUsers(), выполняемого на компьютере вне Active Directory (AD), с неправильным паролем в строке подключения, проверьте, если вы получаете неправильное исключение пароля. Если вы этого не сделаете, вы не можете подключиться к своему серверу AD, проверьте брандмауэр, если вы получите недопустимое исключение пароля, перейдите к следующему шагу.
-
Если вы можете, попробуйте выполнить такое же приложение, локально на сервере AD, сначала с неправильным паролем, чем с правильным, выполнение приложения локально предоставляет более подробное исключение, что не так (для меня это исключение приводит меня к устранению проблемы). В моем случае он сказал мне, что служба сервера не запущена, чем эта служба рабочей станции не запущена.
Некоторые мысли о том, что для работы на сервере необходимы серверные и рабочие станции: служба afaik Server используется для совместного использования файлов Windows (netbios over TCP) и использует порт 445, поэтому, возможно, этот порт должен открывается в дополнение к порту LDAP. Мое второе наблюдение заключалось в том, что событие, открытое портом 445 (netstat -an), по-прежнему не может работать, winones будут отбрасывать все пакеты на этот порт, если флажки Windows Client и File and Printer sharing не отмечены на сетевом интерфейсном адаптере, который обновил эти пакеты, Проверьте "telnet External_IP 445". Thats вся информация, которую я собрал, борясь с этой проблемой.
Ответ 5
Вы проверили с помощью инструмента просмотра LDAP из удаленного окна, чтобы узнать, может ли он подключаться к критериям, которые здесь используются? То есть Это проблема подключения или что-то еще?
Ответ 6
В случае, если кто-то наткнется на это и захочет разбить голову на стене... Недавно попытался сделать все это для сервера AD, который у моей компании был в другом домене, чем в текущем контексте. Использовал предоставленный IP и получил сбои, как указано здесь. Даже использовал такой инструмент, как SOTERTRA LDAP Admin, и он работал нормально, однако AccountManagement не удалось.
У нас был открытый URL, привязанный к этому IP-адресу (все еще позволяющий определенному IP-адресу совершать вызовы). Как только я заменил IP с предоставленным URL, он работал как шарм.
Надеюсь, что это спасет кого-то часы головокружения. Я просто сдался.