Tôi nhận được lỗi "Không có điểm cuối nghe tại net.pipe: // localhost" như được mô tả ở các địa điểm khác nhưng tôi dường như không tìm thấy câu trả lời thực sự.Đặt SPN trên địa chỉ điểm cuối cho điểm cuối dịch vụ NetNamedPipe
Đây là một định danh lớn của vấn đề: http://kennyw.com/indigo/102
Khi sử dụng WCF, Windows authentication được thực hiện thông qua SSPI-Negotiate, mà trong nhiều trường hợp sẽ chọn Kerberos như cơ chế xác thực thực tế . Tuy nhiên, nếu mục tiêu SPN truyền cho SSPI là một cũng được hình thành SPN cho tài khoản máy tính cục bộ (ví dụ host/[tên máy dns]) sau đó Negotiate sẽ sử dụng NTLM (loopback tối ưu hóa) và access token sẽ không có SID mạng (và do đó sẽ có thể sử dụng được với NetNamedPipes).
Nhưng nó không cho tôi biết cách giải quyết vấn đề. Tôi đang tạo điểm cuối của mình theo lập trình.
var binding = new NetNamedPipeBinding();
binding.Security.Mode = NetNamedPipeSecurityMode.Transport;
binding.Security.Transport.ProtectionLevel = ProtectionLevel.EncryptAndSign;
var id = EndpointIdentity.CreateSpnIdentity("host/" + Environment.MachineName);
var endpointAddress = new EndpointAddress(new Uri(serviceClientUrl), id);
var client = new ServiceClient(binding, endpointAddress);
Tôi đoán rằng sự cố của tôi nằm trong CreateSpnIdentity nhưng tôi không chắc chắn nên sử dụng giá trị nào.
Thông tin bổ sung: Để giải thích thêm về ngữ cảnh này. Dịch vụ Wcf được lưu trữ dưới dạng Dịch vụ Windows đang chạy trong tài khoản NetworkService (Tôi đã thử Hệ thống cục bộ). Dịch vụ được tạo bằng cách sử dụng hàm tạo NetNamedPipeBinding mặc định:
host.AddServiceEndpoint(typeof(IService), new NetNamedPipeBinding(), "ServiceName");
Tôi đã tạo một webpart SharePoint sử dụng dịch vụ này. Các kicker là nếu trang SharePoint được thiết lập để xác thực dựa trên biểu mẫu hoặc chỉ tên máy được sử dụng trong url dưới Windows Authentication thì không có vấn đề gì. CHỈ nếu tên máy hoàn toàn đủ điều kiện được sử dụng cho url trong xác thực Windows để tôi nhận được lỗi ở trên.
Tôi khá chắc chắn điều này có liên quan đến các vấn đề về Kerberos NTLM được khắc phục trong bài viết nhưng tôi không chắc chắn cách thực hiện.
Vâng, tôi đã nhận ra rằng Net Tcp thực sự là giải pháp duy nhất của tôi (điều này là tốt bởi vì cuối cùng chúng tôi sẽ chuyển dịch vụ này sang một máy khác). Cảm ơn thông tin chi tiết và liên kết. – webwires