RMM › Implantação de agentes

Implantar o agente via Active Directory — Manual de uso (administrador)

Público: administradores e técnicos do MSP que instalam o agente do GestorMSP nos computadores de um cliente com domínio Active Directory. Para instalar em uma única máquina, veja a Central de Implantação (instalador manual).

Com a implantação via Active Directory, o GestorMSP descobre os computadores do domínio de um cliente e instala o agente neles, sem você passar máquina por máquina. Um agente já instalado em um controlador de domínio (DC) faz a descoberta e dispara a instalação. Para quem trabalha fora da rede do cliente (usuários remotos), o mesmo assistente oferece o pacote Intune.

Estado de validação. O recurso foi entregue e mesclado, mas ainda não foi validado em um Active Directory real (descoberta, criação de GPO, instalação nas máquinas) nem em um tenant Intune real. Faça sempre um piloto com poucos computadores antes de ligar a instalação automática em produção. Este manual descreve o comportamento esperado e não garante suporte por versão do Windows.

1. Como funciona, em resumo

1. O agente no controlador de domínio consulta o Active Directory e lista os computadores Windows.
2. O GestorMSP registra cada computador e decide, conforme a política, se instala sozinho (Automático), se espera a sua aprovação (Com aprovação) ou se não faz nada (Desligado).
3. A instalação é feita por push: o controlador manda o computador baixar o instalador assinado e executá-lo, usando uma credencial de domínio guardada no cofre da empresa.
4. Se o computador estiver desligado ou o push falhar, o GestorMSP tenta de novo nos próximos ciclos, até um limite. Para máquinas que ficam offline, existe a GPO de startup, que instala o agente no próximo boot.
5. O instalador não fica guardado no controlador. O computador confere a integridade (SHA-256 e assinatura) antes de executar.

2. Onde fica o assistente

Há três caminhos para o mesmo assistente:

• Dispositivos → Novo dispositivo → Computadores do domínio (Active Directory). É o caminho mais curto.
• Central de Implantação → Implantar via Active Directory (escolha a empresa antes).
• Integração Microsoft Active Directory da empresa.

Se o cartão aparecer desabilitado, o texto dentro dele diz o motivo:

3. Pré-requisitos

Permissões

Quem tem só write pode editar a política, mas não pode ampliar o alcance do modo Automático. Isso exige approve.

4. Passo a passo do assistente

O assistente tem cinco passos. Você pode voltar a qualquer um depois.

4.1. Controlador de domínio

Escolha qual DC descobre os computadores e inicia a instalação.

• Automático: o sistema escolhe um DC disponível que consiga consultar o Active Directory.
• Ou escolha um DC específico da lista (cada um mostra Disponível ou Offline e quando foi testado).
• Usar outro controlador se o escolhido estiver offline (failover): quando ligado, outro DC da empresa executa o ciclo. O último ciclo sempre registra qual DC executou.

Clique em Salvar controlador. Se a lista estiver vazia, instale o agente em um DC e rode o teste da integração.

4.2. Pré-requisitos

Mostra o estado de cada item (plano, integração, controlador, credencial, descoberta, WinRM) a partir do último ciclo. O que ainda não rodou aparece como Verificado ao rodar o ciclo. Use Rodar agora para conferir. Itens que exigem ação trazem o que fazer.

Aqui também fica o painel das GPOs (seção 7).

4.3. Computadores

Lista os computadores descobertos, com sistema operacional, OU, status, último erro e tentativas. Você pode filtrar por status, selecionar vários computadores (até 500 de uma vez) e:

• Aprovar (no modo Com aprovação) ou Rejeitar.
• Tentar de novo em um computador que falhou.

Computadores que nunca recebem instalação aparecem com o motivo:

4.4. Política

Define o que o GestorMSP faz com o que descobre. Toda alteração é versionada e auditada.

Como OUs e grupos se combinam. Com os dois preenchidos vale a interseção: o computador precisa estar numa das OUs e ser membro de algum dos grupos. Com só um deles, vale só ele. Sem nenhum, vale o domínio inteiro. O resumo de alcance, logo abaixo, escreve o que a sua escolha significa.

