Le raccourci SAP GUI du portail : Logon Ticket, SNC et le SSO vers SAP GUI

Quand nous lançons une transaction SAP depuis le portail d’entreprise, SAP GUI s’ouvre et nous voilà connectés au backend ABAP sans avoir saisi de mot de passe. Entre le clic dans le navigateur et la session SAP GUI, un petit fichier a transité sur le poste. On le désigne parfois par un nom approximatif (« sap.tx », « tx.sap ») ; en réalité, c’est un raccourci SAP GUI, et comprendre ce qu’il contient, c’est comprendre tout le SSO du portail vers SAP GUI.

Ce raccourci porte deux choses de nature différente, qu’il ne faut pas confondre : une description de connexion (quel système, quelle transaction, et éventuellement un nom SNC) et, dans le scénario du portail, un SAP Logon Ticket qui sert de preuve d’identité. Ce sont aussi, nous le verrons, deux voies de SSO distinctes, pas deux ingrédients d’une même recette.

Un raccourci SAP GUI, pas un format à part

Le fichier généré par le portail est un raccourci SAP GUI, c’est-à-dire un fichier texte au format INI qu’ouvre sapshcut.exe. Le navigateur le reçoit avec le type MIME application/x-sapshortcut et le passe à SAP GUI, qui le lit et ouvre la session. C’est le même objet que le raccourci qu’on peut créer soi-même depuis la barre d’outils de SAP GUI, ou « manuellement dans un environnement Windows », comme le rappelle la documentation SAP (Authentication Security for SAP Shortcuts).

Sa structure tient en quelques sections. Voici un raccourci minimal, tel qu’il se présente sur le disque :

[System]
Name=PRD
Client=100

[User]
Name=jdupont
Language=FR

[Function]
Title=Afficher une commande (VA03)
Command=*VA03

[Configuration]
GuiSize=Maximized

[Options]
Reuse=1

La section [System] désigne le système (identifiant et mandant), [User] l’utilisateur et la langue, [Function] la transaction à lancer (*VA03 enchaîne directement sur l’écran voulu), et [Configuration] ou [Options] les réglages d’affichage. Rien, à ce stade, ne porte l’authentification : un raccourci peut tout aussi bien stocker un mot de passe, ce que SAP déconseille formellement, nous y reviendrons.

Le Logon Ticket glissé dans le raccourci

Dans le scénario du portail, l’authentification vient d’un SAP Logon Ticket. Le portail et l’AS ABAP partagent ce mécanisme : le portail émet un ticket signé, et « le logon ticket est passé au raccourci SAP GUI par une iView du portail » (Single Sign-On for SAP Shortcuts). Concrètement, l’iView ajoute au raccourci un paramètre qui transporte le ticket MYSAPSSO2, sous une forme du type at="MYSAPSSO2=<ticket signé, en base64>". Ce paramètre at n’est pas documenté officiellement : il relève de la pratique connue de la communauté SAP, pas d’une API publique.

Le ticket est de très courte durée. Le portail génère pour l’occasion un ticket de réentrance, valable de l’ordre de deux minutes : juste le temps d’ouvrir la session. SAP GUI présente ce ticket à l’AS ABAP, qui vérifie la signature du portail et ouvre la session si son profil l’accepte (le paramètre login/accept_sso2_ticket côté backend). Le mot de passe de l’utilisateur n’intervient jamais.

Du portail à SAP GUI : le ticket signé voyage dans le raccourci, l’AS ABAP en vérifie la signature.

Pour que cet échange fonctionne, plusieurs conditions doivent être réunies, et la documentation SAP les liste sans détour (Single Sign-On for SAP Shortcuts) :

• l’utilisateur a le même identifiant dans tous les systèmes atteints par le ticket (les mots de passe, eux, peuvent différer) ;
• l’AS ABAP qui accepte le ticket est dans le même domaine DNS que le serveur qui l’émet ;
• les horloges des deux systèmes sont synchronisées, faute de quoi « le système accepteur peut recevoir un logon ticket pas encore valide, et l’authentification échoue » ;
• le serveur émetteur dispose d’un certificat et d’une paire de clés pour signer le ticket ;
• l’annuaire (UME) du portail utilise le même magasin d’utilisateurs que l’AS ABAP.

