Le Firefighter centralisé ne démarre plus après une migration RISE : KBA SAP 2314735

Un paysage où SAP GRC Access Control reste on premise pendant que les systèmes ERP managés migrent vers RISE with SAP produit une panne aussi précise que déroutante. Tout ce que GRC fait via le connecteur RFC continue de fonctionner : Access Risk Analysis renvoie des résultats, Access Request Management provisionne, le monitoring continu des contrôles de Process Control collecte, et le Firefighter décentralisé (/GRCPI/GRIA_EAM) dans le système plugin se comporte normalement. Une seule chose s'arrête : appuyer sur Logon dans le logon pad Firefighter centralisé de GRAC_EAM. L'ID Firefighter passe au rouge et aucune fenêtre de session ne s'ouvre.

Rien dans la couche GRC ne l'explique, et c'est pourquoi ces tickets durent des semaines, à parcourir les paramètres de connecteur, les types d'utilisateur, les objets d'autorisation et les listes de notes. La cause se situe une couche plus bas, et SAP la documente dans la KBA 2314735 — Remote Logon through an RFC Destination does not work.

À quoi ressemble la panne des deux côtés

Le symptôme est asymétrique, et cette asymétrie est le premier indice utile. Sur le hub GRC, le logon semble réussir :

• La session Firefighter est créée. GRAC_FFSESSION l'affiche, et la synchronisation des logs récupère les documents de modification.
• Les documents de modification sur l'ID Firefighter montrent le déverrouillage et la réinitialisation du mot de passe : la chaîne côté serveur s'est donc exécutée.
• Le syslog montre le hub créant sa destination RFC temporaire pour la session, puis la supprimant : le flux de logon s'est donc terminé sans lever d'exception.
• ST22 est vide, SLG1 est vide, et il n'y a aucun échec d'autorisation dans SU53, ni pour l'ID Firefighter ni pour l'utilisateur RFC.

Dans le système plugin, au même instant (attention au décalage de fuseau horaire entre les deux systèmes quand vous comparez), le syslog montre l'inverse : Transaction Canceled, message D01, sous l'utilisateur Firefighter, sans code transaction. La session a été terminée à son établissement, à l'intérieur du programme de logon SAPMSYST.

Cette combinaison contient tout le diagnostic en miniature. Le hub considère le logon réussi parce que SYSTEM_REMOTE_LOGIN renvoie sy-subrc 0 avec un message d'erreur vide ; aucune exception n'est levée, donc le programme de logon GRC n'écrit aucun statut d'erreur et rien n'arrive dans le log applicatif. Le démarrage du GUI sur la destination temporaire échoue silencieusement. Pendant ce temps, la cible a annulé la session qu'elle avait commencé à construire, parce qu'elle ne pouvait délivrer d'écran à personne.

Le test qui sort GRC du débat

Avant de toucher au moindre paramètre GRC, reproduisez la panne sans GRC. Dans SM59 sur le hub GRC, ouvrez la destination du plugin et utilisez le bouton Remote Logon.

• Test de connexion : réussi.
• Remote Logon : rien. Pas de nouvelle fenêtre, pas de message, pas de dump.

C'est exactement le symptôme de la KBA 2314735, et il vaut la peine de l'acter tôt : il reformule le problème de « le Firefighter est cassé » vers « le remote logon sur cette destination RFC est cassé », ce qui devient une question basis et réseau plutôt qu'une question GRC. Le logon Firefighter centralisé est un remote logon. Le hub GRC crée une destination temporaire pour la session et appelle le remote logon dessus ; si le Remote Logon de SM59 ne fonctionne pas sur la destination permanente, la destination temporaire n'a aucune chance.

Maintenir un utilisateur dialogue avec mot de passe dans la destination et retenter le Remote Logon est une preuve complémentaire raisonnable, et cela échoue de la même manière. Un Remote Logon muet avec un test de connexion vert n'est pas un problème d'authentification.

Pourquoi le reste de GRC continue de fonctionner

C'est la partie qui rend le ticket circulaire si personne ne l'énonce explicitement.

Ce qui reste est la seule chose dont seul le Firefighter centralisé a besoin, et qu'aucun élément de cette liste n'exerce : une connexion ouverte depuis le système cible vers l'appelant, transportant l'écran SAP GUI.

Le mécanisme

Un remote logon ne peut pas utiliser la connexion RFC elle-même comme support des données GUI, par exemple un écran de logon. Le système cible établit donc une connexion retour distincte vers le système appelant.

