%3F.png)
Sempre tenho acessado máquinas remotas com coisas como compartilhamentos de arquivos (\\serverName\share) e usando comandos do Powershell que usam um parâmetro -ComputerName. Se eu fizer isso para uma máquina em um domínio remoto, terei que fornecer o argumento -Credential. E tudo isso funciona bem. Acho que isso se chama DCOM. Também posso acessar o WMI assim. No entanto, quando tento usar enter-pssession na máquina remota, ele não funciona por causa de algum problema do Kerberos. Supostamente, a diferença é que o Kerberos fornece autenticação mútua das máquinas. Mas, se eu estiver acessando uma máquina em um domínio remoto, ela não estará usando Kerberos para transações no estilo DCOM. Então, se eu fizer a sessão funcionar colocando a máquina remota em meus Winrm TrustedHosts (e nomeando-a com o endereço IP), em vez de configurar uma infraestrutura de certificado (e, portanto, não ter nenhuma autenticação de máquina), isso é realmente pior do que o DCOM comandos que tenho executado desde sempre? --Já vi pessoas escreverem coisas como "use isso apenas em máquinas de teste, não em ambientes de produção" porque a conexão não é criptografada. Mas, a transação de credenciais ainda está supostamente criptografada. Se não houver problema em usar -ComputerName e -Credential com outros comandos, qual é a diferença?
Responder1
Sim, é menos seguro.
NTLM (que é o protocolo de autenticação usado) é tecnicamente menos seguro. Você está apresentando suas credenciais a um host. E o NTLM não oferece autenticação do host ao cliente. É simples para um invasor personificar esse host nesse endereço IP.
Em um ambiente Kerberos, você não apresenta suas credenciais ao host, mas sim a um servidor de autenticação separado, que fornece um token e esse token é então apresentado para autenticação. As credenciais são apresentadas em menos hosts que são mais seguros que um servidor típico.
Se a Autenticação Básica estiver habilitada e usada em vez de Negociar/NTLM, essas credenciais serão enviadas sem criptografia, o que é obviamente ruim. No entanto, após a autenticação, a sessão é criptografada no nível da mensagem, independentemente do esquema de transporte HTTP/HTTPS. Os métodos de autenticação Basic+HTTP e Digest nunca devem ser ativados/usados.
A maioria das organizações não faz isso porque não passaria em uma auditoria. Em cenários de grupo de trabalho, os certificados são quase sempre usados.
https://devblogs.microsoft.com/powershell/compromising-yourself-with-winrms-allowunencrypted-true/