Si vous êtes utilisateur de SSO (Single Sign On) sur l’IBM i, alors vous utilisez l’EIM (Enterprise Identity Mapping).

Pour rappel (en très simplifié), le SSO vous permet de propager votre authentification Windows jusqu’à l’IBM i de sorte que n’avez pas besoin de saisir votre profil/mot de passe : une association entre vos comptes Windows et IBM i est réalisée et prise en compte automatiquement.

Pour gérer ces associations, vous pouvez utiliser IBM Navigator for i :

A partir de là vous avez accès à toute la gestion de l’annuaire (nécessite une authentification).

Bien entendu, ces fonctions sont critiques d’un point de vue de la sécurité : une modification de la configuration peut empêcher toute connexion, ou au contraire permettre une connexion avec un profil IBM i élevé !

IBM a donc délivré une nouvelle fonction d’usage QIBM_NAV_SECURITY_EIM (EIM related security) à cet effet : limiter l’accès aux fonctions EIM via Navigator for i.

La valeur par défaut est *ALLOWED pour tous -> vous devriez la passer à *DENIED !

Dès lors, si vous tentez d’accéder aux fonctions EIM, vous obtenez :

Plus de détails sur les Group PTF :

https://www.ibm.com/support/pages/node/6520030#Q22025

https://www.ibm.com/support/pages/node/6485853

Vous voulez automatiser la gestion de votre SSO pour l’IBM i, contactez nous : https://www.gaia.fr/produits/

Si vous avez assisté à l’événement Securiti 2025 organisé par i.gayte.it, nous avions présenté une fonctionnalité SQL permettant de limiter l’accès aux informations du plan cache SQL.

Vous trouverez par ailleurs le replay de l’événement ici : Sécurit.i 2025 : Replays – I.Gayte.it

En effet, ce dernier contient de nombreuses informations nécessaires à l’adaptation du moteur SQL. Mais il contient aussi les données utilisées dans vos requêtes : constantes littérales, valeurs de comparaisons …

Bien entendu, certaines valeurs sont à protéger, y compris des utilisateurs ayant les droits de consulter le plan cache.

SYSPROC.SET_COLUMN_ATTRIBUTE

Cette procédure permet de cacher les informations pour certaines colonnes de certaines tables : https://www.ibm.com/docs/en/i/7.6.0?topic=services-set-column-attribute-procedure

Pour ceci :

L’attribut est visible dans le catalogue DB2 : QSYS2.SYSCOLUMNS2, colonne SECURE => 0 ou 1

Désormais, lorsque vous accédez au cache :

Cela fonctionne, mais à moitié !

Correctif

IBM a publié un correctif : https://www.ibm.com/support/pages/security-bulletin-ibm-i-affected-obtaining-information-without-proper-authority-cve-2025-36371

Toutes les versions depuis la 7.2 sont touchées : mettez à jour !

Merci à l’équipe du lab de Rochester qui a résolu ce problème rapidement. Il semble toutefois que personne ne l’avait remonté préalablement !

Désormais on obtient bien :

L’IBM i propose de nombreuses fonctionnalités sous-utilisées, n’hésitez pas à nous faire part de vos questions.

, Copier vos données VIA DDM/DRDA

Vous connaissez tous DDM qui permet d’avoir un fichier qui pointe sur une système

Cette solution s’appui sur DRDA, donc DRDA devra etre configuré aujourdh’ui en IP

Cette solution est simple elle permet par exemple de mettre à jour des données d’un système vers un autre IBMi

Nous vous proposons un outil simple qui vous permettra de faire des copies dynamiques

La commande CPYRMTDTA

/* programme associé CPYRMTDTA */
CMD PROMPT(‘Copie data vers un IBMi’)

