Módulos de Protocolo e Clientes de Rede do WiKID

Visão geral
Protocolos permitem que o WiKID Strong Authentication Server aceite solicitações de validação de credenciais vindas de sistemas externos (clientes de rede). A edição Community do WiKID oferece suporte a LDAP, TACACS+ e wAuth.
O wAuth é o interface nativo do servidor WiKID. Ele usa SSL/TLS e autenticação por certificado para permitir que clientes — distribuídos ou locais — comuniquem dados de autenticação por redes potencialmente inseguras. O sistema de demonstração de registro usa um Java bean (wClient) para verificar informações de autenticação do usuário; o ficheiro de exemplo está em /opt/WiKID/tomcat/webapps/WiKIDAdmin/example.jsp ou acessível via https://servername/WiKIDAdmin/exmample.jsp.
Selecione a opção de cabeçalho Módulos de Protocolo para iniciar a inicialização. Você verá a lista de módulos de protocolo disponíveis no servidor.
Figura 16 – Protocolos não inicializados
Important: o protocolo wAuth é habilitado automaticamente — nenhum outro protocolo opera sem ele.
Ativar o protocolo LDAP
Para habilitar LDAP, na página Habilitar Protocolos clique em LDAP para abrir a tela de habilitação do LDAP. Os parâmetros obrigatórios para o módulo LDAP são:
- LDAP_wauth_host: Endereço IP do servidor WiKID que validará as requisições bind LDAP (sempre 127.0.0.1).
- LDAP_wauth_kfile: Localização do certificado de Cliente de Rede para acesso LDAP ao servidor WiKID (geralmente /opt/WiKID/private/localhost.p12).
- LDAP_wauth_pass: Senha do certificado de Cliente de Rede acima.
- LDAP_wauth_port: Porta em que o servidor WiKID está escutando (geralmente 8388). Nota: o LDAP, internamente, responderá na porta 10389.
- LDAP_wauth_server: Código de 12 dígitos do domínio contra o qual o LDAP verificará as requisições bind.
Depois de preencher, clique em Atualizar.
Notas rápidas:
- Verifique permissões do arquivo de chave (/opt/WiKID/private/localhost.p12) — somente o usuário do serviço deve ter leitura.
- Teste com uma ferramenta LDAP (ldapsearch) apontando para o proxy WiKID na porta configurada.
Criar Clientes de Rede
Clientes de rede são sistemas que solicitam validação de senhas de uso único (OTP) ao servidor WiKID. Eles atuam como proxies, recebendo dados do usuário e consultando o WiKID para validação. Cada cliente usa um dos módulos de protocolo instalados; portanto, o módulo correspondente deve estar instalado, inicializado e habilitado antes de você adicionar um cliente para ele.
Cada cliente de rede deve ser configurado no servidor WiKID antes de solicitar validações. Para clientes wAuth, é necessário gerar um certificado para o cliente de rede. A exceção é o cliente localhost, pré-instalado por padrão; mesmo assim, recomenda-se regenerar esse certificado periodicamente, bem como os certificados de clientes remotos.
A tela inicial para clientes de rede mostra a lista atual e opções para criar novos clientes.
Figura 17 – Tela inicial de Cliente de Rede
Selecione “Criar novo Cliente de Rede” para adicionar um cliente. Você verá a tela de propriedades do cliente.
Figura 18 – Propriedades do Cliente de Rede
Propriedades gerais (obrigatórias para todo cliente):
- Nome – Nome descritivo do servidor. Será exibido na interface de administração e nos logs. Recomenda-se usar host + domínio WiKID para clareza.
- Endereço IP – Endereço IP do cliente de rede.
- Protocolo – Protocolo de comunicação usado por este cliente. Apenas protocolos previamente habilitados estarão disponíveis. A seleção determina propriedades adicionais obrigatórias.
- Domínio – Domínio de autenticação WiKID no qual este cliente requisitará validação de credenciais.
Criando um certificado para clientes wAuth
Se você estiver criando um cliente wAuth, será necessário gerar um certificado do cliente. Complete as informações solicitadas (CN, OU, etc.). Observação: a máquina cliente não precisa ter um FQDN (nome de domínio totalmente roteável). É aceitável usar um nome curto como “www” ou “extranet” em vez de “vpn.wikidsystems.com”.
Figura 19 – Criação de certificado para cliente wAuth
Após gerar o certificado, baixe o arquivo de chave (por exemplo, um .p12) e instale-o no cliente de rede conforme o cliente/appliance exigir.
Passo a passo: Criar um cliente wAuth (mini-metodologia)
- Verifique que o módulo wAuth está habilitado (wAuth é habilizado automaticamente na maioria das instalações).
- No painel de Módulos de Protocolo, confirme que o protocolo desejado (wAuth/LDAP/TACACS+) está inicializado.
- Vá em Clientes de Rede → Criar novo Cliente de Rede.
- Preencha Nome, Endereço IP, Protocolo = wAuth e Domínio.
- No formulário de certificado, defina CN (nome do host do cliente), OU e outros atributos conforme política interna.
- Gere o par de chaves e exporte o certificado de cliente (.p12) com uma senha segura.
- Faça o download do certificado e instale-o no cliente (appliance, servidor RADIUS, etc.).
- Teste a conexão: do cliente, efetue uma chamada de autenticação e verifique logs no WiKID.
- Registre o certificado e a senha no cofre de chaves da organização; planeje rotação periódica.
Checklist rápido antes de ativar um cliente
- Módulo de protocolo está instalado, inicializado e habilitado.
- Endereço IP do cliente incluído na configuração do cliente no WiKID.
- Certificado do cliente (para wAuth) gerado e instalado com a senha correta.
- Domínio WiKID correto configurado no perfil do cliente.
- Testes de autenticação realizados e logs verificados.
- Procedimento de rotação de chaves agendado.
Matriz comparativa curta (quando usar cada protocolo)
- wAuth: recomendado para clientes que suportam TLS com certificado de cliente; maior segurança e integridade; ideal para comunicações ponto a ponto.
- LDAP: usado quando é necessário proxy LDAP para autenticação centralizada; útil para integração com diretórios existentes.
- TACACS+: indicado para equipamentos de rede que suportem TACACS+ para controle de comandos e autenticação em dispositivos de rede.
Boas práticas de segurança
- Use certificados por cliente (não compartilhar certificados entre múltiplos dispositivos).
- Proteja os arquivos .p12 e suas senhas; restrinja acesso ao diretório /opt/WiKID/private.
- Revogue certificados comprometidos imediatamente e remova o cliente no WiKID.
- Habilite logging detalhado temporariamente ao diagnosticar problemas, mas não mantenha logs detalhados sem rotação e retenção controlada.
- Agende rotação periódica de certificados (por exemplo, 6–12 meses, conforme política da sua organização).
Cenários comuns de falha e soluções rápidas
- Falha de autenticação após troca de certificado: confirme que o novo certificado foi importado no cliente e que o WiKID recebeu a versão atualizada.
- Erro de ligação LDAP: verifique LDAP_wauth_host (deve ser 127.0.0.1) e portas (8388 vs 10389), além da senha do keystore.
- Cliente não listado: verifique permissões e se o módulo de protocolo está habilitado.
Critérios de aceitação
- O cliente de rede aparece listado no painel de administração com o nome e IP corretos.
- O cliente consegue realizar requisições de validação e recebe respostas de sucesso para credenciais válidas.
- Logs do WiKID mostram a autenticação do cliente e não exibem erros de certificado ou de porta.
- Procedimento de rotação de certificado é documentado e testado.
Glossário (linhas únicas)
- wAuth: Protocolo nativo do WiKID que usa TLS e certificados de cliente.
- Cliente de Rede: Sistema que solicita validação de credenciais ao WiKID.
- Keystore (.p12): Arquivo que contém a chave privada e certificados do cliente.
Notas finais e resumo
Este guia apresenta as etapas essenciais para ativar módulos de protocolo no WiKID, configurar parâmetros críticos do LDAP e criar clientes de rede, com foco em clientes wAuth que exigem certificados. Siga a checklist e as boas práticas de segurança para reduzir risco operacional e garantir uma gestão segura de certificados.
Resumo rápido:
- Habilite e inicialize o módulo de protocolo antes de criar clientes.
- wAuth é obrigatório e usa certificados; gere e proteja o .p12 do cliente.
- Teste autenticações e implemente rotação e revogação de certificados.
Important: mantenha backups seguros das configurações e dos certificados e registre mudanças no CMDB da organização.