Certaines permissions sont refusées aux utilisateurs de manière imprévue

Causes et solutions possibles :
  • La politique de sécurité
    Exiger des comptes d'ouverture de session sur tous les postes clients
     est définie sur
    Activé
     et l'utilisateur tente d'utiliser Remote Desktop Services pour accéder à distance à
    FactoryTalk
     Network Directory.
    Si les utilisateurs nécessitent l'accès à
    FactoryTalk
     Network Directory à l'aide de Remote Desktop Services, définissez la politique de sécurité
    Exiger des comptes d'ouverture de session sur tous les postes clients
     sur
    Désactivé
    .
    Vérifiez également le paramètre de politique correspondant à
    Identifier les clients des serveurs terminaux par le nom
    .
    • Si ce paramètre est défini sur
      Client terminal
      , tous les ordinateurs se connectant à Network Directory doivent disposer de comptes ordinateurs dans Network Directory pour pouvoir se connecter.
    • S'il est défini sur
      Ordinateur serveur
      , l'hôte Remote Desktop Session doit disposer d'un compte dans Network Directory pour que les clients se connectent.
  • Il existe des ensembles d'autorisations en conflit. Si des autorisations explicites conflictuelles sont définies, l'autorisation
    Refuser
     est prioritaire par rapport à
    Autoriser
    . Par exemple, si le groupe d'opérateurs se voit refuser explicitement l'accès à une application, mais que l'accès est explicitement accordé à l'application pour un compte utilisateur individuel (Jane), la permission Refuser est prioritaire sur Autoriser et Jane ne peut pas avoir accès à l'application car son compte utilisateur fait parti du groupe Opérateurs. Cela se produit parce que des permissions explicites conflictuelles sont définies dans la même ressource. Pour autoriser l'accès à l'application par Jane, vous devez refuser l'accès du groupe Opérateurs à une ressource dans un niveau supérieur de la hiérarchie (par exemple,
    FactoryTalk
     Network Directory ou
    FactoryTalk
     Local Directory dans laquelle se trouve l'application), puis autoriser explicitement les exceptions de l'application.
    Vérifiez les autorisations de l'utilisateur et des groupes auquel il appartient et modifiez-les selon les besoins pour autoriser l'accès.
  • Un utilisateur ayant un compte lié à
    Windows
     utilise un mot de passe vide. Les utilisateurs ne peuvent pas utiliser de mots de passe vides pour les comptes liés à
    Windows
     sans risquer de rencontrer des échecs intermittents de la sécurité ou une impossibilité de se connecter. Pour des raisons de sécurité, n'utilisez pas de mots de passe vierges avec les comptes.
    Dans la mesure du possible, l'utilisateur doit modifier son compte
    Windows
     pour utiliser un mot de passe. S'il existe une exigence opérationnelle selon laquelle les utilisateurs n'utilisent pas de mot de passe pour les comptes liés à
    Windows
    , sur l'ordinateur local de chaque utilisateur, désactivez la politique de sécurité locale
    Windows
    Comptes : Limiter l'utilisation de mots de passe vides aux comptes locaux pour la connexion à la console uniquement
  • Les modifications d'abonnement au groupe sont en attente pour un compte utilisateur.
    Si les abonnements au groupe d'un compte utilisateur ont été modifiés ou si un compte utilisateur a été ajouté à un compte groupe d'utilisateurs, l'utilisateur doit se déconnecter de
    FactoryTalk
     et se connecter à nouveau pour que les modifications prennent effet.
  • Un groupe d'actions a été supprimé au cours de la session utilisateur.
    Si un groupe d'actions a été supprimé, certaines autorisations rendues explicitement possibles par le groupe d'actions peuvent désormais être refusées à un utilisateur. Pour corriger ce problème, vous pouvez soit :
    • Recréez un groupe d'actions et réaffectez les autorisations à l'utilisateur et la ressource (des autorisations ne sont pas restaurées en recréant un groupe d'actions portant le même nom que le groupe d'actions supprimé).
    • Assignez les permissions requises à l'utilisateur ou le compte de groupe.
    • Si le groupe d'actions est utilisé par de nombreuses ressources, il peut être plus simple et rapide de restaurer
      FactoryTalk Directory
       à partir d'une sauvegarde, plutôt que de recréer le groupe d'actions et toutes ses autorisations.
  • Le groupe d'actions refuse explicitement les autorisations
    En cas d'utilisation de groupes d'actions, et de refus explicite d'autorisation à un groupe, comprenant des actions dont les utilisateurs ont besoin pour compléter des tâches, il convient de supprimer les actions affectées du groupe d'actions et de réinitialiser les autorisations pour ces actions.
  • Les autorisations ne sont pas définies après la restauration de
    FactoryTalk Directory
    , du dossier Système ou d'une application
    • En cas d'utilisation des comptes poste de travail local appartenant à un groupe de travail
      Windows
      , des comptes utilisateurs liés à
      Windows
       perdront leurs paramètres de sécurité. Cela se produit car l'identifiant unique associé au compte ne peut pas être joint à nouveau au compte restauré pour des raisons de sécurité. Une fois le compte lié à
      Windows
       restauré, les autorisations doivent être recréées. Pour éviter ce problème, utilisez des domaines
      Windows
       au lieu des groupes de travail.
    • En cas de restauration d'une application sans le dossier système correspondant dans un autre répertoire ou un répertoire sur un ordinateur différent, les autorisations de sécurité associées à l'application initiale ne seront plus effectives dans une application restaurée qui est associée à un dossier système différent. Les paramètres de sécurité inopérants sont indiqués par une icône d'utilisateur en grisé, suivie de l'ID unique du compte. Recréez ces autorisations après la restauration.
  • Les paramètres de sécurité ne sont pas configurés pour le répertoire
    Les paramètres de sécurité sont complètement différents dans Network Directory et Local Directory. Les modifications apportées aux paramètres de sécurité dans Network Directory n'affectent pas Local Directory et inversement. Si vous utilisez à la fois un Network Directory et un Local Directory, vous devez configurer la sécurité dans chaque répertoire séparément. En outre, assurez-vous que les utilisateurs se connectent au bon répertoire.
  • L'installation ou la mise à niveau de la version de
    FactoryTalk Services Platform
     sur un ordinateur client connecté à un serveur FactoryTalk Network Directory exécutant une version antérieure peut entraîner des résultats inattendus avec les applications
    Rockwell Automation
    . Cela est dû au fait que la version ultérieure de
    FactoryTalk Services Platform
     peut inclure de nouvelles politiques du produit ou de nouvelles actions sécurisables.
    Pour éviter ce problème, mettez à niveau le logiciel de la plate-forme
    FactoryTalk
     sur l'ordinateur hébergeant le serveur
    FactoryTalk
     Network Directory vers la même version que la dernière version de
    FactoryTalk Services Platform
     installée sur un ordinateur client quelconque de votre réseau.
Fournir une réponse
Vous avez des questions ou des commentaires sur cette documentation ? Veuillez envoyer vos commentaires ici.
Normal