Annuaires - Déclarer et configurer un annuaire de codes PUK (SQL)

Principe

Lorsque les utilisateurs de Watchdoc sont enregistrés dans un annuaire Entra ID (Microsoft Azure), s'ils s'authentifient à l'aide d'un code PUK, ces codessont enregistrés dans une table SQL.

Prérequis

Avant de déclarer l'annuaire, il convient de connaître :

  • le nom de la base SQL où se trouve la table "Cards" dans laquelle seront également enregistrés les codes PUK ;

  • le compte d'accès à cette base (nom d'utilisateur et mot de passe).

Procédure

Déclarer un annuaire de codes PUK

Depuis le Menu principal de l'interface d'administration,

  1. dans la section Configuration, cliquez sur Annuaires utilisateurs :

  2. Dans la liste des annuaires qui s'affiche, cliquez sur le bouton Déclarer un nouvel annuaire :



→ Vous accédez à l'interface Déclarer un nouvel annuaire utilisateur constituée de plusieurs sections.
Le nombre et la nature des paramètres figurant dans cette interface varient en fonction du type d'annuaire à configurer.

 

Configurer l'annuaire de codes PUK

  1. Dans la section Propriétés, sélectionnez le Type Base de Codes PUK (SQL):


    • Global: cochez cette case si vous configurez l'annuaire sur un serveur master et que vous souhaitez le répliquer sur les serveurs esclaves (si le mode de synchronisation est bidirectionnel.


  2. Saisissez les informations obligatoires permettant d'établir la communication entre Watchdoc® et la base de données :

    • Identifiant : saisissez l'identifiant de l'annuaire ;

    • Utiliser la configuration de la base de statistiques : cochez cette case si vous souhaitez utiliser la même base que la base de statistiques, afin de ne pas avoir à remplir tous les champs suivants.
      Cette case permet notamment de gagner du temps pour la configuration des serveurs slaves en mode Mailbox qui ne partagent pas une base de données commune. Les codes PUK sont enregistrés dans la base associée à chaque serveur slave.


Si vous n'utilisez pas la configuration de la base de statistiques, complétez les champs suivants :

  • Serveur SQL : indiquez le serveur où est localisée la base SQL qui héberge l'annuaire. Cliquez sur le bouton Parcourir pour parcourir votre espace de travail afin d'y sélectionner le serveur parmi les serveurs SQL détectés sur votre réseau ;

  • Mot de passe : saisissez dans la zone le mot de passe du compte utilisateur habilité à gérer la base SQL ;

  • Base de données : indiquez le nom de la base de données dans laquelle doivent être enregistrées les codes PUK associés aux utilisateurs inscrits dans l'annuaire Entra ID ( watchdocstats, la plupart du temps).Cliquez sur le bouton Parcourir pour parcourir le serveur SQL déclaré précédemment afin d'y sélectionner les tables statistiques qui y sont déclarées. Par défaut, les codes PUK sont enregistrés dans la base des badges (cards).

Options

Les informations saisies permettent de préciser le paramétrage de génération des codes PUK associés aux utilisateurs d'un annuaire Entra ID :

  • Seed : saisissez un nombre servant de "Graine aléatoireFermé Une graine aléatoire (aussi appelée germe aléatoire) est un nombre utilisé pour l'initialisation d'un générateur de nombres pseudo-aléatoires. (source : Wikipédia)" permettant d'initialiser le générateur des codes PUK des utilisateurs. Ce chiffre est un entier de 32 bits compris entre 1 et 2.147.000.000 ;

  • Algorithme : dans la liste, sélectionnez le niveau d'algorithme permettant de générer les codes PUK de vos utilisateurs (6 ou 10 chiffres) ;

  • Variabilité : dans la liste, sélectionnez (si nécessaire) la fréquence à laquelle l'annuaire de codes PUK sera regénéré. Par défaut, l'annuaire ne change pas. Regénérer les codes PUK permet d'augmenter la sécurité de ce mode d'authentification.

  • Variabilité : dans la liste, sélectionnez (si nécessaire) la fréquence à laquelle l'annuaire de codes PUK sera regénéré. Par défaut, l'annuaire ne change pas. Regénérer les codes PUK permet d'augmenter la sécurité de ce mode d'authentification.

Journalisation

  • Enregistrer les requêtes SQL dans le journal de l'application : cochez la case si vous souhaitez garder une trace des requêtes SQL dans un fichier dédié.

Durée de vie du cache

