cancel
Showing results for 
Search instead for 
Did you mean: 

Kerberos/GSS API changed from RHEL to RHEL6?

Former Member
0 Kudos

Hello Experts,

for our ABAP systems I have configured SSO via standard MIT Kerberos on Linux/Intel (RHEL5) as well as Solaris/SPARC and Solaris/Intel  - works like a charm.

Now when I upgrade the Linux servers to RHEL6, the OS part of SSO still works, I get a TGT, klist shows me the correct credentials, etc., but the ABAP stack does no longer authenticate via SSO. All I get is a funny error popup "SAP System Message: S".

Is there any known change of the API from RHEL5 to RHEL6 and ideally a way to work around it?

The entry in dev_wx for the log attempt is:

N  *** ERROR => SncPEstablishContext()==SNCERR_GSSAPI  [sncxxall.c 3357]

N        GSS-API(maj): No credentials were supplied, or the credentials were unavailable or inaccessible

N      Unable to establish the security context

N  <<- SncProcessInput()==SNCERR_GSSAPI

M  *** ERROR => ThSncIn: SncProcessInput (SNCERR_GSSAPI) [thxxsnc.c    1034]

M  {root-id=001999B7BD5C1ED2AB982A0ECF295DD0}_{conn-id=00000000000000000000000000000000}_0

M  *** ERROR => ThSncIn: SncProcessInput [thxxsnc.c    1039]

M  {root-id=001999B7BD5C1ED2AB982A0ECF295DD0}_{conn-id=00000000000000000000000000000000}_0

M  in_ThErrHandle: 1

M  *** ERROR => ThSncIn: SncProcessInput (step 4, th_errno 44, action 1, level 1) [thxxhead.c   11313]

M  {root-id=001999B7BD5C1ED2AB982A0ECF295DD0}_{conn-id=00000000000000000000000000000000}_0

The parameters (which are working just fine under RHEL5) are:

snc/enable = 1

snc/gssapi_lib = /usr/lib64/sasl2/libgssapiv2.so

ssl/ssl_lib = $(DIR_EXECUTABLE)/libsapcrypto.so (this is the current PL 43)

sec/libsapsecu = $(DIR_EXECUTABLE)/libsapcrypto.so

ssf/ssfapi_lib =$(DIR_EXECUTABLE)/libsapcrypto.so

login/accept_sso2_ticket = 1

login/create_sso2_ticket = 2

snc/accept_insecure_cpic = 1

snc/accept_insecure_gui = 1

snc/accept_insecure_rfc = 1

snc/extid_login_diag = 1

snc/permit_insecure_start = 1

ssf/name = SAPSECULIB

Installed packages on RHEL5 (all x86_64):

cyrus-sasl-gssapi-2.1.22-7.el5_8.1

krb5-libs-1.6.1-70.el5

krb5-libs-1.6.1-70.el5

krb5-workstation-1.6.1-70.el5

libgssapi-0.10-2

pam_krb5-2.2.14-18.el5

and on RHEL6:

cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64

krb5-libs-1.10.3-10.el6.x86_64

krb5-workstation-1.10.3-10.el6.x86_64

libgssglue-0.1-11.el6.x86_64

pam_krb5-2.3.11-9.el6.x86_64

Any info is much appreciated.

Andreas Niewerth

Accepted Solutions (0)

Answers (3)

Answers (3)

martin_eberle
Explorer
0 Kudos

Hi Andreas

We are facing almost the exact problem:

-we use Kerberos with MIT on our AIX and LINUX (RHEL5) since several month without any problem

-now we've updated one linux machine from RHEL5 to 6

-we have installed the very same librarys & versions like you (except the PAM libs we don't have installed)

-via kinit we get the kerberos ticket without problems

-from the beginning on we have had our ad service accounts with encryption arcfour-hmac

=> if this is DES, then you have to change it or tell in krb5.conf to allow weak encryption. Altough I guess, that you have checked that already (with klist -e)

At the end we get, when trying to login:

1) SAP GUI displays this error msg:  "SAP-Systemnachricht: F".

