Configuration du cluster

Référence pour la mise à jour des chaînes de connexion et des informations d'identification SQL Server dans le fichier cluster_config.json dans Automation Suite.

Mise à jour de la connexion SQL Server

Pour mettre à jour la chaîne de connexion ou les informations d'identification sur SQL Server, modifiez directement le fichier cluster_config.json sur le nœud de serveur principal. Vous pouvez modifier directement les champs SQL (sql.username, sql.password et sql.server_url) dans le fichier en fonction de ce que vous devez mettre à jour.

Après avoir mis à jour le fichier, relancez l'assistant d'installation interactif sur la même machine avec la configuration mise à jour comme paramètre. Il vous suffit de relancer l'installation sur le serveur principal.

Mise à jour de l'authentification Kerberos

Pour mettre à jour la configuration d'authentification Kerberos globale et/ou la configuration d'authentification spécifique au service, reportez-vous à Configuration de l'authentification Kerberos via cluster_config.json.

Ajout d'administrateurs système

Un administrateur système est créé par défaut dans Automation Suite avec le nom d'utilisateur admin sur l'organisation hôte.

Si l'accès à l'organisation hôte est perdu - par exemple, si le mot de passe de l'administrateur système est perdu ou si les seuls utilisateurs disposant de comptes d'administrateur système quittent l'entreprise - il existe un outil pour ajouter ou restaurer un administrateur système.

Ce script ne fonctionne pas si le paramètre de chaîne de connexion SQL "Integrated Security=true" existe pour les services de plateforme.

./bin/uipathctl config add-host-admin --username [new-admin-username] --email [new-admin-email] --password [new-admin-password]

• Le champ --username est obligatoire.
• --password est requis uniquement si le nouvel administrateur utilise l'authentification de base pour se connecter.
• --email est facultatif sauf si votre fournisseur d'identité externe l'exige (par exemple, Google correspond en fonction de l'e-mail, pas du nom d'utilisateur).

Il existe quelques remarques importantes sur la façon dont l'administrateur est créé ou restauré :

• Les nouveaux administrateurs ne peuvent pas avoir le même nom d'utilisateur ou adresse e-mail qu'un administrateur existant. Si vous utilisez le même nom d'utilisateur ou adresse e-mail qu'un administrateur existant, l'administrateur existant est mis à jour. Ceci est utile si vous souhaitez modifier le mot de passe.
• Si un administrateur a été supprimé et que vous utilisez le même nom d'utilisateur ou e-mail pour un nouvel utilisateur, l'administrateur supprimé sera restauré au lieu d'en créer un nouveau. Le champ du mot de passe n'est pas écrasé dans ce cas. Un cas exceptionnel est si plusieurs administrateurs ont été supprimés avec le même nom d'utilisateur ou e-mail, ce qui entraîne la création d'un nouvel administrateur.
• Si l'un des fournisseurs d'identité externes configurés sur l'hôte est forcé, cela impose des restrictions sur les paramètres. Par exemple, si Windows AD est forcé, le nom d'utilisateur doit être sous la forme user@domain. Si Google est forcé, un e-mail est requis.
• Lors de la première connexion à un nouveau compte administrateur, le mot de passe doit être changé.

Réactivation de l'authentification de base

Les administrateurs de l'organisation et du système peuvent ne pas être en mesure de se connecter en raison d'un problème avec leur configuration Azure Active Directory ou un autre fournisseur d'identité externe. Les administrateurs de l'organisation peuvent être bloqués car l'indicateur Disable basic authentication est coché dans les paramètres d'authentification. Les administrateurs de l'organisation et du système peuvent être bloqués car un fournisseur d'identité externe a été configuré en tant que force/exclusive.

Cet outil tentera de réactiver l'authentification de base pour une organisation.

Ce script ne fonctionne pas si le paramètre de chaîne de connexion SQL Integrated Security=true existe pour les services de plateforme.

./bin/uipathctl config enable-basic-auth --orgname [org-name]

Remarque :

Le champ --orgname est obligatoire. Si l'authentification de base est restreinte au niveau de l'hôte, définissez le nom d'organisation sur host.

Mise à jour du protocole TLS

La passerelle d'entrée Istio configurée dans Automation Suite pour le routage, la communication entre les services, etc. utilise TLS pour sécuriser les échanges. Pour éviter toute menace de sécurité, les versions obsolètes du protocole TLS sont désactivées par défaut.

Seules les versions TLS 1.2 et supérieures sont actuellement prises en charge, et si vous utilisez une version précédente, il est recommandé de mettre à niveau. Cependant, il est toujours possible de se connecter à l'aide d'une version précédente de TLS, mais vous devez d'abord l'activer sur le serveur Automation Suite.

Important :

TLS 1.0 et 1.1 sont obsolètes, et l'activation de ces versions peut poser un risque de sécurité. Il est fortement recommandé de mettre à niveau vers TLS 1.2 ou supérieur au lieu d'activer des versions inférieures sur le serveur.

Pour activer une version TLS non prise en charge, suivez l'une des étapes suivantes :

• Pour activer la prise en charge de TLS 1.0 et versions ultérieures, exécutez la commande suivante :

  kubectl -n istio-system patch gateway main-gateway --type=json \
      -p='[{ "op": "replace", "path": "/spec/servers/0/tls/minProtocolVersion", "value": "TLSV1_0"}]'
  

• Pour activer la prise en charge de TLS 1.1 et versions ultérieures, exécutez la commande suivante :

  kubectl -n istio-system patch gateway main-gateway --type=json \
      -p='[{ "op": "replace", "path": "/spec/servers/0/tls/minProtocolVersion", "value": "TLSV1_1"}]'