Kiểm thử LDAP/LDAPS: bind, search, paging, replication lag và failover

RFC 4511 định nghĩa các LDAP operation như Bind, Search, Modify và Unbind; RFC 4513 mô tả cơ chế xác thực/bảo mật. Bài toán đo cần cụ thể: login storm, group lookup nhiều tầng, service-account bind, đồng bộ thuộc tính hay truy vấn inventory. Mỗi use case có filter, scope và payload khác nhau.

Không dùng ldapsearch đơn lẻ để kết luận khả năng phục vụ ứng dụng. Client library có connection pool, retry, DNS caching và timeout riêng; chúng phải nằm trong phạm vi test hoặc được mô phỏng đúng.

Topology gồm load generator tại một hoặc nhiều network zone, DNS/load balancer nếu production có dùng, ít nhất hai directory node, replication link và hệ thống quan sát server/network. Tạo data set có cấu trúc OU, group depth, attribute size và index status đại diện nhưng không chứa dữ liệu thật.

Đồng bộ clock giữa generator, load balancer và directory. Capture DNS, TCP/TLS và LDAP result code; server metrics gồm worker/thread, connection, cache, disk, replication queue và resource saturation. Chỉ đo client latency mà thiếu server evidence sẽ khó tách lỗi filter, index và network.

Profile nên ghi tỷ lệ bind/search/modify, bind mới so với connection reuse, concurrency, arrival pattern, filter, base DN, scope, attributes trả về, page size và TLS mode. Dùng open workload nếu muốn giữ request rate; dùng closed workload nếu mô phỏng user chờ phản hồi, nhưng không so throughput giữa hai mô hình như cùng điều kiện.

Khóa server build, schema, index, data cardinality, cache warm/cold, JVM/runtime nếu có, certificate chain, cipher/TLS version, load-balancer persistence và replication mode. Tách cold-cache, steady-state, burst và soak test.

Pass/fail phải gắn với user journey: p99 group lookup có thể quan trọng hơn tổng op/s. Ghi riêng authentication failure mong đợi, policy reject và lỗi hệ thống để error rate không bị diễn giải sai.

• KPI: Operation latency · Phân tách: bind/search/modify; p50/p95/p99 · Bằng chứng: Client event log · Lưu ý: Không chỉ dùng average
• KPI: Throughput · Phân tách: op/s thành công · Bằng chứng: Result code + server count · Lưu ý: Loại retry double-count
• KPI: Error rate · Phân tách: LDAP result code/transport/TLS · Bằng chứng: Raw response và log · Lưu ý: Phân biệt timeout với reject
• KPI: Replication lag · Phân tách: write-to-visible · Bằng chứng: Object/version marker · Lưu ý: Đo trên từng replica
• KPI: Paging completeness · Phân tách: entry ID/hash · Bằng chứng: Manifest và cookie flow · Lưu ý: Không chỉ đếm trang đầu
• KPI: Recovery · Phân tách: fault-to-service · Bằng chứng: Timeline, retry, node state · Lưu ý: Bao gồm stale read

RFC 2696 mô tả simple paged results control nhưng page size phía client không phải cam kết tuyệt đối của server. Test phải dùng cookie opaque do server trả về đến khi cookie rỗng. Với data set cố định, đối chiếu đủ entry; khi data thay đổi giữa các page, RFC 2696 cho phép gặp entry lặp hoặc thiếu, nên không gọi đó là lỗi giao thức nếu chưa có cam kết snapshot riêng. Không tự tái sử dụng cookie trên node khác sau failover nếu hãng không hỗ trợ.

