Ou: "Isso é uma coisa? E como eu verificaria se fosse?"
Em um ambientesem um controlador de domínio, ao acessar um compartilhamento em uma caixa do Windows Server 2008 R2,de um computador remotosem uma conta de usuário correspondente no servidor, (e conectando digitando \\SERVERNAME\ShareNameno menu Iniciar) Atualmente observo o seguinte comportamento com base na configuração "Compartilhamento protegido por senha" (configurações de compartilhamento avançadas):
Quando "Compartilhamento protegido por senha" estiver ativadosobre, todas as tentativas de conexão falharão após 30 segundos com:
Falha de logon: o usuário não recebeu o tipo de logon solicitado neste computador.
Com "Compartilhamento protegido por senha" ativadodesligado, conexões com compartilhamentos acessíveis anônimos são permitidas, enquanto compartilhamentos com permissão restrita falham com:
Você não tem permissão para acessar \SERVERNAME\ShareName. Entre em contato com o administrador da rede para solicitar acesso.
Este parece ser um comportamento esperado. Preciso ter determinados compartilhamentos acessíveis por logons anônimos, então tive que alterar essa configuração do padrão paradesligado.
NO ENTANTO,há um terceiro caso aqui.(o quê?)
Se você tentar se conectar a um compartilhamentosem ter modificado esta configuração(ou seja, está definido parasobremas você nunca clicou nele), a conexão se comporta de maneira semelhante aosobrecaso acima, pois leva até 30 segundos para mostrar uma resposta,mas então ele exibe uma caixa de diálogo de autenticação:
Tive esse palpite depois de bater minha cabeça contra a parede por alguns dias e apenas repliquei isso em um servidor sem compartilhamentos existentes: Crie um compartilhamento não lido, tente conectar e obter diálogo, altere a configuração, conecte-se com sucesso, altere a configuraçãovoltare receba uma mensagem de erro diferente. (Testei tudo isso em sistemas clientes novos para que não houvesse risco de armazenamento em cache.)
Para reiterar: controlei os sistemas do cliente. Isso parece estar totalmente relacionado ao servidor.
Portanto, está claro para mim que alterar a configuração "Compartilhamento protegido por senha" está mudando mais de uma coisa (chave de registro? Sou nativo do Mac) nos bastidores, e que as configurações padrão com as quais o sistema é fornecido NÃO correspondem todas. com a configuração refletida no painel de controle (ou o próprio painel de controle está quebrado e deveria mudar mais coisas).
Portanto, a questão é: isso é intencional ou é um bug? E em ambos os casos, qual é a "configuração oculta" que está sendo alterada ou deixada inalterada? Como alguém rastrearia isso? Estou ficando sem servidores novos para testar. :-(
Responder1
Isso realmente despertou meu interesse. Consegui replicar suas descobertas em meu laboratório com o mesmo padrão de resultados que você descreve. Usei o Procmon para tentar ver quais alterações foram feitas e quase desisti até ver o seguinte:
Isso mostra lsass.exe (Autoridade de Segurança Local) gravando no SAM local e fazendo alterações na conta de Convidado integrada (conhecido RID 501). Com certeza, quando testei novamente seu cenário enquanto observava o status da conta de convidado, vi que ele estava ativado quando o "Compartilhamento protegido por senha" estava desativado. No entanto, quando o "Compartilhamento protegido por senha" é reativado, a conta de convidado não é desativada novamente. Desativar manualmente a conta de convidado restaura a funcionalidade original: são solicitadas credenciais (ou seja, seu terceiro caso).
Não sei por que isso se comporta assim. PARA ser honesto, eu nunca tinha alternado a configuração “Compartilhamento protegido por senha” antes de hoje (ou mesmo notado). Espero que isso ajude no seu projeto. Se alguém estiver interessado em aprofundar, seria interessante saber se esse comportamento ainda está presente no Server 2012/2012 R2...
Ah, e para suas perguntas originais (isso é intencional ou é um bug?), não tenho a menor ideia ...
Responder2
Se entendi sua pergunta corretamente, as credenciais dos compartilhamentos são salvas no Credential Manager, no painel de controle.
Para abrir a caixa de diálogo de autenticação, basta excluir a credencial relativa a esse compartilhamento no Gerenciador de credenciais.
Quando você marca 'Lembrar minhas credenciais', isso geralmente é salvo no Gerenciador de credenciais e se essa senha estiver errada, você verá o erro de falha de logon.
Responder3
Pode não ajudar você, mas caso isso aconteça - muitas vezes recebo chamadas em que meus usuários não conseguem acessar um compartilhamento (sua senha antiga é armazenada em cache pelo Windows) e peço que eles façam o seguinte:
uso líquido * /D