Điểm:1

ldapsearch liên tục bị lỗi mặc dù tên người dùng/mật khẩu được cung cấp là chính xác

lá cờ mx

Đang làm việc để liên kết một máy chủ vào ldap (thư mục hoạt động) và đang cố gắng để một liên kết đơn giản hoạt động. Các lệnh tôi đã thử là:

ldapsearch -x -H ldap://192.168.10.10 -b "dc=example,dc=domain,dc=com" -D "cn=bind_user,dc=example,dc=domain,dc=com"-W
ldapsearch -x -H ldap://192.168.10.10 -b "dc=example,dc=domain,dc=com" -D "cn=bind_user,ou=Users,dc=example,dc=domain,dc=com" -W
ldapsearch -x -H ldap://192.168.10.10 -b "dc=example,dc=domain,dc=com" -D "cn=bind_user,cn=Users,dc=example,dc=domain,dc=com" -W

Máy chủ LDAP của tôi là thư mục hoạt động (windows 2016). Tên miền của tôi là example.domain.com. Tôi không tin rằng mình có gì đặc biệt trong cấu trúc OU của mình. Người dùng sống trong khu vực "Người dùng" như bình thường. Cổng 389 được mở thông qua tường lửa. Liên kết ẩn danh bị chặn theo mặc định

Suy nghĩ về lý do tại sao liên kết đơn giản này sẽ không hoạt động? Có lẽ tôi đã thử 20 hương vị ở trên mà không gặp may.

Lỗi tôi nhận được là:

Nhập mật khẩu LDAP:
ldap_bind: Thông tin xác thực không hợp lệ (49)
    thông tin bổ sung: 80090308: LdapErr: DSID-0C09044E, nhận xét: Lỗi AcceptSecurityContext, 
dữ liệu 52e, v2580

Lỗi cho tôi biết đó là thông tin xác thực hoặc DN không hợp lệ nhưng không thể nhìn/hiểu được những gì có thể bị tắt. Cảm ơn bạn!

Jevgenij Martynenko avatar
lá cờ us
Hãy thử sử dụng [email protected] làm tên người dùng. Đồng thời kiểm tra nhật ký máy chủ để biết chi tiết lỗi đăng nhập
IT_User avatar
lá cờ mx
@JevgenijMartynenko Tôi đã thay đổi -D thành -D "username@domain" và quản lý thành công để nhận được truy vấn/phản hồi hợp lệ. Bạn có suy nghĩ gì về lý do tại sao việc đánh vần tên miền đầy đủ như tôi đã làm sẽ không hiệu quả không?
Jevgenij Martynenko avatar
lá cờ us
Không ý kiến. Nhưng khuyến nghị của tôi là tránh sử dụng đường dẫn tên người dùng DN để tích hợp hệ thống càng nhiều càng tốt. Nó làm cho cuộc sống của quản trị viên miền dễ dàng hơn rất nhiều nếu bạn sử dụng FQDN. Bằng cách này, họ có thể sắp xếp lại cấu trúc của AD theo nhu cầu của mình mà không ảnh hưởng đến việc tích hợp ứng dụng
IT_User avatar
lá cờ mx
@Jevgenij Nếu bạn đăng câu trả lời đó, tôi sẽ sẵn lòng chấp nhận. Nó giải quyết vấn đề của tôi.
Điểm:1
lá cờ cn

các DN Sai lầm. Không có đơn vị tổ chức người dùng. Nó phải là cn=Người dùng.

"cn=bind_user,ou=Users,dc=example,dc=domain,dc=com"

IT_User avatar
lá cờ mx
Tôi đã thử thay đổi đó và nó cũng báo lỗi như trước.
lá cờ cn
@IT_User: thì câu hỏi phải được sửa. Nó cũng hiển thị DN của người dùng ở hai vị trí, vì vậy chỉ nên có một.
IT_User avatar
lá cờ mx
Tôi vừa cập nhật câu hỏi để hiển thị nỗ lực đó ngay bây giờ.
Điểm:1
lá cờ us

Hãy thử sử dụng [email protected] làm tên người dùng.

Khuyến nghị của tôi là tránh sử dụng đường dẫn tên người dùng DN để tích hợp hệ thống càng nhiều càng tốt. Nó làm cho cuộc sống của quản trị viên miền dễ dàng hơn rất nhiều nếu bạn sử dụng FQDN. Bằng cách này, họ có thể sắp xếp lại cấu trúc AD theo nhu cầu của mình mà không ảnh hưởng đến việc tích hợp ứng dụng

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.