Il y a plusieurs solutions, la plus simple est sans doute celle la ,vous devrez avoir accès à la console et connaitre un mot de passe sur la console (HSCROOT par exemple)
Il faut savoir que vous pouvez vous connecter à celle ci, même si vous avez un mot de passe désactivé.
A partir d’ACS
Sélectionner Console 5250
Vous devez rentrer un mot de passe de votre HMC, exemple HSCROOT
Vous devez choisir votre partition
et saisir le mot passe même *DISABLED sur la mire d’ouverture
Une fois connecter il suffit de réactiver le profil
==>CHGUSRPRF USRPRF(QSECOFR) STATUS(*ENABLED)
Remarque:
Il est malgré tout conseillé d’avoir un compte de secours que vous dédiez à une reprise derrière une désactivation intempestive.
Par exemple :
SECOURS qui sera dédié à ca avec des droits identiques à QSECOFR et avec un mot de passe gardé au coffre
plus d’informations ici : https://www.ibm.com/support/pages/qsecofr-profile-disabled
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2024-03-27 14:27:542024-03-27 15:40:15Mot de passe QSECOFR désactivé
C’est une bibliothèque qui contient les sources d’environ 15 outils IBMi, le plus connu est NETS qui permet de gérer les partages en mode 5250. Elle est développée par Jim Sloan, ce sont les outils TAATOOLS et depuis la version V3.7 ce sont eux qui gérent les licences.
Donc vous pouvez acquérir une licence du produit en vous adressant ici : support@taatool.com
Vous pouvez également avoir une version des outils sur votre machine : en effet avant la version 3.7 IBM distribuait gratuitement ce produit
Dans ce menu vous avez par exemple l’option 12 qui permet de gérer les utilisateurs désactivés, c’est une alternative simple à Navigator for i dans certains cas.
Pour rappel, les listes de validation sont des objets sur IBMi, de type VLDL.
Par ligne de commande, on peut seulement créer une liste ou la supprimer.
L’utilisation classique des listes d’autorisation est la sécurisation de vos serveurs IWS par authentification basique. Celles-ci permettent l’utilisation d’un profil qui n’est pas un réel utilisateur IBM i.
La gestion, de ces listes, se passe dans navigator for i, dans le HTTPAdmin :
Onglet « Advanced »
Ce que vous pouvez faire :
Ajouter une entrée dans la liste, si la liste de validation n’existe pas, elle sera créé pour l’occasion. A minima, il faut renseigner la liste de validation, un profil et un mot de passe
Changer le mot de passe d’une entrée
Supprimer une entrée
Lister les entrées d’une liste
Ce que vous ne pouvez pas faire :
Consulter le mot de passe en cours d’une entrée, un classique en terme de sécurité.
Supprimer une liste de validation, il faut utiliser la commande 5250 DLTVLDL
Pour mettre en place la sécurisation d’un serveur via ces listes, il faut, toujours depuis le HTTPAdmin, au niveau de la gestion des sécurités de votre serveur HTTP*, sélectionner l’option liste de validation :
Avantage :
Ne pas créer de réel utilisateur IBMi pour l’authentification.
Permettre à des tiers extérieurs d’avoir un login ne pouvant servir que dans le cadre d’appel HTTP à un serveur protéger par la liste d’autorisation dont est issu le login
Encryption de la liste au niveau OS. Pas de possibilité d’accès aux données de la liste de façon simple.
En cas d’appel depuis l’extérieur du réseau de confiance, ça semble une bonne option.
Inconvénient :
Il faut connaître en amont le client qui va se connecter, et donc avoir une gestion de demande /création de compte
L’interface de gestion n’est pas compatible avec un grand nombre d’entrées dans la liste. Dans ce cas il faudra, soit trouver une autre solution pour sécuriser son serveur, soit utiliser les API misent à disposition par IBM
* Sur les versions récentes, la sécurité peut aussi être gérée au niveau du serveur applicatif. A vous de voir, si vous voulez un duo de serveurs HTTP/applicatif ou seulement un serveur applicatif, mais c’est un autre sujet…
IBM nous fournit des API pour gérer les listes de validation. On retrouve les actions possibles dans Navigator for i…. Et d’autres !
En regardant de plus près ces API, on constate sur la création d’une entrée de la présence d’un attribut permettant ou non de décrypter un mot de passe :
Navigator for i utilisant les valeurs par défaut, lorsqu’on crée une entrée par ce biais, le mot de passe n’est pas décryptable. Par contre, si on crée une entrée par l’API correspondante, avec cet attribut positionné à QSY_VFY_FIND (1), on peut par la suite récupérer le mot de passe via l’API C QsyFindValidationLstEntry() ou son équivalent QSYFDVLE
Prenons des exemples :
Je crée dans une liste de validation, dédié à l’article, DTFORM/DEMOBLOG, un profil MdpnonVIsible avec l’attribut de décryptage à ‘0’, et un profil MdpVisible avec l’attribut de décryptage à ‘1’.
Première remarque : l’appel d’api d’ajout d’une entrée dans une liste de validation renvoie un erreur si la liste n’existe pas. Il faut la créer au préalable par la commande CRTVLDL.
En regardant dans Navigator for i, les deux entrées apparaissent sans distinction :
Lors du décryptage, si on tente un appel de l’API find avec une erreur, mauvais nom de liste, profil inexistant, …, le retour est en erreur, comme pour toutes les API : -1. On peut récupérer le message détaillé de l’erreur, on reste sur de la gestion standard :
Si on lance l’API Find avec pour le profil MdpnonVisible :
L’API renvoie un code retour ok, mais pas de mot de passe, normal, il n’est pas décryptable.
Avec le profil décryptable, on récupère bien le mot de passe initial :
Par cette méthode, vous pouvez donc récupérer des mots de passe stockés dans une liste de validation, à la condition que l’entrée ait été créée avec le top de décryptage à ‘1‘.
Pour compléter la sécurité sur le décryptage des mots de passe, vous pouvez mettre :
Sur la liste de validation
Un profil technique comme propriétaire
Aucun droit sur aucun autre profil .
Avoir un programme dédié au décryptage avec :
Comme propriétaire le même que celui de la liste de validation
Compilé pour faire de l’adoption de droit.
Et si on veut aller plus loin, en cas de debug possible en prod, protéger les sources, du programme de décryptage et ses appelants, par mot de passe.
Bien entendu cette stratégie n’est valable que si la gestion des droits utilisateurs est rigoureuse… Pas de *allobj sur les profils par exemple !
Conclusion :
Vous pouvez utiliser les listes de validation pour stocker des profils/mot de passe, sans les stocker en clair sur la machine. Mais on peut très bien imaginer utiliser ces listes pour stocker toutes les données sensibles permettant les échanges inter-applications ou autre :
URL d’invocation de WS
IP ou nom DNS pour FTP / SFTP
…
Et pour cela de se créer une liste par usage, liste pour URL, liste pour IP/DNS, …, de mettre dans le profil, un code application, et dans le mot de passe la valeur que l’on veut récupérer, avec la limitation de 600 caractères pour le mot de passe, à part pour des URL très spécifique, ça ne devrait pas être limitatif.
Les listes de validation restent des objets très peu connu, mais qui mérite de l’être !
/wp-content/uploads/2017/05/logogaia.png00Damien Trijasson/wp-content/uploads/2017/05/logogaia.pngDamien Trijasson2024-02-05 14:16:002024-04-15 17:56:25Utiliser les listes de validation comme coffre fort de mot de passe
Vous pouvez utiliser le catalogue base de données pour identifier vos informations sensibles
Pour cela vous allez utiliser les vues syscolumns de QSYS2 (norme IBMi) ou sqlcolumns de SYSIBM (norme DB2)
Vous pouvez rechercher toutes les zones qui contiennent (email, mail, RIB, IBAN, ETC..)
Dans notre exemple , on recherchera les zones IBAN dans toutes les tables en analysant : Nom de zone SQL Nom de zone IBMI Entête de colonne Texte de colonne
Sans différentiation de majuscule minuscule
Et on sortira la liste des droits public sur ces objets
— liste des fichiers avec une zone IBAN
— Avec un IBAN
SELECT COLUMN_NAME AS Zone,
IFNULL(COLUMN_HEADING, ' ') AS Entete,
IFNULL(COLUMN_TEXT, ' ') AS Text,
TABLE_SCHEMA AS bibliotheque,
TABLE_NAME AS fichier,
(SELECT OBJECT_AUTHORITY
FROM QSYS2.OBJECT_PRIVILEGES
WHERE SYSTEM_OBJECT_SCHEMA = TABLE_SCHEMA
AND OBJECT_NAME = TABLE_NAME
AND OBJECT_TYPE = '*FILE'
FETCH FIRST ROW ONLY) AS DROIT_public
FROM qsys2.syscolumns
WHERE COLUMN_NAME LIKE ('%IBAN%')
OR SYSTEM_COLUMN_NAME LIKE ('%IBAN%')
OR UCASE(COLUMN_HEADING) LIKE ('%IBAN%')
OR UCASE(COLUMN_TEXT) LIKE ('%IBAN%');
Conclusion :
Ca veut dire que toutes les tables avec *public à *USE sont visualisables par tous les utilisateurs de la machine.
Pour sécuriser vous devez le faire sur les fichiers Soit – Mettre en place des droits sur l’objet, attention l’utilisateur peut avoir droit à ce fichier quand il est dans l’application. Soit – Sécuriser un service d’accès par exemple ici ODBC, pour éviter un accès remote, (Fonctions usage ou programme d’exit sont les meilleurs solutions)
Bien sur si vous créez de nouvelle table vous pouvez crypter ces zones, ce qui la rendrait illisible à un utilisateur qui ne connait pas la clé
Contrôler le nombre de paramètres passés à un programme CL – %PARMS() / CEETSTA
Il arrive parfois d’avoir moins de paramètres passés à un programme CL que le nombre attendu, par exemple si on ajoute un paramètre à ce dernier mais que pour diverses raisons on ne souhaite pas modifier et recompiler tous les programmes qui y font appel.
Il existe deux solutions relativement simples à implémenter pour contrôler le nombre de paramètres transmis afin d’adapter en conséquence le comportement du programme : La fonction intégrée %PARMS et l’API CEETSTA.
%PARMS() – V7R4 et ultérieures
À partir de la V7R4, rien de plus simple, il suffit d’utiliser la fonction intégrée %PARMS(), qui retourne le nombre de paramètres :
PGM PARM(&PARAM1 &PARAM2)
/* Paramètres */
DCL VAR(&PARAM1) TYPE(*CHAR) LEN(10)
DCL VAR(&PARAM2) TYPE(*CHAR) LEN(10)
/* Corps du programme en fonction du passage du paramètre */
IF COND(%PARMS() *EQ 2) THEN(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 est renseigné')
ENDDO
ELSE CMD(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 n''est pas renseigné')
ENDDO
ENDPGM
Malheureusement, si on est confrontés à une contrainte de version, %PARMS ne descend pas en dessous de la V7R4 :
CEETSTA – V7R3 et antérieures
Dans ce cas, la solution la plus propre (je ne parlerai donc pas de monitoring sur un CHGVAR) est l’utilisation de l’API CEETSTA. Il suffit de lui passer en paramètre : – Une variable qui contiendra la valeur de retour, 1 si le paramètre est transmis, 0 s’il n’est pas transmis – Une variable indiquant la position du paramètre à contrôler
presence_flag
Sortie
*INT
Variable de retour : 1 ou 0
arg_num
Entrée
*INT
Position de la variable à tester
PGM PARM(&PARAM1 &PARAM2)
/* Paramètres */
DCL VAR(&PARAM1) TYPE(*CHAR) LEN(10)
DCL VAR(&PARAM2) TYPE(*CHAR) LEN(10)
/* Déclaration des variables nécessaires à l'utilisation de l'API */
DCL VAR(&PRESENCE) TYPE(*INT) /* Variable de retour : 1 ou 0 */
DCL VAR(&ARG_NUM) TYPE(*INT) VALUE(2) /* Position de la variable à tester */
/* Appel de l'API */
CALLPRC PRC('CEETSTA') PARM((&PRESENCE) (&ARG_NUM))
/* Corps du programme en fonction du passage du paramètre */
IF COND(&PRESENCE *EQ 1) THEN(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 est renseigné')
ENDDO
ELSE CMD(DO)
SNDPGMMSG MSG('Le paramètre &PARAM2 n''est pas renseigné')
ENDDO
ENDPGM
Remarques
Le compte des paramètres pour la arg_num commence à 1 La valeur de retour est un *INT pas un *LGL
https://www.gaia.fr/wp-content/uploads/2023/08/Openssh.gif191194Julien/wp-content/uploads/2017/05/logogaia.pngJulien2023-12-24 01:41:132023-12-24 01:41:15Contrôler le nombre de paramètres passés à un programme CL – %PARMS() / CEETSTA
La durée de vie théorique d’une bande LTO est donnée pour 30 ans, mais elle dépend beaucoup des conditions d’utilisation et elles peuvent être défectueuses. Certaines sociétés changent leurs bandes tous les 3 ans.
La bonne pratique c’est de le faire quand vous changez votre POWER en principe tous les 3 à 5 ans.
Mais il peut être important de contrôler l’état de vos supports pour éviter les mauvaises surprises.
Il n’existe pas de service SQL ni de sortie outfile pour l’instant.
Vous allez pouvoir faire une analyse par volume.
C’est vous qui indiquez le nom de volume quand vous formater votre support INZTAP DEV(TAPXXX) NEWVOL(xxxxxx) vous disposez de 6 caractères
Exemple : ==>INZTAP DEV(TAP01) NEWVOL(LUNDI1) …
La commande qui va vous permettre d’analyser ces volumes est la commande PRTERRLOG qui va vous générer un spool QPCSMPRT.
En principe vous avez un roulement de bande par semaine.
Vous pouvez contrôler le volume dans le lecteur avant de déclencher une sauvegarde, mais il n’est pas conseillé de la bloquer, vous pouvez remonter un message.
« * Attention bande du LUNDI trouvée dans le lecteur * »
Exemple
Vous devez connaitre le type de votre unité de bande pour utiliser cette commande.
Il est important : d’avoir un plan de reprise d’activité suite à un crash de tester une restauration partielle de temps en temps de passer la cartouche de nettoyage tous les 6 mois
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2023-12-20 07:50:392024-02-26 18:21:00Surveillez l’état de vos bandes
Depuis la V7R1 (SF99701 – DB2 – niveau 23), on peut invoquer des web service via SQL. Les fonctions se trouvent dans SYSTOOLS.
En V7R4 TR5, sont sorties de nouvelles fonctions, elles se trouvent dans QSYS2.
Outre les fonctions HTTP, celles pour encoder / décoder en base64 et pour encoder / décoder L’URL, ont aussi été implémentées dans QSYS2.
Rappel des différences entre ces fonctions
Tout d’abord les performances. Les fonctions de QSYS2 permettent un gain non négligeable, elles sont basé sur les fonctions AXIS en C natif, contrairement à celles de SYSTOOLS qui sont basées sur des classes java.
Les paramètres dans l’entête ou le corps du message sont transmis en JSON pour les fonctions de QSYS2, à la place de XML pour celle de SYSTOOLS.
La gestion des certificats est simplifiée par l’utilisation de DCM, alors qu’avec les fonctions de SYSTOOLS, il fallait pousser le certificat dans le magasin du runtime java utilisé par les fonctions HTTP. En cas de multiple versions de java installées, il fallait s’assurer de laquelle servait pour les fonctions HTTP. L’ajout du certificat, se faisait via des commandes shell.
Les types et tailles des paramètres des fonctions ont été adaptés pour ne plus être des facteurs limitants de l’utilisation des fonctions SQL, voici quelques exemples :
Certaines utilisations ont aussi été simplifiées en automatisant des tâches.
Prenons l’exemple d’un appel à un web service avec une authentification basique. Le couple profil / mot de passe doit être séparé par « : » et l’ensemble encoder en base64. C’est la norme HTTP.
Dans le cas des fonctions de SYSTOOLS, il fallait effectuer l’ensemble des opérations, alors qu’avec les fonctions de QSYS2, il suffit de passer le profil et le mot de passe dans la propriété BasicAuth. La mise en forme et l’encodage étant faits directement par les fonctions AXIS :
Il y a par contre un cas limitatif des fonctions QSYS2, que IBM a rajouté, alors que la norme HTTP autorise ce type d’appel.
Il s’agit d’avoir une authentification basique sur un appel en http.
Ce cas n’est pas trop contraignant, aujourd’hui le https est la norme et le http quasiment disparu…. quasiment ! Nous rencontrons encore chez nos clients des web services « interne » en http. La migration en https n’étant pas vendeur auprès des directions qui n’y voit aucun gain pour le métier. C’est l’éternel problème des changements structurels en IT.
Dans ces cas, la fonction de QSYS2, renverra une erreur, assez claire !
Le premier réflexe est de voir avec le fournisseur du service s’il ne dispose pas d’une version en https.
Maintenant, si vous n’avez pas d’autre choix que d’appeler un web service en http avec authentification basique, il faudra continuer d’utiliser les fonctions de SYSTOOLS. Dans tous les autres cas, aucune hésitation, utilisez les fonctions de QSYS2.
Mais mettons nous d’accord, de l’authentification basique en http, ce n’est pas de la sécurité, c’est une absurdité.
En http, le message passe en clair sur la trame réseau, avec votre profil / mot de passe, encodé en base 64, et non encrypté, donc en clair eux aussi.
Edit :Précision apportée par Gautier Dumas de CFD-innovation. Merci à lui. On peut contourner le problème avec les fonctions de QSYS2. Il ne faut pas utiliser la propriété BASICAUTH, mais construire l’authentification basique comme on le faisait avec celle de SYSTOOLS. VALUES QSYS2.HTTP_GET( ‘http://hostname/wscommon/api/contacts’, ‘{« header »: »Authorization, BASIC dGVzdHVzZXI6dGVzdHB3ZA== »}’); Il n’y a donc vraiment plus de raison de continuer avec les fonctions de SYSTOOLS !
Vous faites le l’administration, le plus souvent en 5250 sous l’écran de commandes IBMI ==> call QCMD
Vous voulez effacer la log que vous voyez par la commande DSPJOBLOG.
La première solution consiste à vous déconnecter, du coup la log est effacée ou transformée en spool.
Cette méthode efface tout le contexte mis en place, liste de bibliothèques , variables d’environnement, objets dans QTEMP que vous avez peut être mis beaucoup de temps à construire dans vos tests.
L’idée c’est d’avoir une solution moins radicale qui permette de n’effacer que la log de votre travail, c’est pourquoi vous devriez avoir dans vos tools un outil comme celui la
Une commande qu’on a appelé astucieusement CLRLOG que vous pouvez trouver ici
https://www.gaia.fr/wp-content/uploads/2017/02/team3.png600600Pierre-Louis BERTHOIN/wp-content/uploads/2017/05/logogaia.pngPierre-Louis BERTHOIN2023-09-17 16:31:212023-09-17 16:42:33Effacer la log de votre travail
Administration, Non classé, Open source, SecuritéSe connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)
Se connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)
Mise en place d’OpenSSH Server sur Windows
Pour mettre en place OpenSSH Server sur Windows, la méthode « standard » consiste à passer par les Paramètres > Applications et fonctionnalités > fonctionnalités facultatives :
Il est recommandé de redémarrer Windows une fois la fonctionnalité ajoutée.
Il suffit ensuite de démarrer le serveur via le gestionnaire de Services Windows :
Il est également souhaitable de configurer le démarrage automatique du serveur :
Remarque
Il est également possible d’installer OpenSSH sur Windows via d’autres sources (GitHub par exemple) ce qui permet, entre autres, de choisir plus facilement sa version d’OpenSSH, voir section Détail.
Création d’un jeu de clefs SSH via ssh-keygen
Pour plus de détails sur la création de clefs, vous pouvez vous référer à l’article de Guillaume Gestion des clefs SSH.
Dans cet article je vais tout réaliser sur l’IBM i via QSH :
$ ssh-keygen -t ecdsa -f ~/.ssh/ssh_key
Mise en place de la clef privée et configuration côté IBM i (client)
On a généré la clef privée dans le répertoire .ssh de l’utilisateur, donc elle est déjà bien en place. Il suffit donc de créer un fichier config dans le répertoire .ssh de l’utilisateur afin de simplifier nos commandes pour la suite. Voici un exemple de fichier config :
[~/.ssh/config]
Host windows
Hostname sshd_server.lan
User jl
IdentityFile ~/.ssh/key
StrictHostKeyChecking accept-new
Host
Nom de la configuration, utilisé à la place des différentes informations à la connexion
Hostname
Adresse ou nom du serveur à atteindre
User
Nom de l’utilisateur
IdentityFile
Chemin vers la clef privée
StrictHostKeyChecking accept-new
Permet d’ajouter automatiquement la signature du serveur distant au known_hosts
Mise en place de la clef privée et configuration côté Windows (serveur)
Il faut transférer la clef ssh_key.pub vers Windows et l’ajouter soit au fichier %UserProfile%.ssh\authorized_keys pour un utilisateur lambda, soit au fichier C:\ProgramData\ssh\administrators_authorized_keys pour un utilisateur ayant des droits d’administrateur local.
Attention à ce niveau, les droits des fichiers sont un peu particulières, il faut comme toujours avec le SSH réduire au maximum les utilisateurs ayant accès au fichier et, particularité de Windows, ajouter le droit de lecture au profil de service local Système :
Activation du fichier de log – Configuration sshd_config
Afin de pouvoir analyser d’éventuels problèmes ou simplement vouloir observer un peu plus en détail les différentes étapes de la mise en relation d’un flux ssh il est possible d’activer la log du serveur.
Par défaut celle-ci est redirigée vers les journaux d’évènements Windows et est seulement en « info ». On les retrouver via l’Observateur d’événements Windows :
Le mieux à mon avis est de repasser par un système plus standard, soit un vrai fichier de logs.
Pour ce faire, il faut aller modifier le fichier de configuration du serveur SSH, généralement il se trouve ici :
C:\ProgramData\ssh\sshd_config
ou
%ProgramData%\ssh\sshd_config
Il faut rechercher les lignes suivantes :
[sshd_config]
# Logging
#SyslogFacility AUTH
#LogLevel INFO
Les décommenter et indiquer les valeurs suivantes :
Une fois la configuration modifiée et le serveur redémarré, il suffit de retenter une connexion puis d’aller consulter le fichier de log :
C:\ProgramData\ssh\logs\sshd.log
ou
%ProgramData%\ssh\logs\sshd.log
Remarque
Les problèmes courants se passent généralement autour des lignes liées au fichier authorized_keys ou administrators_authorized_keys, problèmes de droits ou chemin du fichier utilisé…
Test de SSH IBM i vers Windows
On peut maintenant tester le tout via QSH ou CALL QP2TERM. Grâce au fichier config la commande est simple : (l’option -T permet de désactiver l’allocation d’un pseudo terminal)
$ ssh -T windows
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r
Il est maintenant possible d’exécuter des commandes Shell Windows à partir de cette connexion.
Si on voulait obtenir les mêmes niveaux de log côté client (IBM i) que l’on a activé côté Windows, on pourrait utiliser la commande suivante :
$ ssh -T -vvv windows
OpenSSH_8.0p1, OpenSSL 1.1.1t 7 Feb 2023
debug1: Reading configuration data /home/jl/.ssh/config
debug1: /home/jl/.ssh/config line 1: Applying options for *
debug1: /home/jl/.ssh/config line 4: Applying options for laptop
debug1: Reading configuration data /QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/ssh_config
...
Microsoft Windows [version 10.0.19045.3208]
(c) Microsoft Corporation. Tous droits r
https://www.gaia.fr/wp-content/uploads/2023/08/Openssh.gif191194Julien/wp-content/uploads/2017/05/logogaia.pngJulien2023-08-02 19:21:092023-08-11 16:00:34Se connecter à un serveur SSH exécuté sous Windows à partir d’un IBM i (Comment obtenir la log pour débuguer les problèmes éventuels)
Sécurisez vos services IBM i ! Nous ne le répéterons jamais suffisamment : vous devez crypter les accès au telnet 5250, au serveur de base de données etc … Bref partout où transitent aussi bien vos profils/mots de passe que vos informations métier.
Nous prenons ici l’exemple de telnet, le plus visuel.
Pour crypter vos connexions telnet : https://www.ibm.com/docs/en/i/7.5?topic=server-assigning-certificate-telnet
En synthèse :
Importer ou créer un certificat dans DCM (Digital Certificate Manager)
Associer ce certificat aux services à sécuriser : TELNET ici mais aussi CENTRAL, SIGNON, DATABASE …
Ne pas oublier de permettre la connexion sécurisée à telnet :
Permettre l'accès non sécurisé et sécurisé (ports 23 et 992) :
CHGTELNA ALWSSL(*YES)
Permettre l'accès sécurisé uniquement (port 992 uniquement) :
CHGTELNA ALWSSL(*ONLY)
Dès lors vous pouvez vous connecter avec ACS en mode sécurisé. Soit en indiquant au niveau de la configuration dans l’émulateur 5250 (menu Communication puis Configuration) :
Soit au niveau de la connexion système dans sa globalité :
A la prochaine connexion vous obtenez :
Mais comment ces certificats sont-ils gérés par ACS ?
Principe d’un certificat, chaîne de certification
Un certificat est une clé de cryptage permettant de chiffrer les données entre un serveur et un client.
La question est de savoir comment faire confiance à un certificat (celui de votre banque par exemple ?).
Un certificat est lui-même signé, c’est à dire validé, par une autorité de certification à laquelle nous faisons confiance.
Exemple avec les informations issues d’un navigateur :
Le navigateur fait confiance à www.volubis.fr car le certificat est lui-même signé par « Gandi Standard SSL CA 2 » et « USERTrust RSA Certification Authority » qui sont eux connus du navigateur :
D’autres critères entrent en compte comme la durée de validité par exemple
Pour un certificat non reconnu par votre navigateur, vous avez :
Validation par Access Client Solutions
ACS va utiliser la même mécanique : si l’autorité de certification est connue de ACS, alors le certificat est validé.
Si l’autorité n’est pas connue : demande à l’utilisateur de valider ou non l’accès.
Access Client Solutions utilise plusieurs magasins de certificats pour stocker les autorités :
le magasin lié à votre JVM qui exécute ACS
un magasin propre à ACS en complément
Magasin lié à la JVM
Pour trouver la JVM utilisée par ACS :
Java utilise par défaut un magasin de certificats JAVA_HOME\lib\security\cacerts. Ce magasin est protégé par un mot de passe (défaut = changeit)
Remarque :
Cette configuration par défaut peut être modifiée par fichier de configuration ou arguments de démarrage de la JVM.
Nous retrouvons bien notre autorité primaire « USERTrust RSA Certification Authority » :
Magasins liés à ACS
Par défaut, chaque utilisateur d’ACS dispose de son propre magasin de certificat (complémentaire à celui de l’environnement Java ci-dessus).
Dans les préférences vous retrouvez l’emplacement des configurations :
Access Client Solutions dispose également d’un outil de gestion des certificats pour son propre magasin uniquement : menu « Outils » puis « Gestion des clés » :
Cela vous permet d’importer, supprimer, voir vos certificats.
Remarque :
Cette configuration par défaut peut être modifiée par fichier de configuration AcsConfig.properties : permet d’indiquer l’emplacement du magasin de certificats.
Cas d’un certificat « internet »
Si vous avez acheté votre certificat auprès d’un organisme certificateur (Gandi pour nous, mais aussi OVH, Sectigo … Let’s encrypt gratuit), Access Client Solutions ne devrait rien vous demander et accepter directement le certificat : les autorités présentes dans le magasin associé à votre JVM permettent la validation.
Vous pouvez rencontrer des problèmes avec d’anciennes installations de Java non mises à jour : les nouvelles autorités de certification ne seront pas présentes. Bien sûr cela n’arrive jamais.
Cas d’un certificat « local »
Pour un certificat que vous avez généré sur votre IBM i, ou autre plateforme dans votre SI, si vous disposez de vos propres autorités de certification internes (fréquent dans les sociétés de grande taille) : Access Client Solutions ne dispose pas des autorités permettant la validation !
Remarque :
Si vos équipes de déploiement des postes client livrent les autorités de certification dans le magasin de la JVM, vous revenez dans le cas précédent.
A la première connexion, vous avez ce message :
Non : vous refusez la connexion
Oui : l’autorité de certification est ajoutée au magasin de certificats d’ACS.
Après avoir répondu « Oui » :
Aucun message affiché lors des prochaines connexions.
Changement de certificat
Comment faire en sorte que la sécurisation de vos services ou un changement de certificat soit transparent pour vos utilisateurs ?
Nous savons que demander à des centaines d’utilisateurs de répondre « Oui » peut générer un support très important aux équipes et être anxiogène.
Mise en place
Au-delà du certificat, il faut procéder aux changements de configurations : au niveau de la définition du système et/ou de la session 5250.
Pour le certificat, plusieurs solutions :
Vous disposez d’un poste modèle sur lequel vous avez installé ACS, et importez manuellement l’autorité de certification. Il vous suffit alors de déployer le fichier cacerts de ACS sur les différents postes.
Ce dernier est ici : "C:\Users\{USER}\Documents\IBM\iAccessClient\Private\{USER}\cacerts"
Dans le fichier de configuration AcsConfig.properties : vous pouvez indiquer un fichier cacerts mutualisé sur un lecteur réseau par exemple :
Injection du certificat en mode commande
ACS dispose de commande, avec option silencieuse :
/PLUGIN=certdl => demande à downloader l’autorité de certification et l’importer dans le magasin
/SYSTEM=nom système configuré => depuis le système en question
A intégrer dans vos outils de déploiement pour exécution sur chaque poste client ! Le certificat est ensuite visible dans le menu « Outils » puis « Gestion des clés ».
Renouvellement
Le certificat est issu de la même autorité de certification que le précédent : rien à faire ! C’est l’autorité qui est stockée, pas le certificat lui-même
Le certificat est issu d’une autre autorité (autre fournisseur, autorité précédente périmée ou invalidée) : il faut injecter l’autorité dans le magasin de certificat (cf Mise en place)
En synthèse : pas de difficulté, plusieurs solutions en fonction de votre organisation et outillage !
N’oubliez pas de renouveler vos certificats avant la date d’expiration …