La voie SNC : l’autre SSO, et pas le même fichier

Le raccourci peut aussi porter de quoi établir une connexion SNC (Secure Network Communication) : le nom SNC du serveur applicatif, que SAP GUI utilise pour négocier une connexion authentifiée, par GSSAPI/Kerberos ou par certificat X.509. C’est le mécanisme que nous avons détaillé dans l’article sur le SSO Kerberos vers SAP GUI.

Attention toutefois à ne pas mélanger les deux. SNC et Logon Ticket sont deux voies de SSO séparées, pas deux parties d’un même ticket. SAP est même explicite sur ce point : dans le scénario du portail par logon ticket, « ce scénario ne prend pas en charge SNC Client Encryption » (Single Sign-On for SAP Shortcuts). Autrement dit, un raccourci donné nous connecte en SSO soit par le ticket du portail, soit par SNC, mais il ne combine pas les deux pour authentifier.

La différence ne porte pas que sur l’étiquette. Elle change ce qui est protégé :

Un logon ticket prouve l’identité, il ne chiffre pas le protocole DIAG entre SAP GUI et le serveur ; SNC, lui, peut assurer l’authentification et la protection du flux. C’est une raison de plus de ne pas voir le raccourci comme un simple conteneur fourre-tout.

Observer le fichier soi-même

Rien ne vaut d’ouvrir le fichier en vrai. Par défaut, le navigateur le passe aussitôt à SAP GUI et nous ne le voyons jamais. Pour l’intercepter, il suffit de dire au navigateur de l’enregistrer au lieu de l’ouvrir : retirer l’association du type application/x-sapshortcut (ou de l’extension .sap) à SAP GUI, ou récupérer la réponse du portail depuis les outils de développement. Nous obtenons alors le raccourci brut sur le disque.

Ouvert dans un simple éditeur de texte, il révèle ses sections, et surtout la ligne du ticket :

[System]
Name=PRD
Client=100
...
at="MYSAPSSO2=AjExMDAgABRqZHVwb250ICAg...<base64 signé>..."

La valeur du paramètre at est un SAP Logon Ticket encodé en base64. Le point à retenir : ce ticket est signé, pas chiffré. En décodant le base64, nous lisons son contenu en clair, et c’est la signature du portail qui en garantit l’authenticité, pas le secret du contenu :

# isoler la valeur après MYSAPSSO2= puis la décoder
echo 'AjExMDAgABRqZHVwb250ICAg...' | base64 -d | strings

Dans la sortie, nous retrouvons en clair l’identifiant du système émetteur et son mandant, l’identifiant de l’utilisateur, puis un bloc binaire : la fenêtre de validité et la signature PKCS#7 du portail, que nous n’avons pas besoin de lire nous-mêmes. C’est exactement ce que l’AS ABAP contrôle à la réception : un ticket signé par un portail de confiance, pour cet utilisateur, encore dans sa courte fenêtre de validité.

Et puisqu’un ticket se décode à l’œil nu, glissons-y un clin d’œil. Décodez donc cette valeur, vous n’y trouverez pas de ticket : QmllbiB0ZW50ZS4gQ2UgTG9nb24gVGlja2V0IGEgZGVqYSBleHBpcmUsIGV0IGxhIGJsYWd1ZSBhdXNzaS4=

Attention : ce ticket reste une preuve d’identité valide, même pour quelques secondes seulement. Nous faisons donc ces manipulations sur un système de test, et nous ne laissons pas traîner un ticket réel, encore moins dans un article ou un ticket d’incident.

Anatomie du ticket, décodée

Décoder la valeur avec strings en donne un aperçu ; regardons la structure complète. Un SAP Logon Ticket est un format binaire simple : un en-tête, puis une suite de champs en TLV (type, longueur, valeur). L’en-tête tient en deux éléments, la version et la page de codes des valeurs. Chaque champ qui suit commence par un identifiant d’un octet et une longueur sur deux octets, puis la valeur. Le champ 0x01 porte l’identifiant de l’utilisateur ; le champ 0xFF (255), en fin de ticket, porte la signature.

Voici un ticket fictif, décodé et annoté — la disposition exacte des octets est simplifiée pour la lecture, mais l’ordre et la nature des champs sont ceux d’un vrai ticket. Les octets lisibles d’un côté, leur sens de l’autre :

