Authentification multi-facteurs (MFA) sur IBM i 7.6

Mise en place, administration et exploitation du MFA intégré IBM i

1. Pourquoi le MFA ?

1.1 Le problème du mot de passe seul

Un mot de passe peut être volé, deviné, ou contourné sans que l'utilisateur légitime ne s'en aperçoive. Les techniques d'attaque sont nombreuses et bien documentées :

• Password spraying : tester des mots de passe courants sur des milliers de comptes.
• Phishing : tromper les utilisateurs pour obtenir leurs identifiants (technique remarquablement efficace).
• Manipulation du helpdesk : convaincre le support de réinitialiser un compte, y compris de profils de personnes qui ont quitté l'organisation.
• Achat de listes : réutiliser des couples identifiant/mot de passe issus de fuites de données (bases de données compromises revendues sur le dark web).
• SIM swapping : usurper la carte SIM d'un utilisateur pour intercepter des SMS de validation.

Dans tous ces cas, si le MFA avait été activé, l'attaque aurait échoué même en possession du mot de passe valide.

1.2 Réglementations et cyber-assurances

L'activation du MFA est aujourd'hui requise ou fortement recommandée par de nombreux référentiels :

• PCI DSS v4.0 — §8.4 : MFA obligatoire pour tous les accès non-console au Cardholder Data Environment (CDE).
• NIST Cybersecurity Framework : bonne pratique explicite pour les accès distants et privilégiés.
• ISO 27001 : renforcement du contrôle d'accès logique.
• Cyber-assurances : depuis 2021-2022, de nombreux assureurs exigent le MFA comme condition d'éligibilité ou de maintien de la couverture. Ne pas avoir de MFA, c'est parfois ne pas pouvoir s'assurer.

1.3 Historique des standards

IBM i 7.6 implémente RFC 6238 (TOTP). Tous ces algorithmes reposent sur un shared secret — aucune couverture réseau n'est nécessaire pour les tokens HOTP et TOTP.

1.4 Avant IBM i 7.6 : les solutions ISV

Avant IBM i 7.6, les solutions MFA disponibles sur IBM i étaient fournies par des éditeurs tiers : elles s'appuyaient principalement sur des exit points IBM i pour intercepter les authentifications.

Limites :

• Exit points non disponibles pour toutes les interfaces d'authentification (des « trous » existaient).
• Nécessité d'un serveur d'authentification externe.
• Configuration complexe (agents, ports firewall, certificats).
• Pas de couverture en état restreint.

1.5 IBM i 7.6 : le MFA natif

IBM i 7.6 introduit un MFA intégré à l'OS, disponible sans achat de logiciel supplémentaire :

• Aucun logiciel tiers à acheter ou installer.
• Aucun serveur d'authentification externe.
• Aucun port firewall à ouvrir.
• Aucun programme agent.
• Couverture de toutes les interfaces d'authentification IBM i.
• Vérification simultanée du mot de passe et du facteur TOTP (pas de gap exploitable).
• Fonctionne en état restreint.
• Configurable profil par profil.

2. Architecture de la solution

2.1 Principe TOTP (RFC 6238)

L'utilisateur saisit ce code lors de sa connexion. IBM i calcule de son côté le même code et les compare.

2.2 Stockage et protection de la clé TOTP

La clé TOTP est stockée dans le profil utilisateur (*USRPRF), avec le même niveau de protection que le mot de passe.

Protection technique :

• Chiffrée par AES avec une clé dérivée de 32 octets.
• Stockée dans un bloc de contrôle interne protégé par Hardware Storage Protection (HSP).
• Le HSP est une protection intégrée au matériel Power et appliquée par le processeur lui-même.
• Valeur HSP utilisée : "no access from user state" et "protect at all security levels".
• Tout code de niveau utilisateur (user state) est physiquement exclu du bloc de contrôle.
• Si un code utilisateur tente d'y accéder, le matériel génère une exception et le Licensed Internal Code retourne une erreur.

En pratique : même un profil avec *ALLOBJ ne peut pas lire directement la clé TOTP d'un autre utilisateur.

2.3 Principales applications d'authentification compatibles

Toute application implémentant RFC 6238 est compatible :

2.4 Le Host Connection Server (HCS)

Un des défis du MFA sur IBM i est que certaines interfaces (ACS, Navigator, DCM) établissent plusieurs connexions successives pour une même session utilisateur. Sans HCS, chaque connexion demanderait un code TOTP.

Avant HCS : chaque connexion à un serveur hôte (Database Server, Print Server, File Server...) nécessite une authentification distincte → l'utilisateur devrait entrer son code TOTP à chaque fois.

Avec HCS : le client s'authentifie une seule fois (avec User + Password + TOTP) auprès du Host Connection Server. Ce serveur transmet ensuite les nouvelles connexions aux autres serveurs hôtes sans ré-authentification.

ACS, IBM Navigator for i et Digital Certificate Manager (DCM) ont été mis à jour pour utiliser HCS.

3. Concepts clés

3.1 Clé TOTP (secret partagé)

La clé TOTP est la valeur secrète commune au profil utilisateur IBM i et à l'application d'authentification.

Caractéristiques :

• Chaque utilisateur a sa propre clé TOTP.
• Un utilisateur doit posséder une clé TOTP avant que son profil puisse être configuré avec la méthode *TOTP.
• L'administrateur ne peut pas définir la clé TOTP à la place de l'utilisateur : chaque utilisateur génère la sienne.
• La clé est affichée sous forme encodée en base32 lors de sa création.

Exemple d'affichage après CHGTOTPKEY :

TOTP key  . . . . . . . :   PGWG KZ6T 7RRY AZLG PPDJ MHFN CRYQ MDAF
Copy/paste version  . . :   PGWGKZ6T7RRYAZLGPPDJMHFNCRYQMDAF

Recovery key  . . . . . :   47BB3CD184DC10789972AD8B601E98ED
                            2520AD706D6D6697C905BD6EC6DA8BCA

The TOTP key has been saved in your profile. It must also be entered into your
TOTP generator client application, without the blanks.

Save the recovery key for this TOTP key in a safe place.

Enter=Continue   F9=Check TOTP

3.2 Clé de récupération (Recovery Key)

La clé de récupération est générée en même temps que la clé TOTP. Elle permet de se connecter à la place d'un code TOTP généré, dans les cas où l'utilisateur n'a plus accès à son application d'authentification.

Comportement :

Procédure de secours si la fenêtre de 10 minutes est dépassée :

