2013-02-18 33 views
28

Tôi đang gặp sự cố khi gọi dịch vụ web từ trong ứng dụng web và tôi hy vọng một người nào đó ở đây có thể trợ giúp. Từ những gì tôi có thể biết, số này có vẻ như để liên hệ với Kerberos double-hop issue. Tuy nhiên, nếu có, tôi không chắc chắn phải làm gì để thực sự khắc phục sự cố. Để làm cho mọi việc trở nên khó khăn hơn, tôi không có quyền thích hợp để thực hiện các thay đổi đối với tài khoản Active Directory, vì vậy tôi cần biết những gì cần hỏi khi yêu cầu thay đổi. Trong trường hợp của tôi, tôi cần phải vượt qua các thông tin xác thực (Tích hợp Windows Authentication) từ một ứng dụng web vào một dịch vụ web phụ trợ để dịch vụ web chạy theo ngữ cảnh người dùng thích hợp.Làm cách nào để khắc phục sự cố kép của Kerberos?

Dưới đây là vấn đề chính xác của tôi:

này hoạt động

Working scenario

này không hoạt động

Non-working scenario

Các chỉ sự khác biệt giữa kịch bản làm việc và kịch bản không hoạt động là kịch bản làm việc đang chạy ứng dụng trên máy chủ cục bộ (cho dù máy tính của nhà phát triển hoặc trên máy chủ được đề cập) và ví dụ không hoạt động đang chạy trên máy khác. Mã giữa hai kịch bản chính xác giống nhau.

Những gì tôi đã cố gắng

  1. Thêm một SPN vào tài khoản miền chạy hồ bơi ứng dụng cho mỗi máy chủ setspn -a http/server1 DOMAIN\account
  2. phương pháp khác nhau của mạo danh
  3. Xóa mã mạo danh using(...) và thực hiện cuộc gọi dịch vụ web dưới dạng tài khoản nhóm ứng dụng. Điều này hoạt động như mong đợi.

Có ai có ý tưởng nào về việc tôi có thể làm gì để khắc phục sự cố này không?

+3

Sơ đồ nguội khiến cho câu hỏi dễ hiểu hơn nhiều - cảm ơn! –

Trả lời

12

Các máy chủ trung gian phải được tin cậy cho đoàn. Nếu không, ủy nhiệm sẽ không được ủy quyền và máy chủ trung gian không thể mạo danh ứng dụng khách gốc.

+1

Điều này đã trở thành giải pháp trong môi trường tôi đã mô tả ở trên. Tuy nhiên, chúng tôi đã gặp phải (và vẫn đang chạy vào) cùng một vấn đề trong môi trường sản xuất của chúng tôi khi NLB đang được sử dụng. Tôi đang làm việc thông qua các vấn đề bây giờ, nhưng cần phải thiết lập một môi trường thử nghiệm bắt chước môi trường sản xuất của chúng tôi để xác định nguyên nhân chính xác. Bất kỳ cơ hội nào bạn biết phải làm gì trong trường hợp đó?Thêm một SPN vào tài khoản miền đang chạy tất cả các dịch vụ với tên cụm và FQDN kết thúc phá vỡ tất cả xác thực. –

+0

Bạn không thể ánh xạ SPN cho một số tài khoản. Tất cả các SPN phải có sự khác biệt trong toàn khu rừng. Vì bạn đang đứng sau bộ cân bằng tải, bạn có thể thử như sau: 1. chuyển tiếp DNS đến miền NLB, đảo ngược DNS tới các máy chủ thực. 2. Sử dụng NLB kết hợp với DNS round-robin. Điều này làm việc chắc chắn. –

+0

Có lẽ tôi đã giải thích mọi thứ không chính xác do kiến ​​thức hạn chế của tôi về không gian vấn đề. Những gì tôi ban đầu đã cố gắng làm (đã phá vỡ mọi thứ) là chạy các lệnh sau: setspn -A http/servername DOMAIN \ webaccount setspn -A http/servername.FQDN DOMAIN \ webaccount –

3

Thường xuyên hơn không phải lý do là Máy chủ 1 không chuyển mã thông báo ủy nhiệm cho máy chủ 2. Vì vậy, khi Máy chủ 2 cố gắng sử dụng vé xác thực đó để đến nơi khác (có thể là máy chủ SQL) không thành công.

Bạn nên thiết lập mức độ mạo danh cho WCF gọi

ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Delegation 

http://msdn.microsoft.com/en-us/library/system.servicemodel.security.windowsclientcredential.allowedimpersonationlevel.aspx

Các vấn đề liên quan