ActiveDirectoryMembershipProvider "Không thể liên lạc miền hoặc máy chủ được chỉ định."

Question

Tôi có một ứng dụng đang sử dụng ActiveDirectoryMembershipProvider để cấp quyền truy cập cho người dùng. Ứng dụng này được lưu trữ trên máy không phải miền, với tường lửa giữa máy chủ ứng dụng và bộ điều khiển miền.

Chúng tôi đã mở cổng LDAP cho DC trên mạng bên trong - cho dù chúng tôi có cố gắng gì, chúng tôi sẽ gặp lỗi "Không thể liên lạc miền hoặc máy chủ được chỉ định".

Có ai có bất kỳ đề xuất nào về cách tôi có thể giải quyết vấn đề này không? Chúng tôi đã thử tất cả mọi thứ chúng tôi có thể nghĩ đến và chỉ không nhận được bất cứ nơi nào.

chuỗi kết nối của tôi là:

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

Và nhà cung cấp của tôi là:

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

Answer 1

Bạn đã thử nghiệm với một công cụ duyệt LDAP, từ hộp điều khiển từ xa để xem nếu nó có thể kết nối với các tiêu chuẩn đang được sử dụng ở đây? I E. Nó có phải là một vấn đề kết nối hay cái gì khác?

Answer 2

Nó có vẻ như giải pháp là để mở cổng 445.

Read this thread

Chúng tôi không được phép mở vì vậy tôi đoán tôi bị mắc kẹt.

Answer 3

Bạn có thể sử dụng hai bài báo, có thể giải quyết vấn đề của bạn

www.ddj.com/windows/184406424

forums.asp.net/t/1408268.aspx

và kiểm tra tường lửa của bạn

Answer 4

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

Vì bạn có thể truy vấn trực tiếp bằng công cụ LDAP, điều này cho thấy tường lửa mở chính xác. Tuy nhiên, hãy nhớ rằng ActiveDirectoryMembershipProvider hiện không sử dụng LDAP cũ, nó sử dụng công nghệ của Microsoft. Ví dụ: nếu bạn đặt connectionProtection="Secure", ADMP sẽ thử sử dụng SSL và cổng 636, nếu không thành công, nó sẽ sử dụng ký hiệu IPSec được tích hợp sẵn của Microsoft (xem this article để biết thêm chi tiết).

Dù sao, điều này làm cho tôi băn khoăn về một vài điều:

1. Liệu miền AD đã một IPSec "yêu cầu" chính sách mà từ chối các kết nối từ các máy tính không-domain/phi cấu hình? (Có lẽ không, kể từ khi bạn kết nối với LDAP đơn giản, nhưng nó đáng để điều tra.)
2. Bạn đã thêm tên NetBIOS của bộ điều khiển tên miền vào tệp lmhosts và tên DNS của nó vào tệp máy chủ của bạn chưa? (Nhiều giao thức kiểm tra tên được báo cáo của mục tiêu khớp với tên bạn đã cố gắng kết nối.)
3. Rất nhiều người đã lưu ý vấn đề bằng cách sử dụng ADMP giữa các miền khác nhau và giải pháp yêu cầu tạo niềm tin một chiều. Vì có vẻ như máy tính khách của bạn không nằm trong miền, bạn không thể có niềm tin đó - trừ khi (a) nó là thành viên của miền khác với niềm tin một chiều hoặc (b) đó là thành viên của cùng một tên miền và do đó sự tin tưởng của máy khách-máy chủ là ngầm định.

Answer 5

Tôi gặp lỗi này và đã cố khắc phục. Có nhiều lý do có thể dẫn đến này, đây là một danh sách công việc phải làm để xác định vấn đề exect:

1. Tạo một ứng dụng vi mô, với Membership.GetAllUsers phương pháp đơn(), thực hiện trên máy bên ngoài Active Directory (AD), với mật khẩu không chính xác trong chuỗi kết nối, hãy kiểm tra xem bạn có ngoại lệ mật khẩu không chính xác hay không. Nếu bạn không nhận được nó, bạn không thể kết nối với máy chủ AD của bạn, hãy kiểm tra tường lửa, nếu bạn nhận được ngoại lệ mật khẩu không hợp lệ, hãy thực hiện bước tiếp theo.

2. Nếu bạn có thể, hãy thử chạy cùng một ứng dụng, định vị trên máy chủ AD, trước tiên với mật khẩu không chính xác, với chính xác, thực thi ứng dụng cục bộ cung cấp ngoại lệ chi tiết hơn là gì (đối với trường hợp ngoại lệ này dẫn tôi khắc phục sự cố) . Trong trường hợp của tôi nó nói với tôi rằng dịch vụ máy chủ không được bắt đầu, hơn là dịch vụ Workstation không được bắt đầu.

Một số suy nghĩ về thực tế là nó đòi hỏi các dịch vụ Server và Workstation để được làm việc trên máy chủ: dịch vụ afaik Server được sử dụng để chia sẻ các cửa sổ tập tin (NetBIOS trên TCP), và đang sử dụng 445 cảng, vì vậy nó Mey được rằng cổng này phải được mở ngoài cổng LDAP. Quan sát thứ hai của tôi là sự kiện nếu cổng 445 mở (netstat -an) nó vẫn không hoạt động được, winows sẽ thả tất cả các gói vào cổng này nếu các hộp kiểm Windows Client và File and Printer không được kiểm tra trên bộ điều hợp giao diện mạng. . Kiểm tra "telnet External_IP 445". Thats tất cả các thông tin tôi thu thập được trong khi strugling với vấn đề này.

Answer 6

Trong trường hợp bất cứ ai tình cờ gặp điều này và muốn đập đầu vào tường ... Gần đây đã thử làm tất cả điều này cho một máy chủ AD mà công ty của tôi có trong một miền khác với ngữ cảnh hiện tại. Đã sử dụng IP được cung cấp và nhận được lỗi như đã nêu ở đây. Ngay cả khi sử dụng một công cụ như Softerra LDAP Admin và nó hoạt động tốt, tuy nhiên AccountManagement thất bại.

Chúng tôi đã có URL được hiển thị công khai nối với địa chỉ IP đó (vẫn chỉ cho phép một số IP nhất định thực hiện cuộc gọi). Khi tôi thay thế IP bằng URL được cung cấp, nó hoạt động như một sự quyến rũ.

Hy vọng điều này sẽ tiết kiệm cho người nào đó số giờ đập vỡ đầu tôi chỉ cần đặt mình vào.