Atenção ao modo Automático sem nenhum filtro. Ele instala o agente em todos os computadores Windows do domínio. A tela avisa e pede confirmação (seção 5).

Recomendação para o primeiro uso: comece em Com aprovação, com um grupo-piloto de poucos computadores. Passe para Automático só depois de conferir os resultados.

4.5. Acompanhamento

Mostra o resumo do último ciclo (concluído, controlador offline, credencial ausente etc.) e a contagem de computadores por status. Use Rodar agora para forçar um ciclo (há um intervalo mínimo de cerca de dois minutos entre ciclos manuais).

Status de um computador:

5. Ligar o modo Automático

Ligar ou ampliar o modo Automático exige a permissão aprovar. Ao salvar, o GestorMSP mostra uma confirmação com tudo o que a escolha afeta: OUs, grupos, se controladores de domínio estão incluídos, o controlador executor, o failover e o teto por tenant. Você precisa marcar "Entendo que o agente será instalado automaticamente dentro do alcance acima" e clicar em Confirmar e salvar.

6. Escolher só alguns computadores: OU, grupo e interseção

• Por OU: use quando a estrutura do Active Directory já separa o que você quer (ex.: OU=Estacoes,DC=corp,DC=local).
• Por grupo: use quando a seleção não segue as OUs (ex.: um grupo "Piloto-GestorMSP" com 10 computadores). Adicione os computadores ao grupo no Active Directory e escolha o grupo na política.
• Interseção: use os dois para reduzir ainda mais.

Observações:

• A pertinência a grupo é transitiva: um computador que está num grupo dentro do grupo escolhido também entra.
• Filtrar pelo grupo padrão Domain Computers devolve vazio: o Active Directory registra esse grupo como grupo primário do computador, e o filtro não o enxerga. Use outro grupo.
• O filtro por grupo depende do agente do controlador atualizado. Com agente antigo, o ciclo não instala nada e mostra Agente do controlador desatualizado (sem filtro por grupo). Atualize o agente do DC (OTA) e rode o ciclo de novo.
• Se o computador aprovado sair do grupo antes de ser instalado, ele vira Fora dos grupos permitidos e perde a aprovação.

7. GPOs: gerência remota e instalação no startup

No passo Pré-requisitos o GestorMSP pode criar duas GPOs no domínio do cliente. Nada é criado automaticamente: é sempre uma ação sua, em duas etapas.

Como aplicar uma GPO

1. Escolha as OUs alvo (uma por linha) e/ou marque Vincular também na raiz do domínio.
2. Escolha os grupos que recebem a GPO (filtro de segurança). Sem grupos, o GestorMSP usa o grupo GestorMSP-Managed-Computers, que nasce vazio: nenhuma máquina é afetada até você adicionar computadores (ou grupos de computadores) a ele.
3. Para a GPO de startup, informe o número estimado de máquinas e a validade do código de instalação (o padrão é 24 horas).
4. Clique em Simular. Nada é alterado: o resultado mostra se a GPO será criada ou atualizada, em quais OUs, com quais valores e quais conflitos existem.
5. Se a simulação estiver boa, clique em Aplicar, marque a confirmação e confirme. Aplicar exige a permissão aprovar, e a simulação precisa ser do mesmo alcance (ela vale por 15 minutos; se mudar OU, raiz ou grupo, simule de novo).

Quando a GPO roda

A GPO de startup é script de inicialização do computador, não de logon: a máquina precisa ligar (ou reiniciar) com o controlador de domínio acessível. Quem só acorda e se conecta depois instala no próximo boot. Ela não alcança quem está fora da rede do cliente: para esses, use o pacote Intune (seção 8).

Vínculo na raiz do domínio

Vincular na raiz faz a GPO valer em todo o domínio, restrita só pelo filtro de segurança. Por isso:

