không thể hiểu tại sao apache LDAP auth thất bại

Đột nhiên, ngày hôm qua, một trong những máy chủ apache của tôi không thể kết nối với máy chủ LDAP (AD) của tôi. Tôi có hai trang web đang chạy trên máy chủ đó, cả hai đều sử dụng LDAP để xác thực với máy chủ AD của tôi khi người dùng đăng nhập vào một trong hai trang web. Nó đã hoạt động tốt hai ngày trước. Vì lý do không rõ, như ngày hôm qua, nó đã ngừng hoạt động. Nhật ký lỗi chỉ nói điều này:

auth_ldap authenticate: user foo authentication failed; URI /FrontPage [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server], referer: http://mysite.com/

Tôi nghĩ có lẽ chứng chỉ SSL tự ký của tôi đã hết hạn, vì vậy tôi đã tạo một chứng chỉ mới cho mysite.com, nhưng không phải cho tên máy chủ của chính máy chủ và vấn đề vẫn tồn tại. Tôi đã kích hoạt ghi nhật ký mức gỡ lỗi. Nó hiển thị giao dịch SSL đầy đủ với máy chủ LDAP và dường như hoàn thành không có lỗi cho đến khi kết thúc khi tôi nhận được thông báo "Không thể liên hệ với máy chủ LDAP". Tôi có thể chạy ldapsearch từ dòng lệnh trên máy chủ này và tôi có thể đăng nhập vào nó, nó cũng sử dụng LDAP, vì vậy tôi biết rằng máy chủ có thể kết nối và truy vấn máy chủ LDAP / AD. Nó chỉ là apache mà không thể kết nối.

Googling cho một câu trả lời đã không có gì, vì vậy tôi đang hỏi ở đây. Bất cứ ai có thể cung cấp cái nhìn sâu sắc cho vấn đề này?

Đây là phần LDAP từ cấu hình apache:

<Directory "/web/wiki/">
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Login"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    #AuthBasicAuthoritative off
    AuthLDAPUrl ldaps://domain.server.ip/dc=full,dc=context,dc=server,dc=name?sAMAccountName?sub
    AuthLDAPBindDN cn=ldapbinduser,cn=Users,dc=full,dc=context,dc=server,dc=name
    AuthLDAPBindPassword password
    require valid-user
</Directory>

Một dấu vết gói từ máy chủ httpd / máy khách LDAP đã tiết lộ một thông báo về CA không xác định.

Cảnh báo TLSv1 (Cấp độ: Gây tử vong, Mô tả: CA không xác định)

Tôi đã tìm thấy và thêm tùy chọn sau vào httpd.conf của mình:

  LDAPVerifyServerCert          off

Điều đó đã khắc phục sự cố của tôi trong CentOS 6. Các máy chủ httpd của CentOS 5 không yêu cầu bất kỳ sửa đổi nào và đã hoạt động mà không có tùy chọn.

Tôi đã gặp một vấn đề tương tự như vậy trước đây với AD trên Windows 2003: giải pháp tôi tìm thấy là không ràng buộc bằng cách sử dụng toàn bộ DN mà thay vào đó sử dụng cú pháp user @ domain:

AuthLDAPBindDN user@domain.com

Bạn có quyền truy cập vào nhật ký từ máy chủ LDAP của bạn không? Chúng có thể hữu ích trong việc khắc phục sự cố này.

Tôi đã thấy điều này khi một bản cập nhật gói gây ra những thay đổi trong ứng dụng khách ldap.conf (thường là /etc/ldap.conf hoặc /etc/openldap/ldap.conf) và đặt lại tùy chọn TLS_REQCERT thành một cài đặt nghiêm ngặt hơn. Nó có thể đàm phán SSL đúng cách, nhưng cuối cùng vẫn sẽ thất bại vì không thể xác thực chuỗi chứng chỉ từ một gốc đáng tin cậy.

Bạn có thể muốn kiểm tra đồng hồ của các máy chủ. Nếu chênh lệch thời gian nhiều hơn một vài phút, vé xác thực sẽ không hợp lệ.

Mặc dù đây không chính xác là thông báo lỗi, phần 'máy chủ khác đột nhiên gặp vấn đề tương tự' có thể chỉ ra vấn đề như vậy.

Bạn cần áp dụng chứng chỉ LDAP CA để hoạt động với LDAPS

Tôi có một vấn đề tương tự, mà tôi đã xác định bằng cách chạy lệnh này:

