Issues with SNC certificates as server identifies incorrect SECUDIR path.

[Former Member]

Hi All,

I am facing with SECUDIR path identification by secondary servers of same SID.

As a part of SNC implementation for RFC connections, I am enabling SNC with activation of sap cryptolibrary certificate from STRUST.

System is Netweaver 7.4.

Steps:

1. I implamented parameters reqiored for SNC communication except snc/enable=0.

2. Restarted the system and the created SNC cryptolib certificate from STRUST.Certificate got created in OS level at /usr/sap//sec in promary & secondary servers.

3. I enabled SNC using snc/enable =1

4. I faced an issue that my primary server was trying to read certificates from HOME i.e. /global/adm, so I set parameter SETENV03 = SECUDIR=$(DIR_INSTANCE)/sec in primary instance. I    restarted the instance & it worked. 

5. But for secondary instance, even if I have set profile parameter SETENV for SECUDIR, it still looks for certificate at home directory.

Please see logs below:

case1- SECUDIR is taken correctly in one instance

SncInit(): Initializing Secure Network Communication (SNC) N        IBM RS/6000 with AIX (mt,ascii,SAP_UC/size_t/void* = 16/64/64) N        UserId="adm" (1304), envvar USER="adm" 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=/sapmnt//exe/libsapcrypto.so N    File "/sapmnt//exe/libsapcrypto.so" dynamically loaded as GSS-API v2 library. N N Sun Jun 19 06:36:09 2016 N    SECUDIR="/usr/sap//DVEBMGS05/sec" (from $SECUDIR) N    The internal Adapter for the loaded GSS-API mechanism identifies as: N    Internal SNC-Adapter (Rev 1.1) to CommonCryptoLib N    Product Version = CommonCryptoLib (SAPCRYPTOLIB) Version 8.4.43 pl40 (Oct  8 2015) MT-safe N  SncInit():  found snc/identity/as=p:CN=SAP/KerberosN  SncInit(): Accepting  Credentials available, lifetime=Indefinite N  SncInit(): Initiating Credentials available, lifetime=Indefinite M  ***LOG R1Q=> p:CN=SAP/Kerberos [thxxsnc.c    301] M  SNC (Secure Network Communication) enabled

case 2-SECUDIR is taking from HOME for this instance

SncInit(): Initializing Secure Network Communication (SNC) N        IBM RS/6000 with AIX (mt,ascii,SAP_UC/size_t/void* = 16/64/64) N        UserId="adm" (1304), envvar USER="adm" 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=/sapmnt//exe/libsapcrypto.so N N Sun Jun 19 07:16:53 2016 N    File "/sapmnt//exe/libsapcrypto.so" dynamically loaded as GSS-API v2 library. N    SECUDIR="/home/adm/sec" (from HOME) N    The internal Adapter for the loaded GSS-API mechanism identifies as: N    Internal SNC-Adapter (Rev 1.1) to CommonCryptoLib N    Product Version = CommonCryptoLib (SAPCRYPTOLIB) Version 8.4.43 pl40 (Oct  8 2015) MT-safe N  SncInit():  found snc/identity/as=p:CN=SAP/KerberosN  SncInit(): Accepting  Credentials available, lifetime=Indefinite N  SncInit(): Initiating Credentials available, lifetime=Indefinite M  ***LOG R1Q=> p:CN=SAP/Kerberos [thxxsnc.c    301] M  SNC (Secure Network Communication) enabled Thanks, Devendra

[isaias_freitas]

Hello Devendra,

Confirm that there are conflicting SETENV parameters.

For example, if you have created the parameter SETENV_03 at the beginning of the profile, but the same parameter is defined below your new definition, the second occurrence of SETENV_03 will overwrite the first one.

In other words, the SETENV_XX parameters must start at zero (SETENV_00), and be sequential (but where they exist in the profile - beginning or end, not in order - does not matter).

If the above was not the case, have you stopped the sapstartsrv process, besides stopping SAP?

This process is not stopped by the "stopsap" command.

After stopping SAP (e.g., with "stopsap"), you can execute the command

   sapcontrol -nr XX -function StopService

To stop the sapstartsrv, or

   sapcontrol -nr XX -function RestartService

In order to restart it.

(XX is the instance number)

If the issue persisted, please attach the complete profile to this thread.

Regards,

Isaías

[Former Member]

Hi Isaías, Thanks for your response. Case 1 where issue occured first and then I set SETENV_03 parameter as a unique number in squence adm 6> ls -rlt | grep -i SETENV _DVEBMGS_di00 SETENV_00 = DIR_LIBRARY=$(DIR_LIBRARY) SETENV_01 = SHLIB_PATH=$(DIR_LIBRARY):%(SHLIB_PATH) SETENV_03 = SECUDIR=$(DIR_INSTANCE)/sec SETENV_02 = LIBPATH=$(DIR_LIBRARY):%(LIBPATH) Case 2 where this issue occured and didn't resolve even after setting up environmnet parameter adm 8> ls -rlt | grep -i SETENV _D_di01 SETENV_00 = DIR_LIBRARY=$(DIR_LIBRARY) SETENV_01 = LD_LIBRARY_PATH=$(DIR_LIBRARY):%(LD_LIBRARY_PATH) SETENV_02 = SHLIB_PATH=$(DIR_LIBRARY):%(SHLIB_PATH) SETENV_03 = LIBPATH=$(DIR_LIBRARY):%(LIBPATH) SETENV_04 = PATH=$(DIR_EXECUTABLE):%(PATH) SETENV_05 = SECUDIR=$(DIR_INSTANCE)/sec One difference that I see is that there are start profiles for SCS, ASCS & two of the three dialog instances. So it seems that primary instance & one dialog instance for which start profile is not there, this parameter worked fine. But other instances has START profile and I didn't set parameter in start profile. adm 10> ls -rlt | grep -i SETENV START_D_di01 SETENV_00 = DIR_LIBRARY=$(DIR_LIBRARY) SETENV_01 = SHLIB_PATH=$(DIR_LIBRARY):%(SHLIB_PATH) SETENV_02 = LIBPATH=$(DIR_LIBRARY):%(LIBPATH) Please suggest if environment variables should be set exactly same in all instance profiles as well as start profiles wherever applicable. Thanks,

[isaias_freitas]

Hello Devendra,

If a START profile exists, then you should set the SETENV parameter at the START profile.

However, you should either have START profiles for all instances, or for none.

If there are no START profiles, the SETENV, Start_Program and other parameters that would normally be set at the START profile should then be set at the instance profile.

Regards,

Isaías