PARM KWD(FROMFILE) TYPE(*NAME) LEN(10) MIN(1) +
PROMPT(‘Fichier source’)
PARM KWD(FROMLIB) TYPE(*NAME) LEN(10) MIN(1) +
PROMPT(‘Bibliothèque source’)
PARM KWD(TOFILE) TYPE(*NAME) LEN(10) MIN(1) +
PROMPT(‘Fichier cible’)
PARM KWD(TOLIB) TYPE(*NAME) LEN(10) MIN(1) +
PROMPT(‘Bibliothèque cible’)
PARM KWD(RMTLOC) TYPE(*CHAR) LEN(30) MIN(1) +
PROMPT(‘Emplacement distant (RDB)’)

Le programme CLLE (à améliorer )

PGM (&FFILE &FLIB &TLIB &TFILE &RMT)/*——————————*/
/* Copier les données d’un fichier local vers un fichier distant */
/* en utilisant drda */
/* drda doit etre configurer sur le système distant */
/* et l’utilisateur en cours doit pouvoir s’authentifier */
/* */
/*——————————————————————*/
DCL &FFILE *CHAR 10
DCL &FLIB *CHAR 10
DCL &TFILE *CHAR 10
DCL &TLIB *CHAR 10
DCL &RMT *CHAR 30
INCLUDE SRCMBR(ERREUR1) SRCFILE(GCOMPILE/QCLSRC)
CHKOBJ &FLIB/&FFILE *FILE
DLTF FILE(QTEMP/RMTFILE)
MONMSG CPF2100
CRTDDMF FILE(QTEMP/RMTFILE) RMTFILE(&TLIB/&TFILE) +
RMTLOCNAME(&RMT *IP)
CPYF FROMFILE(&FLIB/&FFILE) TOFILE(QTEMP/RMTFILE) +
MBROPT(*REPLACE)
MONMSG CPF0000 EXEC(DO)
SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA(‘Copie +
fichier : ‘ *BCAT &FFILE *BCAT +
‘,impossible’) MSGTYPE(*ESCAPE)
ENDDO
INCLUDE SRCMBR(ERREUR2) SRCFILE(GCOMPILE/QCLSRC)

Remarque :

Bien sur vous devrez contrôler la sécurité, attention par exemple un profil *disabled peut se connecter en DRDA

Pour vous aidez, vous pouvez télécharger notre outil WRKSRVAUTE pour gérer vos postes d’authentifications :https://github.com/Plberthoin/PLB/tree/master/GTOOLS

Passage d’un paramètre à l’état Null de SQL à RPGLE

Voici un petit retour d’expérience sur un cas d’usage où on doit transmettre l’état Null d’un paramètre depuis une procédure SQL vers une procédure de service RPGLE.

Pour rappel, Null est un état, pas une valeur. Il permet justement d’indiquer qu’une variable ne possède pas de valeur définie.

Dans le cas d’usage traité ici, je dois exposer une procédure de service RPGLE en procédure SQL, et gérer l’état Null pour l’un des paramètres seulement.

La procédure de service RPGLE reçoit en paramètre une DS qui contient 3 sous-zones, chacune ayant été définie avec 2 noms (un nom long et un nom court) grâce à un overlay. La procédure de service RPGLE doit pouvoir gérer l’état Null de la deuxième sous-zone.

Template de la DS et Prototype de la procédure de service RPGLE :

Le mot-clé NULLIND permet de définir l’état Null pour les sous-zones Parametre_02 et P2.

Le stockage de la sous-zone P2 est superposé à celui de la sous-zone Parametre_02. Lorsque l’une des deux sous-zones prend une valeur, l’autre prend la même valeur.

OPTION(*NULLIND) permet de transmettre à la procédure de service, l’état Null des sous-zones de la DS.

En RPG, l’état Null d’un paramètre est transmis sous forme d’un INDICATEUR. Il pourra être testé avec la fonction intégrée %NULLIND() : *ON (état Null) ou *OFF (état non Null).

Procédure de service :

Le mot-clé ALWNULL(*USRCTL) est indiqué dans la déclaration de contrôle pour permettre de gérer l’état Null des paramètres.

