2009-08-12 22 views
10

Mam aplikacji, która używa ActiveDirectoryMembershipProvider do przyznania dostępu do użytkowników. Aplikacja jest hostowana na komputerze nie będącym domeną, z zaporą ogniową między serwerem aplikacji a kontrolerem domeny.ActiveDirectoryMembershipProvider "Nie można skontaktować się z określoną domeną lub serwerem."

Otworzyliśmy port LDAP do DC w wewnętrznej sieci - jednak bez względu na to, co próbujemy, otrzymujemy komunikat o błędzie "Nie można skontaktować się z określoną domeną lub serwerem".

Czy ktoś ma jakieś sugestie, w jaki sposób mogę rozwiązać ten problem? Próbowaliśmy wszystkiego, co możemy wymyślić i po prostu nigdzie się nie dostaliśmy.

Moje ciąg połączenia jest:

<add name="ADConnectionString" 
    connectionString="LDAP://10.5.3.7:389/DC=MyTestDomain,DC=local"/> 

A mój usługodawca:

<add name="ActiveDirectoryMembershipProvider" 
    type="System.Web.Security.ActiveDirectoryMembershipProvider" 
    connectionStringName="ADConnectionString" 
    attributeMapUsername="SAMAccountName" 
    connectionProtection="None" 
    connectionUsername="LdapUser" 
    connectionPassword="LdapPassword" /> 

Odpowiedz

0

Czy testowane narzędzie przeglądania LDAP, ze zdalnej skrzynki, aby zobaczyć, czy można to połączyć z kryteriami używane tutaj? To znaczy. Czy jest to problem z łącznością, czy coś innego?

+0

Tak - możemy przesyłać zapytania przy użyciu narzędzia LDAP, korzystając z tych samych informacji. To mnie martwi. Jedną z dziwnych rzeczy, które zauważyłem, jest to, że dostawca członkostwa AD próbuje uzyskać nazwę NetBIOS serwera, z którym się łączysz (przekopałeś to za pomocą reflektora) - i że podczas tego jest próba/catch, która rzuca dokładnie wiadomość że dostaję. Nie wiesz, dlaczego dostawca uważa, że ​​potrzebuje nazwy NetBIOS serwera. –

3

Wydaje się, że rozwiązaniem jest otwarty port 445.

Read this thread

Nie wolno otwierać, więc myślę, że utknąłem.

+0

Otwarcie portu 445 załatwiło sprawę. Mógłbym połączyć się przez 'System.DirectoryServices.DirectoryEntry (...)' dobrze używając mojego ciągu połączenia LDAP, ale wszelkie próby połączenia przez 'ActiveDirectoryMembershipProvider' przyniosłyby następujący błąd:' Nie można skontaktować się z określoną domeną lub serwerem '. Otwarcie tego portu rozwiązało problem. – codechurn

1

Można użyć tych dwóch artykułów, można rozwiązać problem

www.ddj.com/windows/184406424

forums.asp.net/t/1408268.aspx

i check twoje zapory ogniowe:

4

The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.

Ponieważ można zapytać bezpośrednio za pomocą narzędzia LDAP, co sugeruje, że zapora jest poprawnie otwarta. Należy jednak pamiętać, że model ActiveDirectoryMembershipProvider nie używa zwykłego starego protokołu LDAP, lecz korzysta z technologii firmy Microsoft. Na przykład, jeśli ustawisz connectionProtection="Secure", ADMP spróbuje użyć SSL i portu 636, jeśli to się nie powiedzie, użyje wbudowanego w Microsoft podpisu IPSec (więcej szczegółów znajdziesz w artykule this article).

