LDAP xác thực người dùng trên khắp miền tin cậy

Question

Ứng dụng của tôi định nghĩa người dùng có thẩm quyền thông qua LDAP (thường là Active Directory):

1. Khách hàng xác định một máy chủ LDAP (TreeA) và một nhóm (GroupA). Bất kỳ người dùng nào trong GroupA đều có thể sử dụng ứng dụng.
2. Lúc đăng nhập, người dùng gửi tên truy cập và mật khẩu của họ - nếu một ràng buộc với LDAP TreeA với thông tin của họ hoạt động, VÀ tài khoản người dùng của họ đang ở trong một GroupA, họ là tốt để đi

tôi đã đi đến một tình huống mà hai Active Directories tin tưởng lẫn nhau, và GroupA được chỉ định trong TreeA chứa người dùng từ TreeB. Vì vậy, bướC# 2 thất bại vì tôi đang cố gắng để xác thực UserB (từ TreeB) đối với TreeA.

Ứng dụng có quyền truy cập vào TreeA, vì vậy tôi cho rằng ứng dụng có thể xem trong GroupA và xem UserB ở đó. Nhưng làm thế nào nó sẽ biết rằng nó cần phải gửi yêu cầu ràng buộc để TreeB để xác thực tên người dùng và mật khẩu?

Có cách nào tốt hơn để tiếp cận vấn đề này không?
Các yêu cầu ràng buộc như vậy đối với TreeA có được chuyển tiếp tự động tới TreeB vì có mối quan hệ tin cậy không?

Answer 1

Có thể bạn chỉ gặp sự cố cấu hình trên máy chủ LDAP (TreeA). Bạn đã viết rằng có sự tin tưởng giữa TreeA và TreeB, để bạn có thể thêm UserB (từ TreeB) làm thành viên của GroupA trong TreeA. Nếu bạn có thể làm điều này, hơn bạn đã thiết lập thành công sự tin cậy theo đúng hướng giữa TreeA và TreeB. Bạn nên hiểu, tin cậy đó chỉ có nghĩa là Active Directory B chỉ xác minh mật khẩu người dùng, nhưng UserB theo mặc định sẽ không có quyền truy cập vào bất kỳ tài nguyên nào từ Active Directory A. UserB có thể không có quyền tạo LDAP liên kết với máy chủ A. Trong trường hợp, vấn đề sẽ được giải quyết bằng cách cấp cho UserB quyền đăng nhập từ xa trên máy chủ A và quyền truy cập đọc vào GroupA và có thể đọc sự cho phép đối với OU nơi GroupA tồn tại. Bạn có thể thử Insight for Active Directory để theo dõi quyền truy cập AD để bản địa hóa các vấn đề về quyền.

Lý do khác có thể khiến sự cố của bạn có thể là sử dụng API mà bạn sử dụng để truy cập LDAP. Trong câu hỏi của bạn, bạn không viết bất kỳ thông tin nào về API. Bạn có sử dụng API Win32 như ldap_bind_s hoặc sử dụng DirectoryEntry trong .NET không? Trong cả hai trường hợp, điều quan trọng là bạn phải sử dụng tên miền rõ ràng cùng với tên tài khoản (cho UserB) trong khi ràng buộc hoặc sử dụng null cho cả tên và mật khẩu cho thông tin xác thực người dùng hiện tại của người dùng.

Việc sử dụng tài khoản cố định từ TreeA cho tất cả các truy cập vào TreeA (cũng cho các bài kiểm tra về UserB) cũng có thể giải quyết được vấn đề, nhưng có thể chỉ là một số loại sử dụng ứng dụng.

Trong bất kỳ cách nào, thông tin thêm trong câu hỏi của bạn có thể thu hẹp vấn đề và cách giải quyết vấn đề.

Answer 2

Có lẽ bạn nên sử dụng bản sao ldap sao cho các đối tượng luôn có mặt trong cả hai máy chủ?

Answer 3

Ứng dụng có quyền truy cập vào TreeA, vì vậy tôi cho rằng ứng dụng có thể xem trong GroupA và xem UserB ở đó. Nhưng làm thế nào để nó biết rằng nó cần phải gửi yêu cầu ràng buộc để TreeB xác thực tên người dùng và mật khẩu ?

Các member thuộc tính trong GroupA sẽ cung cấp tên đầy đủ phân biệt (dn) của từng thành viên, mà có thể giống như thế:

member: CN=User1,OU=People,DC=TreeA,DC=foobar,DC=com 
member: CN=User2,OU=People,DC=TreeB,DC=foobar,DC=com 

Vì vậy, khi những nỗ lực 'User2' để xác thực, bạn có thể phù hợp CN và biết rằng bạn nên xác thực với 'TreeB' thay vì 'TreeA'. (Có lẽ bạn sẽ có một số loại bảng ánh xạ DN đến tên máy chủ của máy chủ AD). Hoặc, bạn chỉ cần brute-force nó và thử 'TreeB' nếu bạn nhận được một 'không có người dùng như vậy' từ 'TreeA'.

Bạn sẽ cần đưa ra quyết định cách xử lý trường hợp tên người dùng trùng lặp trong hai cây - một người có ưu tiên so với tên kia không?

Một cách tiếp cận khác là yêu cầu người dùng chỉ định cây nào họ đang xác thực, ví dụ bằng cách đăng nhập bằng tên đăng nhập như 'user1@treea.foobar.com'.

Answer 4

Hãy nói rằng bạn có tên miền A và miền B tin tưởng lẫn nhau, và nếu bạn muốn để xác thực người dùng B từ miền B chống lại miền A trên máy chủ một tên miền của một vì vậy những gì bạn phải làm là:

1. Mạo danh người dùng B trên tên miền A bằng cách sử dụng API Win32.

2. Xác thực người dùng B chống lại miền A bằng cách sử dụng DirectoryEntry, sau đó bạn có thể truy cập vào AD của miền A để biết thông tin người dùng khác, chẳng hạn như nhóm được chỉ định.

Tôi đã triển khai nó trong ứng dụng ASP.NET sử dụng xác thực Windows.

Hy vọng điều đó sẽ giúp ích,