Comment configurer l'authentification IBM MQ: OS et LDAP

5 août 2019.

Authentification d'utilisateur IBM MQ

Un gestionnaire de files d'attente IBM MQ peut être configuré pour authentifier les utilisateurs qui se connectent. Mais il ne conserve pas de liste d'utilisateurs ni de mots de passe. C'est la fonctionnalité que MQ laisse aux ressources externes. Vous pouvez choisir entre deux options:

1. Authentification à l'aide du système d'exploitation
2. Authentification à l'aide d'un protocole LDAP (Lightweight Directory Access Protocol)

Dans cet article, nous allons parler des deux. Certains paramètres sont communs à ces deux méthodes et sont décrits dans la présente section:

ADOPTCTX – Il convient d'adopter ou non le contexte

Les clients MQ envoient des ID utilisateur et des mots de passe pour l'authentification à l'aide d'une structure de données appelée MQCSP ( Paramètres de sécurité de la connexion MQ).

Il est généralement renseigné dans le code par programmation si vous avez un client personnalisé ou sur une page de configuration si vous avez une application fournisseur (telle que WebSphere Application Server, par exemple).

Un autre ID utilisateur que les clients MQ envoient au serveur. Il est différent de ce qui est envoyé dans MQCSP. Cet ID utilisateur est l'ID utilisateur sous lequel l'application client est exécutée.

Supposons que vous vous connectiez à votre machine Linux avec votre ID utilisateur personnel: mike123 puis que vous compiliez votre application Java MQ à l'aide de javac. puis exécutez-le en utilisant JRE. Dans l'application, vous remplissez une table de hachage avec les paramètres de connexion MQ, parmi lesquels figurent un ID utilisateur et un mot de passe de compte de service pour votre application, autorisés à accéder aux objets du gestionnaire de files d'attente auquel vous vous connectez. Cet ID utilisateur de compte de service est app456 .

Le gestionnaire de files d'attente recevra les deux éléments suivants: mike123 et app456. Il utilisera app456 pour l'authentification (son mot de passe sera vérifié), mais la prochaine étape sera déterminée par le paramètre ADOPTCTX.

S'il est défini sur YES l'ID utilisateur dans MQCSP sera utilisé. pour les contrôles d'autorisation, affichés sur les écrans et apparaissant dans les messages (il s'agira de l'utilisateur qui met et récupère des messages ou de la publication / sub) Le gestionnaire de file d'attente n'adopte cet ID utilisateur qu'après s'être authentifié avec succès.

S'il est défini sur NO l'ID utilisateur sous lequel l'application est exécutée sera utilisé pour les contrôles d'autorisation et pour les étapes ultérieures. 19659009] Notez que l'authentification est TOUJOURS effectuée sur la paire ID utilisateur MQCSP et mot de passe.

Un exemple plus compliqué doit être présenté ici pour les applications .NET. Sous Windows, les applications s'exécutent sous des ID utilisateur connectés à la machine. Vous pouvez modifier cela en configurant votre application pour qu'elle s'exécute en tant que service. Dans ce cas, elle s'exécutera sous un compte de service ou en utilisant l'option «Exécuter en tant que…». Pour envoyer un ID utilisateur et un mot de passe dans MQCSP, vous devez utiliser une technique .NET appelée emprunt d'identité .

Une autre remarque à faire est que Linux ne sait pas ce qu'est un domaine Windows, c'est sensible à la casse lorsqu'il s'agit d'ID utilisateur et vérifie uniquement les 12 premiers symboles de l'ID utilisateur. Les comptes Administrateur Windows, ADMINISTRATOR et administrateur (tous identiques sous Windows) deviennent Administrato, ADMINISTRATO et administrato (tous distincts sous Linux).

CHCKCLNT – Authentification des connexions client et procédure à suivre

Une connexion client est toujours faite sur un canal. Une connexion locale est établie en mode de liaison en liant directement aux bibliothèques de serveur. Une connexion MQ Explorer est une connexion client. Une connexion runmqsc est une connexion locale.

NONE – Aucune vérification d'ID utilisateur et de mot de passe n'est effectuée. Si un ID utilisateur ou un mot de passe est fourni par une application cliente, les informations d'identification sont ignorées. En principe, aucune authentification n'est effectuée par MQ.

