SPnego and SNC with AES-256 keys

[Former Member]

SCN pals,

We have SPnego / SNC setup on both our NW7.31SP07 and NW7.40SP07 systems.

We used the basic steps outlined in the videos:

http://scn.sap.com/docs/DOC-40178

But one thing that I have noticed, is that once I have established a connection into SAPGUI via SNC or WEBGUI via SPNEGO, my ticket in "klist" looks like this:

C:\Users\nwells>klist

Current LogonId is 0:0x5b639

Cached Tickets: (2)

#0>     Client: MY-ID @ MY-DOMAIN.COM
        Server: krbtgt/MY-DOMAIN.COM @ MY-DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x60a00000 -> forwardable forwarded renewable initial pre_authent
        Start Time: 5/20/2015 15:26:53 (local)
        End Time:   5/21/2015 1:26:53 (local)
        Renew Time: 5/27/2015 15:26:53 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1>     Client: MY-ID @ MY-DOMAIN.COM

        Server: krbtgt/MY-DOMAIN.COM @ MY-DOMAIN.COM

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent

        Start Time: 5/20/2015 15:26:53 (local)

        End Time:   5/21/2015 1:26:53 (local)

        Renew Time: 5/27/2015 15:26:53 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

#2>     Client: MY-ID @ MY-DOMAIN.COM
        Server: SAP/SA-AGC-ABAP-SID@ MY-DOMAIN.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
        Start Time: 5/20/2015 15:26:53 (local)
        End Time:   5/21/2015 1:26:53 (local)
        Renew Time: 5/27/2015 15:26:53 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)

#3>     Client: MY-ID @ MY-DOMAIN.COM

        Server: HTTP/my-hostname.my-domain.com@ MY-DOMAIN.COM

        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

        Ticket Flags 0x40a00000 -> forwardable renewable pre_authent

        Start Time: 5/20/2015 15:26:53 (local)

        End Time:   5/21/2015 1:26:53 (local)

        Renew Time: 5/27/2015 15:26:53 (local)

        Session Key Type: RSADSI RC4-HMAC(NT)

Does anyone know why my SAP Kerberos tokens come over as RSADSI RC4-HMAC(NT) ?

When I created the keytab at the OS level, I got this as part of the output:

keytab: KeyTab content stored:

    Version  Time stamp                 KeyType   Kerberos name

          1  Thu May  7 15:42:25 2015   DES       SA-AGC-ABAP-SID@MY-DOMAIN.COM
          1  Thu May  7 15:42:25 2015   AES128    SA-AGC-ABAP-SID@MY-DOMAIN.COM
          1  Thu May  7 15:42:25 2015   AES256    SA-AGC-ABAP-SID@MY-DOMAIN.COM
          1  Thu May  7 15:42:25 2015   RC4       SA-AGC-ABAP-SID@MY-DOMAIN.COM

and in the SPNEGO transaction, I have these listed:

DES-CBC-CRC

DES-CBC-MD5

AES128_CTS_HMAC_SHA1_96

AES256_CTS_HMAC_SHA1_96

RC4-HMAC-MD5

RC4-HMAC-MD5-56

So I would think that I'm covered.

I read this note and applied it in my NW7.31 but it was N/A on 7.40.  I meet the kernel requirements too for both.

1832706 - SPNego ABAP: Fixes for Algorithms AES128, AES256, DES

If I get my AD administrator to click the button for my user SA-AGC-ABAP-SID@MY-DOMAIN.COM that says "This account support Kerberos AES 256 bit encryption" in the account options....NOTHING works!  SPnego just goes back to username/pass, and SNC pops up a message when you try  to login that says "GSS-API(min): A2210217:the verification of the Kerberos ticket failed

target="p:CN=SA-AGC-ABAP-SID"

I also read this note:

1677641 - Kerberos authentication problem (SNG/GSS error a2210217)

but we already have the latest NWSSO2.0 SP05 login library and note 1832706.  I'm certain my user/pass for AD is correct.

Anyway..I know I said a lot....ANY thoughts?

thanks,

NICK

[tim_alsop · Accepted solution]

Nick,

Depending on which version of Active Directory you are using and what functional level of domain and/or forest, the encryption type used for Kerberos service tickets will differ. Of course, it is possible to make sure that service tickets are issued with AES etype if the domain supports AES, but this is not the default etype in your case, so RC4 is used.

Thanks

Tim

[Former Member · Accepted solution]

Tim,

I appreciate the response!

So I guess I need to get with the AD guys at my company to figure out what they can do.  Another question related.  My "tgt" is below.  it's always AES 256.