Au lancement du remote logon, le système appelant transmet sa propre adresse IP avec la demande de logon. Le système cible résout de son côté le nom d'hôte de l'appelant. Si ces deux valeurs divergent, la cible ne peut pas ouvrir la connexion retour, l'appelant ne reçoit jamais l'écran de logon, et le remote logon est impossible. La KBA 2314735 l'illustre avec deux systèmes dont la résolution de noms n'est pas unique :

L'appelant annonce 10.1.2.3. La cible résout abchost vers 100.1.2.3, qui n'est pas l'adresse qu'on lui a donnée, et s'arrête là. Le même effet se produit lorsque les deux systèmes sont reliés par un SAProuter : la résolution de noms peut être parfaitement cohérente et la cible ne peut malgré tout pas joindre l'appelant directement.

Une migration vers un tenant cloud managé crée précisément cette asymétrie. Le hub GRC reste dans le réseau d'entreprise avec son adresse interne ; le système plugin vit désormais dans le réseau du fournisseur, atteint le réseau d'entreprise via une passerelle ou un peering, et résout les noms d'hôtes d'entreprise via des forwarders qui peuvent ne pas résoudre le hub du tout. Rien dans le chemin RFC aller n'est affecté, et c'est pourquoi toutes les autres fonctions GRC sont intactes. Nous avons observé le même comportement sur un second tenant managé, sans lien avec le premier, alors que les systèmes non migrés du même paysage continuaient de fonctionner : ce n'est donc pas un accident de migration isolé.

La résolution propre, selon la KBA, consiste à faire résoudre le nom d'hôte du système appelant vers la même adresse IP dans les deux systèmes. Dans un paysage hybride, c'est souvent hors d'atteinte, et c'est à cela que sert le workaround.

Le correctif : la destination loopback

Deux étapes, toutes deux dans le système cible, c'est-à-dire le système plugin qui doit ouvrir la connexion retour.

1. Paramètre de profil d'instance. Positionnez rdisp/use_rfc_dest_lookup = ON dans le profil d'instance des instances du système cible. Les instances concernées doivent être redémarrées : c'est donc un changement planifié, pas une bascule RZ11 que l'on annule en quelques secondes.

2. Destination loopback. Créez une destination RFC supplémentaire dans le système cible, nommée d'après le système appelant et portant de bout en bout les données de connexion du système appelant :

Deux détails de ce tableau sont là où le workaround échoue le plus souvent en pratique :

• Les options gateway sont celles de l'appelant, et elles sont obligatoires. La connexion retour est ouverte via le gateway du système appelant : les champs Gateway host et Gateway service doivent donc porter l'hôte de l'appelant et son sapgwNN. Une destination loopback dont seul le Target host est renseigné, avec les champs gateway vides, paraît plausible, passe le test de connexion, et ne corrige pas le logon. C'est la raison numéro un du « nous avons créé la destination et rien n'a changé ».
• Aucune donnée de logon. La destination existe pour décrire une route de retour, pas pour connecter quiconque. Si vous y maintenez un utilisateur, vous construisez autre chose.

Si un SAProuter est impliqué, la router string se préfixe à la fois au Target host et au Gateway host.

Lancez le test de connexion sur la destination loopback. Une fois qu'il passe, le remote logon du système appelant vers le système cible doit fonctionner, et avec lui le logon Firefighter centralisé.

Vérifier avant et après

Deux contrôles niping vous disent si la route décrite par la destination loopback existe réellement. La note SAP 500235 documente l'outil.

Depuis l'hôte cible, confirmez que le gateway service de l'appelant est joignable :

niping -c -O -S sapgwNN -H <hote-du-hub-grc>

Depuis l'hôte appelant, confirmez que l'adresse maintenue dans la destination loopback se résout bien vers le nom d'hôte de l'appelant :

niping -v -H <adresse-ip-utilisee-dans-le-loopback>

Remontez ensuite la pile dans l'ordre, car chaque étape a un propriétaire différent : test de connexion sur la destination loopback, SM59 Remote Logon sur la destination du plugin depuis le hub, et seulement ensuite un logon Firefighter dans GRAC_EAM. Ne tester que la dernière étape gâche une fenêtre de changement alors que la première était déjà fausse.

Le faire sur un tenant managé