• exige uma confirmação própria ("Confirmo vincular esta GPO na raiz do domínio inteiro");
• o GestorMSP nunca vincula em Domain Controllers, mas uma GPO na raiz herda para a OU Domain Controllers; o que impede que ela os alcance é o filtro de segurança;
• por isso o GestorMSP recusa grupos de controlador de domínio como filtro, e recusa também um grupo que contenha DCs quando a GPO vai na raiz;
• se a política do rollout restringe por OUs, vincular na raiz é recusado.

Remover

Remover desvincula e exclui só a GPO criada pelo GestorMSP (um backup fica no controlador). Se já existir uma GPO com o mesmo nome criada por outra pessoa, o GestorMSP não toca nela e avisa. Configurações já aplicadas nas máquinas podem permanecer até serem revertidas.

Segurança do código de instalação

A GPO de startup guarda um código de instalação no SYSVOL, que qualquer máquina do domínio pode ler. Por isso ele tem número de usos limitado e validade curta e pode ser revogado. Não reaproveite o código para outra finalidade.

8. Computadores fora do domínio: pacote Intune

No fim do assistente, Máquinas fora do domínio: pacote Intune serve usuários remotos ou eventuais. Duas formas:

Publicar no Intune (automático). O GestorMSP cria o agente como app Win32 no Intune do cliente.

1. A empresa precisa ter a conexão Microsoft 365 e a permissão do Intune concedida (DeviceManagementApps.ReadWrite.All) por um Administrador Global ou Administrador do Intune do cliente. O botão Conceder permissão do Intune leva a isso.
2. Clique em Publicar no Intune e confirme. O app é criado sem nenhuma atribuição: o GestorMSP nunca atribui, nunca marca como obrigatório.
3. No centro de administração do Intune, atribua o app a grupos de dispositivos (não de usuários) e escolha Obrigatório quando decidir fazer o rollout.

Pacote manual. Escolha a arquitetura (x64 ou ARM64), a validade do código e o máximo de instalações e clique em Gerar pacote. A tela entrega o MSI assinado e o passo a passo para criar o app Win32 (com o Win32 Content Prep Tool da Microsoft).

Pontos de atenção:

• O comando de instalação contém o código de instalação, que os administradores do Intune do cliente podem ler. Ele expira, tem limite de usos e pode ser revogado na própria tela.
• Despublicar remove o app do Intune e revoga o código; as máquinas que já instalaram o agente não são desinstaladas.
• A detecção do Intune só confirma o arquivo no disco. O dispositivo é considerado instalado quando o agente fala com o GestorMSP: confirme na lista de Dispositivos.
• A publicação ainda não foi validada em um tenant Intune real. Se o Intune recusar o pacote, a publicação é desfeita e o erro aparece na tela, sem deixar nada no Intune.

9. Problemas comuns

10. Limites conhecidos

• Só instala em computadores Windows. Linux, macOS e dispositivos IoT não são instalados por este caminho.
• Nunca instala em controladores de domínio pela rotina automática (opção recomendada na política).
• O push depende de WinRM e de uma credencial de administrador local. Máquinas fora da rede do cliente só são alcançadas pelo Intune.
• A GPO de startup só age no boot com o DC acessível.
• Exclusões por grupo ou OU (instalar em tudo, menos em alguns) não existem: escolha o alcance por inclusão.
• O filtro por grupo exige agente do controlador atualizado.
• Ainda não validado em Active Directory e Intune reais: faça piloto.

11. Boas práticas

1. Comece em Com aprovação, com um grupo-piloto pequeno.
2. Confira a lista de Computadores e os motivos de exclusão antes de ligar o Automático.
3. Aplique a GPO de gerência remota antes do push, para o WinRM e o acesso de administrador não serem o motivo das falhas.
4. Use Simular sempre antes de Aplicar uma GPO.
5. Mantenha o failover ligado se a empresa tiver mais de um controlador de domínio.
6. Depois do rollout, confirme os computadores na lista de Dispositivos.

Segurança › SecureLogon (MFA de logon do Windows)

GestorMSP SecureLogon — Manual de Configuração (administrador)

Público: administradores e técnicos do MSP. Para o usuário final, veja securelogon-uso.md. Procedimentos de emergência detalhados ficam no runbook.

