none
Cliente fora do dominio (notebook) não mapeia pasta após troca de senha do servidor RRS feed

  • Pergunta

  • Boa Tarde à todos !

    Problema: após troca de senha do servidor Win2012 R2, um notebook (Win 8.1) que não está no domínio não mais acessa e nem permite o mapeamento de pastas no servidor.

    Antes da alteração, mapeei com o endereço "\\ip do servidor\shared folder" e tudo funcionava perfeitamente. Após solicitação de troca de senha do servidor, não se consegue mais com quaisquer usuários, incluindo o Administrador (apenas nesta máquina).

    Procedimentos já verificados: Ping (OK) ; nslookup (OK) ; já verificado que o driver está com "Client for MS Networks" setado; já inseridos netsh winsock reset; ipconfig / flushdns; restartado a máquina; ipconfig /registerdns sem efeito.

    Os cmds net view \\server /all e netview \\ipserver /all apresentam erro 

    Também já tentado com vários outros pontos de rede com mesma falha

    Quando se tenta mapear uma pasta, seja \\ip server ou \\domínio abre-se a tela de autenticação e apresenta o erro "the specified network password is not correct."

    Peço orientações do que mais pode ser feito ou de como resetar o cache de conexão ao servidor.

    Grato

    Adir

    quarta-feira, 15 de junho de 2016 18:31

Respostas

  • Adir

    execute os procedimentos abaixo abaixo:

    1- Remova todos os mapeamentos de rede, executando o comando abaixo:

    NET USE * /del

    2- Remova todas as credenciais salvas executando o comando abaixo:

    rundll32.exe keymgr.dll,KRShowKeyMgr

    3- Siga o caminho abaixo e remova todas as credenciais salvas:

     Start ->Run->Type control userpasswords2> Advanced->Manage passwords

    4- Se ainda assim, o problema persistir, habilite o log de depuração do NET LOGON executando o comando abaixo:

    nltest /dbflag:0x2080ffff

    reinicie o serviço de netlogon para iniciar a depuração:

    net stop netlogon & net start netlogon

    Reproduza o problema, e compartilhe conosco o resultado da autenticação identificado ao final do arquivo de log c:\windows\logs\netlogon.log.

    Após finalizar os testes será necessário parar a depuração, execute o comando:

    Nltest /DBFlag:0x0

    Boa sorte!


    Achou útil? Classifique! Acessem nosso blog: http://www.dsindepth.com.br

    • Marcado como Resposta Thales F Quintas segunda-feira, 20 de junho de 2016 18:51
    segunda-feira, 20 de junho de 2016 18:39

