SAP Crypto SNC PSE SSO from AIX daemon

[Former Member]

Summary

We're trying to setup SNC with the SAP Crypto library on AIX, but we're getting inconsistent SSO access to the PSE depending on whether we run from the command line or from a daemon process that runs with the exact same user account. Put differently, SNC connectivity works from the command line and fails when run from the daemon (both from the same machine and same user).

Environment

We have only one [NIS] user account on the AIX client machine and the

sapgenpse seclogin -l

indicates that there is only one SSO mapping performed and it's the correct one for that user as the JCO demo client VeriClient can connect without errors using trusted system SNC (EXTIDTYPE and EXTIDDATA).

Initial assessment

The problem seems to be that it's the PSE SSO check that fails after monitoring the two processes using truss.

When run from the JCO client, it's easy to see it opening cred_v2, reading it and continuing on to the PSE file. The daemon however, after attaching truss to that process, we can see that it opens cred_v2, reads it and closes immediately and then proceeds to open dev_rfc.trc and writes the following error:

Error

Unable to connect to SAP BW server. Connect to SAP gateway failed
Connect_PM  GWHOST=host.domain.com, GWSERV=sapgw01, ASHOST=host.domain.com, SYSNR=01

LOCATION    CPIC (TCP/IP) on local host
ERROR       SNCERR_GSSAPI
            An operation failed at the GSS-API level
            sec_avail="false"

TIME        Fri Feb 22 10:06:07 2008
RELEASE     640
COMPONENT   SNC (Secure Network Communication)
VERSION     5
RC          -4
MODULE      sncxx_mt.c
DETAIL      SncInit
COUNTER     2

We saw this on Windows as well and the solution there was to either change the service to run under the NT AUTHORITY\SYSTEM account and make a corresponding PSE association with SYSTEM, like so:

sapgenpse seclogin -p <mypse> -O SYSTEM

or, keep the service to run under the domain account and add the fully qualified domain user name to the PSE SSO, like so:

sapgenpse seclogin -p <mypse> -O "DOMAIN\Username"

Question

Back to AIX though, does anyone know why a daemon process that runs under the same user and has the same environment settings as when on the console would fail the PSE SSO check. Could it be related to the unix user not being a local host user?

Does the SAP crypto library assume a different name (some sort of FQUN) when running as a daemon and NIS'd user. I know it sounds very far-fetched, but I can't otherwise justify why it would simply error out after reading the cred_v2 file when all else appear equal.

Many thanks,

/Henrik

[Former Member]

Heard back from some great guys at Secude and I thought I should share the finding that led to the resolution of this problem.

Setting the CPIC_TRACE=3 environment variable, generated a trace with enough detail that it was possible, even easy, to discern which user was being used to access the PSE.

In particular the following line was of interest:

GSS-API(min): No credentials found for this name (not logged on) (USER=user)

For the record, there is no such account with name user either locally or in our NIS, and naturally ps was making no references to such an account in the process list. Nonetheless, after

sapgenpse seclogin -p <mypse> -O user

I could access the PSE from the daemon process.

Without fully understanding the rationale for this behaviour, my thanks go out to the folks at Secude.

/Henrik

[WolfgangJanzen]

That actually sounds like a bug - you might consider reporting this to SAP (msg component BC-SEC-SNC) containing a reference to this SDN posting and attaching the entire trace file (from which you've extracted the quoted part).