Aller au contenu principal

Authentification

Serveurs d'authentification pris en charge​

Le serveur d’authentification est un registre utilisateur utilisé pour authentifier les données d’identification de l’utilisateur. Lenovo XClarity Administrator prend en charge les types de serveurs d’authentification suivants.
  • Serveur d'authentification local. Par défaut, XClarity Administrator est configuré pour utiliser le serveur LDAP (Lightweight Directory Access Protocol) intégré qui réside sur le serveur de gestion.
  • Serveur LDAP externe. Actuellement, seulement Microsoft Active Directory et OpenLDAP sont pris en charge. Ce serveur doit se trouver sur un serveur Microsoft Windows externe connecté au réseau de gestion.

    Lorsqu'un serveur LDAP externe est utilisé, le serveur d'authentification local est désactivé.

    Avertissement
    Pour configurer la méthode de liaison d'Active Directory afin qu'elle utilise des données d'identification de connexion, le contrôleur de gestion de la carte mère de chaque serveur géré doit exécuter un microprogramme de septembre 2016 ou ultérieur.

  • Système de gestion d’identité externe. Actuellement, seul CyberArk est pris en charge.

    Si des comptes utilisateur destinés à un serveur ThinkSystem ou ThinkAgile sont intégrés à CyberArk, lors de la configuration initiale des serveurs pour la gestion (avec authentification gérée ou locale), XClarity Administrator peut recueillir les données d’identification auprès de CyberArk pour se connecter au serveur. Avant de pouvoir recueillir les données d’identification de CyberArk, les chemins d’accès à CyberArk doivent être définis dans XClarity Administrator. Une confiance mutuelle doit être établie entre CyberArk et XClarity Administrator à l’aide d’une authentification mutuelle TLS via des certificats clients.

  • fournisseur d'identité SAML externe. Actuellement, seul Microsoft Active Directory Federation Services (AD FS) est pris en charge. Outre la saisie d'un nom d'utilisateur et d'un mot de passe, l'authentification multifacteur peut être configurée pour offrir une sécurité accrue en exigeant un code PIN, la lecture d'une carte à puce et un certificat client.

    Lorsqu'un fournisseur d'identité SAML externe est utilisé, le serveur d'authentification local n'est pas désactivé. Les comptes utilisateur locaux sont requis pour se connecter directement à un châssis ou à un serveur géré (sauf si l'Encapsulation est activé sur cet appareil), pour l'authentification d'API REST et PowerShell, ainsi que pour la récupération si l'authentification externe n'est pas disponible.

    Vous pouvez choisir d'utiliser à la fois un serveur LDAP externe et un fournisseur d'identité externe. Si les deux sont activés, le serveur LDAP externe est utilisé pour se connecter directement aux appareils gérés, et le fournisseur d'identité est utilisé pour se connecter au serveur de gestion.

Pour plus d'informations sur les serveurs d'authentification, voir Gestion du serveur d'authentification.

Authentification d'appareil​

Par défaut, les appareils sont gérés par XClarity Administrator authentification gérée pour la connexion aux appareils. Lors de la gestion de serveurs rack et de châssis Lenovo, vous pouvez choisir d'utiliser l'authentification locale ou l'authentification gérée pour vous connecter aux appareils.

  • Lorsque l'authentification locale est utilisée pour les serveurs rack, les châssis Lenovo et les commutateurs d'armoire, XClarity Administrator utilise des données d'identification stockées pour l'authentification sur l'appareil. Les données d'identification stockées peuvent être un compte utilisateur actif sur l'appareil ou un compte utilisateur dans un serveur Active Directory.

    Vous devez créer des données d’identification stockées dans XClarity Administrator qui correspondent à un compte utilisateur active sur l’appareil ou un compte utilisateur dans un serveur Active Directory avant de gérer l’appareil à l’aide de l’authentification locale (voir Gestion de données d'identification stockées).

    Remarque

    • Les appareils RackSwitch prennent en charge uniquement les données d'identification stockées pour l'authentification. Les données d'identification utilisateur XClarity Administrator stockées ne sont pas prises en charge.

  • L'authentification gérée vous permet de gérer et de surveiller plusieurs appareils à l’aide des données d’identification dans le serveur d’authentification XClarity Administrator au lieu des données d’identification locales. Lorsqu'un appareil (autre que des serveurs ThinkServer, System x M4 et des commutateurs) est géré par authentification gérée, XClarity Administrator configure l'appareil géré et ses composants installés afin d'utiliser le serveur d'authentification XClarity Administrator pour la gestion centralisée.

    • Lorsque l’authentification gérée est activée, vous pouvez gérer des appareils à l’aide de saisies manuelles ou de données d’identification stockées (voir Gestion des comptes utilisateur, Gestion de données d'identification stockées).

      Les données d’identification stockées sont utilisées uniquement jusqu’à ce que XClarity Administrator configure les paramètres LDAP sur l’appareil. Ensuite, toute modification apportée aux données d’identification stockées n’a aucun impact sur la gestion ou la surveillance de cet appareil.

      Remarque
      Lorsque l’authentification gérée est activée pour un appareil, vous ne pouvez pas modifier les données d’identification stockées pour cet appareil à l’aide de XClarity Administrator.

    • Si un serveur LDAP local ou externe est utilisé comme serveur d'authentification XClarity Administrator, les comptes utilisateur définis dans le serveur d'authentification sont utilisés pour se connecter à XClarity Administrator, aux modules CMM et aux contrôleurs de gestion de la carte mère dans le domaine XClarity Administrator. Les CMM locaux et les comptes utilisateur du contrôleur de gestion sont désactivés.

    • Si un fournisseur d'identité SAML 2.0 est utilisé comme serveur d'authentification XClarity Administrator, les comptes SAML ne sont pas accessibles pour les appareils gérés. Cependant, lorsque vous utilisez un fournisseur d'identité SAML et un serveur LDAP ensemble et que le fournisseur d'identité utilise des comptes qui existent dans le serveur LDAP, les comptes utilisateur LDAP peuvent être utilisés pour se connecter à des appareils gérés, tandis que des méthodes d'authentification plus avancées qui sont fournies par SAML 2.0 (comme l'authentification à plusieurs facteurs et la connexion unique) peuvent être utilisées pour la connexion à XClarity Administrator.

    • L'authentification unique permet à un utilisateur qui est déjà connecté à XClarity Administrator de se connecter automatiquement au contrôle de gestion de la carte mère. La connexion unique est activée par défaut lorsqu’un serveur ThinkSystem ou ThinkAgile est amené dans la gestion par XClarity Administrator (sauf si le serveur est géré avec des mots de passe CyberArk). Vous pouvez configurer le paramètre global pour activer ou désactiver la connexion unique pour tous les serveurs ThinkSystem et ThinkAgile gérés. L'activation de la connexion unique pour un serveur ThinkSystem et ThinkAgile remplace le paramétrage global pour tous les serveurs ThinkSystem et ThinkAgile (voir Gestion des serveurs).

      Remarque
      La connexion unique est automatiquement désactivée lorsque vous faites appel au système de gestion d’identité CyberArk pour vous connecter.

    • Lorsque l'authentification gérée est activée pour les serveurs ThinkSystem SR635 et SR655 :

      • Le microprogramme du contrôleur de gestion de la carte mère prend en charge jusqu'à cinq rôles utilisateur LDAP. XClarity Administrator ajoute ces rôles utilisateur LDAP aux serveurs lors de la gestion : lxc-supervisor, lxc-sysmgr, lxc-admin, lxc-fw-admin et lxc-os-admin.

        Les utilisateurs doivent être affectés à au moins l'un des rôles utilisateur LDAP spécifiés pour pouvoir communiquer avec les serveurs ThinkSystem SR635 et SR655.

      • Le microprogramme du contrôleur de gestion ne prend pas en charge les utilisateurs LDAP dont le nom d'utilisateur est identique à celui de l'utilisateur local du serveur.

    • Pour les serveurs ThinkServer et System x M4, le serveur d'authentification XClarity Administrator n'est pas utilisé. À la place, un compte IPMI est créé sur l'appareil avec le préfixe «  LXCA_  » suivi d'une chaîne aléatoire. (Les comptes utilisateur IPMI locaux ne sont pas désactivés.) Lorsque vous annulez la gestion d'un serveur ThinkServer, le compte utilisateur «  LXCA_  » est désactivé, et le préfixe «  LXCA_  » est remplacé par le préfixe «  DISABLED_  ». Pour déterminer si un serveur ThinkServer est géré par une autre instance, XClarity Administrator recherche les comptes IPMI ayant le préfixe «  LXCA_  ». Si vous choisissez de forcer la gestion d'un serveur ThinkServer géré, tous les comptes IPMI sur l'appareil avec le préfixe «  LXCA_  » sont désactivés et renommés. Pensez à supprimer manuellement les comptes IPMI qui ne sont plus utilisés.

      Si vous utilisez des données d'identification saisies manuellement, XClarity Administrator crée automatiquement des données d'identification stockées et utilise ces dernières pour gérer l'appareil.

      Remarque
      Lorsque l’authentification gérée est activée pour un appareil, vous ne pouvez pas modifier les données d’identification stockées pour cet appareil à l’aide de XClarity Administrator.

      • Chaque fois que vous gérez un appareil en utilisant des données d'identification saisies manuellement, de nouvelles données d'identification stockées sont créées pour cet appareil, même si d'autres données d'identification stockées ont été créées pour cet appareil lors d'un processus de gestion précédent.

      • Lorsque vous annulez la gestion d'un appareil, XClarity Administrator ne supprime pas les données d’identification stockées qui ont été créées automatiquement pour cet appareil lors du processus de gestion.

Compte utilisateur de récupération​

Si vous spécifiez un mot de passe de récupération, XClarity Administrator désactive le CMM local ou compte utilisateur du contrôleur de gestion et crée un nouveau compte utilisateur de récupération (RECOVERY_ID) sur l'appareil à des fins d'authentification ultérieure. Si le serveur de gestion échoue, vous pouvez utiliser le compte RECOVERY_ID pour vous connecter à l'appareil et prendre des mesures de récupération nécessaires pour restaurer les fonctions de gestion des comptes sur l'appareil jusqu'à ce que le nœud de gestion soit restauré ou remplacé.

Si vous annulez la gestion d'un appareil qui possède un compte utilisateur RECOVERY_ID, tous les comptes utilisateur locaux sont activés, et le compte RECOVERY_ID est supprimé.

Remarques
  • Si vous modifiez les comptes utilisateur locaux désactivés (par exemple, si vous modifiez un mot de passe), les modifications n'ont aucune incidence sur le compte RECOVERY_ID. En mode d'authentification gérée, le compte RECOVERY_ID est le seul compte utilisateur activé et opérationnel.
  • Vous ne devez utiliser le compte RECOVERY_ID qu'en cas d'extrême nécessité, par exemple si le serveur de gestion échoue ou si un problème réseau empêche l'appareil de communiquer avec XClarity Administrator pour authentifier des utilisateurs.
  • Le mot de passe RECOVERY_ID est spécifié lorsque vous découvrez l'appareil. Veillez à noter ce mot de passe pour un usage ultérieur.

Pour plus d'informations sur la récupération de la gestion des dispositifs, voir Reprise de la gestion avec un module CMM après une défaillance du serveur de gestion, Récupération de la gestion du serveur au format tour après une défaillance du serveur de gestion.