O GestorMSP SecureLogon exige um segundo fator ao entrar em computadores e servidores Windows (logon local e desbloqueio de tela). Quem decide é o backend; o agente do GestorMSP instalado na máquina e o provedor de logon (DLL) só aplicam a decisão.

Estado de validação. O código foi mesclado, mas ainda não foi validado em Windows real (instalação do MSI, tela de logon e matriz de VMs Windows 10/11 e Server 2019/2022 estão pendentes). Faça sempre piloto antes de exigir o MFA em produção. Este manual não garante suporte por versão do Windows.

1. Como funciona, em resumo

1. O usuário se cadastra fora do logon, no portal do GestorMSP (TOTP, e-mail, push no celular). Não existe cadastro dentro da tela de logon do Windows.
2. O administrador cria uma política (escopo, métodos, modo) e escolhe quem é protegido (todos os usuários ou só usuários/grupos alocados).
3. O dispositivo é armado (pela política em modo Exigir ou manualmente). O agente registra o provedor de logon na máquina.
4. No logon, o usuário digita usuário e senha do Windows, e o provedor pede o segundo fator. A decisão é tomada no backend; a senha do Windows nunca é enviada ao backend.
5. O servidor de AD não decide nada: ele só fornece usuários e grupos pela sincronização. Cada servidor ou estação protegido precisa do agente e do provedor de logon.

2. Pré-requisitos

Permissões

Atenção. Com os perfis padrão, Técnico e Gerente já podem armar/desarmar dispositivos e gerar códigos de emergência, mesmo sem policy:write. Revise os perfis antes do rollout.

Ligar/desligar o MFA de uma empresa exige policy:write e manage. Ações em massa e a chave do tenant na Frota exigem as duas permissões e, para a chave do tenant, um operador sem restrição de empresa.

3. Roteiro de implantação recomendado

1. Contratar o módulo e conferir as permissões.
2. Criar a política em modo Monitorar (é o padrão do assistente). Nada é bloqueado: o agente só registra quem teria sido exigido e se o usuário já tem fator cadastrado.
3. Avisar os usuários para se cadastrarem no portal (veja o manual de uso). O sistema não envia convite por e-mail: o aviso é manual (e-mail, chamado ou comunicado interno). O painel de adoção mostra quem ainda não tem fator.
4. Escolher o público: Todos os usuários ou Somente usuários alocados (seção 5). Para servidores, o comum é alocar só os administradores.
5. Piloto: aplique a política a poucos dispositivos (TI) por cerca de uma semana.
6. Guardar os códigos de emergência de cada dispositivo armado (impressos ou em cofre) antes de qualquer queda.
7. Mudar para Exigir e ampliar por ondas. Não ligue o logon offline na primeira onda.
8. Acompanhar os relatórios e a lista de dispositivos divergentes.

4. Onde ficam as telas

5. Configuração passo a passo

5.1 Criar a política (assistente)

Botão Nova política (ou Editar política), título Ativar MFA de logon. O assistente tem cinco passos.

1. Escopo

Precedência quando várias políticas se aplicam: Dispositivo > Grupo/OU > Empresa > Tenant. Só política habilitada entra. Entre OUs vence a mais profunda; em empate entre duplicatas de mesmo escopo, vale a mais antiga. O escopo de uma política existente não pode ser alterado.

O escopo por OU/grupo define em quais computadores a política vale. Para definir quais usuários são protegidos, use a alocação (seção 5.2).

2. Métodos — padrão do assistente: Código do aplicativo autenticador (TOTP), Notificação push e Código de backup. Código por e-mail fica fora por padrão (é um fator mais fraco); pode ser reordenado por preferência.

3. Modo

4. Isenções e janelas

• Isenções: por SID da conta ou usuário do GestorMSP, com Motivo obrigatório (até 500 caracteres) e Válida até (vazio = sem validade). Cada uso é auditado e vale mesmo com o backend fora do ar.
• Quando o backend está indisponível:
  • Fechado (padrão): ninguém entra, exceto por código de emergência.
  • Somente offline: aceita o logon offline por QR, se habilitado.
  • Aberto, com limite: libera só com a senha do Windows por um número limitado de logons (padrão 3, faixa 1–10) e por um tempo desde o último contato com o backend (padrão 60 min, faixa 5–240). Exige o aceite do risco e gera alerta a cada uso.
