SSO Kerberos vers SAP GUI et SAP NetWeaver: SNC, SPN et keytab expliqués

Posted On 27 octobre 2026

Je ne vais pas refaire ici un guide d’installation pas à pas de SAP Single Sign-On. Les guides SAP et quelques billets de la communauté le font déjà. Je préfère expliquer ce qui se passe réellement entre le poste Windows, le contrôleur de domaine et le serveur ABAP quand un utilisateur ouvre SAP Logon et se retrouve connecté sans saisir de mot de passe. Quand le SSO tombe en panne, savoir à quelle étape l’échange échoue évite de régénérer des PSE au hasard.

Nous verrons comment SNC s’appuie sur GSS-API, ce que contient réellement le « keytab » côté SAP, quels paramètres de profil interviennent, comment un principal Kerberos devient un utilisateur SAP, puis comment diagnostiquer les erreurs les plus courantes.

Présentation de la maquette

Pour tous les exemples, j’utilise les noms suivants:

Domaine Active Directory: test.local (royaume Kerberos TEST.LOCAL)
Contrôleur de domaine / KDC: dc01.test.local
Serveur SAP NetWeaver AS ABAP: srvsap01.test.local, SID ABC, instance 00
Compte de service Active Directory: svc.sapabc
SPN déclaré sur ce compte: SAP/svc.sapabc
Utilisateur de test: TESTrvernier, utilisateur SAP RVERNIER

Côté serveur, la bibliothèque SNC est la CommonCryptoLib livrée avec le noyau SAP (sapcrypto.dll sous Windows, libsapcrypto.so sous Linux). Côté client, SAP GUI pour Windows utilise une bibliothèque SNC compatible Kerberos, en pratique le Secure Login Client de SAP Single Sign-On.

SNC et GSS-API

SNC (Secure Network Communications) n’est pas un protocole d’authentification. C’est une couche que SAP insère dans ses propres protocoles (DIAG pour SAP GUI, RFC, CPIC) et qui délègue tout le travail de sécurité à une bibliothèque externe via l’interface GSS-API v2 (RFC 2743). Le noyau SAP ne connaît rien à Kerberos. Il appelle gss_init_sec_context côté client, gss_accept_sec_context côté serveur, échange des jetons opaques, puis demande à la bibliothèque d’emballer les données avec le niveau de protection voulu (authentification seule, intégrité, confidentialité).

Avec le mécanisme Kerberos (RFC 4121), le jeton envoyé par le client contient un AP-REQ, c’est-à-dire le ticket de service obtenu auprès du KDC et un authentificateur. Le serveur déchiffre ce ticket avec la clé du compte de service. S’il y parvient, il obtient le nom du client (rvernier@TEST.LOCAL), que SNC lui présente sous la forme d’un nom SNC. C’est ce nom qui sera ensuite associé à un utilisateur SAP.

Flux d’une connexion SAP GUI avec SNC Kerberos

Le serveur SAP ne contacte jamais le contrôleur de domaine pendant l’ouverture de session. Tout repose sur le fait qu’il possède localement les mêmes clés que celles que le KDC a utilisées pour chiffrer le ticket. Si ces clés divergent (mot de passe changé, mauvais type de chiffrement, mauvais sel), le ticket est indéchiffrable et le SSO échoue. La majorité des pannes vient de là.

Compte de service et SPN pour SAP

Le serveur SAP a besoin d’une identité Kerberos. On crée donc un compte utilisateur dans Active Directory, dédié au système ABC (un compte par système, pas un compte partagé pour tout le paysage SAP). Ce point est très important pour la suite: les clés de ce compte vont être recopiées dans un fichier sur le serveur, donc chaque rotation de mot de passe impose une mise à jour côté SAP.

On déclare ensuite le SPN et on vérifie qu’il est unique dans la forêt:

setspn -S SAP/svc.sapabc TESTsvc.sapabc
setspn -L TESTsvc.sapabc
setspn -Q SAP/svc.sapabc
setspn -X

-> setspn -S refuse d’ajouter un SPN déjà présent ailleurs, contrairement à l’ancien -A.
-> setspn -X recherche les doublons. Un SPN en double donne au KDC un comportement imprévisible et le résultat est un ticket chiffré avec la clé du mauvais compte.

La convention SAP/<compte> est la plus répandue dans les exemples de la communauté, mais elle n’a rien d’obligatoire. Ce qui compte, c’est la cohérence entre trois endroits: le principal utilisé pour générer le keytab, le paramètre snc/identity/as du serveur et le nom SNC saisi dans l’entrée SAP Logon.

