FATAL SNCERROR – Accepting Credentials not available!

Hello upgrade friends,

do you use SSO in your environment? Yes?
Do plan an upgrade to EhP6 or kernel change to 7.20/7.21 EXT? Yes?

=> Than you might run into the same difficulty like me :/

After kernel switch phase of an EhP 6 upgrade I have faced the issue that the system couldn’t start (Phase: STARTSAP_PUPG).
OK, let’s try to look into the work process traces, because there were no disp+work processes active and sapcontrol (sapcontrol –nr x -function GetProcessList) shows me also that not all prcoesses are running.

N        UserId=”sidadm” (ID), envvar USER=”sidadm“

N  SncInit():  found snc/data_protection/max=3, using 3 (Privacy Level)
N  SncInit():  found snc/data_protection/min=2, using 2 (Integrity Level)
N  SncInit():  found snc/data_protection/use=3, using 3 (Privacy Level)
N  SncInit(): found snc/gssapi_lib=/usr/sap/SID/<Instanz>/sll/libsecgss.so
N    File “/usr/sap/SID/<Instance>/sll/libsecgss.so” dynamically loaded as GSS-API v2 library.
N    The internal Adapter for the loaded GSS-API mechanism identifies as:
N    Internal SNC-Adapter (Rev 1.0) to SAP Netweaver Single Sign-On v1.x
N  SncInit():  found snc/identity/as=p:CN=<…>
N  *** ERROR => SncPAcquireCred()==SNCERR_GSSAPI  [sncxxall.c 1445]
N        GSS-API(maj): No credentials were supplied
N      Could’t acquire ACCEPTING credentials for
N
N      name=”p:CN=<….>”
N      FATAL SNCERROR — Accepting Credentials not available!
N      (debug hint: default acceptor = “p:CN=DummyCredential“)
N  <<- SncInit()==SNCERR_GSSAPI
N          sec_avail = “false”
M  ***LOG R19=> ThSncInit, SncInitU ( SNC-000004) [thxxsnc.c    237]
M  *** ERROR => ThSncInit: SncInitU (SNCERR_GSSAPI) [thxxsnc.c    239]

First try was easily to deactivate the SNC parameter in the profiles (=> snc/enable=0) -> it worked, but this solved not the real issue just the symptom.
I have noticed that the SNC Adapter changed with kernel from “SECUDE 5/GSS-API v2” to “SAP Netweaver Single Sign-On v1.x”. OK, I could find out that these adapters are compatible. But wait moment, why it didn’t work if they are compatible?

I have checked the SLL (secure login library) configuration (normally located under /usr/sap/SID/DV*/SLL/ ). The executeable “snc” showed me that everything looks fine:

Using command ‘status -v’, call with –h to see more commands
——————————————————————————
———— status ——————————————————-
——————————————————————————
Product version     : Secure Login Library 1.0 SP 4 Patch 3
  : CryptoLib 8.3.7.11
  : aix-6.1-ppc-64

GSS library         : available
GSS library name    : libsecgss.so

PSE directory       : (existing) /usr/sap/SID/DV*/sec
PSE file            : (existing) /usr/sap/SID/DV*/sec/pse.zip
STRUST cred file    : (existing) /usr/sap/SID/DV*/sec/cred_v2
SNC config file     : (existing) /usr/sap/SID/DV*/sll/gss.xml

PSE accessible      : yes
PSE logged in       : yes
PSE credentials     : MasterPassword SystemDefault

Kerberos keyTab     : Not existing
——————————————————————————
SNC keys registered :  1 entries
1: STRUST  certificate  CN=<…>

Trusted certificates:
from STRUST       :
1: CN=SLS RootCA, OU=SAP SSO, O=<…>, C=DE

It seems that everything is fine!? But it still didn’t work.
May be other libraries were used with the new kernel.
-> No, this also not the right answer because via the profile the same lib is used -> /usr/sap/SID/DV*/sll/libsecgss.so

For me it seems like that cred_v2 cannot be compared with the pse. So I created a new PSE via STRUST and secured it via password to create the cred_v2. (This can also be done via sapgenpse)

I reactivated SNC via the profile parameters and I could start the instance without any issues. So it seems that the old PSE and cred_v2 files are _not_ compatible with the new SNC adapter.

Hope if you run into this issue, you can fix it faster and waste not so much time like me.

Best Regards,
Jens