Thanks Wolfgang for brief explanation.

If we keep "No for Legacy Logon ticket then, issue #5 happens. The work around was to setup "Yes" for Legacy.

After above setting, Issue#5 on reoccur, when we have PPM NWBC (tab 1 in below screen) already running in same browser and open FIORI Launchpad.It prompt for the user id and password. I don't understand why NWBC running for PPM should have conflict with FIORI. The only workaround is to identify each service and bump up "SAML " login module.

For Issue # 6.

Below is the architecture flow.

FIORI SP -> Siteminder IDP ( SAML) -> FIORI Launchpad -> Backend ECC (Trusted RFC)

PPM NWBC ITS User id and pwd -> ECC (Trusted RFC)

Therefore I don't understand why SAML Authentication has to conflict with PPM MYSAPSSO2 for the Issue#5.  They both are on same domain .. Is that an issue?

For session timeout handling, FIORI SP does request re-authentication from IDP but it is frame in frame. Please advice if we can avoid it.

Thank you in advance.

Santosh Lad

Thank you Chris, we do have configured HA which has a fallback SLS server, but we were just trying to see what happens when both the server goes down (very unlikely) , but just incase then the users dont get a login gui, they just get an error message saying SLS is not available .

Thank you

Jonu Joy

Hello Nick,

no need for apologies, I appreciate your help

The first image shows exactly what I mean. To be fair this also happens when using the "usual" logon screen, I simply don't know where to set a default parameter for every user. This really bugs people a lot, as well as not being able to switch languages when they only have one user / one client per system. They would have to go to their profile and change the parameter, but that kills the feeling of a benefit by using SSO and really complicates my project.

Hey Nicolai,

I gotcha.  OK, well, I tried the same steps on my systems.  By that, I mean I changed the language to DE on the SAPGUI logon screen both using SSO and NON SSO in the SAPGUI.  My default in SU01 is still EN.  I didn't change anything in SU01.

I can say that it did make everything German.  My systems are a combination of NW7.31, NW7.02, NW7.40 and that all seemed to work....allowing me to pick between EN and DE based on what I put in the logon mask during the login process.

Could it be that the language you are trying to allow a user to use was never installed?  I really don't know, but it seems like for our systems, SU01 is irrelevant and you should be able to over-ride the language, just like you are trying to do.  At least it works for me....but I know that doesn't help you

Also, if you have CUA, that always adds another layer of complexity.

Knowing that this issue happens for you regardless of SSO/NON-SSO, I still think this question belongs in another forum.  Like maybe the netweaver administrator forum?

NICK

Hello Nick,

our SAP users complain about the extra step they have to perform to change their logon language.

They would like to have a preset for every system just for their user.

They usually use SAP in German, but for some systems they need English as a preset.

What they've got to do is change the language to EN, they want the system to choose EN instead of DE when they try to log on (this is not connected to the SU01 settings).

But I am afraid this won't be possible, at least not user specific with SSO.

Hi All,

I have configured SSO based on Kerberos with SAP Single-Sign On 2.0, the solution used to work before with both web browsers and SAP Logon (Windows). However, recently when I recheck, the SSO does not work anymore for browser authentication. I can log into SAP GUI (for Desktop) with SSO, but when I checked SPNego configuration, the Token Check has error with the following message.

I tried to check the system lock of our KDC, SAP Application Server, as well as my workstation and synchronize the system clocks. However, this does not solve the problem. As you can see from the above screenshot, Kerberos token expires after 5 minutes, so I tried to extend the Maximum tolerance for computer clock synchronization in to 10 minutes, but the situation is still the same, the token still expires after 5 minutes. Could you please provides some hints to troubleshoot the error.

I'm not sure if it's the root cause for SSO on web browser but SSO for SAP GUI does work. I checked the note 1732610, but I guess I need to solve the token verification error first.

I would be very grateful for any contribution.

Best regards,

Duy

Sorry man.  I am out of ideas, not that I ever really had one.  I'm still not sure this is an issue that belongs here in this forum.  I suggest you get a message open.

--NICK

Hey Duy,

Consider tracing the process using report SEC_TRACE_ANALYZER or

you can get there inside SPNEGO tocode at "goto - spnego tracing"

Also, if you follow note 1848999 you can create a ini file called sectrace.ini at the OS level so you can view traces that SAP is going to want anyway.

NICK

Hi,

I have spent quite a while now looking for a resolution so I decided to post finally.  I am trying SSO and am getting an error.  This is the error I am getting when going to BI Launchpad

