%3F.png)
Я всегда получал доступ к удаленным машинам с помощью таких вещей, как общие папки (\\serverName\share) и команд Powershell, которые используют параметр -ComputerName. Если я делаю это для машины в удаленном домене, мне нужно предоставить аргумент -Credential. И все это отлично работает. Я думаю, это называется DCOM. Я также могу получить доступ к WMI таким образом. Однако, когда я пытаюсь использовать enter-pssession для удаленной машины, это не работает из-за какой-то штуки с Kerberos. Предположительно, разница в том, что Kerberos обеспечивает взаимную аутентификацию машин. Но если я получаю доступ к машине в удаленном домене, она в любом случае не использует Kerberos для транзакций в стиле DCOM. Так что, если я заставлю pssession работать, поместив удаленную машину в свой Winrm TrustedHosts (и назвав ее IP-адресом) вместо настройки инфраструктуры сертификатов (и, таким образом, не имея никакой аутентификации машины), разве это действительно хуже, чем команды DCOM, которые я выполнял вечно? --Я видел, как люди писали что-то вроде: "используйте это только на тестовых машинах, а не в производственной среде", потому что соединение не зашифровано. Но транзакция учетных данных, предположительно, все еще зашифрована. Если можно использовать -ComputerName и -Credential с другими командами, в чем разница?
решение1
Да, это менее безопасно.
NTLM (используемый протокол аутентификации) технически менее безопасен. Вы представляете свои учетные данные хосту. И NTLM не предлагает клиенту аутентификацию хоста. Злоумышленнику легко выдать себя за этот хост по этому IP-адресу.
В среде Kerberos вы не представляете свои учетные данные хосту, вы представляете учетные данные отдельному серверу аутентификации, он предоставляет токен, и этот токен затем представляется для аутентификации. Учетные данные представляются на меньшем количестве хостов, которые более безопасны, чем типичный сервер.
Если включена и используется базовая аутентификация вместо Negotiate/NTLM, эти учетные данные отправляются по сети в незашифрованном виде, что, очевидно, плохо. Однако после аутентификации сеанс шифруется на уровне сообщений независимо от транспортной схемы HTTP/HTTPS. Методы базовой+HTTP и дайджест-аутентификации никогда не следует включать/использовать.
Большинство организаций этого не делают, поскольку это не пройдет аудит. В сценариях рабочих групп сертификаты используются почти всегда.
https://devblogs.microsoft.com/powershell/compromising-yourself-with-winrms-allowunencrypted-true/