Серверы Linux перестали использовать удаленное взаимодействие PowerShell через WinRM с использованием NTLM на удаленных серверах Windows.
Итак, по сути, у нас есть команда с серверами Linux, на которых работает PowerShell Core (смесь 6 и 7), которым приходится выполнять удаленные команды Windows PowerShell на серверах Windows. Проблема в том, что команда так и не задействовала Kerberos для аутентификации и полагается на gssapi для работы аутентификации NTLM, что AFAIK на самом деле не поддерживается MS для этого сценария.
Сейчас происходит то, что эти серверы Linux через некоторое время получают ошибки MI_RESULT_FAILED (это началось только на прошлой неделе, до этого все работало нормально) и требует перезапуска службы WinRM на удаленном узле, чтобы удаленное взаимодействие заработало. Это работает примерно в течение дня, прежде чем WinRM потребуется снова откатить.
Теперь, поскольку NTLM не является механизмом аутентификации, поддерживаемым PowerShell Core в Linux (работает только благодаря gssntlmssp, который поддерживается RedHat, а не Microsoft), очевидным путем вперед здесь будет либо использовать OpenSSH для удаленного взаимодействия PS из Linux, либо вместо этого использовать OpenSSH для удаленного взаимодействия PS из Linux, или перейдите на использование аутентификации Kerberos вместо NTLM. Однако, поскольку до прошлой недели все работало, руководство не хочет рассматривать аутентификацию или изменение протокола для решения этой проблемы, они хотят, чтобы то, что работало, было исправлено. На данный момент я пытаюсь выяснить, почему NTLM-аутентификация сломалась, и мои рекомендуемые исправления пока не обсуждаются.
Исходные узлы используют RHEL8 или AL2, удаленные узлы — Windows 2016–2019, а также несколько устаревших версий 2012 года. Удаленное взаимодействие с Windows на Windows PS здесь не нарушается, только с Linux на Windows.
Кто-нибудь сталкивался с такой ситуацией раньше или с чем-то подобным? Есть идеи, как мы могли бы попытаться решить эту проблему?
РЕДАКТИРОВАТЬ: я исправил ошибку выше, чтобы .ACCESS_DENIEDтак сказала команда, сообщившая о проблеме, но при воспроизведении проблемы мы видимMI_RESULT_FAILED. Трассировка WinRM показывает, что аутентификация NTLM прошла успешно, но все равно не удается, даже когда просто отображается «Hello World» черезInvoke-Command.
1 ответ
Я столкнулся с той же проблемой, наша конкретная ошибка была MI_RESULT_FAILED. После перезапуска службы WinRM все заработало нормально, но на следующий день она снова перестала работать.
Оказалось, что антивирус блокирует службу WinRM, когда поступил скриптовый запрос PowerShell от AWX Ansible, поскольку AWX использовал для команды кодировку base64, что вызвало срабатывание правила «Ограничение команд Powershell — EncodedCommand». Эта команда была отправлена дважды за ночь, поэтому до тех пор, пока WinRM не был перезапущен утром, вся связь через этот PID была заблокирована нашим AV. Надеюсь, поможет!