Ctrlk
datadike.commdm.datadike.comGithub
linkedin

Gather accounts

Função para capturar credenciais e padronizar grupos de acesso remotamente, de forma agendadam ou manual.

Consulte nesse documento:

Requerimentos

Para que a coleta de contas funcione corretamente, verifique os seguintes pré-requisitos:

O host deve estar cadastrado em Enviroment >> Assets e acessível via SSH (Linux) ou WinRM (Windows).

A conta administrator/administrador do host deve estar ativa no PAM e com permissão suficiente para listar contas do sistema (ver Persistência da execução).

Para Windows: WinRM deve estar habilitado e a porta 5985 liberada no firewall.

Para Linux: Python deve estar instalado no host alvo (Python 3 preferencialmente).

Step by Step

1

Crie o JOB de automação

SYSADMIN >> ACCOUNTS >> AUTOMATIONS >> GATHER ACCOUNTS

2

Gather account tasks

Função Creat: Clique em + Create para criar uma nova tarefa de coleta de conta

3

Preencha as configurações básicas

Preencha os campos do formulário Configurações Básicas:

Nome (obrigatório): Identificação da operação de coleta.

Nó: Define em qual nó do ambiente a operação será executada.

Dispositivos: Seleciona os dispositivos alvo da coleta de contas.

Execução periódica: Quando ativado, exibe os campos de agendamento — Operações programadas (crontab) e Intervalo (padrão: 24 horas). Se ambos estiverem configurados, o crontab tem prioridade.

Sincronizar com ativo: Quando ativado, as contas coletadas serão sincronizadas automaticamente com os ativos do PAM.

Ativação: Habilita ou desabilita a operação (habilitado por padrão).

Custodiante: Usuário responsável pela operação — utilizado apenas para envio de notificações por email.

Observação: Campo livre para anotações sobre a operação.

4

Persistência da execução:

Enviroment >> Assets >> Click no host >> Accounts >> Administrator >> Quick update >> Active

Por padrão o PAM sempre utilizará a conta administrator/administrador para se conectar aos ambientes, se essa conta tem permissão reduzida, não tem a senha imputada no DataDike ou está desabilitada no S.O., desative essa conta no PAM.

5

Retorno de uma execução bem sucedida:

Troubleshooting

Se a coleta não executar corretamente, verifique os seguintes pontos antes de consultar os erros comuns:

Confirme que o host está acessível na rede e que a porta SSH (22) ou WinRM (5985) está aberta.

Verifique se a conta administrator/administrador está ativa e com a senha cadastrada corretamente no PAM (Enviroment >> Assets >> host >> Accounts >> Administrator >> Quick update >> Active).

Para Windows: confirme que o protocolo WinRM está habilitado no host e que a autenticação NTLM ou Kerberos está configurada corretamente.

Para Linux: confirme que Python 3 está instalado e disponível em /usr/bin/python3.

Consulte a aba Executions do JOB para visualizar o log completo da última execução e identificar o erro específico.

Erros comuns

Esse seguimento se trata de #Advanced knowledge (consulte seu Partner)

MODULE FAILURE

FAILED! => {"changed": false, "module_stderr": "Warning: Permanently added '172.168.168.10' (ECDSA) to the list of known hosts.\r\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 0}

Estruturando a mensagem para melhor entendimento:

Causas:

  1. O DataDike conseguiu se conectar via SSH/WinRM ao host 172.168.168.10.

    • A prova é que ele adicionou a chave ECDSA no known_hosts.

  2. Porém, quando ele tenta rodar o módulo Python/PowerShell dentro da máquina alvo, a execução falha.

    • O rc: 0 é enganoso — o processo de transporte não deu erro, mas o módulo não conseguiu inicializar corretamente.

    • Como o module_stdout veio vazio, não houve retorno útil do script.

  3. Esse tipo de erro costuma estar ligado a:

    • Windows:

      • Problema com WinRM (falta de permissão, autenticação incompleta, ou configuração incorreta).

      • Python não disponível no Windows (quando se usa connection: ssh em vez de winrm).

      • Execução do módulo do Ansible sem privilégios suficientes.

    • Linux:

      • Python não instalado ou em local inesperado (/usr/bin/python3 ausente).

      • Falta de bibliotecas necessárias para o módulo.

Data could not be sent to remote host

fatal: []: UNREACHABLE! => {"changed": false, "msg": "Data could not be sent to remote host "10.0.30.111". Make sure this host can be reached over ssh: Warning: Permanently added '10.0.30.111' (ECDSA) to the list of known hosts.\r\nConnection reset by 10.0.30.111 port 22\r\n", "unreachable": true}

Estruturando a mensagem para melhor entendimento:

Causas:

  1. Serviço SSH não ativo ou caiu no servidor

  2. Firewall bloqueando depois do handshake inicial.

  3. Política de segurança (IDS/IPS) fechando a conexão após tentativa de autenticação.

  4. Usuário incorreto

The connection plugin 'rdp' was not found

Correção: Adicione no cadastro do HOST a porta 22 em protocols

ntlm: the specified credentials were rejected by the server

fatal: [DEMO-WIN03]: UNREACHABLE! => {"changed": false, "msg": "ntlm: the specified credentials were rejected by the server", "unreachable": true}

Consulte no Windows pelo ID 4624, ele comprava que teve a comunicacao mas o bloqueio ocorreu devido a incompatibilidade NTLM

ntlm: HTTPConnectionPool(host='192.168.30.112', port=5985): Max retries exceeded

ntlm: HTTPConnectionPool(host='192.168.30.112', port=5985): Max retries exceeded with url: /wsman (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7f410155d4d0>, 'Connection to 192.168.30.112 timed out. (connect timeout=121)'))", "unreachable": true}

Verifique o firewall do Windows e crie as devidas exceções de regra.

Verifique se o serviço WINRM está executando

PreviousChange secretsNextBreak Vault

Was this helpful?