Architecture de la base de données
UserLock s’appuie sur une base de données centrale pour stocker les journaux d’activité. Comprendre le fonctionnement de cette base et les technologies prises en charge aide les administrateurs à faire les bons choix en termes de performance, de fiabilité et de maintenance à long terme.
UserLock enregistre en continu des informations telles que :
les événements de session et d’authentification,
les changements de statut des utilisateurs,
les actions des administrateurs,
les modifications de configuration.
Une base de données centrale garantit que ces informations sont conservées, consultables et cohérentes sur l’ensemble du déploiement.
Depuis UserLock 13.1, la base de données par défaut est SQLite. Une nouvelle installation stocke ses données dans un unique fichier SQLite local (UserLock.db) sur le serveur UserLock et commence immédiatement à enregistrer.
Cette option est conçue pour la simplicité :
aucune configuration : aucun serveur de base de données à installer, aucun pilote à déployer, aucun identifiant à gérer,
un seul fichier local : toute la base de données tient dans un fichier sur le serveur UserLock, facile à inclure dans les sauvegardes du serveur,
l’accès est contrôlé par les autorisations du système de fichiers du serveur UserLock.
Cas d'usage
👉 Adapté à l’évaluation et à la production dans les environnements de petite et moyenne taille. Pour des volumes importants, un accès partagé entre les serveurs principal et de secours, ou un accès à distance depuis les consoles d’administration, voir Choisir une base de données.
UserLock prend en charge cinq types de bases de données. Les pilotes nécessaires sont installés automatiquement avec UserLock : aucune installation manuelle de pilote n’est requise.
Base de données | Versions prises en charge | Taille maximale | Remarques |
|---|---|---|---|
SQLite (par défaut) | Incluse avec UserLock | Limitée par l’espace disque | Aucune configuration, un seul fichier local. |
Microsoft SQL Server | 2005 et versions ultérieures, 32/64 bits | Aucune limite théorique | Recommandé pour l’évolutivité, la résilience et l’intégration en entreprise. |
Microsoft SQL Server Express | 2005 et versions ultérieures, 32/64 bits | 10 Go | La plupart des fonctionnalités de SQL Server, avec des limitations de processeur et de mémoire vive. Économique et suffisamment robuste pour la production dans les environnements de PME. |
MySQL | 5.6 et versions ultérieures | Dépend du serveur MySQL | Pilotes installés automatiquement ; MySQL est disponible dans la liste des types de bases de données. |
Microsoft Access (hérité) | Fichier | 2 Go | Conservé uniquement pour des raisons de compatibilité. La migration vers SQLite est recommandée. |
Note
Les éditions LocalDB de SQL Server ne sont pas compatibles avec UserLock.
Dans les versions antérieures à 13.1, la base de données par défaut était un fichier Microsoft Access (UserLock.mdb). Access est désormais un type de base de données hérité : il reste pris en charge pour des raisons de compatibilité, de sorte que les installations existantes continuent de fonctionner après la mise à niveau.
Access présente des limitations structurelles :
taille de fichier maximale de 2 Go,
performances et évolutivité limitées,
manque de résilience pour une utilisation à long terme ou en production.
Lorsque la base de données actuelle est un fichier Access, UserLock propose de la migrer vers SQLite. Ne choisissez pas Access pour les nouveaux déploiements.
Note
Pour les étapes de migration dans la console, voir Paramètres serveur ▸ Base de données.
SQLite convient à la production pour l'évaluation et les petits environnements. Choisissez SQL Server (ou SQL Server Express, ou MySQL) si vous prévoyez un volume élevé d’événements, si les serveurs principal et de secours doivent partager un serveur de base de données central, ou si vous devez accéder à la base de données à distance depuis les consoles d’administration.
Note
Les serveurs principal et de secours ont chacun besoin de leur propre base de données. Ils peuvent partager le même serveur de base de données, avec un nom de base de données différent pour chaque serveur UserLock.
UserLock introduit un nouveau moteur d’insertion .NET (ADO.NET) qui écrit les événements dans la base de données. Avec ce moteur, aucun événement n’est perdu lorsque la base de données est temporairement indisponible :
Les événements générés pendant que la base de données est injoignable sont conservés par UserLock.
Ils restent conservés même si le service UserLock redémarre entre-temps.
Dès que la connexion est rétablie, UserLock les insère dans la base de données.
Note
Après une mise à niveau vers 13.1, une connexion à une base de données existante continue d’utiliser l’ancien moteur d’insertion ODBC jusqu’à ce que ses paramètres de connexion soient régénérés avec l’assistant de base de données dans Paramètres serveur ▸ Base de données. Cette étape active le nouveau moteur .NET, requis par SQLite.
Les déploiements UserLock évoluent fréquemment au fil du temps. Les besoins de migration courants incluent :
passer d’Access à SQLite (proposé par la console lorsque la base de données actuelle est un fichier Access),
passer de SQLite ou d’Access à SQL Server (lorsque les volumes d’événements augmentent ou que les serveurs principal et de secours ont besoin d’un serveur de base de données central),
passer d’un SQL Server à un autre (changement d’infrastructure, mise à niveau ou reprise après sinistre).
Les migrations entre tous les types de bases de données pris en charge s’effectuent avec l’assistant de base de données, en conservant intactes les données et l’historique. Voir Migrer la base de données UserLock.
Si vous avez besoin d'aide pour déployer SQL Express, vous pouvez consulter ce guide pour savoir comment installer et configurer SQL Express.
Utilisez SQLite (par défaut) pour les environnements de petite et moyenne taille, et SQL Server (ou SQL Server Express, ou MySQL) pour les volumes importants ou lorsque les serveurs principal et de secours s’appuient sur un serveur de base de données central.
N’utilisez pas Microsoft Access pour les nouveaux déploiements ; migrez les bases Access existantes vers SQLite.
N’utilisez pas SQLite si vous prévoyez d’accéder à la base de données à distance depuis les consoles d’administration. Nous recommandons d’utiliser SQL Server (ou SQL Server Express, ou MySQL).
Avec SQLite, incluez le fichier de base de données dans les sauvegardes du serveur UserLock.
Avec SQL Server ou MySQL, hébergez la base de données sur un serveur sauvegardé.
Surveillez la croissance de la base de données et planifiez sa maintenance (archivage, purge des anciens journaux).
Testez les migrations dans un environnement de préproduction chaque fois que possible.
Travaillez avec votre équipe DBA pour respecter les normes et les politiques de sauvegarde de l’entreprise.
Note
Pour les options de configuration détaillées dans la console, voir Paramètres serveur ▸ Base de données.
La base de données UserLock est composée de quatre tables. Ces tables ne sont pas configurables depuis la console, mais comprendre leur contenu peut aider pour l’audit, le dépannage ou l’intégration.
UserLogonEvents : enregistre les événements de session et d’authentification.
UserStatus : enregistre le Statut utilisateur.
AdminActions : enregistre les actions de des administrateurs.
AdminActionResults : enregistre les résultats liés aux actions administrateur.
Vous trouverez ci-dessous la liste détaillée des champs de ces tables, indiquant leur type et leur usage.
Ces informations sont fournies dans un objectif de transparence et d’intégration.
Note
La base de données UserLock est librement accessible afin de permettre l’intégration et le reporting sur les données collectées. Toutefois, nous recommandons fortement de ne pas modifier la structure ni le contenu de la base.
Nom du champ | Type | Description du champ |
|---|---|---|
EventType | entier | Sessions interactives Sessions d'accès à distance Wi-Fi/VPN Sessions IIS Sessions SaaS Evènements UAC |
EventTime | heure et date | Date et heure de l'événement d'ouverture/fermeture de session |
UserAccount | chaîne | Compte utilisateur |
UserDomain | chaîne | Domaine de l'utilisateur |
UserFullName | chaîne | Nom complet de l'utilisateur |
ComputerName | chaîne | La station de travail ou le serveur de terminal |
ComputerSession | entier | Identifiant de la session terminal |
ClientName | chaîne | Nom de la station de travail ou nom du terminal pour une session terminal |
ClientAddress | chaîne | Adresse de la station de travail ou du terminal (adresse MAC pour les sessions Wi-Fi, sinon adresse IP). |
SessionId | chaîne | Identificateur de session (unique dans le temps) |
SubSessionId | entier | Identificateur de sous-session. Incrémenté par 1 après chaque événement de déverrouillage ou de connexion (nouvelle sous-session) |
Status | entier | 0: Pour tous les événements de session, à l'exception des cas ci-dessous.
3: Pour les événements de fermeture de sessions interactives enregistrés automatiquement après un arrêt ou un crash de l'ordinateur sur lequel la session se déroulait. |
ErrorId | chaîne | Non nul uniquement si l'événement de session n'a pas pu être notifié en temps réel au serveur UserLock. Cela peut arriver dans les cas suivants :
|
LastError | entier | Différent de 0 uniquement si l'événement de session n'a pas pu être notifié en temps réel au serveur UserLock. Consultez la documentation du champ ErrorId ci-dessus pour plus de détails. |
Param1 to Param6 | chaîne | Champs dynamiques pour les événements de sessions NPS/RRAS/IIS |
Id | entier | Identifiant de l'enregistrement (automatique)Record id (auto) |
LogonInfo | entier | La signification de cette valeur est liée à la valeur du champ EventType associé. Raisons détaillées d'une connexion réussie lorsque le champs EventType associé = 1, 3, 5, 101, 201 ou 501: Raisons détaillées d'un refus de connexion par UserLock lorsque le champs EventType associé = 4, 104 ou 204. Un refus de connexion par UserLock peut avoir plusieurs raisons. C'est pourquoi la valeur enregistrée est une valeur cumulative. Par exemple 25 correspond à l'application conjointe de restrictions de Groupe, Session et Quotas de temps (1 + 16 + 8). Raisons détaillées d'un refus de connexion par Active Directory lorsque le champs EventType associé =20, 220 ou 420: Les refus de connexions par Active Directory étant exclusifs, la valeur enregistrée sera toujours une seule valeur de cette liste. Raison détaillée d'un refus de connexion par UserLock lorsque le champs EventType associé = 120: |
SessionType | entier | Type de Session: |
ServerAddress | chaîne | L'adresse IP de l'ordinateur où s'est déroulé l'événement de session. |
TimeZoneShift | entier | Décalage horaire par rapport à UTC (Temps universel coordonné), en minutes. |
SkipReason | entier | Relatif au bouton “Passer” optionnellement affiché dans la boîte de dialogue de configuration MFA. |
Country | chaîne | Pays à partir duquel la connexion a été effectuée |
Nom du champ |
| Description du champ |
|---|---|---|
Id | entier | Identifiant de l'enregistrement (automatique) |
Status | entier | Statut actuel de l'utilisateur. |
Triggers | entier | Identifiant des conditions remarquables pour la déduction du statut actuel de l'utilisateur. |
OldStatus | entier | Statut précédent de l'utilisateur. |
OldTriggers | entier | Identifiant des conditions remarquables pour la déduction du statut actuel de l'utilisateur. |
UserAccount | chaîne | Compte utilisateur |
UserDomain | chaîne | Domaine de l'utilisateur |
UserFullName | chaîne | Nom complet de l'utilisateur |
SessionId | chaîne | Identificateur de session (unique dans le temps) |
SubSessionId | entier | Identificateur de sous-session. Incrémenté par 1 après chaque événement de déverrouillage ou de connexion (nouvelle sous-session) |
EventType | entier | Sessions interactives Sessions d'accès à distance Wi-Fi/VPN Sessions IIS |
EventTime | heure et date | Date et heure de l'événement d'ouverture/fermeture de sessionDate and time of the logon/logoff event |
Nom du champ | Type | Description du champ |
|---|---|---|
Id | entier | ID de l’enregistrement (auto) |
ServerName | chaîne | Nom du serveur |
Kind | entier |
|
Action | entier |
|
DateStart | heure et date | Date et heure de début de l'action de l'administrateur |
DateEnd | heure et date | Date et heure de fin de l'action de l'administrateur |
UserAccount | chaîne | Nom du compte utilisateur à l’origine de l’action |
Priority | entier |
|
Severity | entier |
|
DisplayState | entier |
|
UserAccountFullName | chaîne | Nom complet du compte utilisateur à l’origine de l’action |
Domain | chaîne | Nom du domaine |
Nom du champ | Type | Description du champ |
|---|---|---|
Id | entier | ID de l’enregistrement (auto) |
ServerName | chaîne | Nom du serveur |
AdminActionId | entier | Identifiant de AdminAction |
Item | chaîne | Le paramètre modifié par l’action de l’administrateur |
Param1 | chaîne | Champs dynamique |
Param2 | chaîne | Champs dynamique |
Param3 | chaîne | Champs dynamique |
Param4 | chaîne | Champs dynamique |
Param5 | chaîne | Champs dynamique |
Param6 | chaîne | Champs dynamique |
StateResult | entier |
|
Details | chaîne | Détails concernant l'action de l'administrateur |