• Logon offline: padrão 10 logons (1–100) e validade de 14 dias (1–90). É um fator mais fraco; o primeiro logon de cada usuário exige rede; o celular precisa ter o app instalado e aberto online antes. Máximo de 30 contas por computador.

5. Piloto — selecione até 500 dispositivos. A política-mãe fica em Monitorar e só os dispositivos do piloto exigem. O resultado lista os ignorados (já têm política própria, pertencem a outro piloto). Para desfazer, Voltar para monitorar.

5.2 Escolher quem é protegido — aba "Usuários protegidos"

Cada política tem um modo de alocação:

O modo só vale em Exigir; em Monitorar a alocação é ignorada.

Ao escolher Somente usuários alocados, a tela avisa e pede confirmação:

• Usuários não alocados entram sem MFA (toda entrada assim é auditada).
• Contas não vinculadas a um usuário do GestorMSP continuam bloqueadas.

Para alocar: escolha Tipo de alocação = Usuário ou Grupo do Active Directory, busque pelo nome/e-mail e clique em Alocar. A lista mostra Usuário ou grupo, Tipo, Escopo e Alocado em, com Remover alocação. A alocação vale no próximo ciclo de provisionamento (padrão 300 s).

Regras que o sistema aplica:

• Não é possível trocar para Somente usuários alocados sem nenhuma alocação que alcance a política (erro 409 ALLOCATION_REQUIRED). Para seguir mesmo assim é preciso confirmar Continuar sem proteção (fica na trilha).
• O mesmo vale para remover a última alocação e para o piloto.
• Uma alocação de empresa só vale para aquela empresa; uma alocação do tenant inteiro vale para todas.

Limitações de grupos do AD (leia antes de alocar grupos):

• A pertinência é direta: subgrupos não são resolvidos.
• O grupo primário (por exemplo, Domain Users) não é resolvido. Alocar Domain Users não protege ninguém.
• A pertinência vem da última sincronização do AD. Com sincronização parada há mais de 48 h, o usuário é tratado como "pertinência desconhecida" e é desafiado (lado seguro).
• Usuários com mais de ~1500 grupos podem chegar com a lista incompleta, sem nenhum aviso.

Recomendação: para administradores de servidor, aloque o usuário diretamente, não um grupo.

5.3 Ligar/desligar por empresa e por tenant

No card da empresa (Geral): o interruptor MFA de endpoint ligado para esta empresa (herda do tenant por padrão), Restaurar herdado, Criar/Editar política padrão e o número de computadores com política própria. Desligar pede confirmação. A empresa só pode desligar o que o tenant não desligou; se o tenant desligou, só o administrador do tenant religa.

A chave rmm.endpoint_mfa_ad.enabled vem ligada por padrão no catálogo, mas isso não muda o logon de nenhuma máquina: só dispositivo armado é afetado, e só com o módulo no plano.

5.4 Armar/desarmar um dispositivo e códigos de emergência

Em Dispositivo → MFA de logon:

• Armar / Desarmar. Ao armar, são gerados 3 códigos de emergência independentes, de uso único, exibidos uma única vez (copiar, imprimir ou baixar .txt; é preciso marcar Confirmo que guardei os códigos). Validade padrão: 90 dias (1–365).
• Rotacionar/Gerar novos códigos e Revogar código.
• O estado aplicado mostra: Armado e aplicado, Armado — aguardando confirmação do agente, Armado — o agente reportou um erro, Não armado. A mudança chega ao agente no próximo ciclo.
• Mapeamento de contas (veja 5.4.1): vincule cada conta do Windows (por SID, formato S-1-5-21-…) a um usuário do GestorMSP.

5.4.1 Vínculo entre a conta do Windows e o usuário do GestorMSP