02                      version
04                      page de codes
01 00 08  RVERNIER       champ 0x01 : utilisateur
          portal:...     système émetteur (SID + mandant)
          20261106175…   date de création (GMT) + fenêtre de validité
          uidpwdlogon    schéma d'authentification (ici, identifiant + mot de passe)
FF ...    MII…           champ 0xFF : signature PKCS#7 (certificat de l'émetteur)

Deux enseignements. D’abord, tout est lisible : l’utilisateur, le système émetteur, la validité, et la manière dont la personne s’est authentifiée. Le uidpwdlogon trahit ici un logon par identifiant et mot de passe ; un autre code trahirait un certificat ou SNC. Le ticket ne cache rien, il atteste. Ensuite, le seul élément qui compte vraiment pour la sécurité est le dernier : la signature PKCS#7. C’est elle qui lie le contenu à l’émetteur, et c’est elle que l’AS ABAP recalcule à la réception. Changer un octet du contenu, par exemple y mettre un autre nom d’utilisateur, invalide la signature — à moins de détenir la clé privée de l’émetteur. C’est tout l’enjeu de la section suivante.

MYSAPSSO2, d’abord un cookie

Avant d’être recopié dans un raccourci, le MYSAPSSO2 existe sous sa forme native : un cookie HTTP. Quand nous nous connectons au portail, le serveur pose dans le navigateur un cookie nommé exactement MYSAPSSO2, dont la valeur est le logon ticket. C’est ce cookie qui fait le SSO web : à chaque requête vers un système SAP du même domaine DNS, le navigateur le renvoie, et le système l’accepte sans redemander de mot de passe. Nous le voyons d’ailleurs à côté des cookies de session dans n’importe quel inspecteur de cookies :

Le cookie MYSAPSSO2 posé par le portail, aux côtés des cookies de session.

Le raccourci, lui, en transporte une copie, parce que SAP GUI parle le protocole DIAG et ne peut pas lire le cookie HTTP du navigateur : l’iView glisse la même valeur dans le paramètre at=. Deux détails distinguent les deux formes. Le cookie est généralement un cookie de session (en mémoire, effacé à la fermeture du navigateur), limité au domaine DNS et, selon la configuration, marqué Secure et HttpOnly ; sa durée de validité est celle du logon ticket du portail, souvent plusieurs heures. Ce qui est injecté dans le raccourci est au contraire un ticket de réentrance jetable, de l’ordre de deux minutes par défaut — un paramètre configurable côté portail. Le cookie dure, la copie dans le fichier ne sert qu’une fois.

Le scénario de compromission

Mettons les pièces bout à bout, comme une chaîne d’attaque. Rien d’exotique ici : juste la nature porteuse du ticket, exploitée de l’entrée à l’impact.

Du leurre à l’impact : la nature porteuse du ticket suffit, sans faille logicielle.

Le leurre. L’attaquant monte un proxy d’hameçonnage de type adversary-in-the-middle devant la page du portail. La victime s’authentifie, MFA compris s’il y en a une, et le proxy relaie tout vers le vrai portail tout en capturant le cookie MYSAPSSO2 que celui-ci renvoie.

Le rejeu. Muni du cookie, l’attaquant se présente aux applications web SAP du domaine : elles acceptent le ticket signé sans redemander d’authentification. Pour la partie SAP GUI, le même ticket recopié dans un raccourci at="MYSAPSSO2=…" ouvre une session DIAG.

Le mouvement latéral. C’est ici que le rayon d’impact joue : tous les AS ABAP qui font confiance à l’émetteur acceptent le ticket. D’un seul vol, l’attaquant passe de l’ERP au BW, au portail, à tout système du paysage inscrit dans la même liste de confiance, sous l’identité de la victime.

L’impact. Avec les droits de la victime, il lit ce qu’elle lit — données RH, finance, données clients — et déclenche ce qu’elle peut déclencher. Si la victime est un administrateur, c’est le paysage entier qui bascule. Et comme un ticket émis ne se révoque pas, couper l’accès suppose d’attendre son expiration ou de changer ce qui le rend valide (mot de passe, clé de l’émetteur). Rien, dans cette chaîne, n’a exigé de faille logicielle : seulement un porteur capté et rejoué.