openssl s_client -connect $ldap_host:636 -state -nbio 2>&1. Tôi nghĩ mod_ldap sử dụng openssl bên dưới, vì vậy điều này khá phù hợp để gỡ lỗi.

Tôi đã so sánh nó với một máy chủ mã hóa SSL khác mà tôi biết đang hoạt động. Kết nối SSL được xác minh đúng sẽ hiển thị chuỗi đi đến CA gốc và trả về 0. Việc xác minh SSL không thành công sẽ đưa ra một số và lý do. Bạn có thể sử dụng đầu ra để xác định điều gì sai.

Trong trường hợp của tôi, các certs máy chủ LDAP được ký bởi Verisign, sử dụng các cer CA trung gian . OpenSSL không thể xác minh chứng chỉ và kết nối bị từ chối ("kết nối bị từ chối bởi máy chủ" là không có ích).

Tôi đã có một vấn đề tương tự. Tôi có thể nhận được chứng chỉ với openssl, tôi có thể truy vấn Active Directory qua SSL với ldapsearch trên cùng các cổng. Cuối cùng tôi đổi thành cổng Microsoft Global Catalog 3268 hoặc 3269 và cả hai đều hoạt động. Các máy chủ Microsoft Windows 2003 đã được vá, nhưng điều đó đã xảy ra vài ngày trước khi các vấn đề bắt đầu xảy ra.

Tôi đã triển khai LDAPS trên tất cả các máy chủ của chúng tôi và cũng gặp phải vấn đề này. Nó sẽ biến mất nếu bạn hoàn nguyên về LDAP văn bản (Không lý tưởng, nhưng hữu ích để biết nguồn gốc của vấn đề). Nếu vậy, tôi vẫn chưa tìm ra giải pháp, nhưng có lẽ cùng nhau chúng ta có thể cô lập một lỗi trong authnz_ldap.

Tôi giả định rằng các thử nghiệm dòng lệnh của bạn đã sử dụng cùng một "người dùng liên kết" như trong cấu hình apache của bạn. Nếu không, bạn nên kiểm tra xem bạn có mật khẩu hiện tại chính xác không.

Trước đây, tôi đã từng phải sử dụng cổng danh mục toàn cầu thay vì cổng LDAP tiêu chuẩn cho miền AD. Tôi không thể nhớ lý do tại sao. Đối với ldaps như trong url của bạn ở trên, đây sẽ là cổng 3269.

Cách thức hoạt động này là trang web của bạn cần kết nối với AD bằng thông tin đăng nhập của người dùng liên kết của bạn trước, và sau đó, khi kết nối này được thực hiện, nó sử dụng quyền truy cập này để xác thực thông tin đăng nhập của người dùng khi truy cập trang web của bạn.

Theo thông báo lỗi của bạn, có vẻ như quá trình không thể kết nối với AD với tư cách là người dùng liên kết của bạn (AuthLDAPBindDN).

Đảm bảo rằng tài khoản người dùng liên kết không bị vô hiệu hóa trong Active Directory và mật khẩu bạn đã chỉ định là (AuthLDAPBindPassword) là chính xác . Ngoài ra, đảm bảo rằng người dùng liên kết của bạn có các quyền cần thiết để tra cứu người dùng khác (phải là thành viên của Người dùng Miền trong trường hợp của chúng tôi)

Tôi vừa gặp vấn đề này ("không thể liên lạc với máy chủ ldap") trên RHEL6 và đó là kết quả của những thay đổi đối với openldap. yum đã cập nhật tệp cấu hình /etc/openldap/ldap.conf nhưng thay vì ghi đè lên nó (trong trường hợp nó được tùy chỉnh; trong trường hợp của tôi thì không) nó đã tạo ra một tệp ldap.conf.rpmnew.

Sao chép phiên bản .rpmnew trên ldap.conf đã khắc phục sự cố.

(Tôi không thể đồng ý rằng tắt xác minh chứng chỉ là một câu trả lời cho vấn đề này. Nó tránh được vấn đề theo cách nguy hiểm tiềm tàng.)

Tôi quản lý để khắc phục vấn đề này bằng cách cài đặt berkelydbvà openldapcác gói được tìm thấy ở đây .

Sự khác biệt là RedHat đã bắt đầu liên kết mọi thứ nssthay vì opensslhỗ trợ SSL. Trong trường hợp này, điều đó phá vỡ tất cả mọi thứ. Cài đặt các gói này (được liên kết với openssl) khắc phục sự cố. Chỉ cần lấy các gói và chạy:

yum install berkeleydb-ltb* openldap-ltb*

Sau đó khởi động lại apache, và bạn nên kinh doanh.