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, он работал как шарм.

Надеюсь, что это спасет кого-то часы головокружения. Я просто сдался.