FACULTATIF – Les applications clientes ne sont pas tenues de fournir un ID utilisateur et un mot de passe. Toutes les applications qui fournissent un ID utilisateur et un mot de passe dans la structure MQCSP les authentifient par le gestionnaire de files d'attente. La connexion ne peut continuer que si l'ID utilisateur et le mot de passe sont valides. J'ai parlé de ce paramètre dans l'article précédent du blog. Ce paramètre CHCKCLNT est le paramètre global au niveau du gestionnaire de files d'attente. Ce paramètre est le comportement par défaut, mais il peut être écrasé par un enregistrement d'authentification de canal sur chaque canal. Si vous prévoyez que certaines applications de votre infrastructure ne pourront pas transmettre un ID utilisateur et un mot de passe (applications héritées, applications de fournisseur prenant en charge les anciennes versions de MQ, code personnalisé que personne ne touchera), vous pouvez définir CHCKCLNT sur FACULTATIF ici. , définissez CHCKCLNT sur ASQMGR sur les canaux des applications ne pouvant pas transmettre un ID utilisateur et un mot de passe, et définissez CHCKCLNT sur REQUIRED sur les canaux des applications pouvant envoyer un ID utilisateur et un mot de passe.

REQUIRED ] – Toutes les applications client doivent fournir un ID utilisateur et un mot de passe dans la structure MQCSP. Ce nom d'utilisateur et mot de passe sont authentifiés par le gestionnaire de files d'attente.

La connexion ne sera autorisée à continuer que si l'ID utilisateur et le mot de passe sont valides.

REQDADM – Toutes les applications client utilisant un utilisateur privilégié ID (tel que mqm) doit fournir un ID utilisateur et un mot de passe dans la structure MQCSP. Les applications utilisant un ID utilisateur non privilégié ne sont pas tenues de fournir un ID utilisateur et un mot de passe et sont traitées comme avec le paramètre OPTIONAL.

Tous les ID et mot de passe fournis sont authentifiés par le gestionnaire de files d'attente. La connexion ne peut continuer que si l'ID utilisateur et le mot de passe sont valides.

Toutes les combinaisons de CHCKCLNT au niveau du gestionnaire de files d'attente et de CHCKCLNT au niveau du canal ne sont pas possibles. Une exception notable est la définition de CHCKCLNT sur NONE sur le gestionnaire de files d'attente et la définition de CHCKCLNT sur REQUIRED sur le canal. Une telle connexion échouera avec AMQ9793.

CHCKLOCL – vérification des connexions locales

Une connexion locale se produit en mode de liaison et ne comporte pas de canal. Par exemple, lorsque vous vous connectez à la boîte où le gestionnaire de files d'attente est en cours d'exécution et que vous tapez «runmqsc» dans la fenêtre du terminal, vous établissez une connexion locale.

NONE – Aucune vérification de l'ID utilisateur et du mot de passe. sont faits. Si un ID utilisateur ou un mot de passe est fourni par une application liée localement, les informations d'identification sont ignorées.

FACULTATIF – Les applications liées localement ne sont pas tenues de fournir un ID utilisateur et un mot de passe. Toutes les applications qui fournissent un ID utilisateur et un mot de passe dans la structure MQCSP les authentifient par le gestionnaire de files d'attente. La connexion ne peut continuer que si l'ID utilisateur et le mot de passe sont valides.

REQUIRED – Toutes les applications liées localement doivent fournir un ID utilisateur et un mot de passe dans la structure MQCSP. Cet ID utilisateur et ce mot de passe seront authentifiés par le gestionnaire de files d'attente. La connexion ne sera autorisée que si l'ID utilisateur et le mot de passe sont valides.

REQDADM – Toutes les applications liées localement utilisant un ID utilisateur privilégié doivent fournir un ID utilisateur et un mot de passe dans la structure MQCSP. Les applications liées localement utilisant un ID utilisateur non privilégié ne sont pas tenues de fournir un ID utilisateur et un mot de passe et sont traitées comme si elles étaient associées au paramètre OPTIONAL.