2) sapni_xxx.trace (With all sap gui debug flags activated) shows:    "Fehler im Security Network Layer (SNC)"

-> this happens after the client had send a SNC packet with (I guess a containing kerberos ticket) to the server. Then the server responds the above short message. Nothing more or less you can see on a network sniff.

3) Server side:

My activities / analysis so far:

- no changes on client side, no changes on sap kernel

- rhel6 comes with new kerberos libs

- rhel6 as kerberos client: => SUCCESS

- tested kerberized SSO with browser->Apache http on this server (on top of the same kerb-libs and krb5.conf) and an additional 'http' serviceprincipal name on the ad service account => SUCCESS

- serverside: the only change is (due to new kerb-libs) the SNC-LIB

=>  this leads me to the point of the referenced library (SNC LIB) on the server (param snc/gssapi_lib)

Here I found that you used a different one then we ?!

We use:  /usr/lib64/libgssapi_krb5.so   (which links to /lib64/libgssapi_krb5.so.2.2)

You use: /usr/lib64/sasl2/libgssapiv2.so

=> What is the right on?

And: did you try to set ENV for KRB5_TRACE? I'm wondering, if the SNC call is honored there and might show additional hints?

Martin

tim_alsop
Active Contributor
0 Kudos

Hi,

When SNC was first introduced (many many years ago) the GSS-API v2 standard was used so that potentially any GSS-API v2 compliant library can be used with the SNC interface. Also, SAP decided at that time to ensure quality and compatibility for their customers, so they introduced the BC-SNC Certification so that any vendor who has a GSS-API v2 library can get their library checked by SAP and certified for use with the SNC interface. This BC-SNC certification is still very important and relavent. The gsstest tool is used during the SAP certification process, and If a library does not pass the gsstest testing, then it won't work with SNC and is not certified by SAP.

The SNC interface was designed to use a particular mech OID which is sometimes now referred to as pre-RFC1964.

I just checked using gsstest with the Redhat native krb5 library, and it shows:

=====================================================================

Loading GSS-API shared library #1 "/usr/lib64/libgssapi_krb5.so" ...

  mech_list from gss_indicate_mechs() #1 contains 4 gss_OID elements:

  {

    [ 0] = {1 2 840 113554 1 2 2}         MECH= Kerberos 5 (v2 - rfc1964)

    [ 1] = {1 3 5 1 5 2}                  MECH= Kerberos 5 (PRE-rfc1964)

    [ 2] = {1 2 840 48018 1 2 2}         

    [ 3] = {1 3 6 1 5 5 2}                MECH= SPNEGO (rfc2478)

  }

SNC will recognize this mechanism OID and force this selection ---

  Selecting mechanism (1) from GSS shared library #1:

      {1 3 5 1 5 2}                       MECH= Kerberos 5 (PRE-rfc1964)

====================

So, it looks like the pre-RFC1964 OID is still supported by the library on RHEL6, but clearly something in the library is badly broken. I did a gsstest myself on RHEL6 and the errors shown are worrying so I think you will find they won't be easy to fix.... I suspect that Redhat are using a more recent MIT library and some changes have been made in that library which stop the pre-RFC1964 OID from working correctly and this is why SNC is not working when using this library.

So, you have a few options:

1 - Install an older release of MIT k5 on RHEL6, and use this instead of the native RHEL6 libraries.

2 - Ask Redhat for help. I am not sure that they will be able to help though, since they don't claim that their library is SAP Certified for BC-SNC.

3 - Buy a license for an SNC library that is SAP Certified and uses Kerberos on RHEL6.

I hope this helps?

Tim

martin_eberle
Explorer
0 Kudos

Hi Tim

Could you run a gsstest on the other lib "cyrus-sasl-gssapi" as well, please?

Martin

tim_alsop
Active Contributor
0 Kudos

Martin,