Estado em 2026-11-09. Contas de domínio passam a ser propostas na aba Vínculos de contas (estado Pendente, Aprovado ou Rejeitado); o administrador aprova cada proposta. A lista mostra somente empresas alcançadas por alguma política (política da empresa, ou de dispositivo/OU/grupo daquela empresa); política sem empresa (tenant inteiro) alcança todas. O contato só é encontrado se existir no espelho de autenticação; um reconciliador periódico preenche contatos que ficaram sem espelho. Conta local continua exigindo mapeamento manual por SID: Dispositivo → MFA de logon → Mapeamento de contas locais (nunca vinculada por nome).

Consequências: o vínculo é por dispositivo, e uma conta compartilhada (por exemplo, o Administrator local usado por vários técnicos) só pode ser vinculada a uma pessoa. Ver o registro de gaps e o redesenho em docs/rfcs/endpoint-securelogon-dispositivos-protegidos-v1.md.

Cobrança (regra v6): só é cobrado o usuário protegido vinculado a uma conta local ou de domínio de um dispositivo. A aba Usuários protegidos mostra a coluna Contas vinculadas.

• Isenções do servidor e Eventos recentes (30 dias).
• Configuração do servidor: política própria só deste computador.

Quando restar apenas 1 código, a tela avisa. Não espere chegar a zero.

5.5 Frota (todas as empresas)

Mostra uma linha por empresa: MFA de logon, Política da empresa, Dispositivos armados, Dispositivos divergentes e Usuários alcançados na empresa (inclui alocação do tenant inteiro). Filtros: Nome da empresa, Só com divergências, Só desligadas.

Ações em massa (até 100 empresas por vez): Ligar, Desligar, Herdar do tenant e Política para monitorar.

• Desligar exige digitar a palavra de confirmação.
• Ligar e Herdar pulam empresas que têm política em Exigir (ENFORCE_REVIEW_REQUIRED): ligue essas pela tela da empresa, depois de revisar.
• O lote nunca coloca política em Exigir. O prazo do lote é de 40 s; se estourar, repita a ação.
• A chave do tenant (Ligar/Desligar no tenant) exige operador sem restrição de empresa. Ligar o tenant com empresas em Exigir pede confirmação da contagem.

5.6 Relatórios e auditoria

• Painel e relatórios (report:read): filtros por período (máx. 366 dias), método, resultado e dispositivo; KPIs (falhas, bloqueios, usos do código de emergência, isenções, logons offline, logons liberados em queda); adoção (usuários com/sem fator, por empresa); dispositivos com estado aplicado divergente; eventos com Exportar CSV.
• Trilha de auditoria (card da empresa): Quando, Ação, Quem, Alterações.
• Retenção: auditoria de desafios 30 dias por padrão (faixa 30–730), dados operacionais 7 dias (1–90). A carência de inscrição não expira por prazo.
• Alertas: o uso de código de emergência gera alerta de severidade alta (ENDPOINT_MFA_BREAK_GLASS_USED), e rejeições seguidas de push, o alerta ENDPOINT_MFA_PUSH_FATIGUE. Eles entram na central de alertas; o e-mail só chega se houver regra de notificação configurada no tenant.

6. O que o usuário vê em cada situação

• A tela de logon não mostra quantos logons de carência restam.
• Cinco falhas do backend em contas não vinculadas de um mesmo dispositivo bloqueiam todas as contas não vinculadas daquele dispositivo por 15 minutos.
• Limites de tentativas: 5 falhas bloqueiam por 15 min (por dispositivo e usuário); localmente, 5 falhas por conta com espera de 30 s dobrando até 15 min; código de emergência: 3 falhas, 1 min dobrando até 30 min.

7. O que o SecureLogon não protege

• RDP/NLA (sessão remota), UAC/CredUI, troca de senha e logon de rede.
• Modo de Segurança e WinRE/acesso offline ao disco contornam qualquer provedor de logon de terceiros.
• Com o dispositivo armado, o provedor oculta os provedores padrão (senha, PIN, Windows Hello, biometria, smartcard, FIDO, conta Microsoft). Um provedor novo da Microsoft não está coberto.
• Windows Server Core: a validar.