Tous les ID et mot de passe fournis seront authentifiés par le gestionnaire de files d'attente. La connexion ne sera autorisée à continuer que si l'ID utilisateur et le mot de passe sont valides.

Exemple: vous définissez CHCKLOCL sur REQUIRED, puis vous tapez «runmqsc MYQMGR». Vous obtiendrez une erreur, car vous devez vous authentifier pour une connexion locale. Pour ce faire, exécutez la commande suivante: «runmqsc MYQMGR -u ». Vous serez invité à entrer votre mot de passe. Notez que si vous utilisez l'indicateur -c, votre connexion deviendra une connexion client et le gestionnaire de files d'attente vérifiera plutôt le paramètre dans CHCKCLNT.

FAILDLAY – délai d'attente d'échec

Lorsqu'un ID utilisateur et un mot de passe sont fournis pour la connexion l’authentification, et l’authentification échoue car l’ID utilisateur ou le mot de passe est incorrect. Il s’agit du délai, en secondes, avant que l’échec ne soit renvoyé à l’application. Cela peut aider à éviter les boucles occupées d'une application qui tente simplement, de manière continue, après avoir reçu un échec. La valeur doit être comprise entre 0 et 60 secondes. La valeur par défaut est 1.

Authentification à l'aide du système d'exploitation

Il s'agit de la méthode d'authentification par défaut. Les versions ultérieures de MQ sont préconfigurées pour ce type d'authentification, prêtes à l'emploi (lorsque vous créez un gestionnaire de files d'attente). . La commande permettant de créer un objet d'authentification est la suivante:

DEFINE AUTHINFO ( nom ) AUTHTYPE ( IDPWOS )

ADOPTCTX ( NON | OUI )

CHCKCLNT ( FACULTATIF | REQDADM | NONE | REQUIS )

CHCKLOCL ( OPDALD | | NONE | REQUIS )

FAILDLAY ( 1 | entier )

Description des paramètres ci-dessous.

nom – nom de l'objet d'authentification

AUTHTYPE (IDPWOS) – le type d'authentification est "le nom d'utilisateur et le mot de passe sont vérifiés par le système d'exploitation".

ADOPTCTX CHCKCLNT CHCKLOCL et FAILDLAY sont décrits ci-dessus.

L'objet par défaut créé et activé sur les nouveaux gestionnaires de files d'attente est configuré comme suit s:

AUTHINFO (SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE (IDPWOS) ADOPTCTX (NO)
CHCKCLN [1945] (REDD). ) CHCKLOCL (FACULTATIF) FAILDLAY (1)

Authentification à l'aide de LDAP

Nous examinerons ensuite la méthode d'authentification LDAP. La plupart de ces paramètres seront très familiers aux administrateurs de serveurs LDAP. Si vous pouvez demander leur aide, faites-le. MQ prend en charge l'authentification dans tout produit logiciel conforme aux protocoles LDAP v2 ou v3 (MS AD, IBM Tivoli, LDAP UNIX, Centrify, etc.)

J'utiliserai les deux exemples suivants pour illustrer. Les exemples sont basés sur une configuration LDAP UNIX d’un projet réel:

Entrée de groupe dans UNIX LDAP:

dn: cn = mq_users, ou = groupe, dc = unix, dc = org, dc = com

memberUid: mq_user

memberUid: mike670

memberUid: jill588

memberUid: sam025

objectClass: posixGroup

objectClass: ] Entrée utilisateur sous UNIX LDAP:

dn: uid = mik123, ou = People, dc = unix, dc = org, dc = com

memberOfNetgroup: cn = auth_group1, ou = Netgroup, dc = unix, dc = org, dc = com

memberOfNetgroup: cn = sudo_group2, ou = groupe de réseaux, dc = unix, dc = org, dc = com

memberOfNetgroupShortName: auth_group1

memberOfNetgroupShorturity: memberOf: cn = mike123, ou = groupe, dc = unix, dc = org, dc = com

memberOf: cn = mq_users, ou = groupe, dc = org, dc = com

memberOfShortName: mike123

memberOfShortName: mq_users

objectClass: top

objectClass: personne [19659009] objectClass: inetorgperson

objectClass: inetUser

objectClass: organizationPerson

objectClass: posixAccount

objectClass: shadowAccount