• Workload: Login steady · Profile: bind + user/group search · Rủi ro cần bắt: Tail latency · Tiêu chí quyết định: SLO p95/p99
• Workload: Login storm · Profile: burst account đồng thời · Rủi ro cần bắt: Queue, TLS handshake · Tiêu chí quyết định: Không collapse/retry storm
• Workload: Group-heavy · Profile: filter sâu, nhiều member · Rủi ro cần bắt: Index/filter cost · Tiêu chí quyết định: Latency và đúng kết quả
• Workload: Paged inventory · Profile: nhiều page/cookie · Rủi ro cần bắt: Missing/duplicate · Tiêu chí quyết định: Hash tập entry khớp
• Workload: Write/read · Profile: modify rồi search replica · Rủi ro cần bắt: Replication lag · Tiêu chí quyết định: Consistency theo SLO
• Workload: Node failure · Profile: rút node active · Rủi ro cần bắt: Retry, pool stale · Tiêu chí quyết định: Recovery theo RTO

• Bước 1: Chốt schema/data manifest, accounts, quyền và version matrix.
• Bước 2: Xác nhận certificate chain, hostname, expiry, revocation policy và TLS negotiation.
• Bước 3: Chạy từng operation ở tải thấp để lập baseline result code và latency.
• Bước 4: Kiểm search base/one/subtree, filter hợp lệ/sai và attribute authorization. Thêm bind với mật khẩu rỗng: unauthenticated bind không được ứng dụng hiểu nhầm là xác thực người dùng thành công.
• Bước 5: Duyệt toàn bộ paged search, hash DN/entry ID và kiểm cookie lifecycle.
• Bước 6: Tăng concurrency/request rate theo bậc; giữ plateau đến khi queue ổn định.
• Bước 7: Chạy burst và soak, theo dõi cache, connection pool, retry amplification.
• Bước 8: Gây lỗi từng node/đường replication; đo service recovery và data consistency.
• Bước 9: Tách chi phí TLS handshake và connection reuse bằng các run có/không tái sử dụng kết nối nhưng vẫn xác minh TLS. Chỉ thử transport không mã hóa trong lab cô lập với dữ liệu giả, không dùng tài khoản hay credential production.

Fault set gồm process stop, node unreachable, load-balancer drain, certificate lỗi, replication delay và DNS endpoint change. Với mỗi lỗi, theo dõi connection cũ, connection mới, retry policy, operation idempotency và data version nhìn thấy. TCP reconnect không đồng nghĩa authentication service đã phục hồi.

Để đo replication lag, ghi unique marker và source timestamp khi modify thành công, rồi poll từng replica theo nhịp đã định đến khi đúng version xuất hiện. Không dùng clock client/server không đồng bộ; có thể đo duration từ cùng orchestrator để giảm sai số.

• Xác định operation, result code, DN/filter đã khử nhạy cảm và request ID.
• Tách DNS, TCP, TLS, bind và search timing.
• Kiểm connection pool, timeout và retry phía client.
• Kiểm index plan/cache, worker queue và disk phía server.
• So data version giữa replica; không mặc định mọi node nhất quán tức thời.
• Kiểm certificate/SAN/chain trước khi tắt xác minh TLS để thử.
• Re-run đúng traffic profile sau remediation và lưu diff.

Kết quả phụ thuộc schema, index, filter selectivity, data size và client library; không thể chuyển op/s giữa hai môi trường nếu các biến này khác. Lab dùng synthetic entries cũng không tự chứng minh authorization production đúng.

LDAPS thường được dùng để chỉ LDAP qua TLS ngay từ khi mở kết nối, còn StartTLS nâng cấp một kết nối LDAP theo cơ chế được hỗ trợ; kiểm tra chính xác mode và chính sách client/server. Không công bố “mã hóa an toàn” chỉ vì port hoặc handshake tồn tại nếu hostname/chain không được xác minh.

• Bind: operation thiết lập trạng thái xác thực LDAP.
• Search filter: biểu thức chọn entry/attribute cần trả về.
• Paged results: cơ chế lấy tập kết quả qua nhiều page với cookie.
• Replication lag: khoảng trễ từ write thành công đến replica quan sát đúng version.
• Connection pool: tập kết nối tái sử dụng để giảm thiết lập mới.
• Tail latency: latency ở percentile cao như p95/p99.