Você liga o computador, chega à tela de entrada do Windows 11 e digita sua senha.
Ou utiliza um PIN.
Talvez reconhecimento facial ou impressão digital.
Poucos segundos depois, a Área de Trabalho aparece.
Para o usuário, o processo parece extremamente simples:
identificação
↓
senha ou PIN
↓
Windows aberto
Por trás dessa tela existe uma arquitetura de segurança muito mais complexa.
Um dos componentes centrais dessa arquitetura é:
lsass.exe
O nome vem de:
Local Security Authority Subsystem Service.
O LSASS participa de funções fundamentais relacionadas à segurança e autenticação do Windows.
Mas existe uma simplificação que precisamos evitar desde o começo:
lsass.exe não é simplesmente “o programa que guarda sua senha”.
Essa descrição não explica corretamente como a autenticação moderna do Windows funciona.
Também cria confusão quando entramos em assuntos como:
- PIN;
- Windows Hello;
- conta Microsoft;
- conta local;
- domínio;
- SID;
- token de acesso;
- políticas de segurança;
- credenciais;
- bloqueio e desbloqueio da sessão.
Neste artigo vamos entender o que realmente acontece quando o Windows precisa descobrir:
“Quem é esse usuário e o que ele poderá fazer depois de entrar?”
Primeiro: o que é lsass.exe?
lsass.exe é um processo crítico de segurança do Windows.
Ele participa da implementação da política de segurança local e de mecanismos relacionados à autenticação.
Em uma instalação legítima do Windows, encontramos o executável do sistema associado a:
C:\Windows\System32\lsass.exe
O processo aparece normalmente no Gerenciador de Tarefas.
Não finalize lsass.exe para testar
Essa recomendação é importante.
LSASS não é comparável a fechar um editor de texto ou navegador.
Ele participa de funções críticas do sistema.
Portanto:
não tente encerrar, suspender, renomear ou apagar lsass.exe.
Por que ele é tão importante?
Porque autenticação não termina quando o Windows descobre que uma senha está correta.
Depois da autenticação, o sistema ainda precisa estabelecer a identidade e o contexto de segurança daquele usuário.
Imagine a entrada no Windows como uma sequência
De forma extremamente simplificada:
Usuário
↓
método de entrada
↓
autenticação
↓
identidade
↓
token de acesso
↓
sessão
↓
programas
Essa cadeia ajuda a entender por que simplesmente dizer:
“LSASS verifica a senha”
é insuficiente.
Autenticação e autorização são coisas diferentes
Esse é um dos conceitos mais importantes deste artigo.
Autenticação
Responde:
Quem é você?
Autorização
Responde:
O que você pode fazer?
Exemplo simples
Você consegue entrar no Windows.
Isso demonstra que algum mecanismo de autenticação aceitou sua identidade.
Mas isso não significa que poderá abrir qualquer arquivo.
Por quê?
Porque depois entram em cena:
- usuário;
- grupos;
- privilégios;
- SID;
- ACL;
- token de acesso.
LSASS está dentro desse ecossistema
Por isso o processo é muito mais interessante do que parece quando olhamos apenas o Gerenciador de Tarefas.
Antes do lsass.exe: a tela de entrada
Quando vemos a tela de login, existe uma experiência gráfica apresentando opções como:
- senha;
- PIN;
- reconhecimento facial;
- impressão digital;
- outras opções configuradas.
A tela não é o LSASS
Essa distinção é fundamental.
A interface onde você digita a informação não significa que lsass.exe seja responsável por desenhar aquela tela.
O Windows separa responsabilidades.
Novamente encontramos a arquitetura em camadas
Interface
↓
credencial
↓
autenticação
↓
segurança
↓
sessão
O que são Credential Providers?
O Windows utiliza uma arquitetura conhecida como:
Credential Providers.
Esses componentes participam da experiência de obtenção e apresentação das opções de credenciais.
Isso ajuda a entender por que existem várias opções de entrada
Por exemplo:
- senha;
- PIN;
- biometria;
- outros métodos suportados.
A interface pode apresentar diferentes formas de autenticação sem transformar todas elas na mesma tecnologia.
PIN e senha são a mesma coisa?
Não.
Essa é uma das confusões mais comuns do Windows 11.
A senha de uma conta
Dependendo do tipo de conta, a senha pode estar relacionada à credencial daquela identidade.
O PIN do Windows Hello
O PIN faz parte do modelo do Windows Hello.
Ele não deve ser interpretado simplesmente como:
“uma senha menor armazenada no computador”.
Por que essa diferença importa?
Porque o Windows Hello foi desenvolvido dentro de um modelo moderno de autenticação que pode utilizar material criptográfico protegido pelo dispositivo.
TPM entra nessa história
TPM significa:
Trusted Platform Module.
Em computadores compatíveis, ele pode proteger material criptográfico utilizado por recursos de segurança.
Portanto o PIN possui uma característica importante
Ele está relacionado ao dispositivo.
Isso é diferente da ideia de uma senha de conta que pode ser utilizada em outros contextos.
Exemplo conceitual
Imagine uma conta Microsoft.
A senha dessa conta pode ter utilidade em diferentes serviços associados à identidade.
O PIN configurado naquele computador está ligado ao mecanismo de entrada daquele dispositivo.
Isso explica uma situação comum
Usuário altera a senha da conta Microsoft e pergunta:
“Por que meu PIN continua funcionando?”
Porque PIN e senha não são simplesmente duas cópias da mesma credencial.
Windows Hello
O Windows Hello pode oferecer métodos como:
- PIN;
- reconhecimento facial;
- impressão digital.
A disponibilidade depende do equipamento e da configuração.
Biometria não significa que o Windows simplesmente “envia seu rosto como senha”
A arquitetura utiliza mecanismos próprios para validar a autenticação.
Onde lsass.exe entra?
LSASS participa da infraestrutura de segurança e autenticação, mas não devemos desenhar uma regra simplista:
PIN → lsass.exe → senha correta
A arquitetura real possui vários componentes.
O objetivo deste artigo é justamente evitar essas simplificações
Vamos estudar cada camada.
Conta local
Uma conta local pertence ao próprio computador.
Ela possui uma identidade reconhecida pelo Windows naquele sistema.
Conta Microsoft
Uma conta Microsoft envolve uma identidade online integrada ao Windows.
Isso muda vários aspectos da experiência de autenticação e serviços.
Conta de domínio
Em ambientes corporativos, um computador pode participar de um domínio Active Directory.
Nesse caso entram outros conceitos, como:
- domínio;
- controlador de domínio;
- Kerberos;
- políticas;
- credenciais de domínio.
Microsoft Entra ID
Ambientes modernos também podem utilizar identidades organizacionais associadas ao Microsoft Entra ID.
Portanto:
“login do Windows” não representa um único cenário universal.
LSASS e conta local
Para contas locais, um componente importante historicamente relacionado às informações de contas locais é o:
SAM
SAM significa:
Security Account Manager.
O que é SAM?
É parte da infraestrutura utilizada pelo Windows para gerenciar informações relacionadas a contas locais.
Isso significa que existe um arquivo com todas as senhas em texto?
Não.
Essa é uma interpretação incorreta.
Sistemas modernos não devem depender de armazenar simplesmente:
usuario = Victor
senha = minhasenha123
em texto aberto.
Senha e representação criptográfica
Mecanismos de autenticação utilizam representações e protocolos apropriados em vez de simplesmente manter a senha como texto legível.
Não precisamos manipular essas estruturas para diagnosticar um computador comum.
LSASS e SID
Depois que uma identidade é reconhecida, entra outro conceito que já estudamos em outro artigo:
SID — Security Identifier.
O Windows não depende apenas do nome visível
Imagine:
João
O nome é conveniente para humanos.
Mas o Windows utiliza identificadores de segurança para representar identidades.
Por isso dois usuários chamados João não são necessariamente o mesmo usuário
Podem possuir SIDs diferentes.
Exemplo conceitual
João antigo
↓
SID A
Depois a conta é removida.
Uma nova conta também recebe o nome:
João
Mas possui:
SID B
Para o Windows:
SID A ≠ SID B
Isso afeta permissões
Um arquivo pode possuir uma ACL apontando para o SID antigo.
A nova conta com o mesmo nome não herda automaticamente aquela identidade.
E aqui entramos em autorização
Depois da autenticação, o Windows precisa criar um contexto de segurança.
Um elemento fundamental é o:
Access Token.
O que é um Access Token?
Podemos pensar nele como uma estrutura que representa informações de segurança associadas ao contexto de execução.
Ele pode incluir informações relacionadas a:
- SID do usuário;
- grupos;
- privilégios;
- nível de integridade;
- outras características de segurança.
O token acompanha processos
Quando um usuário inicia uma sessão e programas são executados, esses processos operam dentro de determinado contexto de segurança.
Conceitualmente
Usuário autenticado
↓
Access Token
↓
explorer.exe
↓
programas iniciados pelo usuário
Isso explica por que programas sabem o que você pode acessar
Quando um processo tenta abrir:
C:\Dados\relatorio.xlsx
o Windows pode comparar o contexto de segurança do processo com as regras de acesso do objeto.
ACL entra na comparação
ACL significa:
Access Control List.
Ela contém regras de controle de acesso.
ACE
Dentro de uma ACL existem entradas chamadas:
Access Control Entries.
Portanto podemos imaginar
Processo
↓
Access Token
↓
SID + grupos + privilégios
↓
ACL do arquivo
↓
permitir ou negar
Essa é uma simplificação didática, mas mostra por que login e acesso a arquivos fazem parte de uma cadeia.
“Sou administrador, então posso tudo”
Não exatamente.
Outro componente entra aqui:
UAC — User Account Control.
Administrador não significa que todo programa execute elevado
Uma conta pertencente ao grupo Administradores pode operar normalmente com um contexto não elevado.
Quando uma tarefa exige elevação, o UAC pode entrar em cena.
Isso explica o famoso
Executar como administrador
O programa pode receber um contexto elevado
Mas isso não transforma todas as aplicações abertas pelo usuário em processos elevados.
LSASS e grupos
O usuário pode pertencer a vários grupos.
Por exemplo, dependendo do sistema:
- Users;
- Administrators;
- Remote Desktop Users;
- grupos específicos.
Esses grupos ajudam a determinar direitos e permissões.
Grupos também possuem SIDs
Portanto o token não precisa representar apenas:
usuário
Ele também pode representar identidades de grupos.
Isso explica permissões herdadas de grupo
Imagine uma pasta liberada para:
Grupo Financeiro
Se Maria pertence ao grupo, ela pode obter acesso por meio daquela associação.
A ACL não precisa mencionar Maria diretamente
Pode mencionar o SID do grupo.
LSASS e privilégios
Permissão de arquivo e privilégio não são exatamente a mesma coisa.
O Windows possui privilégios de segurança que permitem determinadas operações administrativas ou de sistema.
Por exemplo
Algumas tarefas administrativas dependem de direitos específicos atribuídos ao contexto de segurança.
Por isso “acesso negado” exige diagnóstico
A causa pode estar em:
- ACL;
- proprietário;
- token;
- grupo;
- privilégio;
- elevação;
- política.
Não é sempre “senha errada”
LSASS e políticas de segurança
O Windows também possui políticas locais relacionadas a segurança.
Abra:
secpol.msc
em edições que disponibilizam essa ferramenta.
Podemos encontrar configurações relacionadas a
- políticas de conta;
- direitos de usuário;
- auditoria;
- opções de segurança.
Em ambientes corporativos
Group Policy pode aplicar configurações centralizadas.
Isso muda o diagnóstico
Se uma configuração volta depois de você alterá-la localmente, talvez exista uma política organizacional reaplicando o valor.
LSASS e Kerberos
Em ambientes de domínio, Kerberos é um protocolo extremamente importante de autenticação.
Kerberos evita uma visão simplista
Não precisamos imaginar que:
“Toda vez que abro um recurso de rede, minha senha é enviada novamente.”
A arquitetura utiliza mecanismos de autenticação e tickets.
O que é um ticket?
Conceitualmente, é uma credencial utilizada dentro do protocolo para demonstrar autenticação/autorização em determinadas interações.
Não precisamos manipular tickets para entender o princípio
O ponto importante é:
autenticação de rede moderna não consiste simplesmente em transmitir senha repetidamente.
NTLM
Outro nome que aparece bastante no Windows é:
NTLM.
Ele é uma família de protocolos de autenticação historicamente utilizada no ecossistema Windows.
Kerberos e NTLM não são a mesma coisa
Em ambientes modernos, a escolha e utilização dependem do cenário.
Conta local versus domínio muda bastante essa arquitetura
Por isso um tutorial que diz:
“Windows sempre autentica assim”
pode estar errado.
LSASS e credenciais em rede
Imagine:
PC-A
tentando acessar:
\\PC-B\Compartilhamento
Agora temos uma autenticação relacionada a outro sistema.
Isso é diferente do login local
O Windows precisa determinar qual identidade será apresentada ao recurso remoto e como ela será autenticada.
Por isso existem situações como
- usuário entra normalmente no Windows;
- mas recebe solicitação de credenciais ao acessar outro computador.
Não existe contradição.
São contextos diferentes.
LSASS e “credenciais incorretas”
Uma mensagem de credencial incorreta também precisa ser interpretada no contexto.
Pergunte:
- conta local?
- conta Microsoft?
- domínio?
- recurso SMB?
- RDP?
- VPN?
- aplicativo?
A mesma palavra “senha” pode aparecer em vários sistemas diferentes
LSASS e bloqueio da sessão
Quando você pressiona:
Win + L
o computador bloqueia a sessão.
Bloquear não significa encerrar sessão
Seus programas podem continuar executando.
Isso é diferente de
Sair
Sair encerra a sessão do usuário
Aplicativos daquele contexto normalmente são fechados.
Bloquear mantém a sessão
A autenticação será necessária para recuperar o acesso interativo.
Isso explica por que arquivos permanecem abertos depois de Win + L
O usuário continua logado.
LSASS e troca de usuário
O Windows também pode manter múltiplas sessões de usuários.
Usuário A
pode continuar com programas abertos enquanto:
Usuário B
entra em outra sessão.
Isso cria múltiplos contextos de segurança
Cada usuário possui sua própria identidade e processos.
Como observar usuários logados?
O Gerenciador de Tarefas possui a seção:
Usuários
Ela ajuda a visualizar sessões ativas.
LSASS e Gerenciador de Tarefas
No Gerenciador de Tarefas você pode encontrar o processo associado à Autoridade de Segurança Local.
CPU alta no lsass.exe é normal?
Picos transitórios podem acontecer.
Mas consumo persistentemente alto merece investigação.
Não finalize o processo
Primeiro procure a causa.
Pergunte
- começou quando?
- ocorre no login?
- acontece ao acessar rede?
- existe domínio?
- houve atualização?
- algum software de segurança mudou?
- existe problema de autenticação?
LSASS pode ser o sintoma, não a causa inicial
Essa regra já apareceu em vários artigos desta série.
Um componente do Windows pode estar processando solicitações geradas por outro componente.
Portanto
lsass.exe com CPU alta
não significa automaticamente:
lsass.exe corrompido
E também não significa automaticamente malware
Precisamos investigar.
Como verificar legitimidade?
Observe:
- caminho;
- assinatura;
- contexto;
- comportamento.
O executável legítimo deve estar associado aos componentes protegidos do Windows.
Nome igual não prova identidade
Um arquivo chamado:
lsass.exe
em uma pasta estranha merece atenção.
Não abra o arquivo suspeito
Use ferramentas de segurança apropriadas para analisá-lo.
Process Explorer
Process Explorer pode ajudar a observar:
- PID;
- caminho;
- assinatura;
- propriedades do processo.
Mas LSASS é um processo sensível
Não tente manipular memória, handles ou outros elementos internos do processo.
O objetivo do diagnóstico é observar o sistema, não interferir em mecanismos de segurança.
Event Viewer
O Visualizador de Eventos é extremamente importante em problemas de autenticação.
Execute:
eventvwr.msc
Security Log
O log de Segurança pode registrar eventos relacionados a autenticação e auditoria, dependendo das políticas configuradas.
Não interprete um único evento isoladamente
Observe:
- horário;
- conta;
- tipo de evento;
- computador;
- contexto.
Falha de login não significa ataque automaticamente
Pode ser:
- senha antiga;
- serviço;
- tarefa agendada;
- unidade de rede;
- aplicativo;
- dispositivo;
- credencial armazenada.
Exemplo interessante
Usuário altera a senha.
Depois disso aparecem várias tentativas de autenticação malsucedidas.
Possível explicação
Algum componente ainda tenta usar uma credencial antiga.
Pode ser
- unidade de rede;
- tarefa;
- serviço;
- aplicativo corporativo.
Isso é muito diferente de concluir imediatamente
“Alguém está tentando invadir meu computador.”
Linha do tempo novamente ajuda
senha alterada
↓
falhas começaram
Essa correlação merece investigação.
Windows Hello e falha de PIN
Se o PIN não funciona, não conclua automaticamente que a senha da conta está errada.
Teste outra opção de entrada disponível
A tela de login permite selecionar:
Opções de entrada
quando mais de um método está configurado.
Se senha funciona e PIN não
O problema está mais próximo da infraestrutura do Windows Hello/PIN.
Se nenhum método funciona
O universo de hipóteses muda.
TPM também pode entrar no diagnóstico
Especialmente quando existem problemas relacionados ao Windows Hello e recursos criptográficos vinculados ao dispositivo.
Mas não limpe o TPM como primeira tentativa
Essa ação pode afetar recursos protegidos por chaves.
Antes de qualquer alteração desse tipo, é necessário compreender impactos em recursos como:
- BitLocker;
- Windows Hello;
- credenciais protegidas.
A regra é simples
Não destrua material criptográfico para diagnosticar um problema que ainda não foi identificado.
LSASS e BitLocker são a mesma coisa?
Não.
BitLocker protege volumes.
LSASS participa de outra camada da segurança.
LSASS e TPM são a mesma coisa?
Não.
TPM é um componente/mecanismo de segurança de hardware ou firmware, dependendo da implementação.
LSASS e Windows Hello são a mesma coisa?
Também não.
O Windows possui várias camadas de segurança
Isso é justamente o que torna o tema interessante.
Primeira sequência de diagnóstico
Se você suspeita de problema envolvendo autenticação:
1. Defina o problema
É login local, PIN, senha, SMB, RDP ou outro recurso?
2. Registre horário
Isso ajuda na correlação com logs.
3. Determine o tipo de conta
Local, Microsoft ou organizacional.
4. Determine o método de entrada
Senha, PIN ou biometria.
5. Teste outra opção de entrada disponível
Sem alterar configurações ainda.
6. Verifique se o problema ocorre somente em uma conta
7. Verifique se ocorre após reinicialização
8. Observe o Gerenciador de Tarefas
Sem finalizar LSASS.
9. Confirme caminho do executável se houver suspeita de falsificação
10. Consulte o Visualizador de Eventos
Correlacione pelo horário.
11. Verifique alterações recentes
Senha, PIN, atualização, política ou software.
12. Considere credenciais antigas
Especialmente em recursos de rede.
13. Não altere permissões aleatoriamente
14. Não limpe TPM sem entender o impacto
15. Não manipule lsass.exe
A principal ideia desta primeira parte
Quando o Windows aceita uma identidade, ele não precisa apenas responder:
“A senha está correta?”
Ele precisa estabelecer:
“Quem é esse usuário?”
Depois:
“A quais grupos ele pertence?”
Depois:
“Quais privilégios possui?”
Depois:
“Qual será o contexto de segurança dos processos executados?”
E, posteriormente:
“Esse contexto possui permissão para acessar este recurso?”
É por isso que LSASS ocupa uma posição tão importante na arquitetura do Windows.
Winlogon, Credential Providers, SAM, Kerberos, Access Token, Windows Hello e proteção do LSASS
Na Parte 1 vimos que lsass.exe não pode ser resumido como “o processo que verifica a senha”.
A autenticação do Windows envolve várias camadas.
Agora vamos acompanhar conceitualmente o caminho desde a tela de entrada até a criação de uma sessão de usuário.
Uma representação didática seria:
Tela de entrada
↓
Credential Provider
↓
Infraestrutura de autenticação
↓
LSA / LSASS
↓
Identidade autenticada
↓
SID + grupos + privilégios
↓
Access Token
↓
Sessão
↓
Processos do usuário
A implementação real possui mais componentes e varia conforme o tipo de conta e método de autenticação. Portanto, esse diagrama serve para entender responsabilidades, não como representação literal de todas as chamadas internas do Windows.
O que é winlogon.exe?
Outro processo importante é:
winlogon.exe
O nome vem de:
Windows Logon Application.
Ele participa de funções relacionadas à sessão interativa do Windows.
Assim como lsass.exe, é um componente crítico.
Winlogon e LSASS são a mesma coisa?
Não.
Essa distinção é fundamental.
Podemos pensar conceitualmente:
experiência/sessão de logon
↓
winlogon.exe
enquanto a infraestrutura de segurança e autenticação envolve:
lsass.exe
Essa é uma simplificação didática.
Não finalize winlogon.exe
Também não é um processo comum que devemos encerrar para testar desempenho.
Estamos falando de componentes críticos da sessão.
O que são Credential Providers?
Quando o Windows apresenta opções como:
- senha;
- PIN;
- reconhecimento facial;
- impressão digital;
existe uma arquitetura responsável por fornecer essas opções de credencial.
Esses componentes são chamados:
Credential Providers.
Um Credential Provider não é necessariamente o mecanismo final de autenticação
Ele participa da obtenção e apresentação da credencial.
Essa diferença é importante.
Pense em duas perguntas
Primeira:
Como o usuário fornecerá uma credencial?
Segunda:
Como essa identidade será validada?
São etapas relacionadas, mas não idênticas.
Isso explica as “Opções de entrada”
Na tela de login do Windows 11 podemos alternar entre métodos disponíveis.
Dependendo da configuração:
PIN
Senha
Biometria
podem aparecer como opções diferentes.
A interface precisa saber qual método apresentar
Os Credential Providers ajudam nessa experiência.
Aplicativos de terceiros podem participar?
Em ambientes corporativos, determinadas soluções de autenticação podem integrar componentes próprios ao processo de entrada.
Isso é mais um motivo para não imaginar o login como um único executável.
O que é LSA?
LSA significa:
Local Security Authority.
É um elemento central da arquitetura de segurança do Windows.
E LSASS?
lsass.exe hospeda funções relacionadas ao subsistema da Autoridade de Segurança Local.
É daí que vem:
Local Security Authority Subsystem Service.
Por que “Local” não significa apenas conta local?
Esse nome histórico não significa que LSASS só participe de autenticação de contas locais.
Ele também possui importância em ambientes de domínio e outros cenários de segurança.
O que é uma Logon Session?
Quando uma autenticação é concluída com sucesso, o Windows estabelece um contexto de logon.
Isso é diferente de “uma janela aberta”
Uma sessão de logon representa um contexto de segurança.
O mesmo computador pode ter vários contextos
Por exemplo:
- usuário interativo;
- serviços;
- tarefas;
- outros tipos de logon.
Nem todo logon significa alguém sentado diante do computador
Esse conceito é muito importante ao interpretar logs.
Uma autenticação pode ocorrer por diferentes motivos
Exemplos:
- entrada interativa;
- acesso pela rede;
- serviço;
- tarefa agendada;
- acesso remoto.
Por isso eventos de logon precisam ser interpretados pelo tipo
Encontrar um evento de autenticação não significa automaticamente que alguém digitou uma senha no teclado.
O que acontece depois da autenticação?
O Windows precisa representar a identidade daquele contexto.
Entram informações como:
- SID;
- grupos;
- privilégios;
- restrições;
- características de segurança.
Access Token
O Access Token é fundamental nessa etapa.
Imagine o token como um “contexto de identidade”
Não como um arquivo físico que o usuário carrega.
Ele representa informações que o sistema utiliza para determinar o contexto de segurança de um processo ou thread.
Conceitualmente
Maria autenticada
↓
SID da Maria
SIDs dos grupos
privilégios
outras informações
↓
Access Token
Depois Maria inicia explorer.exe
O processo é executado dentro daquele contexto.
Em seguida abre o Word
O novo processo também recebe um contexto de segurança apropriado.
E tenta abrir um arquivo
Agora o sistema consegue perguntar:
O contexto desse processo possui acesso ao objeto?
A senha não precisa ser verificada novamente para cada arquivo
Isso é fundamental.
O Windows não precisa pedir:
“Digite sua senha novamente para abrir foto.jpg.”
O processo já possui um contexto de segurança.
É aqui que autenticação encontra autorização
Autenticação
↓
Identidade
↓
Token
↓
ACL
↓
Acesso
O que existe dentro do token?
Sem entrar em estruturas internas desnecessárias, podemos encontrar conceitos relacionados a:
- usuário;
- grupos;
- privilégios;
- nível de integridade;
- restrições.
Grupos são extremamente importantes
Imagine:
Carlos
pertence a:
Users
e:
Administrators
Essas associações participam do contexto de segurança.
Mas estar em Administrators não significa execução elevada constante
Aqui entra novamente o UAC.
UAC e token
Com User Account Control, uma conta administrativa normalmente não significa que todo aplicativo iniciado receba automaticamente poder administrativo completo.
Isso ajuda a reduzir risco
Aplicações comuns podem operar sem elevação.
Quando uma tarefa exige direitos adicionais, o Windows pode solicitar elevação.
“Executar como administrador”
Essa opção altera o contexto de execução do programa.
Portanto dois processos do mesmo programa podem ter contextos diferentes
Exemplo:
cmd.exe
normal
versus:
cmd.exe
elevado.
Mesmo EXE, contexto diferente
Essa é uma ideia importante.
Como visualizar privilégios e contexto?
Process Explorer pode mostrar várias informações relacionadas ao token e à integridade dos processos.
Mas não precisamos modificar nada para diagnosticar.
Integrity Level
O Windows utiliza mecanismos de integridade como parte de sua arquitetura de segurança.
Podemos encontrar níveis como:
- Low;
- Medium;
- High;
- System;
dependendo do processo e do contexto.
Um aplicativo comum geralmente não precisa executar em High
Executar como administrador pode mudar isso
O processo elevado normalmente opera com contexto mais privilegiado.
Integrity Level não é a mesma coisa que usuário
Duas aplicações iniciadas pelo mesmo usuário podem operar com níveis de integridade diferentes.
Isso explica alguns “Acesso negado”
Imagine:
Programa A
e:
Programa B
pertencem ao mesmo usuário.
Mas um está elevado e o outro não.
O comportamento pode ser diferente.
Isso não significa que o SID mudou
A diferença pode estar no token e no nível de execução.
O que é SAM?
Voltando às contas locais, temos:
Security Account Manager.
O SAM participa da infraestrutura das contas locais.
SAM não deve ser tratado como arquivo para edição manual
Não tente manipular seus dados diretamente para “recuperar” login.
O Windows possui mecanismos suportados para gerenciamento de contas.
Onde ficam as informações de conta local?
Existem estruturas protegidas pelo sistema.
O importante para diagnóstico é entender o papel, não tentar extrair ou alterar credenciais.
Conta local: visão simplificada
Usuário fornece credencial
↓
Windows valida a identidade local
↓
LSA/LSASS participa
↓
identidade reconhecida
↓
token
↓
sessão
Agora muda o cenário: Active Directory
Em um domínio, a autenticação pode envolver um:
Domain Controller.
O computador não trabalha isoladamente
Temos:
PC
↓
rede
↓
controlador de domínio
Kerberos
Em ambientes Active Directory, Kerberos possui papel central na autenticação.
O que torna Kerberos interessante?
Depois da autenticação, o protocolo pode utilizar tickets para permitir acesso autenticado a serviços.
Conceitualmente
Usuário autenticado
↓
ticket
↓
serviço
Isso evita imaginar a senha sendo transmitida repetidamente para cada recurso.
O que é KDC?
KDC significa:
Key Distribution Center.
No contexto de Active Directory, ele participa da infraestrutura Kerberos.
Tickets Kerberos
Dois nomes importantes aparecem:
- TGT;
- Service Ticket.
O que é TGT?
TGT significa:
Ticket Granting Ticket.
Ele participa do processo de obtenção de outros tickets no protocolo.
Service Ticket
É utilizado para acesso autenticado a determinado serviço.
Exemplo conceitual
Usuário:
Maria
precisa acessar:
Servidor de Arquivos
A arquitetura pode utilizar Kerberos para obter credenciais apropriadas para aquele serviço.
Não precisamos reenviar a senha manualmente
Essa é uma das vantagens conceituais importantes do sistema.
LSASS participa dessa infraestrutura?
Sim, LSASS possui papel central nos mecanismos de autenticação do Windows.
E NTLM?
NTLM é outra família de mecanismos de autenticação do Windows.
Kerberos e NTLM não são intercambiáveis em qualquer cenário
A escolha depende de fatores como:
- ambiente;
- tipo de conta;
- recurso;
- configuração;
- disponibilidade.
Por que isso importa em diagnóstico?
Porque podemos ter:
“Funciona por IP, mas não pelo nome.”
ou:
“Funciona em um computador e pede senha em outro.”
ou:
“Kerberos não foi usado e ocorreu fallback.”
Esses problemas exigem investigar identidade, DNS, nomes de serviço e configuração, não simplesmente redefinir a senha.
DNS pode influenciar autenticação?
Em ambientes de domínio, DNS possui enorme importância.
Isso surpreende muitos técnicos
Usuário diz:
“Minha senha está correta, então por que o login de rede falha?”
Talvez o problema não seja a senha.
Pode existir problema de:
- DNS;
- comunicação;
- horário;
- domínio;
- serviço.
Horário também importa
Protocolos de autenticação modernos podem depender de sincronização temporal adequada.
Relógio muito incorreto pode causar problemas
Isso mostra novamente como um erro aparentemente de “senha” pode ter outra origem.
Conta Microsoft
Agora temos outro cenário.
Uma conta Microsoft combina identidade online com integração ao dispositivo Windows.
Isso não significa que o computador precise consultar a internet para cada operação local
O Windows possui mecanismos para permitir a experiência de entrada adequada conforme a configuração.
PIN continua diferente da senha da conta
Isso merece repetição porque é uma dúvida frequente.
PIN do Windows Hello
O PIN está ligado ao dispositivo e ao modelo do Windows Hello.
Senha da conta Microsoft
Está associada à identidade da conta.
Portanto
PIN ≠ senha curta
Windows Hello e criptografia assimétrica
Um dos conceitos centrais do Windows Hello moderno é utilizar autenticação baseada em chaves em vez de tratar o PIN como uma senha convencional enviada a serviços.
Conceitualmente
PIN/biometria
↓
autoriza uso local de uma chave
↓
operação criptográfica
O PIN não precisa viajar pela internet como a senha
Essa diferença é importante para compreender o modelo.
TPM pode proteger a chave
Quando disponível e configurado, o TPM pode proteger material criptográfico.
Isso dificulta determinados tipos de abuso
Porque o segredo protegido não precisa existir como uma senha convencional reutilizável.
Mas o PIN pode ser fraco?
O Windows aplica políticas e mecanismos de proteção.
Em ambientes corporativos, administradores também podem impor requisitos.
PIN está preso ao computador
Essa característica reduz a utilidade de um PIN obtido isoladamente fora daquele dispositivo.
Biometria e Windows Hello
Reconhecimento facial ou impressão digital podem participar do processo de desbloqueio do material protegido.
A biometria não substitui toda a arquitetura de segurança
Ela funciona como parte de um sistema maior.
O que acontece se o TPM apresentar problema?
Podemos encontrar sintomas relacionados a:
- PIN;
- Windows Hello;
- chaves;
- recursos protegidos.
Mas novamente
não limpe TPM automaticamente.
Por quê?
Porque o TPM pode proteger chaves utilizadas por outros recursos.
BitLocker é um exemplo importante
Uma alteração inadequada pode resultar na necessidade da chave de recuperação do BitLocker.
Diagnóstico antes da ação
Sempre.
Microsoft Entra ID
Em organizações modernas, o Windows também pode estar associado a identidades do Microsoft Entra ID.
Isso cria outro cenário de autenticação
Não devemos assumir:
empresa = Active Directory local
Ambientes podem ser:
- AD tradicional;
- Entra ID;
- híbridos.
LSASS e Security Packages
A arquitetura da LSA suporta mecanismos de autenticação e pacotes de segurança.
Isso permite ao Windows trabalhar com diferentes protocolos
O ponto importante para o usuário é:
LSASS não possui uma única função “comparar senha”.
Ele está no centro de uma infraestrutura extensível de segurança.
Por que LSASS precisa de tanta proteção?
Porque um processo envolvido em autenticação e segurança é naturalmente um alvo sensível.
Windows moderno adicionou proteções
Entre os conceitos importantes encontramos:
- LSA protection;
- Credential Guard;
- Virtualization-Based Security;
- isolamento de determinados segredos.
O que é LSA Protection?
O Windows pode utilizar mecanismos adicionais para proteger LSASS contra determinadas formas de acesso não autorizado.
Um termo que pode aparecer é RunAsPPL
PPL significa:
Protected Process Light.
O objetivo
Aumentar a proteção de processos sensíveis contra interferência de processos não autorizados.
Isso não significa que LSASS fica “impossível de atacar”
Segurança não funciona em absolutos.
Mas aumenta as barreiras.
Credential Guard
Credential Guard utiliza recursos de segurança baseados em virtualização para ajudar a proteger determinados segredos de autenticação.
VBS
VBS significa:
Virtualization-Based Security.
A ideia é criar isolamento adicional
Em vez de manter todos os elementos sensíveis acessíveis no mesmo contexto tradicional do sistema operacional, determinadas informações podem receber proteção adicional.
Isso mostra a evolução do Windows
Historicamente:
Sistema operacional
↓
segredos
Com recursos modernos:
Windows
↓
isolamento baseado em virtualização
↓
segredos protegidos
Essa é uma simplificação conceitual.
Credential Guard é antivírus?
Não.
Credential Guard substitui Defender?
Não.
Credential Guard substitui TPM?
Também não.
São tecnologias com funções diferentes.
Windows Security funciona em camadas
Podemos encontrar:
Secure Boot
TPM
VBS
Credential Guard
LSA Protection
Microsoft Defender
UAC
ACL
BitLocker
Cada tecnologia atua em áreas diferentes.
Mais segurança pode afetar compatibilidade?
Em determinados ambientes, tecnologias antigas ou integrações específicas podem exigir avaliação.
Não desative proteções apenas porque um tutorial antigo recomenda
Esse é um erro perigoso.
Primeiro descubra a incompatibilidade real
LSASS usando CPU alta
Agora podemos compreender melhor por que esse sintoma é complexo.
Se LSASS participa de autenticação e segurança, CPU alta pode estar associada a uma quantidade elevada de operações relacionadas.
A pergunta correta é
Quem está gerando essas operações?
Exemplos de áreas para investigar
- autenticações repetidas;
- recursos de rede;
- ambiente de domínio;
- software de segurança;
- políticas;
- serviços;
- mudanças recentes.
Não finalize LSASS
O diagnóstico deve ocorrer ao redor do processo.
Caso: CPU alta começa depois de trocar senha
Essa correlação é interessante.
Talvez algum componente continue tentando autenticar com a credencial anterior.
Onde procurar?
Dependendo do cenário:
- tarefas;
- serviços;
- unidades de rede;
- aplicativos;
- recursos corporativos.
Caso: usuário consegue entrar, mas compartilhamento pede senha
Isso não prova problema no login local.
Temos dois contextos
Login local
e:
Autenticação de rede
Caso: PIN não funciona, senha funciona
Isso aponta para uma investigação mais próxima do Windows Hello.
Caso: senha não funciona, PIN funciona
Pode existir diferença entre a credencial da conta e o método local de entrada.
Caso: tudo funciona offline, mas falha em recursos corporativos
Agora investigue:
- rede;
- DNS;
- domínio;
- sincronização;
- autenticação corporativa.
Caso: funciona pelo nome, falha pelo IP
Ou o inverso.
Isso pode fornecer pistas sobre o método de autenticação e resolução de nomes.
Caso: computador de domínio com horário errado
Corrija a causa do horário antes de concluir que existe corrupção de credenciais.
LSASS e Event Viewer
Os logs tornam-se fundamentais nesses cenários.
Security Log
Dependendo da auditoria configurada, podemos encontrar registros relacionados a:
- logon;
- falha de logon;
- criação de sessões;
- uso de credenciais.
Mas volume pode ser enorme
Filtre pelo:
- horário;
- usuário;
- computador;
- evento.
Não leia milhares de eventos aleatoriamente
Comece pelo instante do problema.
Exemplo
Usuário relata:
“Às 14:17 o compartilhamento parou de aceitar minha senha.”
Investigue:
14:15 – 14:20
antes de analisar dias inteiros.
Security Log exige interpretação
Um evento de falha pode conter informações que ajudam a entender:
- conta;
- origem;
- tipo de logon;
- status.
Mas não exponha dados sensíveis desnecessariamente
Ao enviar logs para terceiros, revise:
- nomes de usuário;
- domínio;
- endereços;
- informações internas.
Process Explorer e LSASS
Process Explorer pode ajudar a confirmar:
- processo;
- PID;
- caminho;
- assinatura.
Não utilize ferramentas para extrair credenciais ou memória do LSASS
Isso não é necessário para manutenção normal e reduz a segurança do sistema.
O objetivo é diagnosticar, não contornar proteções
Primeiro grande mapa da autenticação
Agora conseguimos construir um modelo mais completo:
Usuário
↓
Credential Provider
↓
Senha / Hello / outro método
↓
Infraestrutura de autenticação
↓
LSA / LSASS
↓
Conta local / Microsoft / AD / Entra
↓
Identidade autenticada
↓
SID + grupos + privilégios
↓
Access Token
↓
Sessão
↓
Processos
↓
ACL / políticas
↓
Acesso aos recursos
E quando existe recurso remoto?
Acrescentamos:
Processo
↓
recurso de rede
↓
Kerberos / outro mecanismo apropriado
↓
servidor
↓
autorização
Isso explica por que uma simples mensagem “senha incorreta” pode exigir diagnóstico profundo
A falha pode acontecer em diferentes pontos da cadeia.
Casos práticos: CPU alta no lsass.exe, PIN que falha, senha antiga, SMB, domínio e autenticação de rede
Agora vamos transformar a arquitetura das Partes 1 e 2 em diagnóstico prático.
O objetivo é entender uma regra essencial:
quando existe problema de autenticação, o LSASS pode aparecer no centro do sintoma sem ser necessariamente a origem do problema.
Por isso, antes de qualquer tentativa de reparo, precisamos descobrir:
- qual tipo de autenticação falhou;
- em qual momento;
- para qual usuário;
- em qual recurso;
- depois de qual alteração.
Caso 1 — lsass.exe usa muita CPU por alguns segundos durante o login
Um pequeno pico de CPU durante entrada, desbloqueio ou autenticação pode acontecer.
Isso, isoladamente, não significa problema.
Pergunte:
- quanto de CPU?
- por quanto tempo?
- ocorre apenas no login?
- cai depois?
- existe lentidão perceptível?
Pico transitório é diferente de uso constante
Compare:
30% por 2 segundos
com:
30% durante 40 minutos
São situações completamente diferentes.
Caso 2 — lsass.exe permanece com CPU alta
Agora precisamos investigar.
Não finalize o processo.
Procure primeiro o padrão.
Perguntas importantes
- começou depois de qual alteração?
- acontece conectado à rede?
- acontece offline?
- ocorre depois de trocar senha?
- o PC pertence a domínio?
- existe acesso frequente a servidor?
- algum serviço foi alterado?
- algum software de segurança foi instalado?
Caso 3 — CPU alta somente quando o computador entra na rede da empresa
Essa é uma pista importante.
Pode existir relação com:
- autenticações;
- domínio;
- políticas;
- recursos compartilhados;
- serviços corporativos.
Teste comparativo
Observe o comportamento:
sem rede corporativa
versus:
com rede corporativa
Se o padrão muda claramente, a rede e os serviços autenticados entram na investigação.
Caso 4 — CPU alta começa depois de alterar a senha
Esse cenário merece atenção.
Usuário muda a senha.
Pouco depois:
- aparecem solicitações repetidas;
- recursos de rede falham;
- LSASS trabalha mais;
- alguns programas pedem login novamente.
Uma hipótese comum
Algum componente ainda tenta usar a credencial antiga.
Onde procurar?
Dependendo do ambiente:
- unidades de rede;
- serviços;
- tarefas agendadas;
- aplicativos corporativos;
- conexões remotas.
Não conclua que a senha nova está errada
Se o login funciona normalmente, talvez apenas algum componente ainda esteja usando a credencial anterior.
Caso 5 — Windows aceita o PIN, mas a senha não funciona
PIN e senha são credenciais diferentes.
Isso pode acontecer em alguns cenários.
O PIN pode continuar funcionando
Mesmo que exista problema com a senha da conta.
Pergunte
A senha falha onde?
- na tela de entrada?
- em um site?
- no compartilhamento?
- em RDP?
- em conta Microsoft?
Contexto muda tudo
Caso 6 — a senha funciona, mas o PIN não
Agora a investigação muda de direção.
Pode existir problema relacionado a:
- Windows Hello;
- TPM;
- configuração local;
- credenciais do dispositivo.
Não limpe o TPM imediatamente
Essa ação pode afetar recursos protegidos.
Primeiro confirme:
- se a senha funciona;
- se outro método funciona;
- se houve atualização;
- se o problema começou após alteração no firmware ou TPM.
Caso 7 — reconhecimento facial falha, mas PIN funciona
Nesse caso, o problema pode estar mais próximo do componente biométrico.
Investigue:
- câmera compatível;
- driver;
- Windows Hello Face;
- configurações;
- atualização recente.
Caso 8 — impressão digital falha, PIN funciona
Mesma lógica.
O problema pode estar mais próximo do leitor biométrico e seu driver.
Caso 9 — Windows aceita login, mas compartilhamento SMB pede senha
Esse é um dos casos mais comuns em redes pequenas.
Não existe contradição
O login local e a autenticação em outro computador são contextos diferentes.
Exemplo
Você entra no:
PC-A
com:
Victor
Depois tenta acessar:
\\PC-B\Documentos
O PC-B precisa decidir qual identidade aceitar.
Mesmo nome não garante mesma conta
Pode existir:
Victor no PC-A
e:
Victor no PC-B
São identidades diferentes.
SID também será diferente
Mesmo que nome e senha sejam iguais.
Isso explica muitas confusões em rede doméstica
Caso 10 — compartilhamento funcionava e passou a pedir senha
Pergunte:
- houve troca de senha?
- o computador foi recriado?
- uma conta foi apagada e criada novamente?
- mudou de local para Microsoft?
- credenciais antigas ficaram salvas?
Uma conta recriada não é necessariamente a mesma identidade
Mesmo nome não significa mesmo SID.
Caso 11 — credencial de rede antiga continua sendo usada
O Windows pode manter informações de credenciais usadas em determinados recursos.
Quando a senha muda, algum acesso pode continuar tentando a combinação antiga.
O sintoma
- compartilhamento pede senha;
- reconecta e falha;
- aplicativo insiste em credencial inválida.
O diagnóstico correto
Descobrir qual recurso está tentando autenticar e com qual conta esperada.
Caso 12 — usuário consegue abrir pasta local, mas não a mesma pasta pela rede
Autorização local e autorização remota podem envolver camadas diferentes.
Em SMB podem existir
- permissões de compartilhamento;
- permissões NTFS;
- autenticação;
- identidade apresentada ao servidor.
Portanto
NTFS correto
não garante automaticamente:
SMB correto
Caso 13 — usuário é administrador, mas recebe acesso negado
Ser administrador não elimina automaticamente todas as verificações.
Entram:
- UAC;
- token;
- ACL;
- proprietário;
- privilégios.
“Administrador” não significa “ignorar segurança”
Caso 14 — Executar como administrador funciona
Isso fornece uma pista.
Talvez o programa precise de um contexto elevado para determinada operação.
Mas não transforme isso em solução universal
Se um programa comum só funciona como administrador, vale investigar por quê.
Caso 15 — programa funciona em um usuário e falha em outro
Isso aponta para algo específico do perfil.
Possibilidades:
- configuração;
- dados por usuário;
- permissões;
- credenciais;
- associação de conta.
Teste A/B
Usuário A → falha
Usuário B → funciona
Isso reduz bastante o universo de hipóteses.
Caso 16 — todos os usuários falham
Agora pense em componentes compartilhados.
Por exemplo:
- sistema;
- política;
- rede;
- serviço;
- domínio.
Caso 17 — computador de domínio aceita login, mas recursos corporativos falham
Talvez o problema não esteja no login inicial.
Investigue
- DNS;
- conectividade;
- domínio;
- horário;
- tickets;
- políticas.
Caso 18 — relógio do computador está errado
Em ambientes de domínio, horário incorreto pode atrapalhar autenticação.
Por quê?
Protocolos como Kerberos dependem de controles temporais.
Portanto uma “senha certa que não funciona” pode ter causa no relógio
Isso é excelente exemplo de diagnóstico por camadas.
Caso 19 — DNS está errado
Em Active Directory, DNS é fundamental.
Se o computador usa DNS incorreto
Pode não localizar corretamente serviços do domínio.
Resultado aparente
Usuário pensa:
“A senha não funciona.”
Mas a identidade talvez nem esteja conseguindo chegar ao serviço correto.
Caso 20 — funciona offline, falha na rede
Isso também é pista importante.
Se o computador permite entrada local, mas recursos de rede falham, investigue a camada de rede/autenticação remota.
Caso 21 — acesso funciona pelo nome, mas falha pelo IP
Esse comportamento pode mudar a forma como determinado mecanismo de autenticação é utilizado.
Não trate nome e IP como exatamente equivalentes em ambientes autenticados
Caso 22 — RDP pede credencial diferente
Remote Desktop cria outro cenário.
Pergunte
- conta local?
- conta de domínio?
- conta Microsoft?
- qual computador está autenticando?
O nome da conta importa
Em alguns casos, o formato utilizado para indicar a identidade pode mudar.
Caso 23 — RDP conecta, mas usuário local não consegue
Isso pode envolver:
- política;
- direito de logon;
- grupo;
- configuração de acesso remoto.
Autenticação correta não garante direito de usar RDP
Essa é a diferença entre:
autenticação
e:
autorização
Caso 24 — conta foi adicionada ao grupo, mas acesso não mudou imediatamente
O token existente pode ter sido criado antes da mudança.
Em alguns cenários, uma nova sessão pode ser necessária
Porque o contexto de segurança foi estabelecido anteriormente.
Isso ajuda a entender por que sair e entrar pode mudar comportamento
Caso 25 — bloquear e desbloquear não atualiza tudo
Bloquear a estação mantém a sessão.
Isso é diferente de fazer logoff
Win + L
não recria toda a sessão do usuário.
Caso 26 — sair e entrar resolve acesso de grupo
Isso pode acontecer porque uma nova sessão cria novo contexto de segurança.
Caso 27 — reiniciar também resolve
Porque todas as sessões são encerradas e reconstruídas.
Mas novamente:
resolver não significa descobrir a causa.
Caso 28 — serviço para de funcionar depois que senha da conta é alterada
Se um serviço utiliza uma conta específica e depende de credenciais configuradas, uma alteração pode exigir revisão da configuração.
Não mexa no LSASS
O problema pode estar no serviço que está tentando autenticar.
Caso 29 — tarefa agendada falha depois da troca de senha
Mesma lógica.
Procure evento relacionado à tarefa
O Agendador pode fornecer pistas.
Caso 30 — compartilhamento mapeado para de funcionar
Uma unidade de rede pode estar associada a uma sessão anterior ou credencial armazenada.
O sintoma pode aparecer somente ao reiniciar
Porque a reconexão tenta ocorrer novamente.
Caso 31 — lsass.exe usa CPU alta depois de ligar o PC
Observe o que inicia junto com o Windows.
Pode existir atividade de
- rede;
- domínio;
- políticas;
- serviços;
- aplicativos.
Cronometre
08:00 login
08:01 CPU sobe
08:03 serviço conecta
08:05 CPU normaliza
A linha do tempo ajuda.
Caso 32 — CPU alta em intervalos regulares
Isso pode indicar atividade periódica.
Pergunte
Acontece:
- a cada hora?
- sempre no mesmo horário?
- ao bloquear?
- ao conectar VPN?
- ao acessar servidor?
Padrão temporal é evidência
Caso 33 — problema só acontece conectado à VPN
Agora investigue recursos acessados pela VPN.
Possibilidades
- domínio;
- DNS;
- políticas;
- serviços;
- autenticações remotas.
Caso 34 — problema começa depois de atualização de software de segurança
Softwares de segurança podem se integrar profundamente ao Windows.
Não desative tudo imediatamente
Primeiro confirme a correlação.
Caso 35 — Security Log mostra várias falhas de logon
Isso não significa automaticamente invasão.
Pode ser uma credencial antiga
Especialmente quando:
- a senha foi trocada;
- um serviço continua tentando;
- uma unidade de rede reconecta;
- uma tarefa usa outra conta.
O horário ajuda muito
Se as falhas começam exatamente depois da alteração da senha, isso é uma pista relevante.
Caso 36 — falhas vêm sempre do mesmo computador
Agora o computador de origem merece investigação.
Caso 37 — falhas vêm de várias máquinas
Em ambiente corporativo, pode existir uma configuração distribuída.
Caso 38 — nome de usuário aparece errado
Talvez o aplicativo esteja usando outra conta.
Exemplo
Usuário pensa que está usando:
EMPRESA\Maria
mas o programa tenta:
PC\Maria
São identidades diferentes.
Caso 39 — mesma senha, mas conta diferente
A senha ser igual não torna as identidades iguais.
Caso 40 — login local funciona depois de ficar offline
Em alguns cenários corporativos, o Windows consegue permitir entrada com informações previamente disponíveis no dispositivo.
Isso não significa que o domínio esteja acessível
Depois do login, recursos corporativos ainda podem falhar.
Caso 41 — domínio não disponível
O usuário pode confundir:
“Consegui entrar.”
com:
“O domínio está funcionando.”
São coisas diferentes.
Caso 42 — usuário altera senha em outro dispositivo
Depois disso, pode existir diferença temporária entre métodos locais e credenciais online.
PIN pode continuar funcionando
Porque não é simplesmente a senha da conta.
Caso 43 — PIN pede redefinição
Antes de apagar qualquer configuração manualmente, utilize os mecanismos suportados pelo Windows.
Evite tutoriais que mandam remover arquivos protegidos de credenciais sem entender o impacto
Caso 44 — TPM apresenta erro
Investigue primeiro:
- firmware;
- Windows Update;
- BIOS/UEFI;
- estado do Windows Hello;
- BitLocker.
Não use “Clear TPM” como primeira solução
Caso 45 — após atualização de BIOS, Windows Hello apresenta problema
Mudanças de firmware podem alterar o estado de segurança percebido pelo Windows.
Verifique também BitLocker
Antes de fazer qualquer nova alteração.
Caso 46 — usuário troca placa-mãe
Isso pode afetar recursos vinculados ao hardware.
Novamente
PIN, TPM e chaves possuem relação com o dispositivo.
Caso 47 — Credential Guard está habilitado
Isso pode alterar a forma como determinadas credenciais e mecanismos legados funcionam.
Não desative Credential Guard só para “testar”
Primeiro confirme incompatibilidade real.
Caso 48 — software antigo deixa de autenticar
Agora investigue:
- protocolo utilizado;
- dependência legada;
- política corporativa;
- atualização do aplicativo.
Caso 49 — política nova bloqueia método antigo
Isso pode ser totalmente intencional.
Segurança corporativa muda
Uma aplicação que funcionava anos atrás pode depender de um mecanismo que a organização passou a restringir.
Caso 50 — usuário pensa que LSASS está “consumindo senha”
Esse conceito está errado.
LSASS é parte da arquitetura de segurança.
Ele não deve ser tratado como um aplicativo comum manipulando uma senha de forma simples e isolada.
Como diferenciar autenticação de autorização
Essa tabela ajuda muito:
| Sintoma | Área inicial |
|---|---|
| senha/PIN rejeitado | Autenticação |
| login funciona, pasta dá acesso negado | Autorização |
| login local funciona, SMB pede senha | Autenticação remota |
| usuário autenticado, RDP proibido | Política/autorização |
| grupo alterado, acesso não muda | Token/sessão |
| login funciona offline, domínio não | Rede/domínio |
| senha nova, serviço falha | Credencial configurada |
| PIN falha, senha funciona | Windows Hello |
Ferramentas úteis
Gerenciador de Tarefas
Use para:
- observar CPU;
- confirmar processo;
- verificar usuários e sessões.
Event Viewer
Execute:
eventvwr.msc
Use para correlacionar:
- falhas de logon;
- serviços;
- erros;
- horários.
Reliability Monitor
Execute:
perfmon /rel
Pode ajudar em problemas que começaram depois de:
- atualizações;
- falhas de aplicativos;
- mudanças no sistema.
Process Explorer
Use de maneira observacional para confirmar:
- caminho;
- assinatura;
- PID.
Não manipule LSASS.
Gerenciamento de Usuários
Dependendo da edição do Windows, ferramentas administrativas ajudam a verificar:
- contas;
- grupos;
- associações.
PowerShell pode ajudar no inventário
Para tarefas administrativas legítimas, PowerShell pode consultar informações de usuários e grupos.
Mas o objetivo deve ser entender configuração, não tentar acessar credenciais.
Como montar uma linha do tempo
Essa técnica é extremamente útil.
Exemplo:
09:00 — senha alterada
09:05 — login normal
09:10 — unidade de rede falha
09:12 — eventos de autenticação malsucedida
09:15 — serviço corporativo apresenta erro
Agora temos uma narrativa técnica.
Muito melhor do que
“LSASS está usando CPU, então vou reparar o Windows.”
Diagnóstico em 20 etapas
1. Defina o sintoma
Login, PIN, SMB, RDP ou outro?
2. Identifique o tipo de conta
Local, Microsoft, AD ou Entra.
3. Registre horário
4. Verifique se houve troca de senha
5. Teste outro método de entrada disponível
6. Teste o mesmo usuário em outro recurso
7. Teste outro usuário
8. Teste com e sem rede, quando fizer sentido
9. Verifique relógio
Especialmente em domínio.
10. Verifique DNS
Em ambiente corporativo.
11. Verifique se o problema é local ou remoto
12. Observe CPU do LSASS sem finalizá-lo
13. Analise eventos próximos ao horário
14. Procure serviços ou tarefas associados
15. Verifique unidades de rede
16. Verifique mudanças recentes
17. Confirme caminho/assinatura do processo se houver suspeita
18. Não limpe TPM sem necessidade
19. Não desative proteções de segurança sem evidência
20. Corrija o componente responsável, não o LSASS
O erro mais comum
Quando o usuário vê:
lsass.exe
com uso alto de CPU, pensa:
“O arquivo está com defeito.”
Mas talvez o processo apenas esteja recebendo muitas solicitações legítimas ou repetitivas.
Portanto procure quem gera a carga
Essa é a mesma lógica que utilizamos com:
- WMI;
- svchost.exe;
- RuntimeBroker.exe;
- SearchIndexer.exe.
O processo visível pode ser apenas o intermediário
Diferenças entre LSASS, Winlogon, Credential Manager, Windows Hello, TPM, BitLocker, mitos, FAQ e conclusão
Chegamos à parte final do artigo.
Até aqui vimos que lsass.exe não deve ser interpretado como “o programa da senha”. Ele participa de uma arquitetura muito maior, que inclui autenticação, identidade, SID, grupos, privilégios, tokens de acesso, políticas, contas locais, contas Microsoft, domínio, Windows Hello, Kerberos, NTLM e mecanismos modernos de proteção.
Agora vamos organizar essas diferenças de forma prática.
lsass.exe versus winlogon.exe
Esses dois processos aparecem frequentemente juntos em explicações sobre entrada no Windows, mas não são a mesma coisa.
lsass.exe
Está ligado à infraestrutura da Autoridade de Segurança Local e a mecanismos de autenticação e segurança.
winlogon.exe
Participa da infraestrutura da sessão interativa e do processo de entrada do usuário.
Uma representação didática seria:
Tela de entrada
↓
winlogon.exe e componentes de logon
↓
mecanismos de credencial
↓
LSA / LSASS
↓
identidade autenticada
↓
sessão
lsass.exe versus Credential Provider
Um Credential Provider participa da forma como o usuário fornece sua credencial.
Pode apresentar, por exemplo:
- senha;
- PIN;
- biometria;
- métodos corporativos compatíveis.
LSASS não é simplesmente a caixa de texto onde a senha aparece.
lsass.exe versus Credential Manager
Outro componente que causa confusão é o:
Gerenciador de Credenciais do Windows.
Ele pode armazenar determinadas credenciais utilizadas por aplicativos, sites, recursos de rede ou serviços compatíveis.
Isso não significa que o Credential Manager e LSASS sejam a mesma coisa.
Exemplo prático
Você altera sua senha no servidor.
Depois disso:
Login do Windows → funciona
mas:
Compartilhamento de rede → continua tentando senha antiga
Uma credencial armazenada ou uma sessão anterior pode estar envolvida.
O problema não significa necessariamente falha no LSASS.
lsass.exe versus SAM
SAM significa:
Security Account Manager.
Está relacionado à infraestrutura das contas locais.
LSASS possui papel mais amplo na arquitetura de segurança.
lsass.exe versus Active Directory
Active Directory é um serviço de diretório usado em muitos ambientes corporativos.
LSASS existe no computador Windows e participa de mecanismos de autenticação.
Não são equivalentes.
lsass.exe versus Kerberos
Kerberos é um protocolo de autenticação.
LSASS participa da infraestrutura que permite ao Windows utilizar mecanismos como Kerberos em cenários apropriados.
lsass.exe versus NTLM
NTLM também representa mecanismos de autenticação do ecossistema Windows.
Novamente:
LSASS ≠ NTLM
LSASS participa da infraestrutura que pode utilizar diferentes mecanismos.
lsass.exe versus Windows Hello
Windows Hello é uma plataforma de autenticação moderna.
Pode utilizar:
- PIN;
- reconhecimento facial;
- impressão digital.
LSASS não é o Windows Hello inteiro.
Windows Hello versus senha
Essa distinção merece uma última repetição.
Senha
Está vinculada à credencial da identidade.
PIN do Windows Hello
Está vinculado ao dispositivo e ao mecanismo local de autenticação.
Portanto:
PIN não é simplesmente uma senha mais curta.
lsass.exe versus TPM
TPM significa:
Trusted Platform Module.
Ele pode proteger chaves e material criptográfico.
LSASS e TPM possuem funções diferentes.
TPM pode ajudar o Windows Hello
Sim.
Mas isso não transforma o TPM em “local onde fica a senha do Windows”.
lsass.exe versus BitLocker
BitLocker protege volumes de armazenamento.
LSASS participa de outra camada de segurança.
BitLocker não substitui autenticação
Um volume protegido pode ainda exigir:
- identidade;
- token;
- permissões;
- ACL.
lsass.exe versus UAC
UAC significa:
User Account Control.
Ele ajuda a controlar elevação de privilégios.
LSASS e UAC não são a mesma tecnologia.
lsass.exe versus SID
SID significa:
Security Identifier.
SID identifica entidades de segurança.
LSASS participa da infraestrutura que trabalha com identidades, mas não “é o SID”.
lsass.exe versus Access Token
O Access Token representa o contexto de segurança utilizado por processos e threads.
LSASS participa da criação e gerenciamento de contextos associados à autenticação, mas token e LSASS são conceitos diferentes.
lsass.exe versus ACL
ACL define regras de acesso a objetos.
Quando um processo tenta abrir um arquivo, o Windows pode comparar:
token do processo
com:
ACL do objeto
LSASS não é a ACL.
lsass.exe versus explorer.exe
Depois do login, explorer.exe pode iniciar como shell do usuário.
Ele recebe um contexto de segurança associado à sessão.
Portanto:
LSASS → autenticação/contexto
e:
Explorer → shell/interface do usuário
são papéis diferentes.
lsass.exe versus svchost.exe
svchost.exe hospeda diversos serviços do Windows.
LSASS é um processo crítico específico da arquitetura de segurança.
lsass.exe versus RuntimeBroker.exe
RuntimeBroker está relacionado a determinados aspectos de permissões e operações de aplicativos modernos.
Isso não significa que ele autentique o usuário no Windows.
lsass.exe versus ApplicationFrameHost.exe
ApplicationFrameHost está relacionado historicamente à infraestrutura de apresentação de determinadas janelas de aplicativos modernos.
Novamente, função completamente diferente.
lsass.exe versus DWM.exe
dwm.exe é o Desktop Window Manager.
Ele participa da composição gráfica da Área de Trabalho.
Não possui o mesmo papel de autenticação do LSASS.
Tabela comparativa
| Componente | Função principal |
|---|---|
lsass.exe | Segurança, autenticação e LSA |
winlogon.exe | Infraestrutura da sessão de logon |
| Credential Provider | Obtenção/apresentação de credenciais |
| Windows Hello | Autenticação moderna com PIN/biometria |
| TPM | Proteção de chaves e material criptográfico |
| SAM | Infraestrutura de contas locais |
| Kerberos | Protocolo de autenticação |
| NTLM | Família de mecanismos de autenticação |
| Access Token | Contexto de segurança |
| SID | Identificador de segurança |
| ACL | Controle de acesso |
| UAC | Elevação e controle administrativo |
| BitLocker | Criptografia de volumes |
| Credential Manager | Armazenamento de determinadas credenciais |
Ferramentas úteis no diagnóstico
Gerenciador de Tarefas
Bom para:
- CPU;
- memória;
- PID;
- usuários;
- sessões.
Mas não use para finalizar LSASS.
Visualizador de Eventos
Abra:
eventvwr.msc
É uma das ferramentas mais importantes para autenticação.
Log de Segurança
Pode conter eventos relacionados a:
- logon;
- falhas de autenticação;
- uso de contas;
- auditoria.
A disponibilidade depende da configuração de auditoria.
Monitor de Confiabilidade
Abra:
perfmon /rel
Útil para observar a linha do tempo do sistema.
Process Explorer
Pode ajudar a confirmar:
- caminho;
- assinatura;
- PID;
- propriedades gerais.
Use apenas de forma observacional ao lidar com processos sensíveis.
Gerenciamento do Computador
Dependendo da edição e configuração do Windows, ajuda a visualizar:
- usuários;
- grupos;
- sessões;
- compartilhamentos.
Prompt de Comando
Comandos simples podem ajudar na identificação do contexto.
Por exemplo:
whoami
Mostra a identidade atual.
whoami /user
Pode mostrar o SID do usuário atual.
whoami /groups
Permite consultar os grupos associados ao contexto atual.
whoami /priv
Mostra privilégios associados ao token atual.
Essas informações são valiosas
Porque ajudam a responder:
“Com qual identidade e contexto este processo está operando?”
gpresult
Em ambientes corporativos, gpresult pode ajudar a verificar políticas aplicadas.
Isso pode ser útil quando uma configuração de segurança vem de Group Policy.
ipconfig
Parece estranho colocar ipconfig em um artigo sobre LSASS.
Mas em domínio, rede e DNS podem afetar autenticação.
Portanto verificar:
- endereço IP;
- DNS;
- gateway;
pode ser necessário.
nslookup
Também pode ajudar quando existe suspeita de problema de resolução de nomes.
w32tm
Em ambientes corporativos, problemas de sincronização de horário também podem interferir na autenticação.
O princípio é o mesmo
Não existe uma única ferramenta chamada:
“diagnosticar LSASS”.
O diagnóstico depende da camada que falhou.
O que não fazer
Algumas ações aparecem frequentemente em tutoriais, mas podem piorar o problema.
1. Não finalize lsass.exe
É processo crítico.
2. Não apague lsass.exe
Nunca.
3. Não substitua o arquivo manualmente
Use mecanismos suportados de manutenção do Windows.
4. Não desative Credential Guard sem motivo
Primeiro identifique a incompatibilidade.
5. Não desative LSA Protection apenas para testar
Isso reduz segurança.
6. Não limpe TPM como primeira tentativa
O impacto pode envolver chaves e BitLocker.
7. Não altere permissões do System32 aleatoriamente
Isso pode causar problemas maiores.
8. Não baixe lsass.exe de sites aleatórios
Executáveis do sistema não devem ser substituídos por arquivos obtidos em sites de download.
9. Não redefina todas as permissões NTFS do Windows
Uma tentativa agressiva de corrigir “acesso negado” pode destruir configurações corretas.
10. Não conclua malware apenas pelo nome do processo
Verifique caminho, assinatura e comportamento.
11. Não conclua que todo evento de falha de logon é invasão
Analise origem e horário.
12. Não conclua que senha errada é sempre problema de senha
DNS, horário, domínio, políticas e recursos remotos também podem interferir.
13. Não use SFC como primeiro diagnóstico de autenticação
SFC é útil quando há evidência de corrupção de arquivos do sistema.
14. Não use DISM para qualquer problema de login
Ele não corrige automaticamente credenciais, domínio, PIN ou políticas.
15. Não formate o computador antes de entender o cenário
Principalmente em ambiente corporativo.
Quando SFC faz sentido?
Quando existem indícios de corrupção de componentes protegidos do Windows.
Comando:
sfc /scannow
Mas ele não deve ser usado como substituto de diagnóstico.
Quando DISM pode fazer sentido?
Quando existe suspeita real de problema no armazenamento de componentes do Windows.
Exemplo:
DISM /Online /Cleanup-Image /RestoreHealth
Novamente:
não resolve automaticamente problemas de credenciais.
15 mitos sobre lsass.exe
Mito 1 — LSASS é o programa que guarda minha senha
Não dessa forma simplificada.
Mito 2 — PIN é a mesma coisa que senha
Não.
Mito 3 — Se o PIN funciona, a senha obrigatoriamente está correta
Não necessariamente.
Mito 4 — Se a senha funciona localmente, funcionará em qualquer servidor
Não.
Mito 5 — Duas contas com mesmo nome são iguais
Não.
SIDs podem ser diferentes.
Mito 6 — Administrador pode abrir qualquer arquivo automaticamente
Não.
ACL, UAC, token e outros mecanismos ainda importam.
Mito 7 — Todo evento de falha de logon é ataque
Não.
Pode ser credencial antiga, serviço ou tarefa.
Mito 8 — lsass.exe com CPU alta significa vírus
Não necessariamente.
Mito 9 — reiniciar LSASS resolve autenticação
Não tente fazer isso.
Mito 10 — limpar TPM resolve qualquer erro de PIN
Não.
Pode criar complicações adicionais.
Mito 11 — Credential Guard é antivírus
Não.
Mito 12 — BitLocker e LSASS fazem a mesma coisa
Não.
Mito 13 — bloquear o PC equivale a sair
Não.
Mito 14 — trocar o nome da conta altera sua identidade
O SID continua sendo um elemento fundamental da identidade.
Mito 15 — acesso negado sempre significa senha errada
Frequentemente é problema de autorização, não autenticação.
FAQ — Perguntas frequentes sobre lsass.exe
1. O que significa lsass.exe?
Local Security Authority Subsystem Service.
2. lsass.exe faz parte do Windows?
Sim, é um componente crítico de segurança.
3. Onde fica o lsass.exe legítimo?
Normalmente associado ao executável do sistema em:
C:\Windows\System32\lsass.exe
4. Posso encerrar lsass.exe?
Não é recomendável. É um processo crítico do sistema.
5. Posso desativar lsass.exe?
Não como solução de manutenção comum.
6. LSASS guarda minha senha em texto?
Não devemos imaginar a arquitetura dessa forma.
7. LSASS autentica contas locais?
Ele participa da infraestrutura de autenticação e segurança do Windows.
8. LSASS funciona em domínio?
Sim, também possui papel importante em ambientes de domínio.
9. O que é LSA?
Local Security Authority.
10. O que é SAM?
Security Account Manager, relacionado à infraestrutura de contas locais.
11. SAM é o mesmo que LSASS?
Não.
12. O que é SID?
Security Identifier, identificador utilizado pelo Windows para representar entidades de segurança.
13. O nome do usuário é sua verdadeira identidade no Windows?
Não sozinho.
O SID é fundamental.
14. Duas contas chamadas João podem ser diferentes?
Sim.
15. Se eu apagar e recriar João, ele recebe o mesmo SID?
Normalmente uma nova conta representa uma nova identidade.
16. Isso pode causar acesso negado?
Sim, principalmente quando permissões apontam para o SID anterior.
17. O que é Access Token?
É uma estrutura que representa o contexto de segurança utilizado durante a execução.
18. O token contém a senha?
Não é assim que devemos interpretar um Access Token.
19. O token possui SID?
Ele inclui informações de identidade e segurança, incluindo SIDs relevantes.
20. Grupos entram no token?
Sim, associações a grupos fazem parte do contexto de segurança.
21. O que é UAC?
User Account Control.
22. Ser administrador desativa o UAC?
Não necessariamente.
23. Por que “Executar como administrador” muda o comportamento?
Porque o processo pode receber um contexto elevado.
24. O que são Credential Providers?
Componentes relacionados à apresentação e coleta de opções de credenciais.
25. O PIN é uma senha curta?
Não.
26. O PIN funciona apenas naquele computador?
Ele faz parte do modelo do Windows Hello vinculado ao dispositivo.
27. Posso usar o mesmo PIN em vários computadores?
É possível configurar números iguais, mas cada configuração continua relacionada ao mecanismo local de cada dispositivo.
28. Trocar a senha da conta Microsoft altera automaticamente o PIN?
Não necessariamente.
29. Windows Hello usa TPM?
Pode utilizar TPM quando disponível e configurado.
30. TPM guarda minha senha?
Não é correto descrever o TPM dessa forma.
31. Posso limpar TPM para corrigir o PIN?
Não como primeira tentativa.
32. Limpar TPM pode afetar BitLocker?
Pode afetar material criptográfico protegido, por isso exige cuidado e planejamento.
33. O que é Credential Guard?
Um recurso de segurança que ajuda a proteger determinados segredos de autenticação utilizando isolamento.
34. Credential Guard usa VBS?
Está associado a mecanismos de segurança baseada em virtualização.
35. O que é LSA Protection?
Uma camada adicional de proteção para componentes sensíveis da Autoridade de Segurança Local.
36. O que significa PPL?
Protected Process Light.
37. LSASS com CPU alta significa defeito?
Não necessariamente.
38. Quanto de CPU é normal?
Não existe um número universal. Observe duração, contexto e padrão.
39. Um pico durante o login é problema?
Não obrigatoriamente.
40. Uso alto durante horas merece investigação?
Sim.
41. Trocar a senha pode causar autenticações repetidas?
Pode revelar componentes ainda configurados com credenciais antigas.
42. Uma unidade de rede pode continuar tentando senha antiga?
Dependendo da configuração e da sessão, sim.
43. Uma tarefa agendada pode falhar depois de trocar senha?
Pode, se depender de credenciais configuradas.
44. Um serviço pode falhar depois da troca de senha?
Também pode.
45. Por que o login funciona mas a pasta de rede não?
Porque são contextos de autenticação e autorização diferentes.
46. SMB usa as permissões NTFS?
Permissões NTFS podem participar, mas compartilhamento e autenticação remota também entram na equação.
47. Acesso negado significa senha errada?
Não.
48. Pode ser ACL?
Sim.
49. Pode ser UAC?
Dependendo da operação, sim.
50. Pode ser grupo errado?
Sim.
51. Posso visualizar meu SID?
Sim, por exemplo com:
whoami /user
52. Posso ver meus grupos?
Sim:
whoami /groups
53. Posso ver meus privilégios?
Sim:
whoami /priv
54. Kerberos é usado em domínio?
É um protocolo central em muitos ambientes Active Directory.
55. NTLM ainda existe?
Sim, embora ambientes modernos busquem reduzir dependências legadas quando possível.
56. DNS pode causar problema de autenticação?
Sim, especialmente em Active Directory.
57. Horário errado pode interferir?
Sim, particularmente em mecanismos como Kerberos.
58. Entrar offline prova que o domínio está funcionando?
Não.
59. O computador pode permitir login mesmo sem alcançar o domínio?
Em determinados cenários corporativos, sim.
60. Por que depois os recursos corporativos falham?
Porque autenticação local da sessão e comunicação com serviços do domínio são questões diferentes.
Fluxo final de diagnóstico
Quando surgir um problema aparentemente relacionado ao LSASS, siga esta ordem.
1. Identifique exatamente o sintoma
Evite descrições genéricas como:
“senha não funciona”.
2. Determine onde falha
- tela de entrada;
- compartilhamento;
- RDP;
- aplicativo;
- domínio;
- serviço.
3. Determine o tipo de identidade
- local;
- Microsoft;
- Active Directory;
- Entra ID.
4. Determine a credencial usada
- senha;
- PIN;
- biometria.
5. Registre o horário da falha
6. Verifique mudanças recentes
- senha;
- atualização;
- política;
- BIOS;
- TPM;
- rede;
- software.
7. Teste outro método suportado de entrada
8. Teste outro usuário, quando apropriado
9. Diferencie autenticação de autorização
10. Verifique rede e DNS quando houver recurso remoto
11. Verifique horário em ambiente de domínio
12. Analise logs
13. Procure tarefas, serviços e recursos que possam usar credenciais antigas
14. Observe LSASS, mas não manipule o processo
15. Confirme caminho e assinatura se houver suspeita de arquivo falso
16. Verifique políticas aplicadas em ambiente corporativo
17. Evite desativar proteções
18. Não limpe TPM sem compreender consequências
19. Use SFC/DISM somente quando houver indícios de corrupção do sistema
20. Corrija a camada responsável
Esse é o ponto mais importante.
Conclusão
lsass.exe é um daqueles processos que parecem misteriosos apenas porque o Windows mantém grande parte de sua complexidade longe da interface do usuário.
Quando digitamos uma senha, PIN ou utilizamos biometria, não ocorre apenas uma comparação simples para decidir se a Área de Trabalho deve aparecer.
O Windows precisa estabelecer uma identidade confiável.
Depois dessa autenticação, ele precisa determinar:
- quem é o usuário;
- qual é seu SID;
- a quais grupos pertence;
- quais privilégios possui;
- qual contexto de segurança será criado;
- quais processos serão iniciados;
- quais recursos poderão ser acessados.
Por isso conceitos como:
LSASS
SID
Access Token
ACL
UAC
Windows Hello
TPM
Kerberos
Credential Guard
fazem parte de diferentes pontos de uma mesma arquitetura de segurança.
Essa visão também melhora muito o diagnóstico.
Quando um computador aceita o PIN, mas recusa uma senha em outro recurso, não devemos concluir que “o Windows enlouqueceu”.
Quando um compartilhamento pede credenciais mesmo depois do login local, isso não significa necessariamente defeito.
Quando lsass.exe aparece com CPU elevada, também não devemos encerrar o processo ou tratar o executável como culpado automaticamente.
O diagnóstico correto começa identificando:
qual identidade, qual método de autenticação, qual recurso, qual política e qual contexto estão envolvidos.
Quanto melhor entendemos essas camadas, menos dependemos de soluções aleatórias e mais rapidamente encontramos a verdadeira origem do problema.
Precisa de ajuda com autenticação, contas ou Windows 11?
A VMIA – Manutenção e Configuração oferece suporte para diagnóstico e configuração de computadores Windows, incluindo problemas relacionados a contas de usuário, permissões, compartilhamentos de rede, Windows 11, autenticação em recursos locais e de rede e configurações de segurança.
Atendimento por acesso remoto ou visita técnica agendada em São Paulo.
Site: https://vmia.site
Blog técnico: https://vmia.com.br
WhatsApp: https://whats.vmia.com.br
Telefone/WhatsApp: (11) 99779-7772
E-mail: suporte@vmia.com.br
VMIA – Manutenção e Configuração
Suporte técnico com linguagem clara, diagnóstico cuidadoso e soluções adequadas para cada situação.
Faça um comentário