> Tech > Détails de SSO sur Management Central

Détails de SSO sur Management Central

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Pour faire fonctionner SSO avec des applications Management Central, il faut d’abord configurer le système central et les systèmes point d’extrémité pour Kerberos et EIM. Cette étape est nécessaire, quelle que soit l’application à laquelle s’appliquera SSO (par exemple, NetServer au lieu de Management Central). Dans les sections suivantes, j’indique

Détails de SSO sur Management Central

plusieurs articles de scénarios utiles de Info Center pour vous guider dans ce travail de configuration.

Configurer vos systèmes i5/OS pour Kerberos. Pour utiliser Kerberos, vous devez d’abord établir un Kerberos KDC (Key Distribution Center) et définir un royaume Kerberos auquel appartiendront vos systèmes. Le KDC est le système qui contient les utilisateurs et mots de passe Kerberos et qui distribue et authentifie les tickets Kerberos. De nombreuses platesformes peuvent exécuter un KDC, dont Windows AIX et i5/OS V5R3 ; la configuration et la préparation dépendent de la plate-forme. Le scénario V5R3 Info Center « Set up Kerberos server in OS/400 PASE » montre comme établir un KDC dans PASE (Portable Application Solutions Environment) sur i5/OS V5R3. Une fois votre KDC en place et votre royaume défini, vous devez configurer vos systèmes i5/OS pour qu’ils utilisent ce KDC et ce royaume pour demander et authentifier les tickets Kerberos. Le scénario Info Center « Configure network authentication service » explique comment faire cela.

Configurer vos systèmes i5/OS pour EIM. Pour utiliser EIM, vous devez mettre en place un DC EIM et un domaine EIM auxquels vos systèmes appartiendront. Le DC EIM contient tous les EIM Identifiers et les associations entre les utilisateurs sur différents systèmes (par exemple, le profil utilisateur SAMJ sur le système MyBigSys est associé au profil utilisateur SJONES sur le système MySmallerSys). Une fois que vous avez établi le DC EIM et le domaine EIM, vous devez configurer vos systèmes i5/OS pour l’utilisation de ce domaine EIM. Le scénario Info Center « Enable single sign-on for OS/400 » explique comment faire cela.

Configurer Management Central pour l’utilisation de Kerberos et d’EIM. Une fois que vous avez configuré votre KDC et DC EIM et chacun de vos systèmes ou partitions i5/OS pour Kerberos et EIM, vous possédez la base nécessaire pour utiliser les fonctions SSO des diverses applications i5/OS. A partir de là, vous allez configurer de façon à ce que les fonctions SSO de ces applications (Management Central, NetServer, par exemple) fonctionnent de manière appropriée pour votre cas. Tout d’abord, configurez Management Central sur le système central et sur les systèmes d’extrémité, afin qu’ils utilisent Kerberos au lieu du nom et mot de passe utilisateur, pour l’authentification.

Configurer votre système central pour Kerberos. Votre système central essaie par défaut d’utiliser Kerberos pour l’authentification vers tout système d’extrémité qui le supporte. Le système central utilise le principal de service Kerberos i5/OS pour s’identifier lui-même sous la forme de krbsvr400/@. Dans cet exemple, est le nom DNS (par exemple, MyBigSys.mycompany.com) et est tout royaume Kerberos (comme BASEREALM) que vous avez établi quand vous avez configuré votre KDC et vos systèmes i5/OS pour Kerberos. Donc, le principal de service Kerberos par défaut de votre système central dans notre exemple est krbsvr400/ MyBigSys.mycompany.com@BASEREALM.

Vous pouvez définir ce principal Kerberos pour qu’il soit tout autre chose si vous le souhaitez (voir l’encadré « Configurer Management Central » pour plus d’informations sur la manière de changer la configuration). Quel que soit le principal que vous choisissez, vous devez l’ajouter (et un mot de passe) à votre KDC. Sur un KDC installé dans PASE sur un système i5/OS, vous devez démarrer le programme sur la ligne de commande PASE puis utiliser la commande ADDPRINC (Add Principal) pour ajouter le principal et le mot de passe. Les autres KDC utilisent des commandes similaires pour ajouter un principal.

Ensuite, ajoutez ces mêmes principal et mot de passe au fichier keytab du système central. Vous pouvez faire cela dans iSeries Navigator ou à partir de QShell sur un écran passif. Dans iSeries Navigator, allez à MyConnection|CENTRAL_ SYSTEM_NAME|Security|Network Authentication Service puis faites un clic droit sur Manage keytab. Dans QShell, entrez simplement la commande keytab add.

