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 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 18.104.22.168
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=<…>
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.