Is that being sent from SAP or AD?  I guess that would help clear up my understanding on this.

and why do I have 2 of the same thing?

#0>     Client: MY-ID @ MY-DOMAIN.COM

        Server: krbtgt/MY-DOMAIN.COM @ MY-DOMAIN.COM

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x60a00000 -> forwardable forwarded renewable initial pre_authent

        Start Time: 5/20/2015 15:26:53 (local)

        End Time:   5/21/2015 1:26:53 (local)

        Renew Time: 5/27/2015 15:26:53 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1>     Client: MY-ID @ MY-DOMAIN.COM

        Server: krbtgt/MY-DOMAIN.COM @ MY-DOMAIN.COM

        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent

        Start Time: 5/20/2015 15:26:53 (local)

        End Time:   5/21/2015 1:26:53 (local)

        Renew Time: 5/27/2015 15:26:53 (local)

        Session Key Type: AES-256-CTS-HMAC-SHA1-96

[tim_alsop · Accepted solution]

It is common to have more than on TGT in the cred cache. This is because the flags are different. You will see that one of them has forwarded flag set.

[Former Member · Accepted solution]

Tim,

Do you know if those TGT's come from AD or SAP? 

[tim_alsop · Accepted solution]

From AD, since AD is a Kerberos authentication server (KDC) and issues Kerberos tickets.

[Former Member · Accepted solution]

Hey Tim,

OK, that's where I am missing something.  if the TGTs for me are always AES-256, then why would the Server: SAP/SA-AGC-ABAP-SID@ MY-DOMAIN.COM and Server: HTTP/my-hostname.my-domain.com@ MY-DOMAIN.COM always come out using  RSADSI RC4-HMAC(NT)?

[tim_alsop · Accepted solution]

AD uses different encryption types for issuing a TGT compared to when it issues a service ticket. Thats why.

[Former Member · Accepted solution]

OK, got ya,

So I guess that when I got the AD person to set this:

If I get my AD administrator to click the button for my user SA-AGC-ABAP-SID@MY-DOMAIN.COM that says "This account support Kerberos AES 256 bit encryption" in the account options....NOTHING works

that really wasn't the correct way to go about it?

[tim_alsop · Accepted solution]

There should be no reason why clicking the option on the user in AD to make it use AES wouldn't work, especially if the implementation of Kerberos being used is 100% standard and implemented correctly. This has nothing to do with the etype used for service tickets.

[Former Member · Accepted solution]

OK, that makes sense.  Yeah, once we click that button in AD for the user for AES 256, the SNC and SPnego cease to work.  Same thing if we do AES128.

but klist command DOES show that the service ticket, which was previously RSADSI RC4-HMAC(NT) is now the AES-128 or 256.

Would you then say the problem is on the SAP side?  If you agree, then I could trace that via SM50 and SE38 SEC_TRACE_ANALYZER.

[Former Member · Accepted solution]

I put in a message...we'll see

[Former Member · Accepted solution]

Still no word from SAP on this issue.  I've called twice now, but since we are demoing the product I can't go past a medium.

[Former Member · Accepted solution]

Resolved.

I had no idea how important CASE is/was for AES-128/256.

You need to remember a few things for AES-128/256:

1) Your AD team MUST check the 2 boxes for AES-128/256 in the account options for the service account being used.

2) YOU MUST make sure to capitalize the right side of the "@" for your AD service user in both tcode SPNEGO and at the OS level when you build the SAPSNCSKERB.pse

3) I would HIGHLY recommend you get your AD team to build your service user in ALL CAPS.

4) Make sure you build the left side of the "@" with either all CAPs or all lower-case depending on what the AD team did in #3 above.

5) DO NOT CUT/PASTE ANYTHING for TCODE SPNEGO and at the OS level for building the SAPSNCSKERB.pse.  Type it all in manually.

6) make extra sure you know the password of your AD service user.  You can test it by going to your secure login client, right click on your Kerberos toke and do "Login".  Put in your service user (include the @DOMAIN.COM and the password.  it should work!

A good rule of thumb for us was to just take the default RC4 algorithm first.  So if that works, at least you know you did 99% of the stuff right.  THEN and only then check the AES-128/256 and go from there.

Still won't work?  For #4 above, try the userID of the service account left side in both upper and lower case.  Just play with it, regardless of what you AD team said they did!

You can do an excellent trace of the authentication with the help of note 1848999.  If it's not working, go ahead and do it.  SAP will want it anyway.

Follow these steps because if you don't SAP will make you do them anyway when they troubleshoot the issue!