Sécurité : un porteur, et tout ce que ça implique

Comprendre comment ça marche, c’est une chose ; voir ce que ça expose en est une autre. Le point de départ, c’est la nature du ticket : le MYSAPSSO2 est un jeton porteur. Il ne prouve pas que celui qui le présente en est le propriétaire : ni preuve de possession, ni liaison à l’appareil. Quiconque détient la valeur — le cookie dans le navigateur, ou sa copie dans le raccourci — peut la rejouer, et l’AS ABAP l’acceptera tant que la signature est valide et la fenêtre ouverte. C’est tout l’opposé d’un jeton lié à l’appareil comme le Primary Refresh Token d’Entra, dont la réutilisation suppose une clé scellée dans le TPM.

Porteur, canal, appareil : trois façons de lier une preuve d’identité. Le MYSAPSSO2 est à l’extrémité la moins contraignante, et c’est précisément ce qui l’expose.

Voler le cookie. Puisque le ticket vit d’abord comme cookie, il se vole comme un cookie. Une faille XSS sur une application du domaine le lit s’il n’est pas HttpOnly ; un proxy d’hameçonnage de type adversary-in-the-middle le capte au passage ; un flux en clair le laisse filer sur le réseau. Et un cookie MYSAPSSO2 volé, c’est le SSO ouvert vers tous les systèmes SAP du domaine qui font confiance à l’émetteur, sous l’identité de la victime, pour toute la durée du ticket.

Emporter le fichier. Le raccourci est l’autre porte. C’est un fichier : il se copie, se stocke, s’envoie par mail. S’il contient un mot de passe, c’est un identifiant durable qui dort en clair ; s’il contient le ticket, c’est une preuve d’identité valide de quelques secondes à quelques heures. SAP ne dit pas autre chose : « tout utilisateur disposant de permissions suffisantes au niveau OS peut se servir du raccourci pour se connecter à l’AS ABAP » (Authentication Security for SAP Shortcuts). Le transport du fichier jusqu’au poste doit donc être protégé au même titre que le cookie.

Le rayon d’impact. Un ticket ne vaut pas que pour un seul système. Tous les AS ABAP qui font confiance au même portail émetteur acceptent le même ticket : un seul vol se déplace alors latéralement dans tout le paysage. C’est le cœur du problème — et c’est la liste de confiance, que nous détaillons plus bas, qui en décide.

Un ticket volé rejoue vers tous les systèmes qui font confiance à l’émetteur ; si la clé de signature fuit, c’est tout le SSO qui tombe.

Pas de révocation d’un ticket émis. C’est la limite la plus inconfortable. Un logon ticket est auto-porté et signé, avec une fenêtre de validité : une fois émis, il n’existe pas de liste de révocation pour l’invalider à la demande. Nous ne pouvons pas « déconnecter » un ticket volé comme nous tuons une session serveur ; nous ne pouvons que l’attendre expirer. La seule vraie parade, c’est une durée de validité courte.

La clé de signature, le joyau. Toute la confiance repose sur une signature. Si la clé privée du portail émetteur fuit, un attaquant peut forger un ticket pour n’importe quel utilisateur, accepté par tous les systèmes qui font confiance à cet émetteur : c’est la compromission totale du SSO. Cette clé mérite la même protection qu’une autorité de certification, accès restreint et idéalement stockage matériel.

Les parades découlent de tout ce qui précède :

• HTTPS partout, et un cookie MYSAPSSO2 marqué Secure, HttpOnly et SameSite ;
• une durée de validité courte, pour réduire la fenêtre de rejeu ;
• une liste de confiance STRUSTSSO2 réduite aux seuls émetteurs légitimes ;
• la clé de signature de l’émetteur protégée comme un secret de premier ordre ;
• pas de mot de passe dans un raccourci, et un transport protégé du fichier ;
• pour aller plus loin, des mécanismes liés au canal plutôt qu’au porteur : SNC, qui authentifie et chiffre le flux DIAG, le Secure Login de SAP Single Sign-On, Kerberos ou X.509, vers lesquels SAP oriente d’ailleurs les déploiements neufs (Single Sign-On for the SAP GUI).

Durcir la confiance : STRUSTSSO2