DEFINE AUTHINFO (nom) AUTHTYPE (IDPWLDAP)

ADOPTCTX (ID | W ONS)

ADOPTCTX (ID | (OS | SEARCHGRP | SEARCHUSR | SRCHGRPSN)

BASEDNG (chaîne) BASEDNU ('' | chaîne)

CLASSGRP (chaîne) CLASSUSR ('inetOrgPerson' | string)

GRPFIELD (string) USRFIELD ('' | | string)

FINDGRP (chaîne) NESTGRP (YES | NO) SHORTUSR (chaîne)

CHCKCLNT (REQDADM | NONE | OPTIONAL | NOMBRE | OPTIONNEL | REQUIRED)

. CHCKLOCL (RE QDADM | NONE | FACULTATIF | REQUIS)

FAILDLAY (1 | entier)

CONNAME (chaîne) LDAPPWD ('| chaîne) ['| LDAPUSER ('' | string) SECCOMM (NO | YES | ANON)

Description des paramètres ci-dessous.

nom – nom pour cet objet d'authentification

AUTHTYPE (IDPWLDAP) – l'ID utilisateur et le mot de passe seront envoyés à LDAP pour l'authentification. Notez que MQ ne vérifie rien, il reçoit une réponse du serveur LDAP.

ADOPTCTX – décrit ci-dessus.

AUTHORMD – Méthode d'autorisation. Ce paramètre indique au serveur LDAP comment il doit ressembler à l'utilisateur que MQ envoie.

OS – Utilisez des groupes de systèmes d'exploitation pour déterminer les autorisations associées à un utilisateur. C’est ainsi que fonctionnait précédemment IBM MQ.

SEARCHGRP – Une entrée de groupe dans le référentiel LDAP contient un attribut indiquant le nom unique de tous les utilisateurs appartenant à ce groupe. L'appartenance est indiquée par l'attribut défini dans FINDGRP. Cette valeur est généralement member ou uniqueMember. Comme vous pouvez le voir dans notre exemple d'entrée de groupe ci-dessus, la valeur FINDGRP sera «memberUid».

SEARCHUSR – Une entrée utilisateur dans le référentiel LDAP contient un attribut indiquant le nom unique de tous les groupes auxquels il est associé. l'utilisateur spécifié appartient. L'attribut à interroger est défini par la valeur FINDGRP, généralement memberOf. Dans notre exemple d'entrée d'utilisateur ci-dessus, FINDGRP sera memberOf. Comme vous pouvez le constater, un utilisateur peut être membre de deux types de groupes: un groupe réseau et un groupe posix (ou simplement appelé groupe). Dans cet exemple, nous voulons vérifier si un utilisateur appartient au groupe mq_users et si tous les groupes créés pour l'appartenance à MQ sont créés en tant que posixGroups, nous utilisons donc «memberOf». Si nous contrôlions l’appartenance à un groupe réseau (ce qui est très peu probable dans un scénario réel), nous aurions utilisé «memberOfNetgroup» comme FINDGRP.

SRCHGRPSN – 9.1.0 uniquement. Une entrée de groupe dans le référentiel LDAP contient un attribut répertoriant le nom d'utilisateur abrégé de tous les utilisateurs appartenant à ce groupe. L'attribut de l'enregistrement utilisateur qui contient le nom d'utilisateur abrégé est spécifié par SHORTUSR. L'appartenance est indiquée par l'attribut défini dans FINDGRP. Cette valeur est typiquement memberUid. Cette méthode d'autorisation ne doit être utilisée que si tous les noms abrégés d'utilisateurs sont distincts.

Un nom d'utilisateur abrégé est simplement le nom d'utilisateur sans le qualificatif. Il est différent du nom distinctif (DN) qui est complet et donc unique. En regardant notre exemple d'entrée de groupe, nous voyons que les noms d'utilisateur abrégés sont situés dans le champ «memberUid». Notre exemple n’a pas de champ pour les DN d’utilisateurs. Ce type de configuration peut en réalité être valide, étant donné que tous les ID utilisateur courts sont distincts. La valeur du champ SHORTUSR dans notre exemple d'utilisateur serait «uid».

De nombreux serveurs LDAP utilisent un attribut de l'objet groupe pour déterminer l'appartenance à un groupe. Vous devez donc définir cette valeur sur SEARCHGRP. Microsoft Active Directory stocke généralement les appartenances aux groupes sous forme d'attribut d'utilisateur. IBM Tivoli Directory Server prend en charge les deux méthodes. En règle générale, l'extraction des appartenances via un attribut d'utilisateur sera plus rapide que la recherche de groupes répertoriant l'utilisateur en tant que membre.

BASEDNG – DN de base pour les groupes. DN est le nom distinctif. Il consiste en un nom commun (cn) suivi de toute la hiérarchie des objets, comme cn =…, ou =…, dc =…, dc =…, dc =… Pour pouvoir rechercher des noms de groupes, ce paramètre doit: être défini avec le DN de base pour rechercher des groupes sur le serveur LDAP. En regardant notre exemple ci-dessus, nous cherchons dn: et voyons que la base est “ou = Groupe, dc = unix, dc = org, dc = com”

BASEDNU – DN de base pour les utilisateurs . Pour pouvoir trouver l'attribut de nom d'utilisateur abrégé (voir SHORTUSR), ce paramètre doit être défini avec le DN de base pour rechercher des utilisateurs sur le serveur LDAP. Dans notre exemple ci-dessus, recherchez dn: et vous verrez que le DN de base est clairement «ou = Personnes, dc = unix, dc = org, dc = com»

CLASSGRP – Le LDAP classe d'objet utilisée pour les enregistrements de groupe dans le référentiel LDAP

En plus du nom distinctif, chaque objet de LDAP a une classe qui représente le niveau auquel cet objet existe dans la hiérarchie LDAP. Si nous regardons notre exemple de groupe ci-dessus, nous pouvons clairement voir que la classe supérieure de la hiérarchie est «top» et que notre objet group est juste en dessous dans la classe «posixGroup». GroupOfUniqueNames ou group sont d'autres valeurs couramment utilisées. Si la valeur est vide, on utilise groupOfNames.

CLASSUSR – Classe d'objet LDAP utilisée pour les enregistrements utilisateur dans le référentiel LDAP. Regardez notre exemple ci-dessus et remarquez que la hiérarchie des utilisateurs commence à la classe «top» et descend à la classe «shadowAccount». Comme ces exemples sont tirés de la vie réelle, il a été déterminé par essais et erreurs que la classe appropriée pour les utilisateurs est «inetorgperson» et non «shadowAccount». Si vide, la valeur par défaut est inetOrgPerson, qui correspond généralement à la valeur requise. Pour Microsoft Active Directory, la valeur requise est souvent l'utilisateur.

GRPFIELD – Attribut LDAP qui représente un nom simple pour le groupe.

Si la valeur est vide, les commandes telles que setmqaut doivent utiliser nom qualifié pour le groupe. La valeur peut être un DN complet ou un seul attribut. Notre exemple ci-dessus montre que GRPFIELD pour un groupe posix est «cn».

USRFIELD – Attribut LDAP qui représente un nom simple pour l'utilisateur. Si l'ID utilisateur fourni par une application pour l'authentification ne contient pas de qualificateur pour le champ de l'enregistrement d'utilisateur LDAP, c'est-à-dire qu'il ne contient pas de signe égal (=), cet attribut identifie le champ de l'enregistrement d'utilisateur LDAP qui est utilisé pour interpréter l'ID utilisateur fourni. Ce champ peut être vide. Si tel est le cas, tout ID utilisateur non qualifié utilise le paramètre SHORTUSR pour interpréter l'ID utilisateur fourni. Le contenu de ce champ sera concaténé avec le signe "=", ainsi que la valeur fournie par l’application, pour former l’ID utilisateur complet devant figurer dans un enregistrement d’utilisateur LDAP. Par exemple, l'application fournit un utilisateur de fred et que ce champ a la valeur cn, le référentiel LDAP sera recherché pour cn = fred. Dans notre exemple, il s'agit à nouveau de «uid».

FINDGRP – Nom de l'attribut utilisé dans une entrée LDAP pour déterminer l'appartenance à un groupe.

Lorsque AUTHORMD = SEARCHGRP, l'attribut FINDGRP est généralement défini sur member ou uniqueMember.

Lorsque AUTHORMD = SEARCHUSR, l'attribut FINDGRP est généralement défini sur memberOf.

9.1.0 uniquement – Lorsque AUTHORMD = SRCHGRPSN, l'attribut FINDGRP est généralement défini sur memberUid.

Lorsque l'attribut FINDGRP est attribué à. est laissé vide:

Si AUTHORMD = SEARCHGRP, l'attribut FINDGRP est défini par défaut sur memberOf.

Si AUTHORMD = SEARCHUSR, l'attribut FINDGRP est défini sur membre.

9.1.0 uniquement – Si AUTHORMD = SRCHGRPSN, l'attribut FINDGRP

NESTGRP – Nidification de groupe

NO – Seuls les groupes découverts initialement sont considérés pour autorisation.

OUI – La liste de groupes est recherchée récursivement pour enu Tous les groupes auxquels appartient un utilisateur.

Le nom distinctif du groupe est utilisé lors de la recherche récursive de la liste des groupes, quelle que soit la méthode d'autorisation sélectionnée dans AUTHORMD.

Ce paramètre détermine si vous souhaitez autoriser l'imbrication d'autorisations. Exemple:

Le groupe mq_admins contient trois utilisateurs pouvant créer des gestionnaires de files d'attente de création et de suppression.

Le groupe mq_support contient quatre utilisateurs pouvant modifier les attributs des files d'attente. Il contient également des groupes mq_admins, ce qui signifie que les trois utilisateurs de mq_admins obtiennent également des autorisations de mq_support.

Le groupe mq_users est autorisé à parcourir les messages. De plus, elle contient le groupe mq_support.

Cette configuration permet aux utilisateurs de mq_users de naviguer uniquement, aux utilisateurs de mq_support de parcourir et de modifier les attributs de la file d’attente, et aux utilisateurs de mq_admins d’avoir le droit de parcourir, de modifier les attributs de la file d’attente, ainsi que de créer et de supprimer leurs gestionnaires. 19659009] SHORTUSR – Un champ de l'enregistrement utilisateur à utiliser comme nom d'utilisateur abrégé dans IBM MQ.

Ce champ doit contenir des valeurs inférieures ou égales à 12 caractères. Ce nom d'utilisateur abrégé est utilisé aux fins suivantes:

Si l'authentification LDAP est activée, mais que l'autorisation LDAP ne l'est pas, elle est utilisée comme ID utilisateur du système d'exploitation pour les contrôles d'autorisation. Dans ce cas, l'attribut doit représenter un ID utilisateur du système d'exploitation.

Si l'authentification et l'autorisation LDAP sont toutes deux activées, il est utilisé comme ID utilisateur acheminé avec le message afin que le nom d'utilisateur LDAP soit redécouvert lorsque l'utilisateur le détecte. Il faut utiliser l'identifiant à l'intérieur du message

Par exemple, sur un autre gestionnaire de files d'attente ou lors de la rédaction de messages de rapport. Dans ce cas, l'attribut n'a pas besoin de représenter un ID utilisateur du système d'exploitation, mais doit être une chaîne unique. Un numéro de série d'employé est un exemple d'attribut valable à cette fin.

Dans notre exemple, ce champ doit être défini sur «uid».

CHCKCLNT CHCKLOCL et les paramètres FAILDLAY sont décrits ci-dessus.

Notez que la valeur REQDADM de l'attribut CHCKCLNT n'est pas pertinente si le type d'authentification est LDAP. Cela est dû au fait qu’il n’existe aucun concept d’ID utilisateur privilégié lors de l’utilisation de comptes d’utilisateur LDAP. Une autorisation doit être explicitement attribuée aux comptes d'utilisateurs et aux groupes LDAP.

CONNAME – Nom d'hôte, adresse décimale pointée IPv4 ou notation hexadécimale IPv6 de l'hôte sur lequel le serveur LDAP est en cours d'exécution, avec un port facultatif.

Si vous spécifiez le nom de la connexion en tant qu’adresse IPv6, seuls les systèmes dotés d’une pile IPv6 sont en mesure de résoudre cette adresse. Si l'objet AUTHINFO fait partie de la liste de noms CRL du gestionnaire de files d'attente, assurez-vous que tous les clients utilisant la table des canaux client générée par le gestionnaire de files d'attente peuvent résoudre le nom de la connexion.

La syntaxe de CONNAME est identique à celle des canaux. Par exemple, conname (‘hostname (nnn)’) où nnn est le numéro de port. Sous UNIX, Linux et Windows, la longueur maximale est de 264 caractères. Il peut également s'agir d'une liste de noms de connexion séparés par des virgules (si plusieurs serveurs LDAP sont en cours d'exécution).

Notez que le protocole LDAP non sécurisé est généralement configuré sur le port 356 et que LDAP sécurisé est défini sur 636.

LDAPPWD – Mot de passe associé au nom unique de l'utilisateur qui accède au serveur LDAP. Sa taille maximale est de 32 caractères.

LDAPUSER – Nom unique de l'utilisateur accédant au serveur LDAP. La taille maximale du nom d'utilisateur est la suivante: 1024 caractères

SECCOMM – Indiquez si la connectivité au serveur LDAP doit être effectuée de manière sécurisée à l'aide de TLS

OUI – Le serveur LDAP est fabriqué de manière sécurisée à l'aide de TLS.

Le certificat utilisé est le certificat par défaut du gestionnaire de files d'attente, nommé dans CERTLABL sur l'objet du gestionnaire de files d'attente ou, s'il est vide, celui décrit dans Étiquettes de certificat numérique. Le certificat se trouve dans le référentiel de clés spécifié dans SSLKEYR sur l'objet du gestionnaire de files d'attente. Une espèce de cryptage sera prise en charge par IBM MQ et le serveur LDAP. Si le gestionnaire de files d'attente est configuré pour utiliser les spécifications de chiffrement SSLFIPS (YES) ou SUITEB, cela est également pris en compte dans la connexion au serveur LDAP.

ANON – La connectivité au serveur LDAP est fait en toute sécurité en utilisant TLS comme pour SECCOMM (YES) avec une différence.

Aucun certificat n'est envoyé au serveur LDAP; la connexion sera faite anonymement. Pour utiliser ce paramètre, assurez-vous que le référentiel de clés spécifié dans SSLKEYR, sur l'objet du gestionnaire de files d'attente, ne contient pas de certificat identifié comme certificat par défaut.

NO – La connectivité au serveur LDAP n'utilise pas TLS. .

Vous devez insister sur le fait que les connexions établies avec les serveurs LDAP utilisent TLS, car MQCSP est envoyé en clair, ce qui signifie que sans TLS, l'ID utilisateur et le mot de passe sont envoyés sur le réseau sans protection ni chiffrement.

les paramètres que ceci serait la commande pour les exemples LDAP que nous avons utilisés dans cet exercice:

DEFINE AUTHINFO (QMGR1.IDPW.LDAP) AUTHTYPE (IDPWLDAP) CONNAME ('ldap-server1.org.com (636), ldap-server2.org.com (636), ldap-server3.org.com (636)') SHORTUSR (' uid ') ADOPTCTX (YES) AUTHORMD (SEARCHUSR) BASEDNG (' ou = groupe, dc = unix, dc = org, dc = com ') BASEDN U ('ou = Personnes, dc = unix, dc = org, dc = com') CHCKCLNT (FACULTATIF) CHCKLOCL (AUCUN) CLASSGRP ('posixGroup') CLASSUSR ('inetorgperson') FINDGRP ('memberOf') GRPFIELD ('cn') LDPWD (' ldap_password ') LDAPUSER (' cn = utilisateur_ldap, dc = unix, dc = org, dc = com ') NESTGRP (YES) SECCOMM (YES) USRFIELD ('uid')

ALTER QMGR CONNAUTH (QMGR1.IDPW.LDAP)

Après avoir exécuté la commande DEFINE AUTHINFO vous devez redémarrer l'application. gestionnaire de files d'attente. Si vous ne redémarrez pas le gestionnaire de files d'attente, la commande setmqaut ne renvoie pas le résultat correct. Le redémarrage du gestionnaire de files d'attente actualisera également la sécurité de type connauth.

Faites-moi savoir, dans les commentaires, si ces instructions vous ont été utiles dans votre travail quotidien!