Não venda nem descreva o produto como proteção de RDP.

8. Valores padrão

9. Emergências (resumo)

Procedimentos completos, com todos os cenários: runbook.

10. Desinstalação

Ao remover o agente, o instalador apaga o marcador de armado, remove os registros do provedor de logon e do filtro, e remove a pasta da DLL; se o Windows estiver usando a DLL, a remoção fica para o próximo boot. Os dados locais (state.json e audit-spool) são preservados. Log: C:\ProgramData\GestorMSP\Logs\endpoint-mfa-uninstall.log. Exclusão de dispositivo no console revoga as chaves offline e apaga o estado do MFA daquele dispositivo.

11. Pendências conhecidas

• Convite por e-mail aos usuários: existe, mas nasce desligado por empresa (ENDPOINT_MFA_AUTO_INVITE_DEFAULT = false). Avise os usuários manualmente enquanto estiver desligado.
• Medição e cobrança por usuário protegido: o job nasce desligado; a regra de contagem (v6) está implementada, mas isenções, modo "todos" sem medição e sobreposições por escopo aguardam decisão (ver registro de gaps).
• Permissão dedicada para administrar o tenant e para os códigos de emergência: ainda não existe.
• Validação em VM (Windows 10/11 e Server 2019/2022) e teste de intrusão: pendentes.

Segurança › SecureLogon (MFA de logon do Windows)

GestorMSP SecureLogon — Manual de Uso (usuário final)

Público: pessoas que entram em computadores e servidores Windows protegidos pelo GestorMSP SecureLogon. A configuração fica a cargo do administrador: securelogon-configuracao.md.

O SecureLogon pede uma segunda confirmação ao entrar no Windows, além da senha. Assim, mesmo que alguém descubra a sua senha, não consegue entrar sem o seu celular ou o seu aplicativo.

Nem todo mundo é protegido. O administrador escolhe quem passa pela confirmação. Se ele não incluiu você, você entra só com a senha, como antes.

1. Antes do primeiro uso: cadastre o seu autenticador

O cadastro é feito no portal do GestorMSP, antes de entrar no computador. A tela de logon do Windows não permite cadastrar nada.

Importante. O sistema não envia convite por e-mail: o seu administrador avisa que é preciso se cadastrar. Faça o cadastro assim que for avisado. Enquanto você não tiver um método cadastrado, o Windows pode deixar você entrar sem confirmação só por algumas vezes (a "carência"). Quando acabar, o logon será negado.

Entre no portal do GestorMSP, abra o seu perfil e vá à aba Segurança.

Este cadastro vale para usuários da plataforma (técnicos do MSP). Se você é um contato do cliente e acessa o portal portal.gestormsp.com.br, o cadastro de TOTP, push e códigos de backup para o logon do Windows ainda não está disponível nesse portal (lá o login usa apenas código por e-mail). Fale com o seu administrador.

1.1 Aplicativo autenticador (TOTP) — recomendado

1. Em MFA, clique em Configurar MFA (ou Ativar MFA).
2. Abra um aplicativo autenticador no celular (por exemplo, o Microsoft Authenticator ou o Google Authenticator) e escaneie o QR code. Se não puder escanear, use a Chave manual.
3. Digite o código de 6 dígitos exibido no aplicativo e clique em Confirmar.
4. Guarde os códigos de backup exibidos. Eles servem se você perder o celular. Cada um vale uma vez. Guarde em local seguro (cofre de senhas ou papel), nunca no mesmo celular.

1.2 Código por e-mail

Se o seu administrador permitiu, o método é habilitado direto, sem QR code. Seu e-mail precisa estar verificado no perfil.

1.3 Notificação no celular (push) — o mais prático

O push usa o app Autenticador GestorMSP, que é uma página instalada no celular.

1. Primeiro deixe pronto o TOTP (item 1.1) ou o e-mail verificado. Eles são exigidos para comprovar que é você que está cadastrando o aparelho.
2. No perfil, na aba Segurança, seção Autenticador GestorMSP, clique em Adicionar autenticador.
3. Leia o QR code ou abra o link no celular (use Copiar link, se preciso).
4. Se a página disser Instale o app primeiro:
   • iPhone: abra a página no Safari, toque em Compartilhar → Adicionar à Tela de Início e depois abra o app pela tela inicial.
   • Android: siga a instrução de instalação mostrada na página.