Tout le modèle repose sur une question : à qui un système accepte-t-il de faire confiance pour émettre des tickets ? La réponse se configure dans la transaction STRUSTSSO2, qui tient la liste de contrôle d’accès des émetteurs reconnus. Un AS ABAP n’accepte un ticket que si login/accept_sso2_ticket = 1 et que le certificat de l’émetteur, identifié par son système et son mandant, figure dans cette liste. Le principe posé par SAP est net : un système ne devrait accepter les tickets que de son émetteur désigné (SAP Help, trust for logon tickets).

C’est là que les erreurs de configuration se paient, et elles sont fréquentes :

• Une liste trop large. Chaque émetteur de confiance supplémentaire est un portail de plus dont la compromission ouvre ce système. Trois portails de test oubliés dans la liste, et la surface d’attaque triple d’autant.
• Des entrées périmées. Un ancien système démantelé dont le certificat reste dans l’ACL est un émetteur fantôme : si quelqu’un remet la main sur sa clé privée, il forge des tickets que ce système accepte encore.
• La confiance transitive. Comme les systèmes d’un même paysage partagent souvent la même liste d’émetteurs, une entrée de trop n’ouvre pas un système, mais tout le paysage.
• Le revers du même identifiant. Un ticket vaut par le nom d’utilisateur qu’il porte, et le prérequis veut le même identifiant partout. Si un attaquant obtient, sur un système de confiance, un compte au nom d’un utilisateur à privilèges d’un autre système, son ticket parfaitement légitime devient une usurpation ailleurs.

Le durcissement tient donc en peu de gestes, mais réguliers : n’inscrire dans STRUSTSSO2 que les émetteurs réellement nécessaires, retirer les entrées périmées, auditer la liste à intervalles fixes, et traiter chaque certificat d’émetteur accepté comme ce qu’il est — une délégation de confiance sur l’ensemble des comptes du système.

Détecter le rejeu, et pourquoi c’est difficile

Reste la question qui fâche : un ticket volé puis rejoué, le voit-on passer ? Honnêtement, mal. Le rejeu ne déclenche aucun des signaux auxquels on pense d’abord. Pas d’échec d’authentification, pas de mot de passe refusé, pas de second facteur sollicité : l’AS ABAP reçoit un ticket correctement signé, encore dans sa fenêtre de validité, et ouvre la session. Dans les journaux, c’est une connexion réussie de plus, indiscernable d’une vraie à la seule lecture de l’événement.

Le signal n’est donc pas dans l’authentification elle-même, mais dans ce qui l’entoure — les incohérences :

• Une origine inattendue. Le même compte vu depuis un poste, une adresse IP ou un terminal qui ne sont pas les siens. Le ticket est valide, mais il arrive d’ailleurs.
• Un voyage impossible. Deux sessions ouvertes depuis des endroits géographiquement incompatibles dans un intervalle trop court — le classique de la détection de vol de session, transposé au logon ticket.
• Une acceptation sans émission correspondante. Un ticket accepté par l’AS ABAP sans session portail qui l’explique côté émetteur. Rapprocher les deux bouts, émission au portail et acceptation au backend, fait ressortir ce qui, pris isolément, semble normal.

La matière première existe côté SAP : le Security Audit Log (configuré par RSAU_CONFIG, anciennement SM19, et relu par SM20) journalise les connexions et peut tracer l’usage des logon tickets — à condition que les classes d’audit soient activées, et que les journaux soient réellement collectés et corrélés, idéalement dans un SIEM qui rapproche les traces du portail de celles des backends.

Mais disons-le sans détour : il n’existe pas de règle toute faite qui attrape proprement un rejeu de ticket. La détection, ici, est affaire de corrélation et d’anomalie, pas de signature, et elle arrive après coup. C’est pourquoi l’essentiel du travail se joue en amont, à la prévention — tout ce que nous venons de voir.

Au fond, le MYSAPSSO2 appartient à la même famille que les cookies de session et les jetons que l’on vole par adversary-in-the-middle ailleurs : un porteur bien commode, qu’il faut traiter comme un secret, et dont la bonne trajectoire est de devenir un jeton lié au canal ou à l’appareil.

Rémi Vernier

Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.

Tous les articles → LinkedIn →