Tạo dịch vụ Python để truy vấn các thuộc tính AD
Tôi đang tích hợp AD của chúng tôi với các dịch vụ web chạy Python trên linux bằng Python-LDAP qua SASL (DIGEST-MD5) để truy vấn các thuộc tính người dùng AD 2012 (bộ phận, bộ phận, tiện ích mở rộng điện thoại, email, v.v.). Sau khi tìm ra các kink cụ thể cho dịch vụ của tôi so với AD 2003, tôi bắt đầu gặp phải lỗi SPN so với AD 2012 mới của chúng tôi, rằng digest-uri không khớp với bất kỳ SPN nào trên máy chủ. Tôi đã tham khảo chéo danh sách SPN cho cả hai máy chủ và chúng chứa các chất tương tự giống hệt nhau.
Lỗi: Digest-uri không khớp với bất kỳ LDAP SPN nào đã đăng ký cho máy chủ này
Cách khắc phục?
Điều này đã được sửa bằng cách chạy:
setspn -A ldap/<Domain_Name> <Computer_Name>
Lưu ý rằng việc tạo tài khoản dịch vụ không khắc phục lỗi SPN của tôi ngay cả khi lệnh sau được chạy:
setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>
Simple_bind_s () không cần SPN, sasl_interactive_bind_s () cần SPN
Chỉ thêm SPN vào danh sách SPN của máy cục bộ hoạt động cho dịch vụ Python-LDAP của tôi bằng sasl_interactive_bind_s (). Tôi cũng cần lưu ý rằng bước SPN có thể được bỏ qua nếu tôi sử dụng Simple_bind_s () nhưng phương thức này sẽ gửi thông tin đăng nhập trong phần văn bản rõ ràng không thể chấp nhận được.
Tuy nhiên tôi nhận thấy rằng bản ghi chỉ nằm trong danh sách SPN trong khoảng một phút trước khi biến mất? Không có lỗi khi tôi chạy lệnh setspn, nhật ký sự kiện hoàn toàn trống rỗng, không có bản sao ở bất cứ đâu, được kiểm tra với tìm kiếm toàn rừng -F trên cơ sở dn và không có gì. Tôi đã thêm và cố gắng thêm lại và xóa và di chuyển SPN từ đối tượng này sang đối tượng khác để xác minh rằng nó không ẩn ở bất cứ đâu, nhưng lần thứ hai tôi thêm đối tượng ở bất cứ đâu và sau đó cố gắng thêm lại thông báo cho tôi về một bản sao. Vì vậy, tôi rất tự tin rằng không có một bản sao ẩn ở đâu đó.
Hack
Hiện tại tôi đã có một tác vụ theo lịch trình chạy lại lệnh để giữ bản ghi trong danh sách để dịch vụ của tôi sẽ hoạt động một cách thông minh có tên là "SPN Hack"
cmd.exe /C "setspn -A ldap/<Domain_Name> <Computer_Name>"
cho đến khi tôi có thể tìm hiểu tại sao SPN lại bị xóa khỏi danh sách.
Tôi không phải là quản trị viên chính cho AD cụ thể này, quản trị viên có thể có một dịch vụ đang chạy đồng bộ hóa SPN từ một dịch vụ khác trên AD và không biết về nó không? Tiêu đề của tôi là Web Developer, không phải là một cái cớ mà là để giải thích sự thiếu hiểu biết của tôi về vấn đề Active Directory. Tôi đã được yêu cầu biến AD thành người dùng chính DB và tôi đã đọc rất nhiều nhưng tôi không thể tìm thấy bất cứ nơi nào mà mọi người gặp vấn đề với SPN bị 'ghi đè' hoặc 'làm sạch' theo định kỳ và không ai trong số quản trị viên rất quen thuộc với SPN bên ngoài các mục SQLServer.
Tại sao tôi cần hack?
Cho đến nay, bản hack của tôi dường như không gây ra bất kỳ sự cố nào cho bất kỳ người dùng hoặc dịch vụ nào và không tạo ra bất kỳ lỗi nào, vì vậy quản trị viên nói rằng anh ta sẽ để nó chạy và tôi sẽ tiếp tục tìm kiếm. Nhưng sau đó tôi thấy mình trong tình huống bấp bênh khi viết một dịch vụ mà việc triển khai được xây dựng, về cơ bản là hack / rùng mình ... Vì vậy, bất kỳ trợ giúp nào cũng sẽ được đánh giá cao.
Cập nhật
Sau một cuộc trò chuyện với sysadmin, anh ấy đã đồng ý rằng xây dựng một dịch vụ trên hack không phải là một giải pháp, do đó anh ấy đã cho phép tôi tạo ra một dịch vụ địa phương với mã hóa điểm cuối mà tôi có thể sử dụng cho mục đích của mình, kết quả là như nhau . Tôi sẽ theo dõi những gì đang khiến SPN bị loại bỏ. Các liên kết cục bộ không phải là vấn đề khi sử dụng Python-LDAP và dịch vụ cục bộ đã sẵn sàng và chạy chỉ sau một giờ. Thật không may là về cơ bản tôi gói chức năng được tích hợp trong LDAP nhưng chúng tôi làm những gì chúng tôi phải làm.