HTTP Status 500 - com.wedgetail.idm.sso.ProtocolException: com.wedgetail.idm.spnego.server.SpnegoException: GSSException: Failure unspecified at GSS-API level (Mechanism level: com.dstc.security.kerberos.KerberosException: Could not decrypt service ticket with Key type 18, KVNO 2, Principal "HTTP/biwebdev1.corp.domain.com@CORP.DOMAIN.COM" using key: Principal: [1] BOSSO/SVC_BOE_DEV.corp.domain.com@CORP.DOMAIN.COM TimeStamp: Wed Jul 29 02:16:16 CDT 2015 KVNO: -1 EncType: 18 Key: 32 bytes, fingerprint = [4f 2 e1 98 79 dd 53 1 92 45 6e 61 29 eb a8 fb] Exception for this key was: com.dstc.security.kerberos.CryptoException: Integrity check failure[Note: principal names are different; this may or may not be a problem] [Note: KVNO used wildcard match, not exact match; perhaps the password used to generate this key is not the most recent password?] )

This is the end of the stderr.log file

[DEBUG] Wed Jul 29 02:18:38 CDT 2015 jcsi.kerberos: GSS: Acceptor supports: KRB5

[DEBUG] Wed Jul 29 02:18:38 CDT 2015 jcsi.kerberos: Ticket service name is: HTTP/biwebdev1.corp.Domain.com@CORP.DOMAIN.COM

[DEBUG] Wed Jul 29 02:18:38 CDT 2015 jcsi.kerberos: GSS name is: BOSSO/SVC_BOE_DEV.corp.Domain.com@CORP.DOMAIN.COM

[DEBUG] Wed Jul 29 02:18:38 CDT 2015 jcsi.kerberos: Using keytab entry for: BOSSO/SVC_BOE_DEV.corp.Domain.com@CORP.DOMAIN.COM

[DEBUG] Wed Jul 29 02:18:38 CDT 2015 jcsi.kerberos: ** decrypting ticket .. **

  with key

  Principal: BOSSO/SVC_BOE_DEV.corp.domain.com@CORP.DOMAIN.COM

  Type: 1

  TimeStamp: Wed Jul 29 02:16:16 CDT 2015

  KVNO: -1

  Key: [18,  75 67 53 b4 8 b0 df 1b 4d 2f a0 8a 13 bc aa f a e7 ff bd 47 f7 6c 3c 38 2d 9e 4a ca 43 b2 70 ]

[DEBUG] Wed Jul 29 02:18:38 CDT 2015 jcsi.kerberos: Could not decrypt service ticket with Key type 18, KVNO 2, Principal "HTTP/biwebdev1.corp.domain.com@CORP.DOMAIN.COM" using key:

Principal: [1] BOSSO/SVC_BOE_DEV.corp.domain.com@CORP.DOMAIN.COM

  TimeStamp: Wed Jul 29 02:16:16 CDT 2015

  KVNO: -1

  EncType: 18

  Key: 32 bytes, fingerprint = [4f 2 e1 98 79 dd 53 1 92 45 6e 61 29 eb a8 fb]

Exception for this key was:  com.dstc.security.kerberos.CryptoException: Integrity check failure[Note:  principal names are different;  this may or may not be a problem]

[Note:  KVNO used wildcard match, not exact match;  perhaps the password used to generate this key is not the most recent password?]

[DEBUG] Wed Jul 29 02:18:38 CDT 2015 jcsi.kerberos: Caused by: com.dstc.security.kerberos.CryptoException, Integrity check failure

This is my global.properties file

sso.enabled=true

siteminder.enabled=false

vintela.enabled=true

idm.realm=CORP.DOMAIN.COM

idm.princ=BOSSO/SVC_BOE_DEV.corp.domain.com

idm.allowUnsecured=true

idm.allowNTLM=false

idm.logger.name=simple

idm.logger.props=error-log.properties

idm.keytab=E:/WINNT/DEV-TESTSSO.KEYTAB

BILaunchpad.properties file

authentication.visible=true

authentication.default=secWinAD

cms.default=BIAPPDEV1:6400

These are my tomcat java options

-Djava.library.path=C:\Windows\SysWOW64\;E:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\

-Dcatalina.base=E:\Program Files (x86)\SAP BusinessObjects\tomcat\

-Dcatalina.home=E:\Program Files (x86)\SAP BusinessObjects\tomcat\

-Djava.endorsed.dirs=E:\Program Files (x86)\SAP BusinessObjects\tomcat\common\endorsed\

-Dbobj.enterprise.home=E:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\

-Xrs

-XX:MaxPermSize=384M

-Djava.awt.headless=true

-XX:+HeapDumpOnOutOfMemoryError

-Xloggc:E:\Program Files (x86)\SAP BusinessObjects\tomcat\logs\tomcat.gc.log

-XX:+PrintGCDetails