1. L'utilisateur ne peut plus se connecter.
2. L'administrateur supprime la méthode *TOTP du profil (CHGUSRPRF AUTHMTH(*NONE)).
3. L'utilisateur se reconnecte et génère une nouvelle clé TOTP (CHGTOTPKEY).
4. L'administrateur remet la méthode *TOTP sur le profil.

3.3 Intervalle optionnel TOTP (TOTPOPTITV)

L'intervalle optionnel est la durée (en minutes) pendant laquelle un code TOTP n'est pas redemandé après une première authentification réussie.

Mode absolu : *NONE

• Chaque authentification par mot de passe nécessite un code TOTP valide.
• Les clients utilisant des mots de passe mis en cache échoueront.
• Certains clients pourront demander un code TOTP à chaque connexion unique.

Mode intervalle : 1 à 720 minutes

• L'utilisateur s'authentifie une première fois avec User + Password + TOTP.
• L'intervalle démarre.
• Pendant l'intervalle, seul User + Password est demandé.
• Si un code TOTP valide est fourni pendant l'intervalle actif, l'intervalle redémarre à partir de maintenant.
• Si un code TOTP invalide est fourni pendant l'intervalle, il est ignoré (pas d'erreur).
• Si l'intervalle est modifié sur le profil, les minutes restantes sont recalculées immédiatement.

Usage typique : configurer un intervalle pour les utilisateurs qui doivent utiliser des applications ne supportant pas le MFA (connexions SSH, ODBC, etc.) — ils s'authentifient une première fois via ACS ou Navigator, puis utilisent les autres interfaces durant l'intervalle sans saisir de code TOTP.

3.4 Attribut de sécurité "facteur de connexion additionnel"

Cet attribut est le commutateur système du MFA. Il contrôle le comportement de l'ensemble du système.

Ses 4 effets lorsqu'il est activé :

1. Ajoute le champ "Facteur additionnel" sur les écrans de connexion.
2. Active le parsing password:facteur_additionnel pour les profils ayant une méthode autre que *NONE.
3. Active la vérification du TOTP pour les profils avec méthode *TOTP.
4. Active la transmission du facteur à l'exit program QIBM_QSY_AUTH pour les profils avec méthode *REGFAC.

Important n°1 : activer cet attribut ne force pas les utilisateurs à utiliser le MFA. Seuls les profils configurés avec *TOTP ou *REGFAC seront contraints.

Important n°2 : cet attribut n'est pas sauvegardé ni restauré lors des sauvegardes système. Il doit être réactivé manuellement après une restauration complète du système. À intégrer dans la documentation de reprise d'activité.

Important n°3 : si l'attribut est désactivé ultérieurement, les profils ayant *TOTP ne seront plus contraints de saisir un TOTP. La clé TOTP et la méthode *TOTP restent sur les profils. La réactivation de l'attribut réactive immédiatement l'obligation.

3.5 Méthodes d'authentification

Chaque profil utilisateur dispose d'une liste de méthodes d'authentification. Les valeurs possibles sont :

*NONE est la valeur par défaut pour tous les profils, y compris ceux migrés depuis des releases antérieures.

3.6 Format password:facteur_additionnel

Pour les interfaces sans champ "facteur additionnel" (SSH, FTP, ODBC, certains clients tiers), l'utilisateur doit combiner son mot de passe et son code TOTP dans le champ mot de passe en utilisant : comme séparateur.

Exemple : Str0ngPassw#rd:358538

Règles importantes :

• La recherche du : séparateur se fait en partant de la fin de la chaîne (un : peut faire partie du mot de passe).
• La longueur totale (mot de passe + : + facteur) ne peut pas dépasser 128 octets.
• Avec *TOTP : le mot de passe ne devrait pas dépasser 121 octets (121 + 1 : + 6 chiffres = 128).
• Avec *REGFAC uniquement : 128 - 1 - n octets, où n est la longueur du facteur attendu par le programme (1 à 64 octets).
• Ce format ne fonctionne pas si le client utilise une substitution de mot de passe basée sur un hash unidirectionnel. ACS, Navigator for i et DCM utilisent cette méthode : il faut utiliser le champ dédié pour ces interfaces.

4. Prérequis système

4.1 Niveau de sécurité : QSECURITY

Le système doit être au niveau 40 ou supérieur.

DSPSECA       /* Vérifier le niveau actuel */

Ou via Navigator

Si nécessaire :

CHGSYSVAL SYSVAL(QSECURITY) VALUE('40')

La plupart des systèmes en production sont déjà à 40 ou 50. Les systèmes encore à 20 ou 30 devront migrer avant d'activer le MFA. Voir la documentation IBM sur les impacts du changement de niveau de sécurité.

4.2 Niveau de mot de passe : QPWDLVL

Le système doit être au niveau de mot de passe 4.

DSPSYSVAL SYSVAL(QPWDLVL)   /* Vérifier le niveau actuel */

Pour modifier :

CHGSYSVAL SYSVAL(QPWDLVL) VALUE('4')

Impacts à évaluer selon le niveau actuel :

• QPWDLVL 2 ou 3 → 4 : généralement sans impact, un test préalable est recommandé.
• QPWDLVL 0 ou 1 → 4 : changement significatif (longueur de mot de passe, règles de composition) — nécessite une planification et des tests approfondis.

Voir : Planning password level changes

Impacts détaillés du passage QPWDLVL 3 → 4

1. Nouvel algorithme de chiffrement des mots de passe

Le niveau 4 utilise un algorithme de chiffrement unidirectionnel différent des niveaux 2/3. C'est un changement de schéma cryptographique, pas seulement une règle de complexité.

2. Effet différé : IPL obligatoire

Le changement ne prend effet qu'au prochain IPL (redémarrage du système).

Pour voir les valeurs courante et en attente :

DSPSECA

3. Profils utilisateurs sans mot de passe niveau 4 → *NONE

Au passage en niveau 4, tous les mots de passe niveau 0/1/2/3 sont effacés. Si un profil n'a pas encore de mot de passe niveau 4 généré, son mot de passe devient *NONE (connexion impossible).

Avant l'IPL, identifier les profils concernés :

SELECT * FROM QSYS2.USER_INFO WHERE PASSWORD_LEVEL_4 <> 'YES'

ou via PRTUSRPRF TYPE(*PWDLVL) / DSPAUTUSR.

Par exemple sur notre machine en QPWDLVL3, la plupart des profils ont un mot de passe encodé en niveau 4, sauf les profils qui n'ont pas changé de mot de passe depuis longtemps (avant migration en 7.6 et la possibiité d'encoder les mots de passe en niveau 4):