W każdym razie, to sprawia, że ​​zastanawiam się o kilka rzeczy:

  1. Czy domena AD mają IPSec "wymagane" polityka, który odmawia połączenia z non-domain/non-skonfigurowanych komputerów? (Prawdopodobnie nie, ponieważ łączyłeś się ze zwykłym LDAP, ale warto to zbadać.)
  2. Czy dodałeś nazwę NetBIOS kontrolera domeny do pliku lmhosts i jego nazwę DNS do pliku hosts? (Wiele protokołów sprawdza, czy zgłoszona nazwa ich celu pasuje do nazwy, z którą próbowano się połączyć.)
  3. Wiele osób zauważyło problemy z używaniem ADMP między różnymi domenami, a rozwiązanie wymagało utworzenia jednokierunkowego zaufania. Ponieważ wygląda na to, że komputer kliencki nie znajduje się w domenie, nie możesz mieć tego zaufania - chyba że (a) jest członkiem innej domeny z zaufaniem jednokierunkowym lub (b) jest członkiem ta sama domena, a więc zaufanie klienta do serwera, jest niejawna.
+0

Twój drugi punkt doprowadził mnie do rozwiązania! Najwyraźniej nazwa DNS została zmieniona na naszym serwerze testowym, który spowodował niepowodzenie tylko ADMP, podczas gdy każda inna metoda działała! Jednak obecny sposób obejścia tego problemu to posiadanie adresu IP zamiast nazwy hosta w łańcuchu połączenia LDAP, dokładnie w taki sam sposób, w jaki skonfigurował go Scott (zamiast tego nie podaję numeru portu, pozwalam mu wybrać automatycznie) . –

1

Miałem ten błąd i udało mi się go naprawić. Istnieje wiele przyczyn, które mogą prowadzić do tego, tutaj jest lista rzeczy do zrobienia w celu zidentyfikowania problemu exect:

  1. Tworzenie mikro wniosku, wraz z Membership.GetAllUsers pojedynczy() metoda, wykonać na maszynie poza Active Directory (AD), z niepoprawnym hasłem w ciągu połączenia, sprawdź, czy otrzymałeś niepoprawny wyjątek hasła. Jeśli go nie dostaniesz, nie możesz połączyć się z serwerem AD, sprawdź zaporę ogniową, jeśli otrzymasz wyjątek nieprawidłowego hasła, przejdź do następnego kroku.

  2. Jeśli możesz, spróbuj wykonać tę samą aplikację, lokalnie na serwerze AD, najpierw z nieprawidłowego hasła, niż poprawne wykonywanie aplikacji lokalnie zapewnia bardziej szczegółowy wyjątek co jest nie tak (dla mnie ten wyjątek doprowadzić mnie do mocowania problem) . W moim przypadku powiedział mi, że usługa Server nie jest uruchomiona, niż że usługa Workstation nie jest uruchomiona.

Niektóre myśli na tym, że wymagane usługi serwerów i stacji roboczych do pracy na serwerze: usługa serwera AFAIK jest używany do udostępniania plików systemu Windows (NetBIOS przez TCP) i jest za pomocą portu 445, więc to Mey być że port ten musi być otwarty oprócz portu LDAP. Moja druga uwaga była taka, że ​​jeśli port 445 został otwarty (netstat -an) to nadal może nie działać, winows powoduje upuszczenie wszystkich pakietów do tego portu, jeśli pola wyboru Windows Client i udostępniania plików i drukarek nie są zaznaczone na adapterze sieciowym, który wywołał te pakiety . Sprawdź "telnet External_IP 445". To wszystko zebrałem podczas walki z tym problemem.

0

Jeśli ktoś się o to potknie i chce roztrzaskać głowę na ścianie ... Ostatnio próbowałem zrobić to dla serwera AD, który moja firma miała w innej domenie niż obecny kontekst. Używałem dostarczonego adresu IP i otrzymywałem awarie zgodnie z tym, co tu podano. Nawet użył narzędzia takiego jak Softerra LDAP Admin i działało dobrze, jednak konto Account Management nie powiodło się.

Mieliśmy publicznie udostępniony URL podłączony do tego adresu IP (nadal pozwalając tylko niektórym adresom IP wykonywać połączenia). Kiedy już zastąpiłem adres IP podanym adresem URL, zadziałało to jak czar.

Mam nadzieję, że to uratuje komuś godziny roztrzaskiwania głowy. Po prostu się poddałem.

Powiązane problemy