-XX:+UseParallelOldGC

-Djava.security.auth.login.config=E:\WINNT\bscLogin.conf

-Djava.security.krb5.conf=E:\WINNT\krb5.ini

-Djcsi.kerberos.debug=true

AD manual login is working great.  Someone please help!

Hi Nick,

The original problem related to clock skews, and it is fixed by changing at OS level. However, before making the change, I deleted and recreated the key tab in SPNEGO transaction. After that, using SEC_TRACE_ANALYZER, I found the following errors:

The SSO for SAP Logon still works so probably only the key tab created in SPNEGO is the root cause. I believe that I should not delete the key tab in the first place, I don't know how to troubleshoot the problem now. The password for service user in SPNEGO transaction is corrected, the service user also has the host name in HTTP service principle name.

Do you have any idea how to solve the problem?

Regards,

Duy

Hey Duy,

That's the thing about SSO, there are so many moving parts to this which makes it very difficult to troubleshoot.

Like you said, if SNC-SSO is still working to the SAPGUI, then at least you know the AD user-end of things is good.  check "klist" in you DOS prompt on your PC to see if the Kerberos token is coming across when you make the HTTP call.

it should be the FQDN in the service principle name.  Hostname.domain.com

so if you "fixed" the password in SPNEGO then i'm hoping you did the same when you created the sapgenpse keytab right?  what about the cred_v2 ?  do the PINs match?

Browser changes can screw you up to.  Check that in note 1732610.  The "trusted"  or local intranet sites loaded in IE can create an issue.  They did for me.  So you need to check to see if any of those hostnames / IPs match the ones you are trying to reach.

I still say it would be valuable to enable the OS tracing like I said before.

NICK

Turns out I just need to read the documentation closer.  It's in there!

Section 4.1

And it does work in terms of storing "Ignored" URLs.

NICK

The CommonCryptoLib already supports TLS_FALLBACK_SCSV as a client. This prevents susceptibility to attacks on the SSL/TLS client which depend on protocol downgrades.

However, as a server, TLS_FALLBACK_SCSV isn't supported by the CommonCryptoLib. Suppose we have the case where we must provide compatibility with Internet Explorer 6.0 on Windows XP, in an environment where we do not control the user settings, and hence must provide support for SSL 3.0. Whilst IE6 will always be vulnerable to the POODLE attack because by default it will only connect over SSL 3.0, even if our server supports TLS 1.0, 1.1 and 1.2, a MITM attack can always drop any other browser down to SSL 3.0 without support for TLS_FALLBACK_SCSV.

There is a way to mitigate the POODLE attack on SSL 3.0, which is to use record splitting. Also, disabling CBC ciphers over SSL 3.0 will mitigate the vulnerability. Opera have taken the first option and Apple the second. However, record splitting causes compatibility issues due to problems in server-side implementations, and disabling CBC ciphers leaves only RC4 over SSL 3.0, which has also been broken. This leaves many browsers still vulnerable to POODLE, in particular in the mobile space, unless we disable SSL 3.0 on the server side.

Furthermore, there is a TLS 1.0 POODLE exploit affecting servers which fail to check the padding byte requirements. A server demonstrating this vulnerability and not implementing TLS_FALLBACK_SCSV will allow an attacker to roll the browser back from TLS 1.2 or 1.1 to 1.0 in order to use the exploit.

These may not the only attacks that will ever be discovered against older protocols. The draft of TLS 1.3 removes numerous deprecated features from TLS 1.2 which are seen to weaken security, such as compression, renegotiation, non-AEAD ciphers, static RSA and DH key exchange, custom DHE groups, point format negotiation, Change Cipher Spec protocol, Hello message UNIX time, and the length field AD input to AEAD ciphers. If and when new attacks against these features are found and TLS 1.2's (and/or earlier) security is weakened, without TLS_FALLBACK_SCSV support, users will be vulnerable.

There is a flip-side to all this. The reason protocol downgrades are possible is because early implementations of TLS 1.0, 1.1 and 1.2 were often broken. The protocol downgrade occurred when a client couldn't initiate a session with the broken server. TLS_FALLBACK_SCSV doesn't convey any version information and as such becomes a "never fall back" signal. This means that a server implementing TLS_FALLBACK_SCSV with a broken TLS 1.2 implementation will lose the ability to serve requests to the majority of clients. That's Microsoft's view of things, which is why neither IE nor IIS implement the flag.

However, given the inherent insecurity of older protocol versions, I'm not sure SAP should be following Microsoft's lead here, but instead should be following Google and Mozilla.

What is the view of the wider community on whether this flag should be implemented? Do the compatibility concerns outweigh the security advantages, or vice versa?