Pour forcer la génération d'un mot de passe niveau 4 sur ces profils : utiliser CHGPWD CHGUSRPRF... PASSWORD(xxx) ou faire signer l'utilisateur en texte clair (sans substitution de mot de passe).

4. Clients utilisant la substitution de mot de passe (password substitution)

Tout client qui n'envoie pas le mot de passe en clair (il envoie un hash) doit supporter le nouveau schéma de substitution du niveau 4, sinon les connexions échoueront.

Clients IBM officiellement supportés pour QPWDLVL 4 :

• TELNET
• IBM i Access Client Solutions (ACS)
• IBM Navigator for i
• IBM i Host Servers
• QFileSrv.400, DDM, DRDA, NetServer Print

⚠️ Les middlewares tiers (ex. IBM Toolbox for Java intégré dans une application tierce) doivent être vérifiés : s'ils embarquent une version ancienne du middleware, ils ne fonctionneront plus.

5. Sauvegarde préalable indispensable

SAVSECDTA   /* ou SAVSYS */

Cela permettra de restaurer les mots de passe en cas de retour à un niveau inférieur.

6. Modification de QPWDLVL

CHGSYSVAL SYSVAL(QPWDLVL) VALUE(4)

Ou bien par Navigator :

Doit maintenant afficher :

Ou bien :

7. Synthèse : actions à mener avant l'IPL

4.3 Écran de connexion personnalisé

Si votre organisation utilise un écran de connexion 5250 personnalisé, il doit être recréé à partir du format QDSIGNON3 pour inclure le champ "Facteur additionnel".

Cette modification doit être effectuée avant l'IPL qui active le MFA. Si l'IPL est effectué avant la mise à jour de l'écran, les utilisateurs verront le nouvel écran IBM par défaut (avec le champ facteur), mais pas votre écran personnalisé.

Voir : Signon screen display file

A ce stade, après IPL, la zone TOTP n'apparait pas encore à l'écran de connexion, tant que le facteur connexion additionnel n'est pas activé :

Le source est fourni ici QSYS/QAWTSSRC(QDSIGNON3). Vous pouvez le copier et l'éditer.

4.4 Synchronisation de l'heure : NTP

Le TOTP est basé sur l'heure UTC. L'heure du système IBM i et celle de l'application d'authentification doivent être synchronisées.

Une dérive mineure est tolérée par l'algorithme RFC 6238, mais l'activation du client NTP est fortement recommandée.

DSPSYSVAL QTIMADJ   /* Vérifier la configuration de synchronisation */

NTP (Network Time Protocol) et SNTP (Simple Network Time Protocol) reposent sur le même protocole réseau (RFC 5905), mais diffèrent dans leur implémentation. NTP est capable de pondèrer des sources multiples, de calculer et corriger la dérive en ajustant progressivement l'horloge. SNTP fait des sauts dans la correction et est moins précis.

Configuration NTP via Navigator :

Réseau -> Serveurs -> Serveurs TCP/IP -> SNTP -> Propriétés

Démarrer avec TCP/IP :

Indiquer un ou plusieurs serveurs NTP :

Et les réglages de seuil :

Démarrer manuellement :

Vous retrouvez la configuration et les logs ici : /QIBM/UserData/OS400/TCPIP/NTP

Si vous avez plusieurs interfaces réseau, assurez vous que la communication se réalise sur une interface capable de communiquer avec le serveurNTP. Ajouter la directive suivante dans votre fichier /QIBM/USERDATA/OS400/TCPIP/NTP/ntp.conf :

interface listen 172.30.14.7

Puis arrêter et redéamrrer le client NTP.

4.5 TLS recommandé

Avant d'activer le MFA, il est fortement conseillé de s'assurer que les connexions aux host servers, Navigator for i et ACS sont chiffrées via TLS.

Sans TLS, le code TOTP (et le mot de passe) transitent en clair sur le réseau — ce qui réduit considérablement l'intérêt du MFA.

Via Access Client Solutions :

Ou Navigator

Pour remédier :

Installe l'autorité de certification das le "IBM i Magasin Web Trust" :

Que vous pouvez gèrer ensuite :

5. Déploiement — Actions administrateur système

5.1 Vue d'ensemble du processus

┌──────────────────────────────────────────────────────────────────┐
│                     ÉTAPES ADMINISTRATEUR                        │
│                                                                  │
│  Étape 1 : Vérifier prérequis (QSECURITY, QPWDLVL)               │
│      ↓                                                           │
│  Étape 2 : Adapter l'écran de connexion si personnalisé          │
│      ↓                                                           │
│  Étape 3 : Activer l'attribut "facteur de connexion additionnel" │
│      ↓                                                           │
│  Étape 4 : IPL du système                                        │
│      ↓                                                           │
│  Étape 5 (optionnel) : Configurer NTP                            │
│      ↓                                                           │
│  Étape 6 (optionnel) : Enregistrer l'exit program *REGFAC        │
└──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│                       ÉTAPES UTILISATEUR                         │
│                                                                  │
│  Étape 1 : Générer sa clé TOTP (CHGTOTPKEY)                      │
│      ↓                                                           │
│  Étape 2 : Sauvegarder la clé de récupération                    │
│      ↓                                                           │
│  Étape 3 : Configurer l'application + valider (CHKTOTP)          │
│            Notifier l'administrateur                             │
└──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│                    ÉTAPES ADMINISTRATEUR / PROFILS               │
│                                                                  │
│  Étape 1 : Vérifier que l'utilisateur a une clé TOTP             │
│            Activer *TOTP / *REGFAC sur le profil                 │
│            Configurer l'intervalle optionnel                     │
└──────────────────────────────────────────────────────────────────┘

5.2 Vérifier l'état actuel

DSPSECA

Via IBM Navigator for i : Security > MFA Configuration > Security Configuration Information

5.3 Activer l'attribut de sécurité

CHGSECA ADLSGNFAC(*ENABLED)