OPTION(*NULLIND) permet de transmettre à la procédure de service, l’état Null des sous-zones de la DS.

%NULLIND(DSParm.P2) est l’indicateur de l’état Null du paramètre DSParm.P2. Il sera transmis à la procédure.

Procédure SQL avec programme externe RPGLE qui appellera la procédure de service :

Les paramètres 1 à 3 sont INOUT car ils peuvent être modifiés par la procédure de service et retournés à la procédure SQL.

WITH NULLS permet de transmettre au programme externe les indicateurs d’état Null pour tous les paramètres de la procédure.

Les indicateur Null sont transmis au programme externe sous forme de valeurs numériques :

  • -1 -> le paramètre est à l’état Null avec une valeur indéfinie
  • 0 -> le paramètre possède une valeur définie

Procédure SQL avec programme externe RPGLE qui appellera la procédure de service :

Programme externe RPGLE

Programme PROGRPG :

Le mot-clé ALWNULL(*USRCTL) est indiqué dans la déclaration de contrôle pour permettre de gérer l’état Null des paramètres.

Le tableau Null_Array est déclaré à la fin des paramètres, en plus des paramètres de la procédure SQL. Il contient les indicateur d’état Null transmis par la procédure SQL sous forme de valeurs numériques :

  • 0 -> le paramètre possède une valeur définie
  • -1 -> le paramètre est à l’état Null avec une valeur indéfinie

Tous les paramètres peuvent être transmis à l’état Null par la procédure SQL, mais seul l’état Null de Parametre_02 est géré par la procédure de service. J’ai donc rajouté une boucle de contrôle de l’état Null des paramètres pour retourner une erreur à la procédure SQL si un autre paramètre était transmis à l’état Null.

Appel de la procédure PROCILE

Test de la procédure SQL

Test 1

Si l’état Null est envoyé pour un PARM1 au lieu de PARM2, un code E est retournée dans le paramètre ERREUR

.

Test 2

PARM2 envoyé à Null, retourné à 999.99.

.

Test 3

PARM2 envoyé avec une valeur définie, retourné avec la même valeur

, Analyse des problèmes

Depuis le TR1 de la V7R6 ou TR7 de la V7R5, vous pouvez utiliser la vue de SYSTOOL, PROBLEM_INFO.

Ca remplace la commande DSPPRB en OUTFILE

Exemple :

cl: DSPPRB OUTPUT(*OUTFILE) OUTFILE(QTEMP/LSTPRB) ;
SELECT PBID, PBSEV, PBSTAT, PBDESC, PBDATO, PBTIMO FROM LSTPRB

Par exemple, pour voir les problèmes des 2 derniers jours

SELECT * FROM SYSTOOLS.PROBLEM_INFO
  WHERE OPEN_TIME > CURRENT TIMESTAMP – 2DAYS;

Remarque :

On ne peut pas encore traiter sauf à utiliser un QCMDEXC avec une commande CHGPRB , DLTPRB etc …

https://www.ibm.com/docs/fr/i/7.5.0?topic=troubleshooting

La durée de rétention est indiquée en jour dans la valeur système QPRBHLDITV

par défaut c’est 30 jours

il est possible que des problèmes proviennent de requêtes DRDA non conformes c’est le cas pour les outils d’analyse de securité, NESSUS, OpenVAS, Rapid7, Nexpose, Greenbone etc..

ca génèrera un dump FFDC (First Failure Data Capture) vous pouvez éviter la génération de ce dump en utilisant une variable d’environnement, QIBM_SKIP_PRSDUMP

==>ADDENVVAR ENVVAR(QIBM_SKIP_PRSDUMP) VALUE(‘Y’) LEVEL(*SYS)

Sa mise ne œuvre nécessite le redémarrage des prestart job QRWTSRVR.

Attention, toute fois vous ne verrez pas les vrais problémes