The libgssapiv2.so library included with the SASL2 library is a SASL plugin, and it uses the libgssapi_krb5.so library. You could use the SASL library to authenticate to an LDAP server, and instead of using LDAP user id and password, the SASL library would load this plugin and use the Kerberos library to authenticate the user. You need a GSS-API v2 library for SNC, not a SASL plugin library.

Thanks,

TIm

Former Member
0 Kudos

Hi,

I found the solution after all, it is not the API that has changed but the packaging.

In RHEL6, the correct snc/gssapi_lib library is /lib64/libgssglue.so.1, provided by package libgssglue(x86_64).

Also to be installed are krb5-libs & krb5-workstation, and then it works.

Tim, the cyrus-sasl-gssapi package is indeed not needed in RHEL 5 either and libgssapi_krb5.so from package krb5-libs is the more logical choice.

Best regards,

Andreas

alexander_rolla
Explorer
0 Kudos

Hi,

We are still facing a similar problem with RHEL 6

i have changed real names with placeholder

Our Kerberos Environment on Linux seems to work already:

kinit -V -k SAPService/host.domain@DOMAIN

Using default cache: /tmp/krb5cc_0

Using principal: SAPService/host.domain@DOMAIN

Authenticated to Kerberos v5

(We are using HMAC-MD5)

dev_w0 Log

SncInit(): found  snc/gssapi_lib=/lib64/libgssglue.so.1

N    File "/lib64/libgssglue.so.1" 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 Kerberos 5/GSS-API v2

N  SncInit():   found snc/identity/as=p/krb5:SAPService/Host.domain@DOMAIN

But whenever i try to connect via SAPGUI with the following Settings i get an Error:

GUI Settings

SNC activated / SNC Name: p/krb5:SAPService/Host.domain@DOMAIN

Error:

SNCERR_UNKNOWN_MECH

SncPImportPrName() parsing error

name="p/krb5:SAPService/Host.domain@DOMAIN"

might there be a Problem on my FrontendPC?

kind regards

Alexander Rolla

Former Member
0 Kudos

Hi Alexander,

I guess this is already very late to reply.

Have you performed the Front end Env modifications / SNC wrapper DLL file configuration as well.

Please try that in case you havent already tried.

1. Run the SAPSSO.MSI  from the SAP Note 595341  or manually copy the snckrb5.dll file into %win%/system32/folder   & set the environment variable SNC_LIB with the value "gsskrb5.dll".


2. Have you also modified the user profile for which you seek to login via SSO , i.e. modify the SNC tab in the user account settings to  p:USERNAME@DOMAIN.COM

Please retry after these settings.

Regards

Prashant

Former Member
0 Kudos

Hi Andreas,

We got the exact same error as you did [ we are on RHEL 6.4] while using the snc/gssapi/lib=libgssapi_krb5.so.

I saw that you were able to resolve your problem by changing the API to the new RHEL 6 relevant file i.e./lib64/libgssglue.so.1 .

I tried to modify our parameter to the value snc/gssapi/lib = /lib64/libgssglue.so.1 .

We already have the packages krb5-libs & krb5-workstation installed . However we are getting a different error now

*** ERROR => SncPEstablishContext()==SNCERR_GSSAPI  [sncxxall.c 3364]

N        GSS-API(maj): Unspecified GSS failure.  Minor code may provide more information

N        GSS-API(min): No key table entry found for SBQADM/<FQDN>@<MYDOMAIN.COM>

N      Unable to establish the security context

N  <<- SncProcessInput()==SNCERR_GSSAPI

M  *** ERROR => ThSncIn: SncProcessInput (SNCERR_GSSAPI) [thxxsnc.c    1035]

M  {root-id=00221982BAFF1EE4858070692A83CB23}_{conn-id=00000000000000000000000000000000}_0

M  *** ERROR => ThSncIn: SncProcessInput [thxxsnc.c    1040]

M  {root-id=00221982BAFF1EE4858070692A83CB23}_{conn-id=00000000000000000000000000000000}_0