Todas as Respostas

  • Boa tarde Adir Pinto,

    Por gentileza dê uma olhada no KB abaixo, vai lhe auxiliar na solução do problema:


    Thales F Quintas

    Esse conteúdo e fornecido sem garantias de qualquer tipo, seja expressa ou implícita

    TechNet Community Support

    Por favor, lembre-se de Marcar como Resposta as postagens que resolveram o seu problema. Essa é uma maneira comum de reconhecer aqueles que o ajudaram e fazer com que seja mais fácil para os outros visitantes encontrarem a resolução mais tarde.



    • Editado Thales F Quintas quarta-feira, 15 de junho de 2016 19:34
    • Marcado como Resposta Thales F Quintas quarta-feira, 15 de junho de 2016 19:35
    • Não Marcado como Resposta Adir Pinto sexta-feira, 17 de junho de 2016 14:04
    quarta-feira, 15 de junho de 2016 19:34
  • Caro Thales. Grato pelo apoio.

    Combinei com o cliente em rodar o Fixit amanhã na hora do almoço. Caso Ok (ou não) comentarei aqui no post.

    Até lá

    Abçs

    Adir

    quarta-feira, 15 de junho de 2016 20:04
  • Caro Thales

    Infelizmente o Fixit não rodou na máquina do cliente. Irei amanhã no cliente para implementar manualmente (regedit) os procedimentos necessários. Manterei contato.

    Att

    Adir

    quinta-feira, 16 de junho de 2016 17:49
  • Caro Thales

    Acabo de retornar do cliente, alterando os registros cfe o kb 947232 porém sem sucesso também. O Fixit também não rodou.

    Talvez para tentar ser mais claro: máquina estava mapeando drivers da rede até a mudança de senha do servidor, na semana passada. Após isso, sequer enxerga a rede e quando se tenta forçar via IP do servidor, abre-se a tela de autenticação e qualquer usuário e senha (incluindo o Administrador) que se coloque, volta-se  a tela em anexo. Lembrar que é um Notebook pessoal e não é parte do domínio.

    Grato pela atenção

    Adir

    sexta-feira, 17 de junho de 2016 13:50
  • Olá Adir, boa tarde, tudo bem?

    Deixa ver se eu entendi seu cenário...

    Você possui uma estação de trabalho cliente que está em WORKGROUP, e que precisa acessar um file share de um servidor que faz parte de um domínio, correto?

    Neste cenário, quando você tenta mapear o share como unidade de rede, são exigidas credenciais, e você esta adicionando as credenciais de um usuário do domínio, certo?

    Tenho algumas perguntas:

    Se você acessar diretamente o share via \\NOMEDOSERVIDOR, ocorre o mesmo problema?

    Você está adicionando as credenciais seguindo o padrão NOME_DO_DOMINIO\NOME_DO_USUARIO?

    Quando você se refere a troca da senha do servidor, imagino que você se refira a troca de senha do usuário administrador que gerencia este server, correto?


    Achou útil? Classifique! Acessem nosso blog: http://www.dsindepth.com.br

    sexta-feira, 17 de junho de 2016 16:52
  • Caro Fernando, Boa tarde

    Primeiramente Grato pelo suporte.

    Tudo funcionava perfeitamente até ocorrer a troca de senha de Administrador no servidor.

    Conforme mencionado nos posts anteriores, sim tanto com o nome do server, como IP não mais funciona.

    Já foi tentado mudar ponto de rede, outro usuário e inclusive tentado com senha do Administrador sem sucesso.

    Além do proposto pelo Thales no KB 947232 foram tentados os procedimentos: Ping (OK) ; nslookup (OK) ; já verificado que o driver está com "Client for MS Networks" setado; já inseridos netsh winsock reset; ipconfig / flushdns; restartado a máquina; ipconfig /registerdns sem efeito.

    Os cmds net view \\server /all e netview \\ipserver /all apresentam erro 

    Todas as outras 30 máquinas que estão no domínio funcionam sem problemas (Windows 7 Pro), além de um MACBook também fora do domínio. Rede estável.

    Me faz crer que alguma inconsistência no Windows 8.1 PRO desta máquina.

    Existe algum registro que poderia ser o ofensor? Ou teremos de formatar a máquina para resolver esta incongruência? Acho estranho isso pois quando mudarmos a senha de Administrador do servidor, novamente teremos o mesmo impacto.

    Conto com teu apoio para resolver esta questão, agradecendo mais uma vez

    Adir

    sexta-feira, 17 de junho de 2016 17:20
  • Adir

    execute os procedimentos abaixo abaixo:

    1- Remova todos os mapeamentos de rede, executando o comando abaixo:

    NET USE * /del

    2- Remova todas as credenciais salvas executando o comando abaixo:

    rundll32.exe keymgr.dll,KRShowKeyMgr

    3- Siga o caminho abaixo e remova todas as credenciais salvas:

     Start ->Run->Type control userpasswords2> Advanced->Manage passwords

    4- Se ainda assim, o problema persistir, habilite o log de depuração do NET LOGON executando o comando abaixo:

    nltest /dbflag:0x2080ffff

    reinicie o serviço de netlogon para iniciar a depuração:

    net stop netlogon & net start netlogon

    Reproduza o problema, e compartilhe conosco o resultado da autenticação identificado ao final do arquivo de log c:\windows\logs\netlogon.log.

    Após finalizar os testes será necessário parar a depuração, execute o comando:

    Nltest /DBFlag:0x0

    Boa sorte!


    Achou útil? Classifique! Acessem nosso blog: http://www.dsindepth.com.br

    • Marcado como Resposta Thales F Quintas segunda-feira, 20 de junho de 2016 18:51
    segunda-feira, 20 de junho de 2016 18:39
  • Caro Fernando, Bom Dia

    Problema resolvido com o reset dos registros. Na realidade os cmds:

    rundll32.exe keymgr.dll,KRShowKeyMgr e  Start ->Run->Type control userpasswords2> Advanced->Manage passwords  possuem a mesma função !!

    Muitíssimo grato pela atenção e apoio. Mais uma vez, graças a este Forum de Excelencia, problema resolvido.

    Considero fechada esta Thread !!

    Abraços a todos

    Adir

    terça-feira, 21 de junho de 2016 14:33