Les deux étapes du workaround se situent dans le système managé par SAP : ce sont donc des demandes et non des tâches, et elles arrivent chez une équipe différente de celle qui détient le ticket Firefighter. Quelques éléments accélèrent le mouvement.

• Demandez le paramètre et la destination dans une seule requête, avec les valeurs. Nommez le paramètre, précisez qu'un redémarrage d'instance est requis, et donnez la liste complète des champs de la destination : nom, type de connexion 3, load balancing No, Target host, numéro d'instance, Gateway host, Gateway service, aucune donnée de logon.
• Attendez-vous au refus de la voie fichier hosts. Maintenir le nom d'hôte du hub dans le /etc/hosts du tenant est normalement rejeté comme non conforme aux standards Enterprise Cloud Services. Comme le nom d'hôte du hub peut ne pas être résoluble du tout dans le DNS du tenant, maintenir directement l'adresse IP dans la destination loopback évite le débat.
• Certains diagnostics ne vous sont pas accessibles. Sur un tenant managé, les contrôles qui supposent un accès système d'exploitation (exécuter RSBDCOS0, par exemple, comme le suggère la note 2939988) peuvent simplement ne rien faire. C'est une propriété du tenant, pas un second défaut.
• Donnez aux équipes de support le test SM59 Remote Logon, pas le symptôme Firefighter. Un ticket sur composant GRC à propos du Firefighter tend à rester dans le support applicatif. La même panne décrite comme un remote logon sur une destination RFC atteint l'équipe qui peut réellement changer le paramètre.

Ce que ce n'est pas

Chacune des pistes ci-dessous est une cause réelle d'échec de logon Firefighter, et chacune mérite d'être écartée proprement. Aucune ne produit un test de connexion vert avec un Remote Logon muet, et aucune ne peut terminer une session dans SAPMSYST avant qu'un quelconque code du plugin GRC ne se soit exécuté.

Enseignements de terrain

• Prouvez-le d'abord dans SM59. Un test de connexion vert et un bouton Remote Logon muet : un test de deux minutes qui change le propriétaire du problème. Faites-le avant d'ouvrir le ticket.
• Un test de connexion ne prouve que le chemin aller. Il ne dit rien de la capacité de la cible à vous joindre en retour, qui est la moitié dont dépend un remote logon porteur de GUI.
• Lisez les deux syslogs sur le même instant. Le hub qui rapporte un succès pendant que la cible rapporte Transaction Canceled, c'est la signature, et vous ne la voyez qu'en appliquant le décalage horaire et en regardant les deux côtés.
• Le paramètre sans la destination ne fait rien. Positionner rdisp/use_rfc_dest_lookup = ON puis retester est un premier geste raisonnable, et cela ne changera pas le symptôme. Ce résultat n'est pas une preuve contre la KBA.
• Maintenez les champs gateway. Une destination loopback sans le Gateway host et le Gateway service de l'appelant passera son test de connexion et laissera le Firefighter cassé.
• Mettez-le dans le script de test de migration. Le Firefighter centralisé n'est exercé par personne jusqu'au jour où on en a besoin. Ajoutez « le Remote Logon SM59 fonctionne depuis le hub GRC vers chaque destination plugin migrée » à la checklist de cutover, et le problème apparaît en test plutôt qu'au premier incident de production.

Comment MTC aide

Nous travaillons sur la partie ingrate de SAP GRC : faire réellement fonctionner Emergency Access Management sur des paysages qui ne sont plus uniformes, où le hub GRC est on premise et les systèmes managés ne le sont pas. Cela inclut la conception des connecteurs et des RFC à travers les frontières réseau, le dépannage du Firefighter en mode centralisé comme décentralisé, et le maintien d'un log Firefighter et d'une revue suffisamment complets pour tenir en audit. Sur les grands programmes GRC, nous livrons aux côtés de cabinets internationaux de premier plan en audit, risque et technologie, avec une équipe senior basée en Suisse responsable du résultat de sécurité.

À lire également

• Note SAP 3318927 : changements de session Firefighter SP21 sur GRCPINW V1100
• Conception des rôles Firefighter SAP : bonnes pratiques d'accès d'urgence
• Cybersécurité SAP : durcir la plateforme SAP, pas seulement les accès
• SAP GRC Access Control : ce que c'est et quand vous en avez besoin

Références