The CommonCryptoLib does not currently support OCSP Stapling. OCSP Stapling is a method for checking the revocation status of an X.509 digital certificate (commonly referred to as an SSL certificate). OCSP Stapling works by taking the burden of checking the revocation status away from the certificate issuer and placing it on the certificate holder.

Currently, when a user visits a website, if the certificate authority (CA) supports OCSP, a request is sent to the CA to check whether the certificate has been revoked or not, as well as any certificates in its chain. This requires the user's browser to perform a DNS lookup and send multiple HTTPS requests to the CA. In practice, in a corporate network, because users often are not allowed to perform such requests, revoked certificates can continue to be used, because the browser can't check the revocation status. For high-traffic websites, revoked certificates can continue to be used because the CA can't handle the volume of requests.

With OCSP, the certificate holder polls the CA periodically to check the revocation status, and receives a signed response from the CA which is appended to the response sent to the user's browser. It isn't possible (as far as we know) to forge these. The response from the CA is time-stamped, so the request will have to be sent out again before that expires, meaning that a revocation will filter through before too long.

Does the wider community think that adding support of OCSP Stapling to the CommonCryptoLib is a good idea? Personally, I can't see any downsides. Support exists on the server side in OpenSSL from 0.9.8g, the Apache HTTP server since 2.3.3, nginx since 1.3.7, LiteSpeed since 4.2.4, IIS since Windows Server 2008, HAProxy since 1.5.0 and F-5 Networks BIG-IP since 11.6.0, and on the client side, Firefox since version 26, and Chrome and IE since Windows Vista.

Hi Nick,

I did enable the sec trace like you said, the result is similar to the report SEC_TRACE_ANALYZER. I checked before and after the HTTP call, and there is a token for HTTP, as being specified in KDC:

I create SNC-keytab with sapgenpse (and also SPNEGO) again, but it does not help. PSE PIN AND cred_v2 seems to be ok:

I configured IE before, so it would not be the problem.

I tried to focus on the error messages about the decryption failed. In SM21, I can also see the error "SPNego Authentication failed since received token could not be decrypted". Because the password of SPNEGO is correct, I don't know how to continue from here, I tried to search for the error code but no result found. Do you have any other suggestions to troubleshoot the error?

Regards,

Duy

Hi Duy,

You can check your service account password using the SAP note https://service.sap.com/sap/support/notes/2010613 and run the report SNCAX_TEST in transaction se38. You can check it too if you righ click on the kerberos token in Secure Login Client, select Log in... and enter your service account and its password.

KR

Valerie

Hi Valerie,

I checked those before, and they are ok.

Regards,

Duy

You've done all you can do...time to open a message!

SSO experts,

We have SPNEGO setup for one of our AS JAVA 7.4 SP8 systems  (NOT a portal!).  SSO works great!

SSO works great for things like:

NWA

http://hostnameFQDN:port/nwa

UME

http://hostnameFQDN:port/useradmin

RedwoodCPS  (v8.33.112) --> we have ETPRJSCHEDULER deployed and we pay for the full version.

http://hostnameFQDN:port/scheduler

My issue is that SOME users don't want to use their AD userID to SSO to the redwood URL above.  They want to put in a different username and a password.  I thought to myself, OK, no big deal, just add the ?spnego=disabled at the end of the URL right?

Well, that doesn't work on the redwood CPS URL above.  it just gets ignored and goes right into SSO!

Now, for the NWA, the ?spnego=disabled DOES work like it is supposed to!  Forcing the username/pass login.

http://hostnameFQDN:port/nwa?spnego=disabled

For the UME, http://hostnameFQDN:port/useradmin?spnego=disabled doesn't work either but it can see the URL gets extended to /webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/UmeAdminApp and if you stick ?spnego=disabled at the end of that, it will force username / password.

But at any rate, the point is I want RedwoodCPS to force a userID/pass screen using the http://hostnameFQDN:port/scheduler?spnego=disabled

but this does not work.

I also tried http://hostnameFQDN:port/scheduler/ui?spnego=disabled but still no good.

Any ideas?

thanks

NICK

Hello Experts,

We want to configure SSO using SAML between Active Directory and SAP SRM system.

SRM system version is SRM 4.0 which does not support SAML so we are routing this authentication request (token) via SAP Enterprise portal which is on NW 7.31.

In SAP Portal one service provider is already configured for an alias created for Portal itself.

Now we have created another alias for SRM system and same needs to be configured in SAP EP so my query is

What should i do now,

1) Either i should ask IAM team to regenrate metadata again for new alias or

2) Can i create another service provider somehow in NW and download the proceed further.

Sorry if i sounded unaware about SSO terminologies as i am a newbie in this era.

Warm Regards,

Sumit Jha