Pensez aussi aux types de chiffrement. Si vous voulez de l’AES (et vous le voulez, Microsoft pousse depuis longtemps à abandonner RC4), cochez les deux cases AES 128 et 256 bits dans les options du compte, ou positionnez directement l’attribut:

Set-ADUser svc.sapabc -Replace @{"msDS-SupportedEncryptionTypes"=24}

La valeur 24 correspond à 8 (AES128) + 16 (AES256).

Le keytab n’est pas un fichier keytab

Ceux qui viennent du monde MIT Kerberos cherchent souvent un fichier .keytab généré avec ktpass. Ce n’est pas comme ça que fonctionne la CommonCryptoLib. Dans la méthode historique, les clés sont stockées dans un PSE dédié, SAPSNCSKERB.pse, dans le répertoire SECUDIR de l’instance, et c’est sapgenpse qui dérive les clés à partir du mot de passe du compte de service:

set SECUDIR=D:usrsapABCD00sec
sapgenpse keytab -p SAPSNCSKERB.pse -k "AES256 AES128" -a svc.sapabc@TEST.LOCAL
sapgenpse seclogin -p SAPSNCSKERB.pse -O SAPServiceABC
sapgenpse seclogin -l
sapgenpse get_my_name -p SAPSNCSKERB.pse

L’outil demande le PIN du PSE puis le mot de passe de svc.sapabc. La commande seclogin crée l’entrée dans le fichier de credentials (cred_v2) pour que le processus SAP puisse ouvrir le PSE sans PIN. Sous Windows, il faut qu’elle soit valable pour le compte qui fait tourner les work process (SAPServiceABC), sous Linux pour abcadm. Enfin, get_my_name affiche les entrées du keytab, avec leur type de clé. Cette séquence est bien illustrée dans ce billet de la communauté SAP, et l’option -k pour restreindre les types de clés est donnée par Carsten dans cette discussion sur l’AES256.

Un détail qui explique pas mal de cas « ça marche en RC4 mais pas en AES »: les clés AES sont dérivées du mot de passe et d’un sel. Dans Active Directory, pour un compte utilisateur, ce sel est construit à partir du royaume en majuscules et du nom du compte, avec respect de la casse. RC4 n’utilise pas de sel. Si le nom passé à -a ne correspond pas exactement à ce qu’AD utilise (casse différente, nom de SPN au lieu du nom de compte selon la façon dont l’outil construit le sel), les clés AES calculées par sapgenpse ne seront pas celles du KDC, alors que la clé RC4 restera juste. D’où la recommandation, qu’on retrouve dans les discussions SAP, de toujours écrire le royaume en majuscules et de respecter la casse exacte du compte. C’est aussi pour cette raison que j’utilise ici le nom du compte (svc.sapabc@TEST.LOCAL) plutôt que le SPN pour le keytab et l’identité SNC.

Avec SAP Single Sign-On 3.0, SAP a déplacé ce stockage: d’après la KBA 3360330, le keytab est désormais conservé en base via la transaction « SPNEGO », et SAPSNCSKERB.pse est présenté comme une configuration héritée. Le principe ne change pas: ce sont toujours des clés dérivées du mot de passe du compte de service. Seul l’emplacement change. Évitez simplement de mélanger les deux méthodes sur un même système, car c’est une source classique de confusion.

Dernière remarque sur ce PSE: les clés n’expirent pas. Comme le rappelle cette réponse, il n’y a rien à planifier en tâche périodique. Il faut seulement régénérer le keytab quand le mot de passe du compte de service change.