• KBA 2314735: Remote Logon through an RFC Destination does not work. Le symptôme, la cause et le workaround par destination loopback.
• 1292082: RFC fails due to non-unique host name resolution.
• 555162: Asynchronous RFCs with dialog via SAP router.
• 500235: Network Diagnosis with NIPING.
• 2939988: FFID session does not start, target system Hostname/IP address is incorrectly mapped in the network.
• 3380027: Firefighter Login does not open a new Screen or displays an Error "No authorization to logon on to the target system".
• 3444624: Firefighter Session was closed without disconnecting the User Session.
• 3164899: Contrôle d'autorisation S_USER_GRP superflu (BC-SEC-USR-ADM).
• 1769547: "Plan version Current plan was set" during Firefighter Logon, l'un des incidents EAM qui référence la KBA 2314735.
• 3495933: FAQ : Emergency Access Management Service Pack 21 et supérieur.

Questions fréquentes

Pourquoi le logon Firefighter centralisé ne fait rien alors que le test de connexion RFC réussit ?

Parce qu'un test de connexion réussi ne prouve que le chemin aller. Le logon Firefighter centralisé est un remote logon, et un remote logon ne peut pas transporter les données GUI sur la connexion RFC existante : le système cible ouvre une seconde connexion, distincte, en retour vers le système appelant pour délivrer l'écran de logon. L'appelant transmet sa propre adresse IP avec la demande de logon, et la cible résout de son côté le nom d'hôte de l'appelant. Si les deux valeurs diffèrent, ce qui est normal lorsque les deux systèmes se trouvent dans des réseaux différents ou derrière du NAT, la connexion retour ne peut pas être établie. L'appelant ne reçoit jamais d'écran et la cible annule la session qu'elle avait commencé à établir. C'est exactement le scénario décrit par la KBA SAP 2314735.

Qu'est-ce qu'une destination RFC SID@BACK@ ?

C'est la destination loopback du workaround de la KBA SAP 2314735. Dans le système cible, vous créez une destination RFC de type 3 nommée d'après l'identifiant du système appelant suivi de @BACK@, par exemple G1P@BACK@ si le système GRC appelant a le SID G1P. Son Target Host, son numéro d'instance, son Gateway host et son Gateway service pointent tous vers le système appelant, et aucune donnée de logon n'est maintenue. Avec le paramètre de profil d'instance rdisp/use_rfc_dest_lookup positionné sur ON, le système cible utilise cette destination pour ouvrir la connexion retour au lieu de s'appuyer sur sa propre résolution du nom d'hôte de l'appelant.

Le paramètre rdisp/use_rfc_dest_lookup = ON suffit-il à corriger le remote logon Firefighter ?

Non. Le paramètre indique seulement au système cible de chercher une destination loopback ; seul, il ne change rien, et nous l'avons constaté sur le terrain. La destination nommée d'après le SID du système appelant suivi de @BACK@ doit exister dans le système cible, et elle doit être complète. Une destination loopback dont le Target Host est renseigné mais dont le Gateway host et le Gateway service sont vides ne corrige rien non plus, car la connexion retour est ouverte via le gateway du système appelant.

Pourquoi le Firefighter décentralisé fonctionne-t-il alors que le centralisé échoue ?

Parce que seul le Firefighter centralisé a besoin d'un remote logon. En mode décentralisé, l'utilisateur se connecte directement au système plugin et la session Firefighter est établie localement : aucune connexion retour n'est nécessaire. En mode centralisé, le hub GRC construit une destination RFC temporaire, appelle le remote logon, et le système plugin doit ouvrir une connexion vers le hub pour délivrer la session SAP GUI. Le fait que l'EAM décentralisé fonctionne dans le même système est donc un signal utile : la configuration du plugin, l'ID Firefighter et ses rôles sont corrects, et la défaillance se situe sur le chemin retour.

Comment appliquer la KBA SAP 2314735 quand le système plugin tourne sur RISE with SAP ?

Les deux étapes se situent dans le système managé par SAP : les deux passent donc par SAP. Demandez que rdisp/use_rfc_dest_lookup soit positionné sur ON dans le profil d'instance de chaque instance du tenant, avec le redémarrage d'instance qu'impose ce changement, et que la destination loopback nommée d'après le SID de votre système GRC suivi de @BACK@ soit créée dans SM59 avec le Target Host, le numéro d'instance, le Gateway host et le Gateway service de votre système GRC. Maintenir le nom d'hôte du GRC dans le fichier hosts du tenant est généralement refusé comme non conforme aux standards Enterprise Cloud Services, ce qui explique pourquoi la destination loopback avec une adresse IP est la voie praticable.