Our Kerberos level authentication from Linux to the AD happens correctly via both the SAPServiceSBQ & the SBQADM users i.e. when AD level SPN is created as SAPServiceSBQ or SBQADM

SBQADM

=========

orsapbisbx01:sbqadm 51> kinit -V -f -k SBQADM/<FQDN>@<MYDOMAIN.COM>

Using default cache: /tmp/krb5cc_500

Using principal: SBQADM/<FQDN>@<MYDOMAIN.COM>

Authenticated to Kerberos v5

orsapbisbx01:sbqadm 52>

orsapbisbx01:sbqadm 121> klist -e

Ticket cache: FILE:/tmp/krb5cc_500

Default principal: SBQADM/<FQDN>@<MYDOMAIN.COM>

Valid starting     Expires            Service principal

07/25/14 06:19:27  07/25/14 16:19:27  krbtgt/MYDOMAIN.COM@MYDOMAIN.COM

        renew until 08/01/14 06:19:27, Etype (skey, tkt): arcfour-hmac, arcfour-hmac

orsapbisbx01:sbqadm 122>

SAPServiceSBQ

=================

orsapbisbx01:sbqadm 61> kinit -V -k SAPServiceSBQ/<FQDN>@<MYDOMAIN.COM>

Using default cache: /tmp/krb5cc_500

Using principal: SAPServiceSBQ/<FQDN>@<MYDOMAIN.COM>

Authenticated to Kerberos v5

orsapbisbx01:sbqadm 62> klist

Ticket cache: FILE:/tmp/krb5cc_500

Default principal: SAPServiceSBQ/<FQDN>@<MYDOMAIN.COM>

Valid starting     Expires            Service principal

07/25/14 02:22:24  07/25/14 12:22:29  krbtgt/MYDOMAIN.COM@MYDOMAIN.COM

        renew until 08/01/14 02:22:24

orsapbisbx01:sbqadm 63>

Any help will be greatly appreciated, as we are fighting with kerberos for nearly 2 weeks now.

Regards

Prashant

Former Member
0 Kudos

Have you used GSSTEST to see if the Kerberos 5 implementation in RHEL6 is interoperable with SNC? See SAP note 150380 for details. Adding to what Tim writes, SSO using SNC is no longer free of charge. You will have to purchase NWSSO or a 3rd party solution for it.

https://service.sap.com/sap/support/notes/150380

Former Member
0 Kudos

Hi Samuli,

Tim is well-known in this forum for peddling his 3rd-party solution, SNC via MIT Kerberos is not under any restricted license or any fees at all - confirmed by SAP personnel on last year's TechEd in Madrid.

OSS 150380 does not state that SSO via Kerberos requires any licenses (and I am fully aware that NWSSO does), just that there will bw no official support by SAP.

That is why I post this question at SCN and not OSS.

Although the gsstest tool gave me an "accumulated RC" of 14, the authentification itself was working just fine - until the OS upgrade to RHEL6. With that OS version, the accumulated RC also rose to 38.

Andreas

Former Member
0 Kudos

You are right. Since you are using a different GSS-API then the one provided by SAP for the Windows platform you are not breaking any licensing terms. SAP did change the licensing terms regarding SNC based SSO when they released the SAP NetWeaver Single Sign-On product but since you are not using the SAP provided library, there is no violation. See SAP note 1684886 for details regarding the recent change to licensing terms.

Regarding your problem, now you know what means to have a unsupported solution. You could take it up in a RedHat forum and see what can be done.

https://service.sap.com/sap/support/notes/1684886

tim_alsop
Active Contributor
0 Kudos

This forum is for the product from SAP called SAP NW SSO. If you need help with open source Kerberos issues you need to use the open source community forums. However, I am sure somebody from SAP or a SAP partner would love to sell you their product for providing Kerberos-based SSO on Linux. You can find details of such products in SAP EcoHub (soon to be SAP Store).