Acontece que, enquanto a antiga documentação para uso da rede indicava que você precisava usar aspas duplas, no PowerShell você deveria usar aspas simples em torno da senha.
Estou tentando montar uma pasta de rede em um script usando net use, e continuo recebendo um erro de senha incorreta. Estou usando a seguinte sintaxe:
use \server\share password /User:serviceaccount
Fazer isso desta maneira retorna um erro de senha incorreto. Se eu colocar * como senha e entrar no prompt, tudo funciona bem.
Eu também tentei colocar a senha entre aspas duplas "" sem efeito. Essa senha específica é gerada aleatoriamente e consiste em 14 caracteres de caracteres superiores, inferiores, dígitos e especiais (nesse caso, o único caractere especial é $).
O script está sendo executado no Windows Server 2008 R2 e está se conectando ao Server 2003.
Há alguma limitação nos tipos de senhas que podem ser passadas para o uso da rede via argumentos de linha de comando?
EDIT: Isso está sendo executado no PowerShell.
Eu tropecei nesse tipo de mau comportamento ao conectar do Win2012R2 ao Samba 3.6.6, em um "ambiente de grupo de trabalho" (sem domínio próprio do NT).
Nenhuma das duas versões a seguir funcionaria de forma confiável:
NET USE X: \server\share password /User:username
NET USE X: \server\share /User:username password
Curiosamente, talvez houvesse 10% de chance de que funcione ! E, se eu tentar ignorar a senha entre os argumentos do cmdline e solicitar "NET USE", as chances seriam 95% positivas.
Eu tinha outro compartilhamento em um servidor diferente (Linux com um histórico e configuração de atualização diferente) que funcionava muito bem.
Inicialmente, suspeitei de "caracteres especiais", porque minha nova senha era "mais strong". Eu tentei aspas simples ou duplas em torno da senha, sem sucesso. Eu tentei criar uma senha muito simples (e fraca) - sem sucesso.
Em seguida, encontrei conselhos para primeiro usar o cmdkey para salvar as credenciais de logon corretas localmente. Isso nunca foi necessário antes, mas eu tentei mesmo assim:
cmdkey /add:<machine> /user:<username> /pass:<password>
Dessa forma, salvei as credenciais do usuário conectado na máquina cliente, mas isso não resolveu as falhas de logon misteriosas do NET USE.
Então eu me atrapalhei com a configuração e os logs do Samba.
Ao depurar a autenticação do Samba, a seguinte opção smb.conf pode ser útil:
log level = 3 passdb:10 auth:10
O padrão é provavelmente log level = 2 , que nem sequer registra tentativas de login com falha.
O Samba cria arquivos de log úteis em / var / log / samba /. Para cada máquina cliente recebida, ela cria dois arquivos:
log.<ip_address>
log.<netbios_name>
Com um nível de log elevado, é claramente visível que o log baseado em IP termina no ponto em que o smbd aprende o nome NetBios da máquina - e continua no segundo arquivo.
E também era claramente visível que a "verificação de senha" é na verdade um processo bastante complexo :-) O handshake da rede CIFS tem várias trocas de dados, e o processamento das credenciais em parte do servidor Samba não é exatamente trivial também. Em tentativas bem-sucedidas e malsucedidas, no já mencionado log level 10 (seletivo para auth e passdb), você obtém duas páginas de lista de registros densos, onde o Samba sugere como ele prefixar um domínio e como ele tenta mapear um usuário via username map , antes de finalmente tentar verificar as credenciais (pelo menos duas vezes). Curiosamente, o processo é um pouco diferente para os dois estilos de uso diferentes de NET USE no cliente: com senha no cmdline (a sintaxe não faz diferença) vs. com um prompt de senha. O processo preciso provavelmente também dependerá do auth backend que você escolheu no servidor Samba. O meu era o passdb antigo simples (/ etc / samba / smbpasswd).
Para mim, o culpado foi provavelmente o recurso username map . O smb.conf no servidor Samba não é meu próprio bebê, eu aprendi sobre esse recurso ao longo do caminho. Eu encontrei o aviso de outras pessoas que pode morder. Ele pode até mesmo ser usado para mapear vários usuários do Windows para um único usuário UNIX local, ou apenas 1: 1 - de qualquer forma, observe que o Samba tentará procurar (verificar) as credenciais de logon usando o nome de usuário "remapeado" e não o nome de usuário original do Windows (que você também pode ter inserido no smbpasswd). Qual foi possivelmente meu problema. Assim que removi o "nome de usuário culpado" de / etc / samba / smbusers, minha linha NET USE começou a funcionar em qualquer um dos dois formatos com senha no cmdline.
Não tenho certeza do motivo pelo qual o Samba às vezes tenta o nome de usuário do Windows, enquanto outras vezes ele tenta o nome de usuário remapeado. Pode ser um "recurso" específico para a versão histórica específica de smbd e passdb. Ou para uma interação específica de diferentes implementações do CIFS no cliente e no servidor.
E então tive um problema de acompanhamento (após a autenticação) em que security = user combinado com diretórios subjacentes acessíveis a grupos e um grupo configurado incorretamente em / etc / passwd (e / etc / group) significava que meus clientes estavam conectados mas foi negado o acesso a tais diretórios CIFS ... Note que em algumas distroes ou estilos de configuração,
todos os usuários UNIX compartilham um grupo padrão de "usuários", enquanto em outras distroes eles recebem um grupo padrão individual, recém-criado para cada novo usuário ...
De que serve essa resposta para um cenário, em que o servidor é uma máquina com Windows 2003? Provavelmente não é muito útil, exceto pelo contexto geral, que o CIFS tenha uma longa história / evolução por trás dele, e as várias gerações do Windows CIFS podem apresentar "peculiaridades de compatibilidade cruzada" semelhantes às da implementação do Samba de código aberto. Comece a partir de políticas que permitam ou neguem versões mais antigas dos protocolos de autenticação: LanMan e NTLM1, que em geral podem ser proibidos administrativamente em um cliente ou servidor mais moderno, por motivos de segurança (principais deficiências nos protocolos antigos). Eu me lembro especificamente de uma situação em que o windows 7 (ou era o Windows 8?) Começou a insistir no NTLMv2 na configuração padrão.