Utilisation de profils Windows avec Password Manager et Single Sign-On
Cet article ne contient aucune information spécifique à Profile Management. Elle vous indique comment configurer certaines options Windows afin que Citrix Single Sign-On fonctionne de manière optimale avec des profils locaux, des profils itinérants, des profils obligatoires ou des profils hybrides. Cette rubrique s’applique à Citrix Single Sign-On 4.8 ou 5.0.
Profils locaux
Les profils locaux sont stockés sur le serveur local sur lequel l’utilisateur a ouvert une session. Password Manager et Single Sign-On enregistrent les informations du registre dans la ruche HKEY_CURRENT_USER\SOFTWARE\Citrix\MetaFrame Password Manager du registre de l’utilisateur située à l’emplacement suivant :
%LecteurSystème%\Documents and Settings\%NomUtilisateur%\NTUSER.DAT.
Les fichiers sont également enregistrés dans :
%LecteurSystème%\Documents and Settings\%NomUtilisateur%\Application Data\Citrix\MetaFrame Password Manager.
Sur Windows 7, Single Sign-On utilise :
%APPDATA%\Roaming\Citrix\MetaFrame Password Manager
Important : il est d’une importance critique que Single Sign-On dispose d’un d’accès total aux fichiers suivants :
| Nom du fichier | Description |
|---|---|
| %NomUtilisateur%.mmf | Fichier d’informations d’identification de l’utilisateur avec pointeurs vers le fichier aelist.ini. |
| entlist.ini | Fichier de définition d’application créé au niveau de l’entreprise au point de synchronisation ou Active Directory. |
| aelist.ini | Fichier de définition d’application créé en fusionnant le fichier de définition d’application de l’utilisateur local (applist.ini) et les définitions d’application d’entreprise (entlist.ini). |
Profils itinérants
Les profils itinérants sont enregistrés sur un partage réseau et synchronisés sur une copie locale du serveur chaque fois que l’utilisateur ouvre une session. La bonne réussite du déploiement d’un profil itinérant repose sur une connectivité réseau haut débit, telle qu’un réseau SAN ou NAS. Parmi les autres déploiements communs figurent les solutions de regroupement dans lesquelles les profils sont stockés sur des serveurs à haute disponibilité.
Deux problèmes affectent les déploiements des profils itinérants et obligatoires :
- Un profil itinérant unique ne peut être utilisé qu’avec un point de synchronisation de fichier. Lorsque plusieurs points de synchronisation sont utilisés, les données du fichier mappé à la mémoire (fichier MMF) risquent d’être altérées.
- Lorsque les profils itinérants sont utilisés avec des sessions simultanées, ils partagent le fichier mappé à la mémoire d’arrière-plan. Toutes les sessions actives ont en commun certaines données de session, telles que les compteurs de verrouillage de nouvelles tentatives, les compteurs de données sur les dernières utilisations et les entrées du journal des événements.
Profils obligatoires ou hybrides
Les profils obligatoires sont, par définition, des profils utilisateurs en lecture seule. Single Sign-On nécessite des autorisations en écriture sur le répertoire des profils sous le dossier Application Data. Avec les profils obligatoires, un utilisateur peut apporter des modifications, mais elles ne sont pas enregistrées sur le profil au moment de la fermeture de session. Pour que Single Sign-On fonctionne correctement avec les profils obligatoires, le dossier Application Data doit être redirigé.
Les modifications apportées au registre sont écrites chaque fois que l’utilisateur ouvre une session. Les informations d’identification sont synchronisées au point de synchronisation, mais les modifications ne sont pas enregistrées sur le profil.
À compter de Windows 2000, Microsoft fournit un mécanisme de redirection du dossier Application Data. Toutefois, l’utilisation des domaines Windows NT4 nécessite des scripts d’ouverture de session capables de modifier l’emplacement du dossier Application Data. Ceci peut se faire en utilisant des outils tels que Kix ou VBScript pour définir un emplacement accessible en écriture pour le dossier Application Data.
Vous trouverez ci-dessous un exemple dans lequel Kix est utilisé pour rediriger le dossier Application Data lors de l’ouverture de session par l’utilisateur :
Important : cet exemple de script est fourni à titre informatif uniquement. Ne l’utilisez pas dans votre environnement avant de le tester.
``` pre codeblock
$LogonServer = “%LOGONSERVER%” $HKCU = “HKEY_CURRENT_USER” $ShellFolders_Key = “$HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders” $UserShellFolders_Key = “$HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders” $UserProfFolder = “$LogonServer\profiles@userID” $UserAppData = “$LogonServer\profiles@userID\Application Data” $UserDesktop = “$LogonServer\profiles@userID\Desktop” $UserFavorites = “$LogonServer\profiles@userID\Favorites” $UserPersonal = “X:\My Documents” $UserRecent = “$LogonServer\profiles@userID\Recent” if (exist(“$UserAppData”) = 0) shell ‘%ComSpec% /c md “$UserAppData”’ endif if (exist(“$UserDesktop”) = 0) shell ‘%ComSpec% /c md “$UserDesktop”’ endif if (exist(“$UserRecent”) = 0) shell ‘%ComSpec% /c md “$UserRecent”’ endif if (exist(“$UserFavorites”) = 0) shell ‘%ComSpec% /c md “$UserFavorites”’ endif ```
Le profil hybride constitue une autre solution au problème du profil obligatoire. Lorsque l’utilisateur ouvre une session, le profil obligatoire se charge et une application personnalisée charge et décharge les ruches du registre utilisateur en fonction des applications disponibles pour l’utilisateur. L’utilisateur, à l’instar du scénario du profil obligatoire, est en mesure de modifier ces portions du registre pendant la session. La différence avec le profil obligatoire réside dans le fait que les modifications sont enregistrées lorsque l’utilisateur ferme une session et qu’elles sont rechargées lorsque l’utilisateur ouvre à nouveau une session.
Si un profil hybride est utilisé, les clés de registre HKEY_CURRENT_USER\SOFTWARE\Citrix\MetaFrame Password doivent être importées et exportées dans le cadre du processus d’ouverture et de fermeture de session.
Redirection de dossiers
La redirection de dossiers est mise en œuvre à l’aide des objets de stratégie de groupe et d’Active Directory. Elle utilise les stratégies de groupe pour définir un emplacement pour les dossiers qui font partie du profil utilisateur.
Quatre dossiers peuvent être redirigés :
- Mes documents
- Données d’application
- Bureau
- Menu Démarrer
Deux modes de redirection peuvent être configurés avec les stratégies de groupe : redirection de base et redirection avancée. Ces deux modes sont pris en charge par Single Sign-On. Dans Windows 2000, le partage où les données d’application sont stockées doit être référencé en utilisant la variable %username% (par exemple : \\servername\sharename\%username%).
La redirection de dossiers est générale pour l’utilisateur et elle affecte l’ensemble des applications de l’utilisateur. Toutes les applications qui utilisent le dossier Application Data doivent la prendre en charge.
Les articles Microsoft suivant peuvent être utiles pour en apprendre plus sur la redirection des dossiers :
Redirection de dossiers dans Windows
Accorder à l’administrateur l’accès aux dossiers redirigés
Recommandations
- Utilisez la redirection du dossier Application Data dans la mesure du possible. Cette approche permet d’améliorer les performances réseau, en éliminant le besoin de copier ces données chaque fois qu’un utilisateur ouvre une session.
- Lors de la résolution de problèmes avec l’Agent Password Manager, veillez à toujours vérifier que l’utilisateur connecté ait toujours les autorisations de contrôle total sur son propre dossier Application Data.