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"   />

asp.net ldap asp.net-membership activedirectorymembership
person Scott Ivey    schedule 12.08.2009    source източник

Отговори (6)


arrow_upward
4
arrow_downward

Приложението се хоства на машина без домейн, със защитна стена между сървъра на приложения и домейн контролера.

Тъй като можете да правите заявки директно с помощта на LDAP инструмент, това предполага, че защитната стена е отворена правилно. Имайте предвид обаче, че ActiveDirectoryMembershipProvider не използва обикновен стар LDAP, той използва технологии на Microsoft. Например, ако зададете connectionProtection="Secure", ADMP ще опита да използва SSL и порт 636, ако това не успее, ще използва вграденото IPSec подписване на Microsoft (вижте тази статия за повече подробности).

Както и да е, това ме кара да се чудя за няколко неща:

  1. Домейнът AD има ли IPSec „задължителна“ политика, която отказва връзки от компютри без домейн/неконфигурирани? (Вероятно не, тъй като сте се свързали с обикновен LDAP, но си струва да се проучи.)
  2. Добавили ли сте NetBIOS името на домейн контролера към вашия файл lmhosts и неговото DNS име към вашия файл с хостове? (Много протоколи проверяват дали докладваното име на тяхната цел съвпада с името, с което сте се опитали да се свържете.)
  3. Много хора са забелязали проблеми при използването на ADMP между различни домейни и решението изискваше създаването на еднопосочно доверие. Тъй като изглежда, че вашият клиентски компютър не е в домейн, не можете да имате това доверие - освен ако (a) не е член на различен домейн с еднопосочно доверие или (b) не е член на същия домейн и по този начин доверието клиент-сървър е имплицитно.
person ewall    schedule 16.09.2009
comment
Втората ви точка ме доведе до решение! Очевидно името на DNS е било променено на нашия тестов сървър, което е причинило неуспех само на ADMP, докато всеки друг метод е работил! Въпреки това, текущото заобиколно решение за мен беше да имам IP адреса вместо име на хост в моя низ за LDAP връзка, точно по същия начин, по който Скот го е настроил (вместо това не предоставям номера на порта, оставям го да избере автоматично) . - person Alan Fluka; 07.10.2015

arrow_upward
3
arrow_downward

Изглежда, че решението е да отворите порт 445.

Прочетете тази тема

Не ни е позволено да отваряме, така че предполагам, че съм заседнал.

person Community    schedule 21.08.2009
comment
Отварянето на порт 445 свърши работа за мен. Мога да се свържа през System.DirectoryServices.DirectoryEntry(...) съвсем добре, като използвам моя низ за LDAP връзка, но всички опити за свързване през ActiveDirectoryMembershipProvider биха довели до следната грешка: The specified domain or server could not be contacted. Отварянето на този порт реши проблема. - person codechurn; 03.12.2014

arrow_upward
1
arrow_downward

Можете да използвате тези две статии, може да решите проблема си

www.ddj.com/windows/184406424

forums.asp.net/t/1408268.aspx

и проверете вашите защитни стени

person emdadgar2    schedule 16.09.2009

arrow_upward
1
arrow_downward

Имах тази грешка и успях да я поправя. Има множество причини, които могат да доведат до това, ето списък със задачи, за да идентифицирате точния проблем:

  1. Създайте микро приложение с един метод Membership.GetAllUsers(), изпълнете на машина извън Active Directory (AD), с неправилна парола в низа за връзка, проверете дали получавате изключение за неправилна парола. Ако не го получите, не можете да се свържете с вашия AD сървър, проверете защитната стена, ако получите изключение за невалидна парола, преминете към следващата стъпка.

  2. Ако можете, опитайте да изпълните същото приложение, локално на AD сървър, първо с неправилна парола, а след това с правилно, изпълняващо се приложение локално предоставя по-подробно изключение какво не е наред (за мен това изключение ме накара да коригирам проблема). В моя случай ми каза, че сървърната услуга не е стартирана, отколкото тази услуга за работна станция не е стартирана.

Някои мисли относно факта, че се изискват сървърни и работни станции услуги, за да работят на сървъра: afaik Сървърната услуга се използва за споделяне на файлове с Windows (netbios през TCP) и използва 445 порт, така че може да се окаже, че този порт трябва да бъде отворен в допълнение към LDAP порт. Второто ми наблюдение беше, че събитието, ако се отвори порт 445 (netstat -an), все още може да не работи, winows ще пусне всички пакети към този порт, ако квадратчетата за споделяне на клиент на Windows и споделяне на файлове и принтери не са проверени на мрежовия интерфейсен адаптер, който е изпратил тези пакети . Проверете "telnet External_IP 445". Това е цялата информация, която събрах, докато се борех с този проблем.

person Alex Burtsev    schedule 09.11.2011

arrow_upward
0
arrow_downward

Тествали ли сте с LDAP инструмент за сърфиране от отдалечената кутия, за да видите дали може да се свърже с критериите, използвани тук? т.е. Проблем с връзката ли е или нещо друго?

person geoffc    schedule 13.08.2009
comment
Да - можем да правим заявки с помощта на LDAP инструмент, използвайки същата информация. Това ме озадачава. Едно странно нещо, което забелязах е, че доставчикът на членство в AD се опитва да получи NetBIOS името на сървъра, към който се свързвате (изрових това с рефлектор) - и че по време на това има опит/улов, който хвърля точното съобщение които получаваме. Не знам защо доставчикът смята, че се нуждае от netbios името на сървъра. - person Scott Ivey; 13.08.2009

arrow_upward
0
arrow_downward

В случай, че някой се натъкне на това и иска да си разбие главата в стената... Наскоро се опитах да направя всичко това за AD сървър, който моята компания имаше в домейн, различен от текущия контекст. Използваше предоставения IP и получаваше грешки, както е посочено тук. Дори използвах инструмент като Softerra LDAP Admin и той работи добре, но AccountManagement се провали.

Имахме публично изложен URL адрес, свързан с този IP адрес (все още позволявайки само на определени IP адреси да извършват повиквания). След като замених IP-то с предоставения URL, заработи като чар.

Надявам се това да спести на някого часовете разбиване на главата, през които току-що се подложих.

person Ricky Hartmann    schedule 12.02.2015