Console web

En cas d’erreurs de connexion au serveur UserLock, vous serez redirigé sur la page suivante :

Assurez-vous que le service UserLock est bien démarré sur le serveur. S’il est arrêté, démarrez-le et rafraîchissez la page.

Si le message "Vous n'êtes pas autorisé à administrer ce serveur UserLock !" apparait lorsque vous cliquez sur le bouton Connecter de la page d’erreur, cela signifie que le compte Windows que vous utilisez n’est pas autorisé à administrer UserLock.

1. Connectez vous au serveur UserLock

2. Ouvrez la console d'administration locale UserLock et allez sur la page des paramètres du serveur.

3. Dans la page Permissions, ajoutez dans la liste le compte que vous utilisez et ajoutez les droits nécessaires.

4. Cliquez sur le bouton Sauvegarder

5. Retournez sur l’application web et cliquez sur le bouton Connecter

Selon les droits configurés dans UserLock pour le compte Windows utilisé, vous pouvez rencontrer la page d’erreur suivante :

1. Connectez vous au serveur UserLock

2. Ouvrez la console d'administration locale UserLock et allez sur la page des paramètres du serveur.

3. Dans la page Permissions, sélectionnez le compte Windows concerné.

4. Dans la liste des cases à cocher à droite, assurez vous que les droits en lecture sur Activité/Rapports sont cochés, sinon vous ne pourrez pas consulter la grande majorité des pages de l’application.

   • Pour avoir accès aux actions sur les sessions, ajoutez les droits en écriture.

   • Pour consulter la liste des machines, assurez-vous d’avoir les droits en lecture sur Machines et agents.

   • Pour avoir accès aux actions sur les machines, ajoutez les droits en écriture.

   • Pour consulter les propriétés serveur depuis l’application web, assurez-vous que les droits en lecture des Paramètres du serveur sont cochés. Pour pouvoir les modifier, ajoutez les droits en écriture.

Ce message apparaît lors de l’accès à la console Web UserLock et que le pool d’applications UserLockAppPool dans IIS n’a pas pu démarrer.

Dans l’Observateur d’événements Windows (journal des applications) sur le serveur UserLock, vous trouverez l’erreur suivante:

The Module DLL 'C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number.

Source : IIS-W3SVC-WP
ID de l’événement : 2282

Il s’agit d’un problème connu sur les serveurs 64 bits équipés d’Exchange, qui configure ces DLL pour qu’elles se chargent par défaut dans tous les pools d’applications. UserLock tente alors de charger une DLL inutile, imposée par Exchange, qui n’existe pas en version 32 bits.

Solution de contournement : modifier les paramètres de chargement des DLL.

Localisez et sauvegardez ce fichier :

%windir%\system32\inetsrv\config\applicationhost.config

Ouvrez ce fichier avec un éditeur de fichiers texte. Remarque : si votre session est sur le serveur IIS, lancer l'éditeur avec l'option « Exécuter en tant qu'administrateur » activée, sinon vous aurez une erreur lors de l'enregistrement des modifications.

Dans la section <globalModules>, trouvez et modifiez les entrées suivantes en ajoutant preCondition="bitness64" avant /> sur chaque ligne (sauf si déjà présent) :

• "kerbauth" image="<chemin>\kerbauth.dll"

• "exppw" image="<chemin>\exppw.dll"

• Sur Exchange V15 (non nécessaire sur V14) : "cafe_exppw" image="<chemin>\exppw.dll"

Par exemple, sur Exchange V15, remplacez :

<add name="kerbauth" image="<chemin>\kerbauth.dll" />
<add name="exppw" image="<chemin>\exppw.dll" />
<add name="cafe_exppw" image="<chemin>\exppw.dll" />

Par ceci :

<add name="kerbauth" image="<chemin>\kerbauth.dll" preCondition="bitness64" />
<add name="exppw" image="<chemin>\exppw.dll" preCondition="bitness64" />
<add name="cafe_exppw" image="<chemin>\exppw.dll" preCondition="bitness64" />

Dans chaque section <isapiFilters>, trouvez et modifiez les entrées suivantes en ajoutant preCondition="bitness64" avant /> (sauf si déjà présent) :