Une fois que vous avez ajouté le principal de service au KDC et au fichier keytab, le serveur Management Central sur votre système central est prêt à utiliser Kerberos. Pour vous en assurer, utilisez ENDTCPSVR *MGTC pour arrêter le serveur Management Central, attendez que le job QYPSJSVR se termine, puis utilisez STRTCPSVR *MGTC pour redémarrer le serveur. Ensuite, examinez le journal des jobs QYPSJSVR. Vous devriez voir un message du genre « Management Central is enabled as a (profiler/verifier) of protocol (x) » (Management Central est validé comme un (provider/vérificateur) de protocole (x)). Si votre système central est correctement configuré pour Kerberos, vous verrez « Management Central is enabled as provider of protocol 512 » (Management Central est validé comme un provider de protocole 512) signifiant que le système central fournira l’information Kerberos (qui est le protocole 512) aux systèmes d’extrémité. Si ce message n’apparaît pas, revoyez votre configuration.

Configurez vos systèmes d’extrémité pour Kerberos. Vos systèmes d’extrémité utilisent aussi le principal de service Kerberos krbsvr400/@ par défaut et, comme avec le système central, vous pouvez changer cet état par défaut. Il faut aussi ajouter tout principal que vous utilisez pour chaque système d’extrémité, à la fois au KDC et au fichier keytab pour ce système d’extrémité. Il faut aussi préciser que vous voulez que le système d’extrémité Management Central utilise Kerberos. Pour cela, mettez QYPS_KERBEROS_CONFIG à vrai (voir l’encadré « Configurer Management Central » pour plus d’informations à ce sujet). Après avoir configuré cela et redémarré le serveur Management Central, vous pouvez consulter le journal des jobs QYPSJSVR pour voir s’il contient le message « Management Central is enabled as verifier of protocol 512 » (Management Central est validé comme un vérificateur du protocole 512). Ce message indique que le système d’extrémité est prêt à « vérifier » les références Kerberos du système central.

Comme vous utilisez Kerberos pour authentifier le système central (au lieu d’utiliser le nom et le mot de passe utilisateur pour authentifier l’utilisateur), il faut aussi configurer quels systèmes centraux chaque système d’extrémité approuve. Vous pouvez faire cela soit en éditant manuellement le fichier trusted group du système d’extrémité, soit en donnant la valeur 1 à QYPS_TRUST_LEVEL, pour signifier que, pour l’instant, le point d’extrémité accepte toutes les connexions Kerberos en provenance des systèmes centraux et ajoute ces systèmes centraux au groupe approuvé. Dans les deux cas, une fois que votre groupe approuvé est défini, changez le QYPS_TRUST_LEVEL à 2, afin que le point d’extrémité n’autorise que les connexions approuvées.

Analyse de Kerberos dans Management Central. Prenons un moment pour bien analyser la situation actuelle après les opérations précédentes. Tout d’abord, vous avez configuré vos systèmes et partitions iSeries pour Kerberos et EIM. Ensuite, vous avez configuré votre système central Management Central et les points d’extrémité pour utiliser Kerberos chaque fois que c’est possible (c’est-à-dire, quand un système central V5R3 converse avec un système d’extrémité V5R3). Votre système d’extrémité authentifie d’abord le ticket Kerberos pour s’assurer que le système central est bien qui il prétend être, c’est-à-dire dans le cas présent, le principal de service krbsvr400/ MyBigSys. mycompany.com@BASEREALM Ensuite, votre système d’extrémité vérifie si ce principal Kerberos (ce système central) est dans sa liste approuvée. Si tout se passe bien, le point d’extrémité est convaincu que la requête vient bien d’un système central qu’il approuve et, dans cet exemple, le point d’extrémité lance le moniteur. Cette authentification Kerberos est utile en elle-même parce que, désormais, vous n’avez pas besoin du même profil avec le même mot de passe sur chacun de vos systèmes d’extrémité et sur votre système central.

Ajouter des entrées à votre DC EIM. Si nous nous arrêtons à l’étape précédente sans configurer EIM, le système d’extrémité détermine si la requête provient d’un système central valide et approuvé et exécute l’action comme l’utilisateur provenant du système central qui a fait la requête. Par conséquent, s’il est vrai que nous n’avons plus besoin de garder nos mots de passe synchronisés pour les applications Management Central en V5R3, nos profils utilisateur doivent encore être les mêmes. Toutefois, EIM procure un moyen d’exécuter la requête comme un utilisateur choisi sur le système d’extrémité, sans avoir besoin du même profil utilisateur sur chaque système.

