Activation d'un module de protocole WiKID

Objectif et variantes de recherche

But principal : expliquer comment activer un module de protocole et créer des clients réseau pour le serveur WiKID Strong Authentication. Variantes utiles : activer module protocole WiKID, configurer wAuth, activer LDAP WiKID, créer client réseau WiKID, génération certificat wAuth.

Contexte rapide

Un module de protocole permet au serveur WiKID Strong Authentication de fournir des services d’authentification à différents clients réseau. La Community Edition prend en charge LDAP, TACACS+ et wAuth. Le protocole wAuth est l’interface native qui utilise SSL/TLS et des certificats pour sécuriser les échanges.

Important : wAuth est activé automatiquement car les autres protocoles dépendent de son fonctionnement.

Pré-requis

• Accès administrateur au serveur WiKID.
• Accès web à l’interface d’administration (ex. https://servername/WiKIDAdmin).
• Chemin d’installation typique : /opt/WiKID/ pour les fichiers et certificats.
• Port par défaut d’écoute WiKID : 8388 (NB : LDAP peut écouter sur 10389 selon la configuration).

Parcours d’activation d’un module de protocole

1. Connectez-vous à l’interface d’administration.
2. Sélectionnez l’en-tête [Modules de protocole].
3. L’interface liste les modules disponibles. wAuth apparaîtra comme initialisé par défaut.

Figure 16 – Protocoles non initialisés

Activer le protocole LDAP

Cliquez sur LDAP sur la page Activer les protocoles pour ouvrir la page d’activation LDAP. Les paramètres requis sont :

• LDAP_wauth_host : adresse IP du serveur WiKID qui validera les requêtes de bind LDAP (toujours 127.0.0.1).
• LDAP_wauth_kfile : emplacement du certificat du client réseau pour l’accès LDAP au serveur WiKID (habituellement /opt/WiKID/private/localhost.p12).
• LDAP_wauth_pass : phrase de passe du certificat client réseau ci-dessus.
• LDAP_wauth_port : port sur lequel écoute le serveur WiKID (souvent 8388). NB : LDAP peut réellement écouter sur le port 10389.
• LDAP_wauth_server : code à 12 chiffres du domaine contre lequel LDAP vérifiera les requêtes bind.

Après renseignement, cliquez sur Mettre à jour.

Remarque : si vous utilisez TACACS+ ou un autre module, les champs requis peuvent différer. Activez et initialisez le module avant d’ajouter des clients réseau pour ce protocole.

Création de clients réseau

Les clients réseau (Network Clients) sont des systèmes qui demandent la validation d’un mot de passe à usage unique (OTP) au serveur WiKID. Ils agissent en proxy : ils acceptent l’entrée d’un utilisateur puis demandent au serveur WiKID la validation.

Le module de protocole choisi dictera les propriétés supplémentaires à définir pour chaque client.

Figure 17 - Écran initial des clients réseau

Sélectionnez Créer un nouveau client réseau pour ajouter un client. Le formulaire contient les propriétés générales suivantes, obligatoires pour tous les protocoles :

Figure 18 - Propriétés du client réseau

• Nom : nom descriptif du serveur. Utilisez le nom d’hôte et le domaine WiKID pour plus de clarté.
• Adresse IP : adresse IP du client réseau.
• Protocole : protocole de communication utilisé (wAuth, LDAP, TACACS+). Seuls les protocoles activés sont disponibles.
• Domaine : domaine d’authentification WiKID dans lequel le client demandera la validation.

Création d’un certificat pour un client wAuth

Pour un client wAuth, vous devez créer un certificat réseau. Le système peut vous demander les champs suivants : nom commun (CN), organisation, unité, pays, etc. Le réseau ne nécessite pas un nom de domaine pleinement qualifié (FQDN). Un nom court comme “www” ou “extranet” est acceptable.

Figure 19 – Création d’un certificat pour un client wAuth

Procédure rapide :

1. Dans le formulaire, renseignez le Nom et l’Adresse IP.
2. Choisissez Protocole = wAuth.
3. Remplissez les informations du certificat (CN, Organisation, etc.).
4. Générer le certificat et téléchargez le fichier .p12/.pem selon le besoin du client.
5. Importez le certificat côté client et configurez le client pour qu’il utilise l’IP/port du serveur WiKID.

Bonnes pratiques et sécurité

• Activez wAuth en premier. Sans wAuth, les autres protocoles ne fonctionneront pas.
• Restreignez l’accès par adresse IP pour chaque client réseau.
• Rotatez les certificats client régulièrement (périodicité selon votre politique, ex. tous les 6–12 mois).
• Protégez les fichiers p12/.pem par une phrase de passe robuste et stockez-les dans des répertoires à accès restreint (ex. /opt/WiKID/private/).
• Surveillez les logs d’authentification et configurez des alertes pour les échecs répétés.

Modèle de décision pour choisir un protocole

Si vous hésitez entre LDAP, TACACS+ et wAuth, suivez ce flux simple :

flowchart TD
  A[Besoin d'authentifier des utilisateurs via annuaire LDAP ?] -->|Oui| B[Choisir LDAP]
  A -->|Non| C[Le client supporte TACACS+ ?]
  C -->|Oui| D[Choisir TACACS+]
  C -->|Non| E[Choisir wAuth 'fortement recommandé']
  D --> F[Activer et configurer TACACS+]
  B --> G[Activer LDAP et configurer LDAP_wauth_*]
  E --> H[Activer wAuth et créer certificats client]

Check-list par rôle

Administrateur WiKID

• Vérifier que wAuth est activé.
• Activer et initialiser le module requis.
• Créer le client réseau et générer le certificat.
• Documenter le CN et l’IP associés.

Opérateur réseau

• Importer le certificat client sur le serveur/appareil.
• Tester la connexion au port WiKID (ex. 8388).
• Vérifier les logs côté client et côté serveur.

Support applicatif

• Vérifier que le protocole choisi est pris en charge par l’application.
• Confirmer la configuration du domaine et des binds LDAP si applicable.

Template de propriétés d’un client réseau

Critères d’acceptation

• Le module de protocole apparaît comme « initialisé » dans l’interface.
• Le client réseau est listé et l’IP autorisée est correcte.
• Le client peut valider une authentification de test (succès) et les logs enregistrent l’événement.
• Les fichiers de certificat sont stockés de manière chiffrée et protégés par mot de passe.

Scénarios de test minimaux

• Test 1 : Validation OTP réussie depuis le client réseau.
• Test 2 : Rejet si adresse IP source différente de celle configurée.
• Test 3 : Échec si certificat client absent ou corrompu.

Rotation des certificats — mini-méthodologie

1. Générer un nouveau certificat sur le serveur WiKID.
2. Déployer et importer le certificat sur le client hors production.
3. Tester l’authentification en parallèle (si possible).
4. Basculer la production vers le nouveau certificat.
5. Révoquer l’ancien certificat et archiver les traces.

Glossaire rapide

• wAuth : protocole natif WiKID pour échanges sécurisés par certificat.
• Client réseau : système qui sollicite la validation d’identifiants auprès du serveur WiKID.
• OTP : mot de passe à usage unique.

Résumé

• wAuth doit être actif en priorité.
• Activez et initialisez le module choisi (LDAP, TACACS+, wAuth) avant d’ajouter des clients.
• Créez et distribuez les certificats pour les clients wAuth, limitez l’accès par IP et mettez en place une rotation régulière des certificats.

Notes importantes : adaptez les paramètres (chemins, ports, codes de domaine) à votre installation. Conservez les certificats dans des emplacements sécurisés et documentez chaque client pour faciliter la maintenance ultérieure.