Watchdoc peut conserver un cache des informations propres aux utilisateurs afin d'accélérer le temps de traitement. Les informations saisies permettent de définir la durée de conservation des caches.

 

  • TTL Infos : saisissez le temps (en secondes, minutes, heures ou jours), de la durée de conservation des informations utilisateurs.

  • TTL NotFound : saisissez le temps (en secondes, minutes, heures ou jours), de la durée de conservation des informations relatives aux utilisateurs qui se sont authentifiés dans l'application Watchdoc que cette dernière n'a pas trouvés dans l'annuaire.


Durant le délai indiqué, Watchdoc ne sollicite pas l'annuaire mais son cache. Il n'est donc pas recommandé de définir une durée de conservation trop longue, notamment pour les utilisateurs non trouvés.

Cache

Watchdoc peut conserver un cache des requêtes en mémoire afin d'en accélérer l'exécution. Cochez les cases des caches que vous souhaitez activer :

  • Infos user : cochez cette case pour activer le cache relatif aux informations utilisateurs.

  • Non trouvés : cochez cette case pour activer le cache relatif aux utilisateurs dont le compte n'a pas été trouvé.

  • Cache à froid : cochez cette case pour conserver un cache des données "froides", c'est-à-dire des données déjà vérifiées mais expirées.

  • Persistance : cochez cette case pour permettre de conserver le cache sur le disque afin de le retrouver en cas de redémarrage du service Watchdoc.

  • Compression : cochez cette case pour activer la compression du cache sur le disque. Il est fortement recommandé d'activer ce paramètre afin de réduire la taille du fichier quand la persistance est activée.

  • Chiffrement : cochez cette case pour chiffrer le fichier de cache sur le disque afin d'en sécuriser le contenu.

Fusibles

Les annuaires utilisateurs sont généralement hébergés sur un contrôleur de domaine ou serveur distant, accessible via le réseau local. En cas de panne réseau ou de ralentissement important, cela peut provoquer, par effet de cascade, un blocage ou ralentissement du serveur d'impression.

 

Dans ce cas de figure, il peut être utile d'activer un "fusible logique", qui se déclenche en cas de ralentissement majeur du système, afin de stopper les requêtes envoyées au serveur défaillant.

Attention: il est important de bien considérer l'impact de l'activation d'un fusible sur le bon fonctionnement du service !
Afin de protéger efficacement le serveur de tout dysfonctionnement de l'annuaire distant, il est important de calibrer correctement le fusible.
Il est recommandé de tester le paramétrage du fusible avant de le configurer en environnement de production.

Saisissez dans les champs les valeurs au-delà desquelles Watchdoc® cesse d'envoyer des requêtes au serveur d'annuaire pour éviter une surcharge de travail :

  • Erreurs max. : il s'agit du nombre d'erreurs "graves" successives tolérées. Une erreur "grave" est, par exemple, un problème de communication réseau, un timeout, un dysfonctionnement du serveur distant. Ces erreurs sont généralement rares et peuvent parfois se régler naturellement (fin d'une période de pointe, redémarrage du serveur distant). Les erreurs "logiques" (comme un échec d'identification, de syntaxe ou de configuration de l'annuaire) sont ignorées.

  • Durée max. : il s'agit de la durée moyenne maximale tolérée pour l'exécution des 10 dernières requêtes. En cas de fort ralentissement du serveur distant (période de pointe, timeout réseau,...), cette durée est rallongée.

  • Requêtes max. : il s'agit du nombre maximum de requêtes en parallèle autorisées. En cas de forte charge de travail, le serveur distant peut ne pas être capable de répondre à un grand nombre de requêtes simultanées.

  • Délai attente :après déclenchement du fusible, délai d'attente avant réactivation. Au terme de ce délai, Watchdoc® relance les requêtes afin de "sonder" l'état du serveur. Si les requêtes aboutissent, le fusible est réactivé, sinon il attend à nouveau l'expiration du délai. A tout moment, l'administrateur peut manuellement désactiver le fusible. Le fusible reste alors coupé jusqu'à ce qu'il soit réactivé manuellement. Pensez à utiliser cette fonctionnalité afin de tester l'impact d'une panne sur le serveur d'impression.



Les valeurs généralement saisies pour l'activation du fusible dans un environnement multi serveur (Master) sont les suivantes :

  • erreurs max : 5

  • requêtes max : 5

  • durée max : 30 secondes

  • délai attente : 120 secondes

Print clients

Ne pas utiliser cet annuaire pour l'authentification dans le Print Client :cochez cette case si vous ne souhaitez pas utiliser cet annuaire pour permettre à l'utilisateur de s'authentifier dans Watchdoc Print Client.

Validation de la configuration

Cliquez sur le bouton Créer pour valider la configuration de votre annuaire.