EIM permet à la même personne, Sam Jones par exemple, d’avoir un profil utilisateur SAMJ sur MyBigSys, un profil utilisateur SJONES sur MySmallerSys, et un profil utilisateur SAMJ sur MySmallSys. Vous pouvez utiliser iSeries Navigator pour créer ces identificateurs et spécifier les profils utilisateur et systèmes associés (le scénario Info Center « Enable single sign-on for OS/400 » explique comment faire cela). Quand vous configurez vos systèmes pour EIM, ces identités et associations sont stockées sur votre DC EIM.

Pour que les applications Management Central puissent utiliser EIM, vous devez créer un identificateur EIM pour chaque utilisateur de Management Central. Cet identificateur a des associations avec un profil utilisateur sur le système central et un profil utilisateur sur chaque système d’extrémité. Quand Management Central est entièrement configuré pour EIM, votre système d’extrémité obtient le ticket Kerberos et le nom du profil utilisateur d’où provient la requête sur le système central. Le système d’extrémité MySmallerSys utilise Kerberos pour authentifier le ticket puis appelle une API EIM, laquelle extrait du DC EIM la réponse à la question « User profile SAMJ on MyBigSys is associated with which user profile on MySmallerSys? » (Le profil utilisateur SAMJ sur MyBigSys est associé avec quel profil utilisateur sur MySmallerSys ?). L’API renvoie SJONES dans notre exemple, et notre système d’extrémité exécute cette commande comme user SJONES, et ce bien que vous vous soyez connecté au système central comme SAMJ, bien qu’il n’y ait pas de profil SAMJ sur MySmallerSys.

Configurer votre système central et les systèmes d’extrémité pour EIM. Dans la mesure où vous établissez correctement votre DC EIM avec les identificateurs et associations nécessaires et que vous configurez EIM lui-même sur le système central pour qu’il pointe vers votre DC EIM, vous n’avez pas besoin de configurer des paramètres EIM spécifiques sur le système central. Tout ce que vous avez à faire sur vos systèmes d’extrémité (en supposant que les systèmes eux-mêmes soient configurés pour EIM et que les identificateurs et associations nécessaires aient été ajoutés) est de décider si vous voulez utiliser EIM sur votre système d’extrémité et, si vous utilisez EIM, quel paramètre EIM vous voulez.

Vous pouvez choisir entre trois paramètres EIM. Le premier est do not use. Le deuxième, use if identity exists (otherwise use profile), signifie que si une association EIM est trouvée (par exemple, le profil utilisateur SAMJ dans l’exemple précédent), utilisez-la ; sinon, utilisez le même profil utilisateur que le système central. Le troisième paramètre est require identity mapping, qui signifie que si une association est trouvée, utilisez-la, mais si une association n’est pas trouvée, faites échouer la tâche (n’essayez pas d’utiliser le même utilisateur que celui qui est sur le système central). La troisième option est la meilleure quand on veut s’assurer que seuls des profils spécifiques peuvent exécuter des tâches, des commandes et des moniteurs sur un système d’extrémité Management Central donné, et que ces profils viennent des associations EIM.

Si vous ne voulez pas utiliser EIM du tout, mettez la propriété QYPS_USE_ID_MAPPING à 0 (voir « Configurer Management Central »). Sinon, mettez-la à 1. Pour utiliser l’option use if identity exists, mettez QYPS_ID_MAPPING_ONLY à 0. Pour utiliser l’option require identity mapping, mettezla à 1.

EIM dans Management Central. EIM dispense d’employer des noms de profils utilisateur synchronisés sur les systèmes (de la même manière que Kerberos dispensait d’employer des mots de passe synchronisés sur nos profils utilisateur). Vous pouvez établir vos systèmes d’extrémité i5/OS de telle sorte qu’ils utilisent EIM pour déterminer quel profil peut exécuter les tâches et les moniteurs sur chaque système d’extrémité, et si cette association EIM ne peut pas être trouvée, vous pouvez spécifier soit de faire échouer la tâche, soit de revenir en arrière en utilisant le même profil utilisateur.

Téléchargez cette ressource

Guide inmac wstore pour l’équipement IT de l’entreprise

Guide inmac wstore pour l’équipement IT de l’entreprise

Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010