Paramètres de profil snc/*

Voici le jeu de paramètres d’instance que j’utilise sur la maquette (via « RZ10 » ou directement dans le profil):

snc/enable                 = 1
snc/gssapi_lib             = $(DIR_EXECUTABLE)$(DIR_SEP)$(FT_DLL_PREFIX)sapcrypto$(FT_DLL)
snc/identity/as            = p:CN=svc.sapabc@TEST.LOCAL
snc/data_protection/min    = 2
snc/data_protection/max    = 3
snc/data_protection/use    = 3
snc/accept_insecure_gui    = 1
snc/accept_insecure_rfc    = 1
snc/accept_insecure_cpic   = 1
snc/permit_insecure_start  = 1
snc/force_login_screen     = 0
snc/extid_login_diag       = 0

Quelques explications:

snc/gssapi_lib pointe vers la bibliothèque GSS-API chargée par le noyau. Avec la CommonCryptoLib, c’est la même bibliothèque qui gère X.509 et Kerberos.
snc/identity/as est le nom SNC du serveur. Le préfixe p: signifie « nom propre au produit de sécurité », et la CommonCryptoLib attend la forme CN=. Le client devra saisir ce même nom dans SAP Logon.
snc/data_protection/* fixe le niveau de protection: 1 pour l’authentification seule, 2 pour l’intégrité, 3 pour la confidentialité. Je ne vois aucune raison de descendre en dessous de 3 pour use.
Les paramètres accept_insecure_* et permit_insecure_start laissent passer les connexions non SNC pendant la mise en place. On les resserre ensuite (voir plus bas).
snc/extid_login_diag active le mapping par identifiants externes, dont nous parlerons dans la section suivante.

Si vous utilisez la méthode « SPNEGO » de SSO 3.0, vous verrez aussi spnego/enable = 1 et spnego/krbspnego_lib, qui pointe lui aussi vers sapcrypto.

Attention, la CommonCryptoLib attend aussi un PSE SNC classique (« SNC SAPCryptolib » dans « STRUST », fichier SAPSNCS.pse) en plus du keytab. Sans lui, sapgenpse affiche un avertissement explicite au moment de créer le keytab, comme on le voit dans cet échange archivé. La transaction « SNCWIZARD » crée ce PSE et positionne les paramètres de base, si elle est disponible sur votre version.

Enfin, si le PSE est incohérent avec snc/enable = 1, l’instance peut refuser de démarrer. Dans ce cas on repasse temporairement snc/enable à 0, on corrige, puis on réactive. Je fais donc toujours ce premier passage sur un système hors production.

Côté client

SAP GUI charge la bibliothèque indiquée par la variable d’environnement SNC_LIB (le Secure Login Client la positionne à l’installation). Dans l’entrée SAP Logon du système, onglet « Réseau », on active la communication sécurisée, on choisit le niveau de protection maximal et on saisit le nom SNC du serveur:

p:CN=svc.sapabc@TEST.LOCAL

Une faute de frappe ici et le client demande au KDC un ticket pour un principal qui n’existe pas. Le message d’erreur ne vous le dira pas toujours aussi clairement.

Du principal Kerberos à l’utilisateur SAP

Une fois le jeton accepté, le serveur connaît le nom SNC du client, par exemple p:CN=rvernier@TEST.LOCAL. Il lui faut maintenant trouver l’utilisateur SAP correspondant. Le plan initial de cet article parlait de « SNC0 » et de la table USREXTID. Il faut rectifier, car ce sont deux mécanismes différents et SNC0 ne gère pas les utilisateurs.

Le mapping standard se fait dans « SU01 », onglet « SNC ». Le nom SNC saisi (p:CN=rvernier@TEST.LOCAL) est stocké dans la table USRACL. L’association est un pour un, et c’est cette table que le noyau consulte lors d’une connexion SAP GUI. Pour un grand nombre d’utilisateurs, le rapport RSUSR300 permet de générer les noms SNC à partir d’un modèle.
Le mapping par identifiants externes repose sur la table USREXTID, avec un type d’identifiant Kerberos, que l’on maintient par la transaction « EXTID_KERBEROS ». Il n’est pris en compte pour SAP GUI que si snc/extid_login_diag = 1 (et snc/extid_login_rfc pour RFC). L’intérêt est de pouvoir associer des principaux qui ne suivent pas un modèle simple, ou de gérer le mapping en masse depuis un outil de provisioning.
« SNC0 », enfin, maintient la liste de contrôle d’accès des systèmes (table SNCSYSACL). Elle sert aux connexions RFC et CPIC entre systèmes, pas aux utilisateurs SAP GUI.

Deux pièges reviennent régulièrement. Le premier est la casse: le royaume doit être en majuscules (TEST.LOCAL), exactement comme dans le ticket. Le second concerne les utilisateurs dont l’UPN ne correspond pas au sAMAccountName: c’est le nom du principal présent dans le ticket qui compte, pas l’adresse de messagerie affichée dans l’annuaire.

Diagnostic

Quand le SSO ne fonctionne pas, je procède toujours dans le même ordre: d’abord le ticket côté client, ensuite l’acceptation côté serveur, enfin le mapping.

Le client a-t-il un ticket?

klist
klist purge
klist get svc.sapabc@TEST.LOCAL
klist get SAP/svc.sapabc

-> Si klist get échoue avec KDC_ERR_S_PRINCIPAL_UNKNOWN, le nom cible est inconnu du KDC: faute dans le nom SNC, SPN absent ou mauvais royaume.
-> Si le ticket est délivré, regardez le type de chiffrement de la clé de session et du ticket. Un ticket en RC4 alors que vous attendiez de l’AES pointe vers l’attribut msDS-SupportedEncryptionTypes du compte de service.
-> Après une connexion SAP GUI, le ticket doit apparaître dans le cache. S’il n’y est pas, la bibliothèque SNC du client n’a même pas tenté Kerberos: vérifiez SNC_LIB et l’état du Secure Login Client.

Le serveur accepte-t-il le ticket?

Côté ABAP, les informations se trouvent dans les traces des work process (dev_w*). Au démarrage, dev_w0 doit montrer l’initialisation SNC (lignes SncInit) et la version de la CommonCryptoLib chargée. Pour une connexion qui échoue, augmentez le niveau de trace du work process dans « SM50 » (ou de manière ciblée avec « ST11 » pour lire le fichier), reproduisez l’erreur, puis cherchez les lignes SNC et le code GSS-API retourné. Le journal système « SM21 » donne aussi le motif du refus.

Sur le système de fichiers, deux commandes permettent de vérifier que le processus SAP peut réellement utiliser le keytab:

sapgenpse seclogin -l -O SAPServiceABC
sapgenpse get_my_name -p SAPSNCSKERB.pse

La première montre si le compte qui exécute les work process dispose bien des credentials. Si SAPServiceABC ne peut pas ouvrir le keytab, les symptômes sont les mêmes que si les clés étaient fausses. La seconde liste les entrées du keytab et leurs types de clés.

Erreurs typiques

Symptôme	Cause probable
KDC_ERR_S_PRINCIPAL_UNKNOWN côté client	Nom SNC du serveur erroné dans SAP Logon, SPN absent, royaume en minuscules
« The verification of the Kerberos ticket failed » côté serveur	Clés du keytab différentes de celles du KDC: mot de passe du compte changé, sel AES incorrect, SPN en double
« GSS-API(maj): Miscellaneous failure »	Message générique de la bibliothèque, il faut aller lire les traces des deux côtés
« No user exists with SNC name … »	Ticket accepté, mais aucun utilisateur ne porte ce nom SNC dans USRACL (ou dans USREXTID si les identifiants externes sont activés)
Nom SNC du client affiché sous la forme « SNC ENCRYPTION ONLY (KERBEROS SERVER AUTH) »	La session est chiffrée, mais le client ne transmet pas d’identité exploitable pour le SSO (configuration de chiffrement seul)
Instance qui ne démarre plus après activation	PSE SNC ou keytab illisible avec `snc/enable = 1`

La deuxième ligne est la plus fréquente. Les discussions comme celle-ci finissent presque toujours de la même façon: on supprime le PSE, on le recrée avec le bon principal et le royaume en majuscules, on refait le seclogin pour le bon compte, puis on contrôle avec get_my_name et setspn -L. Le cas « SNC ENCRYPTION ONLY » apparaît par exemple dans ce fil. Je n’ai pas trouvé de documentation publique qui détaille précisément ce libellé: mon interprétation reste une piste de diagnostic, pas une règle.

Quelle bibliothèque SNC, et sous quelle licence?

Le plan prévoyait de vérifier ce point, et je préfère être transparent: au moment où j’écris ces lignes (octobre 2026), je n’ai pas pu revalider l’état actuel de toutes les notes SAP concernées. Voici ce qui est établi par les sources que j’ai consultées:

Côté serveur, la CommonCryptoLib est livrée avec le noyau. Le billet de 2016 cité plus haut indique qu’il fallait au moins la version 8.4.30 pour le chiffrement client basé sur Kerberos.
Le message affiché par sapgenpse keytab est clair: le SSO nécessite une licence SAP Single Sign-On, alors que le chiffrement SNC client seul, sans SSO, est gratuit selon la note SAP 1643878.
SAP Single Sign-On 3.0 est la version présentée comme supportée dans la KBA 3360330.

Les anciennes bibliothèques Kerberos pour Windows (gsskrb5 et son équivalent 64 bits fourni par SAP) ne fonctionnaient qu’entre clients et serveurs Windows et sont aujourd’hui des solutions héritées. Avant de lancer un projet, vérifiez sur le portail SAP Support les notes de licence et la matrice de support de la version de Secure Login Client que vous comptez déployer.

Resserrer après la mise en service

Tant que snc/accept_insecure_gui = 1, n’importe qui peut encore se connecter sans SNC avec un mot de passe, et en clair sur le réseau. Une fois le SSO validé pour une population, passez ce paramètre à U. La décision se prend alors utilisateur par utilisateur, grâce à la case « Communication non sécurisée autorisée » de l’onglet « SNC » de SU01. Vous décochez cette case au fur et à mesure du déploiement, et les comptes techniques qui en ont réellement besoin gardent l’exception, documentée. Les connexions SAP GUI restantes sans SNC deviennent ainsi une liste nominative que l’on peut réduire, plutôt qu’une porte ouverte à tout le monde.