Vì vậy, về cơ bản, chúng tôi có một nhóm với các máy chủ Linux chạy PowerShell Core (kết hợp giữa 6 và 7) phải thực thi các lệnh Windows PowerShell từ xa trên các máy chủ Windows. Vấn đề là, nhóm chưa bao giờ có Kerberos hoạt động để xác thực và đang dựa vào gssapi để NTLM auth hoạt động, AFAIK không thực sự được MS hỗ trợ cho tình huống này.
Hiện tại, các máy chủ Linux này đang gặp lỗi MI_RESULT_FAILED sau một thời gian (điều này mới bắt đầu vào tuần trước, trước đó mọi thứ vẫn hoạt động tốt) và yêu cầu khởi động lại dịch vụ WinRM trên nút từ xa để điều khiển từ xa hoạt động. Điều này hoạt động trong khoảng một ngày trước khi WinRM cần được bật lại.
Hiện tại, vì NTLM không phải là cơ chế xác thực được hỗ trợ bởi PowerShell Core trên Linux (chỉ hoạt động do gssntlmssp được duy trì bởi RedHat, không phải Microsoft), con đường rõ ràng phía trước ở đây sẽ là sử dụng OpenSSH cho PS Remoting từ Linux thay thế, hoặc chuyển sang sử dụng xác thực Kerberos thay vì NTLM. Tuy nhiên, vì mọi thứ đã hoạt động trước tuần trước, nên ban quản lý không muốn thực hiện xác thực hoặc thay đổi giao thức để giải quyết vấn đề này, họ muốn những gì đang hoạt động được khắc phục. Tại thời điểm này, tôi đang xoay bánh xe của mình để cố gắng tìm ra lý do tại sao NTLM auth bị hỏng và các bản sửa lỗi được đề xuất của tôi hiện không có sẵn.
Các nút nguồn đang chạy RHEL8 hoặc AL2, các nút từ xa là Windows 2016-2019, với một số phiên bản cũ 2012 kết hợp. Windows sang Windows PS Remote không không phải ngắt ở đây, chỉ có Linux với Windows.
Có ai gặp tình huống này trước đây hoặc một cái gì đó tương tự? Bất kỳ ý tưởng nào về những gì chúng tôi có thể cố gắng giải quyết vấn đề này?
CHỈNH SỬA: Tôi đã sửa lỗi ở trên thành MI_RESULT_FAILED. ACCESS_DENIED là những gì nhóm đã báo cáo vấn đề đã nói, nhưng trong bản tái tạo vấn đề của chúng tôi, chúng tôi thấy MI_RESULT_FAILED. Dấu vết WinRM cho thấy NTLM auth đang thành công nhưng vẫn không thành công ngay cả khi chỉ hiển thị "Xin chào thế giới" qua Gọi lệnh.