• "Exchange OWA Cookie Authentication ISAPI Filter" path="<chemin>\owaauth.dll"

• "Exchange ActiveSync ISAPI Filter" path="<chemin>\AirFilter.dll"

Par exemple, sur Exchange V15, remplacez :

<filter name="Exchange OWA Cookie Authentication ISAPI Filter" path="<chemin>\owaauth.dll" enabled="true" />
<filter name="Exchange ActiveSync ISAPI Filter" path="<chemin>\AirFilter.dll" enabled="true" />

Par ceci :

<filter name="Exchange OWA Cookie Authentication ISAPI Filter" path="<chemin>\owaauth.dll" enabled="true" preCondition="bitness64" />
<filter name="Exchange ActiveSync ISAPI Filter" path="<chemin>\AirFilter.dll" enabled="true" preCondition="bitness64" />

Avec cet attribut de précondition, ces DLL ne seront pas chargées dans le pool d'applications 32 bits.

Sauvegardez et fermez le fichier.

Redémarrez IIS (commande iisreset) et relancez la console Web UserLock.

La console Web devrait maintenant fonctionner.

Si la même erreur persiste, d’autres modules peuvent nécessiter ce prérequis. Consultez le journal des applications dans l’Observateur d’événements Windows pour identifier les modules posant problème.

Autre solution :
Passer le pool d’applications UserLockAppPool en 64 bits. Mais nous ne recommandons pas cette option si vous utilisez la base de données MS Access (utilisée par défaut) qui ne permettra plus l’exécution des rapports depuis la console Web.

Cette erreur se produit car le service UserLock se connecte à la base de données en utilisant l’authentification Windows, alors que la base SQL Server de UserLock est hébergée sur un serveur différent de celui où est installée la console Web IIS, et que la délégation Kerberos n’est pas activée sur le serveur IIS pour permettre une authentification correcte vers le serveur de base de données.

Dans la console Web, tous les rapports et statistiques (par exemple les données affichées dans l’onglet Derniers jours du tableau de bord) seront vides. Vous retrouverez également ce message d’erreur dans le fichier de logs de l’application.

Voici la procédure pour configurer la délégation.

Remarque : Si le compte utilisé pour exécuter le service SQL Server est un Managed Service Account, cette procédure ne fonctionnera pas. La seule solution dans ce cas est de modifier la configuration du service UserLock pour utiliser l’authentification SQL au lieu de l’authentification Windows.

Sur le serveur de base de données, ouvrez la console Services Windows pour identifier le compte utilisé par le service SQL Server.

Dans cet exemple, le serveur hébergeant SQL Server est nommé VES2.VDE.intra et le service SQL Server s’exécute en tant que VDE\SQLServerSvc sur le port 1433.

Toujours sur le serveur de base de données, créez un SPN (Service Principal Name) pour l’instance SQL Server avec la commande suivante :

setspn -A MSSQLSvc/[NomServeur]:[PORT] [NomDuCompte]

Exemple:

setspn -A MSSQLSvc/VES2.VDE.intra:1433 VDE\SQLServerSvc

Une fois le SPN créé, activez la délégation pour le serveur IIS hébergeant la console Web UserLock dans Active Directory.

• Ouvrez la console Utilisateurs et ordinateurs Active Directory.

• Trouvez le serveur IIS hébergeant la console Web UserLock et ouvrez ses Propriétés. (Dans notre exemple, ce serveur est nommé VES1.)

• Allez dans l’onglet Délégation.

• Sélectionnez Faire confiance à cet ordinateur pour la délégation vers des services spécifiés uniquement et choisissez Utiliser n’importe quel protocole d’authentification.

• Cliquez sur Ajouter... pour enregistrer le service SQL Server.

• Dans la fenêtre Ajouter des services, cliquez sur Utilisateurs ou ordinateurs... et entrez le nom du compte de service SQL Server pour lequel vous avez défini le SPN (par exemple SQLServerSvc). Cliquez sur Vérifier les noms puis sur OK.

• La nouvelle entrée apparaîtra dans la liste. Sélectionnez-la et cliquez sur OK.

• Validez en cliquant sur OK ou Appliquer.

La console Web UserLock devrait maintenant pouvoir récupérer toutes les informations depuis la base de données.