Acesso negado erro 3221225578 com compartilhamento de arquivos para o servidor Windows

Question

Estou tentando acessar os compartilhamentos em um servidor. A caixa de credenciais aparece e eu insiro um nome de usuário e senha corretos e recebo acesso negado.

O mais bobo é que eu posso Remote Desktop para o servidor (usando as mesmas credenciais), e eu posso verificar o Security log de eventos para os erros de acesso negado:

Event Type: Failure Audit
Event Source:   Security
Event Category: Account Logon 
Event ID:   681
Date:       3/19/2011
Time:       11:54:39 PM
User:       NT AUTHORITY\SYSTEM
Computer:   STALWART
Description:
The logon to account: Administrator
 by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 from workstation: HARPAX
 failed. The error code was: 3221225578

e

Event Type: Failure Audit
Event Source:   Security
Event Category: Logon/Logoff 
Event ID:   529
Date:       3/19/2011
Time:       11:54:39 PM
User:       NT AUTHORITY\SYSTEM
Computer:   STALWART
Description:
Logon Failure:
    Reason:     Unknown user name or bad password
    User Name:  Administrator
    Domain:     stalwart
    Logon Type: 3
    Logon Process:  NtLmSsp 
    Authentication Package: NTLM
    Workstation Name:   HARPAX 

Pesquisando o código de erro ( 3221225578 ), recebo um artigo sobre o Technet :

Audit Account Logon Events By Randy Franklin Smith

...

Table 1 - Error Codes for Event ID 681

Error Code  Reason for Logon Failure
3221225578  The username is correct, but the password is wrong.

O que parece indicar que o nome de usuário está correto, mas a senha está errada.

Eu tentei a senha muitas vezes, em maiúsculas, minúsculas, em diferentes contas de usuário, com e sem prefixar o nome de usuário com servername\username .

O que dá que eu não posso acessar o servidor através de compartilhamento de arquivos, mas eu pode acessá-lo através de RDP?

Editar:eutenteiinserircredenciaisaleatórias(porexemplo,nomedeusuário:ramdom),apenasparatercertezadequeestoutentandoconectar-meaoservidorcorreto.Ologdeeventosnoservidormostraatentativacomfalha:

EventType:FailureAuditEventSource:SecurityEventCategory:Logon/LogoffEventID:529Date:3/20/2011Time:8:40:28AMUser:NTAUTHORITY\SYSTEMComputer:STALWARTDescription:LogonFailure:Reason:UnknownusernameorbadpasswordUserName:randomDomain:HARPAXLogonType:3LogonProcess:NtLmSspAuthenticationPackage:NTLMWorkstationName:HARPAX

Editar:Tentandotodasaspossíveis Níveis de autenticação do LAN Manager ( secpol.msc - > Configurações de segurança - > Políticas locais - > Opções de segurança - > Níveis de autenticação do LAN Manager):

• Enviar LM & Respostas NTLM: Falha
• Enviar LM & NTLM - use segurança da sessão NTLMv2 se negociado: Falha
• Enviar somente resposta NTLM ( padrão ): Falha
• Enviar somente resposta NTLMv2: falha
• Enviar somente resposta NTLMv2 \ recusar LM: falha
• Enviar somente resposta NTMLv2 \ recusar LM & NTLM: falha

(Cliente: Windows 7. Servidor: Windows 2000 Server)

    

Answer 1

eu descobri o problema, tinha a ver com as configurações do relógio em ambas as máquinas:

• Client: 3/20/2011 1:28:17 ᴘᴍ
• Server: 3/20/2011 1:28:17 ᴘᴍ

Para o olho destreinado, parece que os dois relógios lêem o mesmo. Há uma limitação do protocolo de negiotação que requer que todos os relógios fiquem a 15 minutos um do outro. Esses relógios diferem em uma hora. Isso ocorre porque os sistemas operacionais envolvidos:

• Cliente: Windows 7
• Servidor: Windows 2000 Server

E como o Windows 2000 Server não é mais suportado, sua data de início de verão não é mais válida. Então os tempos em ambas as máquinas são realmente:

• Client: 3/20/2011 1:28:17 ᴘᴍ EDT
• Server: 3/20/2011 1:28:17 ᴘᴍ EST

Isso ocorre porque o cliente mudou (corretamente) para Horário de verão , enquanto o servidor ainda está no Horário padrão . Isso significa que o relógio da máquina do cliente está uma hora à frente do relógio do servidor - e, portanto, os dois não podem autenticar.

Normalmente, quando os dois relógios estão mais de 15 minutos fora de sincronia, você recebe uma mensagem avisando sobre esse fato. Nesse caso, os relógios são sincronizados, portanto, não há aviso.

Resumo: 3221225578, Windows 2000, Horário de Verão

Enquanto isso, só para fazer as coisas funcionarem, eu restaurei o relógio para que o servidor ficasse uma hora atrás - e deixarei a transição "natural" do horário de verão se recuperar - e as transações começarão a acontecer na hora certa. novamente.

    

Answer 2

Pode haver várias causas para um código de falha de autenticação 3221225578 (0xC000006A). Uma é uma incompatibilidade com a configuração LMCompatibilityLevel. Se o servidor estiver configurado de forma mais restritiva que a estação de trabalho, esse é um dos sintomas.

Além disso, tenha cuidado ao testar isso. Se a sua estação de trabalho estiver configurada para um valor permissivo / baixo, é possível que aumentá-la para um valor alto pode causar uma tela azul na inicialização (se os dc também estiverem configurados como valor baixo / permissivo) e talvez seja necessário usar Última opção de menu inicial Good Known para recuperar.

A configuração de segurança mais incompreensível do Windows de todos os tempos
link