5. Dê um Nome do aparelho, informe o código do seu aplicativo autenticador (ou peça o código por e-mail) e toque em Ativar neste aparelho.
6. Aparece "Este aparelho agora é um autenticador."

Você pode ter até 5 aparelhos. Para remover um, use Revogar na mesma seção.

2. Entrando no computador

1. Na tela de logon do Windows, selecione o provedor GestorMSP MFA (título Verificação em duas etapas). Se o administrador definiu uma mensagem, ela aparece na tela.
2. Digite usuário e senha do Windows e pressione Enter.
3. A tela mostra o campo de verificação. Se você tem mais de um método, escolha em Método de verificação:

Dicas

• A senha do Windows não é enviada ao GestorMSP.
• O push expira em cerca de 60 segundos. Se expirar, envie outra notificação.
• Se a aprovação demorar demais (cerca de 45 s depois de aprovada), a tela pede para digitar a senha de novo.
• Se o celular mostrar Não fui eu, é porque você não iniciou aquele logon: avise o seu administrador imediatamente.

3. Mensagens e o que fazer

4. Sem internet no computador (logon offline por QR)

Só funciona se o seu administrador habilitou o logon offline. Além disso:

• Você precisa ter o app Autenticador GestorMSP instalado e inscrito (seção 1.3).
• O app precisa ter sido aberto com internet pelo menos uma vez para sincronizar as chaves.
• O primeiro logon de cada conta no computador exige rede.
• Há um limite de logons sem rede (padrão: 10). Quando acabar, conecte o computador à rede uma vez.

Como fazer:

1. Na tela de logon, escolha Offline (código QR) e toque em Gerar desafio offline. O Windows mostra um QR code e 10 dígitos.
2. No celular, abra o app Autenticador GestorMSP → Logon offline.
3. Toque em Abrir câmera e escaneie o QR code (ou use Digitar, escolha o computador e digite os 10 dígitos).
4. Toque em Gerar resposta. O app mostra 8 dígitos (somem em 60 s).
5. No Windows, digite os 8 dígitos em Resposta de 8 dígitos do celular e pressione Enter.

O desafio vale 5 minutos. Cinco respostas erradas o encerram. Se aparecer "Este usuário ainda não ativou o logon offline neste computador", entre uma vez com rede.

5. Perdi o celular ou não consigo entrar

Nunca compartilhe os seus códigos de backup, o código do aplicativo ou o número de uma notificação. O suporte nunca vai pedir esses códigos por telefone ou mensagem.

6. Perguntas frequentes

Preciso do SecureLogon quando acesso por Área de Trabalho Remota (RDP)? Hoje o SecureLogon protege o logon no próprio computador (console) e o desbloqueio de tela. O acesso por RDP e o logon de rede não passam por essa verificação.

Por que alguns colegas entram só com a senha? O administrador escolhe quem é protegido (por exemplo, só os administradores dos servidores).

Posso cadastrar mais de um método? Sim. Recomendamos TOTP e push, além de guardar os códigos de backup.

Troquei de celular. No portal, revogue o aparelho antigo e cadastre o novo (seção 1). Se usava o TOTP, configure-o de novo e guarde os novos códigos de backup.

A tela de logon não mostra quantas entradas de carência restam. E agora? Cadastre o seu autenticador o quanto antes. Não conte com a carência.

Meu nome de usuário do Windows é diferente do portal. Funciona? A sua conta do Windows precisa estar vinculada ao seu usuário do GestorMSP. Hoje esse vínculo é feito pelo administrador. Se aparecer "não está vinculada", peça ao suporte para vincular.

Quem pode ver os meus acessos? Os acessos ficam registrados para auditoria da empresa (conta, computador e resultado), com retenção definida pelo administrador. O sistema foi desenhado para não registrar códigos de verificação, de backup ou de emergência.