Lưu trữ xác thực Kerberos để mạo danh sau

Question

Có thể lưu trữ vé Kerberos để sử dụng sau này để mạo danh người dùng không?

Tôi có kịch bản trong đó người dùng trực tiếp gọi hệ thống bên ngoài để xử lý một số dữ liệu. Hệ thống bên ngoài dựa vào người dùng bị mạo danh/xác thực chính xác trong AD.

Bây giờ hệ thống gọi phải thay đổi sao cho hàng đợi nằm giữa người dùng và hệ thống bên ngoài và làm việc từ hàng đợi được bàn giao cho hệ thống bên ngoài từ hàng đợi đó bằng dịch vụ Windows. Dịch vụ này cần mạo danh người dùng để hệ thống bên ngoài xử lý chính xác quyền người dùng.

Vì tôi không thể thay đổi hệ thống bên ngoài và không thể lưu trữ tên người dùng và mật khẩu trong hàng đợi, tôi có thể lưu vé Kerberos khi người dùng thêm mục công việc mới vào hàng đợi và sau đó mạo danh người dùng dịch vụ khi nó bàn giao dữ liệu cho hệ thống bên ngoài. Làm thế nào tôi sẽ làm điều đó trong C#?

Answer 1

Có thể lưu nó, nhưng tôi nghĩ vé sẽ không còn tồn tại. Thật không may, bạn chắc chắn sẽ chạy đến số Kerberos double-hop issue trong đó xác thực không thành công từ dịch vụ đến dịch vụ trừ khi bạn đã ủy quyền thiết lập đúng trên mạng của mình. Điều này sẽ yêu cầu bạn thiết lập một số SPN (tên chính của dịch vụ) trên thư mục hoạt động của bạn để yêu cầu các máy chủ tin cậy lẫn nhau.

Tôi chưa bao giờ cố gắng lưu vé Kerberos trong bất kỳ khoảng thời gian nào, vì vậy ngay cả sau khi chiến đấu với đoàn và SPN, nó có thể không hoạt động.

Đây là bài đăng nhanh về thiết lập IIS7 to handle double hop Kerberos tickets và một bài viết khác trên handling it from the networks point of view.

Tôi ước mình có thể trợ giúp nhiều hơn và đăng mã chứ không phải bài viết - nhưng khi bạn điều tra, bạn sẽ thấy đây là lệnh cấm xác thực Kerberos. Chúc may mắn!

Answer 2

• Edit: này là gần nhất tôi có thể nhận được cho câu hỏi thực tế của bạn: Bạn có thể bắt đầu một chủ đề riêng biệt dưới mạo danh, thực hiện yêu cầu từ đó, tuy nhiên thời gian cần thiết? Theo bảo hiểm này sẽ làm những gì cần thiết (trừ khi quá trình dịch vụ được chấm dứt tất nhiên).

Như một anh chàng microsoft đã từng nói với chúng tôi "bảo mật là điều khiến ứng dụng của bạn ngừng hoạt động khi bạn triển khai". (Quan điểm của ông là thử nghiệm với một thiết lập bảo mật thực tế).

Vé có thể có thời lượng là 10 giờ nhưng đó là thời gian từ khi được phát hành. Nó chỉ có thể có một phần nhỏ còn lại bởi thời gian người dùng thực hiện yêu cầu.

Tôi đề nghị bạn chỉ cần giải quyết vấn đề cơ bản theo một cách khác.

Lý do bạn cần xếp hàng là gì? Đơn giản vì dịch vụ bên ngoài bị nghẹt thở vào những giờ cao điểm?

• Bạn có thể tăng cường hoặc mở rộng phần cứng không? Thông thường cách rẻ nhất.
• Bạn có thực sự có quyền hoàn toàn riêng biệt hoặc làm cho vùng người dùng vào một số lượng vai trò hữu hạn không? Nếu vai trò bạn có thể ghi lại vai trò của người dùng và sử dụng tên người dùng được tạo đặc biệt để truy cập dịch vụ bên ngoài, một vai trò cho từng vai trò.
• Dịch vụ bên ngoài có phải là của bạn không?Bạn có thể thêm tùy chọn "giả vờ là Bob" không phụ thuộc vào Windows Mạo danh không?
• Bạn có thể bắt đầu một chuỗi riêng biệt dưới mạo danh, đưa ra yêu cầu từ đó không, tuy nhiên phải mất bao lâu? Sau đó gửi lại cho người dùng? (có điều này sẽ dưới nắp được làm những gì bạn yêu cầu)
• Cuối cùng bạn có thể đặt người dùng trong một "hàng đợi suất" trình duyệt. I E. phát hành chúng với một số, sau đó làm mới trình duyệt sau mỗi 10 giây (hoặc sử dụng Ajax) để cho họ biết có bao nhiêu người đứng trước chúng trong hàng đợi. Khi đến lượt của họ, thực hiện yêu cầu thực tế dưới mạo danh. (Điều này yêu cầu họ giữ cửa sổ trình duyệt mở trong khi đợi trong hàng đợi và cũng yêu cầu bạn theo dõi các yêu cầu chưa xử lý và các trình duyệt đang hoạt động so với các trình duyệt đã biến mất). Nasty, nhưng sẽ làm việc.

Không biết vấn đề thực sự, rất khó để tư vấn, ngoài việc nói không làm theo cách này - quá nhiều gotchas.

Answer 3

giải pháp này đi kèm với một caveat lớn, nhưng thay vì lưu trữ thẻ/vé, bạn có thể sử dụng LsaLogonUser chức năng và đoàn chế nhận mã thông báo cho mạo danh mà không thông tin cung cấp, vào lúc này công việc đã sẵn sàng để được dequeued.

Đây là cách chuyển tiếp giao thức được triển khai, trong đó thông tin đăng nhập không phải Windows (ví dụ: trên trang web công khai) có thể được ánh xạ tới người dùng miền được mạo danh để truy cập vào tài nguyên nội bộ.

Thông báo trước, đây rõ ràng là lỗ hổng bảo mật tiềm năng rất lớn và tài khoản đang chạy quá trình gọi LsaLogonUser phải được cấp SeTcbPrivilege ("Hành động như một phần của hệ điều hành").

Nếu có cách lưu trữ vé, điều đó rõ ràng sẽ tốt hơn nhiều, nhưng điều đầu tiên tôi nghĩ khi tôi thấy câu hỏi là vấn đề thời gian hết hạn mà @Ben đã đề cập.

Chỉnh sửa: A couple của excellent articles về chuyển tiếp giao thức và ủy quyền hạn chế, với phạm vi bảo hiểm rộng lớn.