SNC SSO on AS ABAP and ADS 2008 error "Encryption type not permitted"

[Former Member]

Hi,

We are trying to configure the SSO between AS ABAP on SPARC Solaris 10 and AD on windows 2008 SP2 using SAP SNC and MIT kerberos V5.

Now the Configuration part between SAP server and AD server already done. SAP system start with SNC module activation.

Now we are trying to connect SAPGUI on windows XP client with SNC_LIB = c:\windows\system32\gsskrb5.dll. (the library download for SAP note352295 (win32sso.zip)

We got the error message "SAP system Message:". So we have checked the trace file "dev_w0". found the error message

++++++++++++++

Tue Jun 22 09:41:37 2010

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

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

more information

GSS-API(min): Encryption type not permitted

Unable to establish the security context

<<- SncProcessInput()==SNCERR_GSSAPI

• ERROR => ThSncIn: SncProcessInput (SNCERR_GSSAPI) [thxxsnc.c 976]

• ERROR => ThSncIn: SncProcessInput [thxxsnc.c 981]

in_ThErrHandle: 1

• ERROR => ThSncIn: SncProcessInput (step 4, th_errno 44, action 1,

level 1) [thxxhead.c 10607]

+++++++++++++++++++++

Any help would be appreciated.

Thanks and regards,

Eak

[mvoros]

Hi,

have a look at note 1257108. It contains many tips for troubleshooting as well as heaps of references to other notes. But my guess is that SAP system and AD can't agree on encryption mode. I guess you need to set compatible mode with SAP system on your windows box. I remember something like Microsoft disabled DES by default (good thing) in newer relases and SAP still can use only DES (really bad thing).

Cheers

[tim_alsop]

When you logon to the workstation, using MS AD domain, the encryption type will likely be RSA RC4, or AES if you are using a 2008 domain. The library on server needs to be configured to support this same encryption type.

I hope you are aware that you can purchase a commercially supported and SAP certified SNC library that uses the Kerberos protocol, and has extra features - then you will be supported in case anything goes wrong. The use of MIT k5 with SAP is not supported by SAP or any other company.

Thanks,

Tim

[Former Member]

Hi All,

Thank you for your information,

Let me clarify my understanding, The problem is encryption between windows XP to AD server (windows 2008) or SAP server (Solaris)?

Currently we can use the kinit command to get the TKT certificate from SAP server to AD server.

Should not be the server to server problem. Am I right?

Best Regards,

Eak

[tim_alsop]

>

> Hi All,
> 
> Thank you for your information,
> 
> Let me clarify my understanding, The problem is encryption between windows XP to AD server (windows 2008) or SAP server (Solaris)?
The problem is that XP workstation has obtained a ticket and sent to SAP server, and SAP server has rejected it becuase the encryption type used inside the ticket is not supported by the server.
> 
> Currently we can use the kinit command to get the TKT certificate from SAP server to AD server.
> Should not be the server to server problem. Am I right?
The problem is not between SAP server and AD because you have been able to start SAP without an error in work process log. The problem occurs during logon, which is explained above.
> 
> Best Regards,
> Eak

[Former Member]

Hi Tim Alsop,

Thank you for your clarify,

Now I changed the encryption type from DES-CRC-MD5 to RC4-HMAC as below steps. the error "Encryption type not permitted" was gone but the error "Wrong principal in request" instead.

On Windows 2008 AD

1. ktpass -princ sapsnc/dontcare @ECC6.CORP -mapuser ECC6\sapsnc -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -mapop set +desonly -pass P @ssw0rd -out snc.keytab

On SAP server

2. In /etc/krb5.conf

[libdefaults]

default_realm = ECC6.CORP

default_etypes = rc4-hmac

3. kinit -k -t /etc/snc.keytab sapsnc/dontcare @ECC6.CORP

4. In SAP profile

snc/identity/as = p:sapsnc/dontcare @ECC6.CORP

SAP start successfully

5. In SAPGUI -> network

SNC name = p:sapsnc/dontcare @ECC6.CORP

then I tried to logon, no luck SAPGUI error message and check on dev_w0 found the error below

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

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

GSS-API(min): Wrong principal in request

Unable to establish the security context

Do you have any idea?

Thanks so much,

Best Regards,

Eak

[Former Member]

Hi Tim,

I need your help. Sorry EAK I dont want to disturb your thread but I have some problem need you guys help.

Please also check this for me

Due to SNC Kerberos my JAVA Server is not starting.

Thanks,

Ajay.

[tim_alsop]

Yohan,

I wish I could help you with this new error. However, I am in a difficult situation, since you are asking for help/support with an unsupported implementation. Also, I represent a company that sells a solution which does exactly what you are trying to do with open source. It would therefore be hard for me to help you any more since this would make it look like I am helping you with a competitive solution to the one which my company sells. The error you are getting is very easy to solve if you understand Kerberos protocol, but clearly you don't. This is why you need a supported solution from a SAP partner. Consider what would happen if you get this working and then implement in production in your company and then you get an error like this when a user tries to logon or when the production SAP system is restarted - if SAP cannot be restarted, this will cause issues if it is production system. If you have a supported solution you will have somebody who understands the protocol and technology and who can assist if things go wrong, as they often do - when you don't expect them to...

Thanks,

Tim

[Former Member]

Tim,

I feel uncomfortable with your answer.

You are very knowledgable on SSO issues and you have been helpful to a lot of people BUT in my opinion you are here too much to sell your product. I am not sure that the spirit of the SDN forums is to recruit new customers.

This is just my opinion but I would like to know what moderators think about it.

Best Regards,

Olivier

[tim_alsop]

Olivier,

In hindsight, perhaps my answer was a bit OTT (over the top). The alternative would have been for me to help him fix open source implementation of Kerberos, which would give him the wrong impression that open source Kerberos usage with SAP is supported, which it is not. Another alternative is for me not to answer when somebody directs a question at me asking for help, but I prefer to give honest and truthful answers instead.

Thanks for your understanding. As mentioned, I am trying to set exectations with my response.

Tim

[Former Member]

In my opinion it is okay as Ajay_basis is the real problem here and the solution is some training for the job or purchasing a supported solution.

I interpret Tim's comment to be a disclaimer with a flavour of "may you live in exciting times" to it. After checking ajay's other posts I can understand this.

But yes, blatant adverts particularly without contributing anything else would be an example of something we normally reject or even add to the content filters.

For example: There was a company which pretended to be happy customers giving advice to others... Their product is now no longer certified, thanks to the attention of the authorities which this stunt attracted...

But that is not the case here in my opinion.

Cheers,

Julius

Edited by: Julius Bussche on Jun 25, 2010 11:09 PM

[Former Member]

Windows Vista, Windows 7 and Windows 2008 R2 all disable DES encryption types by default. I first ran into this with SPNEGO failing during authentication to one of my SAP portals. Note 1396724 talks about your options when it is a portal kerberos problem, but the same encryption problem can be caused for SNC.

Now in this case you have two options. Have DES encryption types turned back on and supported, or move to an encryption type that is. I would recommend you simply update your configuration to support RC4. Chances are the rest of your environment and kerberos libraries are not new enough to support AES.

Have your domain admin uncheck DES encryption type support from your service user, and then request they run KTPASS again to create a RC4-HMAC keytab. Once this is completed you will need to copy the new keytab into /etc or where ever you are reading that file from in Solaris right now.

Something along these lines shoudl work:

ktpass /princ servicesusername/dontcare /mapuser AD\ serviceusername /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL /pass <password> /out krb5.keytab

[Former Member]

Hi, Yohan!

Have you decided your problem?

And then I got the same message

[tim_alsop]

>

> Hi, Yohan!
> 
> Have you decided your problem?
> And then I got the same message

This is likely because the SNC library you are using does not support AES encryption type. You need to contact the vendor of your SNC library and ask if they have a new version which you can use, or if there is a patch available. Or, you can use a different SNC library, which does support AES.

[Former Member]

When you generate your ticket you can check what encryption types are being used by your ticket with klist -e. If an encryption type is not working it will state so in the response. Have your unix support run a truss on klist and determine what is missing.

When I ran into a similar issue it was because pkcs11_softtoken_extra.so.1 was missing. We created a soft link to this pkcs11_softtoken_extra.so, perhaps something similar needs to be done. Also be sure to register any new libraries you add, again your UNIX support should be capable of completing both for you.

I've setup SNC between AD 2008 R2 and Solaris Sparc 64-bit on multiple servers now. In every case my kerberos tickets are coming back as AES-256. So as long as your Solaris libraries are up to date, you should be ok.