Si la politique SST bloque la modification (message d'erreur) :

CHGSSTSECA CHGADLSGN(*YES)

Vous pouvez contrôler par DSPSSTSECA.

Puis relancer :

CHGSECA ADLSGNFAC(*ENABLED)

Via IBM Navigator for i :

1. Security > MFA Configuration
2. Cliquer sur Security Configuration Information
3. Clic droit sur Additional Signon Factor → Change
4. Sélectionner Enabled dans la liste déroulante
5. Cliquer Save

Pour verrouiller l'attribut après configuration et empêcher toute modification ultérieure via OS (nécessite alors de passer par SST) :

CHGSSTSECA CHGADLSGN(*NO)

Avant IPL, vous devez avoir :

5.4 IPL obligatoire

Le passage de *DISABLED à *ENABLED nécessite un IPL pour prendre effet. Tant que l'IPL n'a pas eu lieu, la valeur est en attente (pending).

Après l'IPL, les écrans de connexion afficheront un champ "Facteur additionnel".

Après IPL, la saisie du facteur optionnel est disponible dans les différentes interfaces :

5.5 Enregistrer l'exit program *REGFAC (optionnel)

Si vous souhaitez utiliser la méthode *REGFAC pour appeler un programme de validation supplémentaire :

ADDEXITPGM EXITPNT(QIBM_QSY_AUTH) FORMAT(AUTH0100) PGMNBR(1) +
           PGM(ma_bib/mon_pgm_exit) REPLACE(*YES) CRTEXITPNT(*NO) +
           PGMDTA(*JOB *CALC 20)

Le délai d'attente par défaut de l'exit program est 10 secondes. Le paramètre PGMDTA(*JOB *CALC 20) le passe à 20 secondes dans l'exemple ci-dessus.

Via IBM Navigator for i :

1. Security > MFA Configuration
2. Cliquer sur Authentication Exit Point
3. Clic droit sur QIBM_QSY_AUTH → Add Exit Program
4. Renseigner le programme et la bibliothèque
5. Cliquer OK

On en parle plus en détail ensuite.

6. Déploiement — Actions utilisateur

Rappel fondamental : l'administrateur ne peut pas générer la clé TOTP à la place de l'utilisateur. Chaque utilisateur doit générer la sienne en étant connecté avec son propre profil.

6.1 Génération de la clé TOTP via commande CL

L'utilisateur se connecte avec son profil, puis exécute :

CHGTOTPKEY TOTPKEY(*GEN)

L'écran affiche :

• La clé TOTP encodée en base32 (avec et sans espaces).
• La clé de récupération — à copier immédiatement et conserver en lieu sûr.
• La touche F9=Vérifier TOTP pour valider la configuration.

Avec F9 vous pouvez saisir le code TOTP renvoyé par votre application après configuration manuelle :

Une clé peut aussi être spécifiée manuellement (si elle provient d'un autre système) :

CHGTOTPKEY TOTPKEY('PGWGKZ6T7RRYAZLGPPDJMHFNCRYQMDAF')

6.2 Génération de la clé TOTP via IBM Navigator for i

Deux cas selon les droits de l'utilisateur :

Utilisateur sans accès à QIBM_NAV_ALL_FUNCTION :

• Après connexion à Navigator for i, le panneau Manage My MFA Key s'affiche automatiquement.

Utilisateur avec QIBM_NAV_ALL_FUNCTION :

• My Work > My Additional Authentication Factor > Manage My MFA Key

Procédure :

1. Sélectionner Generate and save a MFA key and recovery key for this user profile
2. Cliquer Next
3. Sur le panneau Validate MFA Key and Save Recovery Key :
   • Scanner le QR code avec l'application d'authentification, ou
   • Saisir manuellement la valeur du champ Saved MFA key dans l'application
4. Valider : saisir le mot de passe et le code généré par l'application → Validate
5. Sauvegarder la clé de récupération dans un endroit sûr (coffre de mots de passe, document chiffré...)
6. Notifier l'administrateur que la clé est configurée

Exemple pour un utilisateur avec QIBM_NAV_ALL_FUNCTION

L'affichage suivant présente votre clé à insérer dans votre application (ou via QRCode). N'oubliez pas la clé de récupèration à stocker dans un endroit sécurisé.

Une fois votre application configurée, saisissez votre mot de passe et code TOTP et valider pour confirmer la configuration.

Exemple pour un utilisateur sans QIBM_NAV_ALL_FUNCTION

6.3 Configuration de l'application d'authentification

L'application doit être configurée avec la clé TOTP :

• En scannant le QR code affiché sur l'écran Navigator for i, ou
• En saisissant manuellement la clé encodée en base32 (sans espaces).

Une fois configurée, l'application génère un nouveau code à 6 chiffres toutes les 30 secondes.

6.4 Validation de la configuration

CHKTOTP

L'utilisateur saisit le code généré par son application. Si la validation réussit, la configuration est correcte.

Depuis l'écran CHGTOTPKEY, appuyer sur F9=Check TOTP pour accéder directement à CHKTOTP.

7. Activation du MFA sur les profils utilisateur

7.1 Vérifier qu'un utilisateur a une clé TOTP

DSPUSRPRF USRPRF(NB)

Chercher le champ :

La clé TOTP existe . . . . . . . . . . . . :   Oui   
Date de la dernière modification de la clé   
  TOTP . . . . . . . . . . . . . . . . . . :   20/07/26  13:53:29
Méthodes d'authentification  . . . . . . . :   *NONE   
Intervalle facultatif du TOTP  . . . . . . :   *NONE

Pour voir tous les profils et leurs attributs MFA :

DSPAUTUSR

Appuyer F11 deux fois pour afficher la vue "Additional Authentication Info".

Exemple de sortie DSPAUTUSR :

Afficher les utilisateurs autorisés  
                        
                                    La        Dernière  Intervalle   Minutes  
                                    clé       modif     facultatif  restantes 
Profil      Profil      Méth        TOTP      clé           du         TOTP   
utilisat    groupe      auth        existe    TOTP         TOTP     facultatif
JL                      *NONE       Non                      0           0  
JL2                     *NONE       Non                      0           0  
NB                      *NONE       Oui       20/07/26       0           0  
PLB                     *NONE       Non                      0           0

Via IBM Navigator for i :

• Security > MFA Configuration > Users
• La liste est filtrée par défaut sur les profils ayant une clé MFA configurée.

7.2 Activer la méthode *TOTP

CHGUSRPRF USRPRF(NOM_PROFIL) AUTHMTH(*TOTP)

Via IBM Navigator for i :

• Security > MFA Configuration > Users
• Clic droit sur le profil → Enable Users for MFA authentication

Après quoi :

L'utilisateur doit désormais s'authentifier via mot de passe + TOTP (sinon CPF1120) :

7.3 Configurer l'intervalle optionnel

Si l'intervalle n'est pas configuré, vous pouvez obtenir ce genre de message :

Modifiez par :

CHGUSRPRF USRPRF(NOM_PROFIL) AUTHMTH(*TOTP) TOTPOPTITV(60)

Ou :

Via IBM Navigator for i :

• Security > MFA Configuration > Users
• Clic droit → Properties
• Section Additional Authentication Options → champ Optional Interval

Si l'utilisateur s'est déjà connecté avec TOTP et que le délai d'expiration n'est pas atteint : vous pouvez mettre n'importe quelle valeur dans le facteur optionnel, ce dernier ne semble pas testé.

7.4 Activer la méthode *REGFAC

CHGUSRPRF USRPRF(NOM_PROFIL) AUTHMTH(*REGFAC)

Via IBM Navigator for i :

• Clic droit sur le profil → Enable Users for Exit Program Authentication

7.5 Combiner *TOTP et *REGFAC

CHGUSRPRF USRPRF(NOM_PROFIL) AUTHMTH(*TOTP *REGFAC) TOTPOPTITV(*NONE)

7.6 Afficher les attributs MFA d'un profil

DSPUSRPRF USRPRF(NOM_PROFIL)
DSPAUTUSR    /* F11 deux fois pour la vue MFA */

Via Navigator for i :

• Security > MFA Configuration > Users
• Clic droit → Properties (affiche les minutes restantes de l'intervalle actif)

8. Fonctions avancées

8.1 Exit point *REGFAC — QIBM_QSY_AUTH

Principe

La méthode *REGFAC permet d'appeler un programme exit personnalisé après chaque authentification réussie. Ce programme peut effectuer n'importe quelle vérification supplémentaire et retourner succès ou échec.

Cas d'usage typiques :

• Push notification vers un téléphone avec confirmation biométrique.
• Intégration avec une solution MFA d'entreprise existante.
• Vérification géographique ou horaire (l'authentification vient-elle d'une IP autorisée, à un horaire acceptable ?).
• Intégration avec un SOAR/SIEM.

Note critique : si *REGFAC est la seule méthode et que le programme exit ne fait rien de particulier, cela ne constitue pas une protection MFA. Le programme est seul responsable de la vérification additionnelle.

Interfaces déclenchantes

L'exit program est appelé pour :

• Sign-on (connexion 5250, ACS, Navigator, SSH...)
• Get Profile Handle (QSYGETPH, QsyGetProfileHandle...)
• Generate Profile Token (QSYGENPT, QsyGenPrfTkn...)
• NetServer (accès fichiers réseau)
• Kerberos et SSH (via l'interface d'association du profil à l'authentification)

Pour les API Get Profile Handle : l'authentification a lieu lors de l'appel get. Si le programme exit valide la création du handle, les appels set ultérieurs avec ce handle sont autorisés.

Exemple de programme

Comportement

1. Le programme doit être thread safe, il sera appelé dans des environnements multi-thread
2. Si aucun programme n'est paramétré dans le point d'exit, le contrôle est ignoré (pas de blocage des authentifications)
3. Le programme doit répondre dans un délai par défaut de 10 secondes. Vous pouvez modifier cette valeur :

ADDEXITPGM EXITPNT(QIBM_QSY_AUTH) FORMAT(AUTH0100) PGMNBR(1) 
           PGM(USEREXIT/AUTHEXIT) REPLACE(*YES) CRTEXITPNT(*NO) PGMDTA(*JOB *CALC 20)

4. Le programme doit respecter l'interface attendu par le point d'exit :
   • 1 paramètre en entrée au format AUTH0100
   • 1 paramètre en sortie, de type entier, indiquant si l'authentification réussie ou non
5. le prgoramme peut s'éxecuter avec des profils différents en fonction de l'interface : profil utilisateur pour les interactifs, QUSER_NC pour QZBSCNNSRV (Host connection server), QSECOFR_NC pour QP0ZSPWT (PASE)...
6. Vous ne maitrisez donc pas obligatoirement la liste de bibliothèque (dans ce genre de programme on peut se permettre de qualifier tous les éléments)

Notre programme est fait pour les tests, certains choix sont ici pour permettre de matérialiser des informations.

• Options de compilation

  

• Format du point d'exit

  

• Interface du programme

  

• Quelques variables

  

• Les règles de contrôle

  

• Récupèration du facteur additionnel si transmis

  

• On loggue

  

• La table

  

On voit que le programme est déclenché dans le travail :

Dans notre fichier de log :

Votre programme n'est appelé que si le profil est configuré pour *REGFAC.

Votre programme ne reçoit la valeur du facteur supplémentaire uniquement si *TOTP n'est pas configuré poru le profil.

Certains outils qui lancent plusieurs connexions (ie VSCode) : vous pouvez désactiver votre profil en 1 fois !

APIs avec paramètres d'information additionnelle

8.2 QIBM_RUN_UNDER_USER_NO_AUTH — Protection contre l'usurpation de profil

Problème

Même avec le MFA activé, un utilisateur disposant de *ALLOBJ peut se substituer à un autre profil sans connaître son mot de passe, en utilisant des valeurs spéciales (*NOPWD, *NOPWDCHK) sur des APIs comme QSYGETPH ou la commande SBMJOB USER(xxx).

Cette possibilité contredit les principes du MFA : pourquoi forcer un utilisateur à s'authentifier avec TOTP si quelqu'un d'autre peut "devenir" cet utilisateur sans aucune authentification ?

Solution : QIBM_RUN_UNDER_USER_NO_AUTH

La fonction ID QIBM_RUN_UNDER_USER_NO_AUTH permet de protéger un profil contre cette usurpation.

• Par défaut, tous les profils sont en *ALLOWED (usurpation autorisée, pour la compatibilité ascendante).
• Mettre un profil en *DENIED fait échouer toute opération tentant d'utiliser ce profil comme cible sans authentification préalable.
• Ce n'est pas le profil en *DENIED dont les actions sont restreintes — c'est les autres profils qui ne peuvent plus l'usurper.

Note importante : QIBM_RUN_UNDER_USER_NO_AUTH n'exige pas que le MFA soit activé sur le système. Tout profil interactif peut être protégé, indépendamment du MFA.

Configuration

Via commande CL :

CHGFCNUSG FCNID(QIBM_RUN_UNDER_USER_NO_AUTH) USER(NOM_PROFIL) USAGE(*DENIED)

Via IBM Navigator for i :

1. Security > MFA Configuration > Users
2. Effacer le filtre MFA Key Exists → Apply (pour voir tous les profils)
3. Les profils déjà en *DENIED affichent DENIED dans la colonne Impersonation
4. Clic droit sur le profil → Properties
5. Cocher Restrict the ability to impersonate this user profile without first doing authentication
6. Cliquer OK

Exemples

Exemple 1 — QSYGETPH avec NOPWD

Notre programme de test pour appel de l'API :

NB est en *ALLOWED sur QIBM_RUN_UNDER_USER_NO_AUTH. QSECOFR (avec *ALLOBJ) exécute :

CALL USURP
Profile handle:    █v¾%q█cNÃ  ExceptionID:   BytesAvailable: 0

→ OK

On passe maintenant NB en *DENIED sur QIBM_RUN_UNDER_USER_NO_AUTH.

CHGFCNUSG FCNID(QIBM_RUN_UNDER_USER_NO_AUTH) USER(NB) USAGE(*DENIED)

Puis :

CALL USURP
Profile handle:               ExceptionID: CPF4AF1  BytesAvailable: 26

→ Échec : CPF4AF1 — Opération non autorisée pour le profil utilisateur &1.

Le texte de 2nd niveau indique clairement :

Texte de message formaté   
                                                            Système:   ITEST10 
 ID message . . . . . . . . . :   CPF4AF1  
 Fichier de messages  . . . . :   QCPFMSG  
   Bibliothèque . . . . . . . :     QSYS   
                                         
 Message . . . . :   Opération non autorisée pour le profil utilisateur &1.  
 Cause . . . . . :   Le profil utilisateur &1 n'a pas accès à l'ID   
   d'utilisation de fonction QIBM_RUN_UNDER_USER_NO_AUTH. Il ne peut pas être  
   l'utilisateur cible pour l'opération demandée.  
 Que faire . . . :   Utilisez une autre opération qui ne nécessite pas d'accès 
   à l'ID d'utilisation de fonction ou retirez le profil utilisateur de la   
   liste d'utilisation de fonction QIBM_RUN_UNDER_USER_NO_AUTH, puis réessayez.

Exemple 2 — SBMJOB USER

NB est en *ALLOWED sur QIBM_RUN_UNDER_USER_NO_AUTH. QSECOFR exécute :

SBMJOB CMD(SNDMSG MSG('OK !') TOUSR(QSECOFR)) JOB(NOTIFNB) USER(NB)

→ OK

On passe maintenant NB en *DENIED sur QIBM_RUN_UNDER_USER_NO_AUTH.N

CHGFCNUSG FCNID(QIBM_RUN_UNDER_USER_NO_AUTH) USER(NB) USAGE(*DENIED)

QSECOFR exécute :

SBMJOB CMD(SNDMSG MSG('OK !') TOUSR(QSECOFR)) JOB(NOTIFNB) USER(NB)
Opération non autorisée pour le profil utilisateur NB.   
Non autorisé au profil utilisateur NB.   
Erreurs dans la commande SBMJOB.

→ Échec : CPF4AF1 — Opération non autorisée pour le profil utilisateur &1.

Vrai également pour les tâches planifiées !

Profils IBM fournis _NC

IBM fournit des profils avec le suffixe _NC ("not changeable") : QSECOFR_NC, QPGMR_NC, QSYSOPR_NC, QUSER_NC.

Ces profils :

• Sont identiques aux profils correspondants sans _NC.
• Ne peuvent pas être modifiés et n'ont pas de mot de passe.
• Ne peuvent pas être mis en *DENIED sur QIBM_RUN_UNDER_USER_NO_AUTH.
• Sont utilisés dans les processus système (soumission de jobs, profile handles, serveurs).
• Les applications doivent utiliser ces profils si le profil non-NC est mis en *DENIED.

Les profils QSECOFR, QPGMR, QSYSOPR et QUSER sont désormais les vôtres.

8.3 Audit d'avertissement pour QIBM_RUN_UNDER_USER_NO_AUTH

Avant de mettre un profil en *DENIED, il est prudent d'activer l'audit d'avertissement pour vérifier quelles opérations seraient bloquées.

Étape 1 — Activer l'audit système

/* Vérifier que QAUDCTL contient *AUDLVL */
CHGSECAUD QAUDLVL(*AUTFAIL)   /* ou via CHGSYSVAL SYSVAL(QAUDCTL) VALUE('*AUDLVL') */

Via Navigator : Security > Audit journal > Audit journal configuration → cocher Enable action auditing (*AUDLVL)

Étape 2 — Activer l'audit sur le profil cible

CHGUSRAUD USRPRF(NOM_PROFIL) AUDLVL(*AUTWARN)

Via Navigator : Users and Groups > Users → clic droit → Properties > Capabilities > Auditing → cocher Authorization failure warnings

Étape 3 — Analyser les enregistrements GR-F *USAGEWARN

Les enregistrements d'audit de type GR, sous-type F, avec *USAGEWARN dans le champ 1 sont générés lorsque le profil serait bloqué s'il était en *DENIED.

select *
  from table (
    SYSTOOLS.AUDIT_JOURNAL_GR(STARTING_TIMESTAMP => current timestamp - 2 hours, USER_NAME => 'NB') ) gr
  where gr.entry_type = 'F'

Opérations journalisées dans le champ 3 :

Via Navigator avec la gestion des magasins de données (journal d'audit) :

Observer ces enregistrements pendant quelques jours/semaines avant de basculer en *DENIED. Si des opérations légitimes apparaissent, les corriger (utiliser les profils _NC, adapter les applications) avant d'activer la restriction.

8.4 Tokens de profil améliorés (Enhanced Profile Tokens)

Un token de profil peut être transmis à d'autres processus pour qu'ils exécutent des actions au nom de l'utilisateur authentifié. Les tokens améliorés ajoutent une couche de protection.

Paramètres additionnels

• Verification ID : valeur définie par l'application identifiant l'usage spécifique du token (application, service, action). Le même Verification ID doit être fourni lors de l'utilisation du token.
• Remote IP : adresse IP réseau associée au token. La même IP doit être fournie lors de l'utilisation.

Ces valeurs ne peuvent pas être extraites du token, mais sont transmises à QIBM_QSY_AUTH avant la génération si le profil a *REGFAC.

Les tokens améliorés protègent contre les attaques de replay et pre-play.

APIs pour les tokens améliorés

La génération d'un token de profil de type multiple-use, regenerable nécessite des valeurs de token amélioré dans certaines configurations. Voir l'API QSYGENPT pour les détails.

8.5 Mirroring de la clé TOTP entre systèmes

Dans les environnements multi-systèmes (HA, DR, développement/production), il peut être nécessaire de répliquer la clé TOTP d'un utilisateur d'un système à un autre pour qu'il puisse utiliser la même clé TOTP partout.

APIs disponibles

Retrieve TOTP Key (QSYRTVK)

• Requiert *ALLOBJ + *SECADM
• Retourne une version protégée de la clé TOTP (ne peut pas être utilisée directement)
• À utiliser en tandem avec QSYSETK

/* Documentation : */
/* https://www.ibm.com/docs/api/v1/content/ssw_ibm_i_76/apis/qsyrtvk.htm */

Set TOTP Key (QSYSETK)

• Requiert *ALLOBJ + *SECADM
• Définit la clé TOTP à partir du résultat de QSYRTVK
• Réinitialise les minutes restantes de l'intervalle optionnel à 0
• Met à jour la date de modification de la clé TOTP et du profil
• Ne peut pas être utilisé pour mettre la clé à *NONE si *TOTP est la méthode d'authentification

/* Documentation : */
/* https://www.ibm.com/docs/api/v1/content/ssw_ibm_i_76/apis/qsysetk.htm */

Check TOTP Key (QSYCHKK) — PTF 5770SS1 V7R6M0 SJ05455

• Vérifie si la clé TOTP d'un profil correspond à celle récupérée par QSYRTVK
• Utilisé par une application de mirroring pour détecter si la clé a changé
• Un échec incrémente le compteur d'authentifications invalides du profil

/* Documentation : */
/* https://www.ibm.com/docs/api/v1/content/ssw_ibm_i_76/apis/qsychkk.htm */

9. Combinaisons de méthodes — niveaux de sécurité

Il existe 12 combinaisons courantes selon la méthode d'authentification, l'intervalle optionnel et l'accès à QIBM_RUN_UNDER_USER_NO_AUTH.

9.1 Accès et impacts de QIBM_RUN_UNDER_USER_NO_AUTH

QIBM_RUN_UNDER_USER_NO_AUTH *ALLOWED :Les tentatives d'exécution sous ces profils via une interface ne nécessitant pas de mot de passe (SBMJOB USER=xxx, QSYGETPH avec NOPWD...) sont autorisées.

QIBM_RUN_UNDER_USER_NO_AUTH *DENIED : Les tentatives d'exécution sous ces profils sans authentification préalable échouent avec CPF4AF1.

¹ Fadhila représente le profil le plus sécurisé possible, sous réserve que l'exit program exige une authentification hors bande (push notification + biométrie par exemple).

9.2 Recommandations

• Comptes à privilèges (*ALLOBJ, *SECADM, *JOBCTL) : configurer au minimum *TOTP + QIBM_RUN_UNDER_USER_NO_AUTH *DENIED.
• Utilisateurs standards : commencer par *TOTP avec un intervalle raisonnable (30-60 min).
• Comptes de service / batch : ne pas activer *TOTP (les jobs batch ne peuvent pas saisir un code TOTP). Ne pas mettre ces profils en *DENIED sur QIBM_RUN_UNDER_USER_NO_AUTH.
• Déploiement progressif : commencer par les comptes les plus exposés, puis étendre progressivement.

10. Compatibilité applicative

10.1 Applications compatibles sans modification

Ces applications utilisent le Host Connection Server et gèrent nativement le MFA :

Ces trois applications utilisent la substitution de mot de passe (hash unidirectionnel) : le format password:TOTP ne fonctionne pas. Il faut impérativement utiliser le champ "Additional factor".

10.2 Applications nécessitant des modifications

IBM Toolbox for Java

• Si la connexion utilise User ID + Password et que le profil a *TOTP, il faut spécifier le facteur additionnel sur l'objet Java utilisé avant connexion :

  // La classe AS400 dispose de constructeurs acceptant un facteur additionnel
  AS400 system = new AS400("monsysteme", "monuser", "monmotdepasse", "123456");
  

• Les applications Toolbox qui utilisent les credentials du job courant peuvent rencontrer des erreurs si le profil du job a *TOTP. Elles doivent être modifiées pour obtenir et définir la valeur TOTP sur l'objet AS400.
• Par défaut, les tokens de profil améliorés sont créés si le serveur IBM i les supporte. Pour désactiver : option JVM com.ibm.as400.access.AS400.useEnhancedProfileTokens=false.
• Pour créer plusieurs objets AS400 avec le même user/password/TOTP sans intervalle optionnel : utiliser le premier objet AS400 comme paramètre du constructeur des objets suivants.

ACS en batch / commandes directes sur IBM i

Si ACS est exécuté directement sur IBM i (interactivement ou en batch) et que le job courant a *TOTP, une erreur d'authentification se produit dans ces conditions :

• L'intervalle optionnel est *NONE.
• L'intervalle optionnel est positif mais expiré.

→ En job interactif : ACS invite l'utilisateur à saisir ses credentials + TOTP. → En job batch : le job reste en attente indéfiniment.

10.3 Applications avec mot de passe mis en cache

Ces applications stockent le mot de passe et s'authentifient silencieusement en arrière-plan. Elles échouent avec le MFA en mode absolu (TOTPOPTITV(*NONE)) car le code TOTP a expiré.

Stratégie recommandée : configurer un intervalle optionnel suffisant pour couvrir la durée d'utilisation de l'application.

CHGUSRPRF USRPRF(NOM_PROFIL) TOTPOPTITV(60)

L'utilisateur s'authentifie une première fois (via ACS ou Navigator), puis l'application peut fonctionner pendant 60 minutes.

10.4 Format password:TOTP — Interfaces sans champ dédié

Pour les interfaces qui n'ont pas de champ "Additional factor" :

Éduquer les utilisateurs : l'invite SSH affiche simplement "password" sans indication du format attendu. Les utilisateurs doivent être informés qu'ils doivent ajouter : + code TOTP.

Pour FTP par exemple, voici un script .bat permettant de tester :

On obtient dans ftp.log :

Connect‚ … itest10.gaia.lan.
220-QTCP at ITEST10.GAIA.LAN.
220 Connection will close if idle more than 5 minutes.
501 OPTS unsuccessful; specified subcommand not recognized.
331 Enter password.
530 Log on attempt by user NB rejected.
221 QUIT subcommand received.

Avec l'ajout du TOTP :

Et la log indique :

Connect‚ … itest10.gaia.lan.
220-QTCP at ITEST10.GAIA.LAN.
220 Connection will close if idle more than 5 minutes.
501 OPTS unsuccessful; specified subcommand not recognized.
331 Enter password.
230 NB logged on.
200 Representation type is ASCII nonprint.
250-NAMEFMT set to 1.
250 "/home/NB" is current directory.
200 PORT subcommand request successful.
150 Retrieving file /home/NB/curl.log
226 File transfer completed successfully.
ftp : 2756 octets reçus en 0.
00 secondes … 2756.00 Ko/s.
221 QUIT subcommand received.

Cas de Code for IBM i (Visual Studio Code)

Si vous activez MFA sur votre profil développeur, il est conseillé de se connecter avec une clé SSH.

Lors de nos tests, Code for IBM i a refusé notre clé au format PPK, fonctionnelle sur le même système avec d'autres outils.

La connexion a réussi avec un export de la clé privée au format openSSH vie PuttyGen :

Code for IBM i tente ensuite de se connecter à plusieurs services. Vous pouvez donc avoir ce genre de message :

C'est dû au règlage d'intervalle pour le profil :

Mettez une valeur raisonnable.

Avant de pouvoir se connecter à Code for IBM i : se connecter via une interface qui supporte le TOTP de façon explicite (telnet par exemple), afin que l'authentification soit mise en cache pour l'intervalle configuré.

10.5 Applications incompatibles ou nécessitant des ajustements

Ces applications ne fonctionnent pas si l'intervalle optionnel de l'utilisateur a expiré :

• QFileSrv.400
• NetServer
• DRDA/DDM (Connect SQL supporte le format password:totp)
• Passthrough
• QNTC
• IBM i Access ODBC Driver
• IBM.Data.DB2.iSeries data provider
• IBMDA400, IDMDASQL, IBMDARLA (ADO et OLE DB)

Interfaces définitivement incompatibles :

• Network File System (NFS) : si le profil est MFA, l'accès est redirigé vers l'utilisateur anonyme de l'export.
• HTTP basic authentication sur IWS : l'IWS server ne supporte pas *TOTP pour les web services qu'il protège directement. Solution : utiliser IBM HTTP Server en frontal, qui supporte le format password:totp.
• Opérations de cluster IBM i : la plupart échouent si l'utilisateur a *TOTP ou *REGFAC.
• IBM Toolbox for Java — proxy server : non supporté pour les profils avec *TOTP.

Fix Central :

11. MFA SST/DST

11.1 Présentation

System Service Tools (SST) et Dedicated Service Tools (DST) disposent d'une implémentation MFA indépendante du MFA OS.

Points clés :

• La clé TOTP d'un profil SST est totalement distincte de la clé TOTP du profil OS correspondant — même si le profil SST est lié à un profil OS.
• Un administrateur SST peut activer le MFA pour SST sans activer le MFA OS.
• L'environnement SST/DST limité ne supporte pas les solutions MFA tierces classiques (pas d'exit points, Kerberos non supporté) — le MFA natif SST comble ce manque.

Ne nécessite aucun accès internet.

L'horloge doit être synchronisée.

11.2 Différences avec le MFA OS

11.3 Nouveaux attributs SST

Un profil SST dispose de ces nouveaux attributs :

• TOTP key exists : indique si l'utilisateur SST a établi une clé TOTP.
• Authentication Method : TOTP ou NONE (défaut).

11.4 Commandes SST

11.5 Procédure d'activation SST

1. L'administrateur SST active le TOTP sur la connexion SST. STRSST puis option 8. Work with Service Tools Server Security and Devices puis option 5. Work with service tools security options

   

   A partir de maintenant :

   

2. L'utilisateur SST génère sa clé TOTP.

   1. Soit par la commande CHGSSTKEY

      

      Affiche :

      

   2. Soit depuis les menus SST

      

      

3. Il configure son application d'authentification.

4. Il sauvegarde la clé de récupération.

5. SST force la vérification du facteur TOTP avant de sauvegarder la clé.

   

6. L'administrateur SST active le TOTP sur le profil SST de l'utilisateur.

   Soit depuis les menus SST :

   

   Soit par la commande CHGSSTUSR :

   

7. À partir de ce moment, le code TOTP est requis à chaque authentification SST.

   

12. Référence rapide

12.1 Commandes CL

12.2 APIs TOTP

12.3 Checklist déploiement — Administrateur système

• Vérifier QSECURITY ≥ 40
• Vérifier QPWDLVL = 4 et évaluer les impacts
• Adapter l'écran de connexion personnalisé si nécessaire (QDSIGNON3)
• Vérifier la synchronisation NTP (QTIMADJ)
• Configurer TLS sur les Host Servers et Navigator for i
• Exécuter CHGSECA ADLSGNFAC(*ENABLED)
• Planifier et exécuter l'IPL
• Vérifier le champ "Facteur additionnel" sur les écrans de connexion
• Enregistrer l'exit program QIBM_QSY_AUTH si nécessaire
• Mettre à jour la documentation de reprise d'activité (attribut non restauré)

12.4 Checklist déploiement — Utilisateur

• Se connecter avec son propre profil IBM i
• Exécuter CHGTOTPKEY TOTPKEY(*GEN) ou se connecter à Navigator
• Sauvegarder la clé de récupération (coffre, document chiffré)
• Configurer l'application d'authentification (QR code ou saisie manuelle)
• Valider avec CHKTOTP (ou F9 depuis CHGTOTPKEY)
• Notifier l'administrateur que la clé est configurée

12.5 Checklist activation — Administrateur par profil

• Vérifier que l'utilisateur a une clé TOTP (DSPUSRPRF ou DSPAUTUSR)
• Définir la méthode : CHGUSRPRF USRPRF(xxx) AUTHMTH(*TOTP)
• Définir l'intervalle optionnel selon le profil de risque
• Évaluer si QIBM_RUN_UNDER_USER_NO_AUTH *DENIED est approprié
• Activer l'audit d'avertissement avant de mettre en *DENIED (CHGUSRAUD AUDLVL(*AUTWARN))
• Informer l'utilisateur de la procédure sur les interfaces sans champ dédié (SSH, FTP...)
• Tester la connexion avec l'utilisateur

12.6 Références documentaires

• IBM i 7.6 — Multi-factor authentication (MFA)
• IBM i Integrated MFA — IBM Support
• IBM i – Enabling MFA: Technical Guide
• Service tools MFA (SST/DST)
• Host Connection Server
• API QSYRTVK — Retrieve TOTP Key
• API QSYSETK — Set TOTP Key
• IBM-supplied function IDs — QIBM_RUN_UNDER_USER_NO_AUTH