Secure Login Client - Started without access to network

[Former Member]

Hi,

We have users that work from home and use the Secure Login Client (Fat client). We are using the SPNEGO authorization method. When they start their computer, they are not connected to the network. The SLC starts at computer startup and runs into a "No host found." error. This is correct. They then connect to the network use VPN software. Since the SLC did not connect at startup, the user does not have a valid certificate. Is there a way to get the SLC to automatically login to the SSO server after the user has connected to the VPN, or do they have to manually login after the connection?

Thanks for any help!

[Former Member]

The problem was solved after upgrading SSO Server to Version 2 SP3 and using the actual SLC version Version 2 SP3. Just shows, that downwards compatibility is not always given. Thanks Alex for your support!

Best regards,

Kent

[Former Member]

Hello,

what version of Secure Login Client do you use?

We have improved the Secure Login Client for VPN use cases in 2.0 SP03.

The new behavior will be that if the Secure Login Client is not able to enroll a new Certificate from
the Server (because of network errors) he will show a bubble warning message and waits till the network settings on the clients will be changed.
After a network change is detected Secure Login Client will start automatically a new certificate enrollment.

best regards

Alexander Gimbel

[Former Member]

Hi Alexander,

Thanks for the response. We are using Release 2.022.

We had the newer release of SLC SP3 installed, but that did not work. That was back in April or May.

Where can I download the newest version of the SLC for testing?

Best regards,

Kent Kleinsteuber

[Former Member]

Hello,

the Secure Login Client 2.0 SP03 is available in the SAP software download center.

What kind of VPN do the client use? Do they use a IPv6 connection (normaly Direct Connect) for VPN ?
As you have tested with 2.0 SP03, does the Connection warning bubble pop up ?

best regards

Alexander Gimbel

[Former Member]

Hi Alexander,

I have downloaded the SP3 version of SLC. It runs but does not use the Kerberos SSO option, even though the Kerberos ticket is in my store and the option in SLC is marked.

After setting the trace for the SLC (which is much more comfortable 🙂 ), I found that is is trying to use my SAP Service Marketplace certificate to verify my user and not the Kerberos ticket. I could not find any options to avoid this behavior.

We are using Checkpoint securty and an SSL web Gateway for our VPN connections.  I will first check whether the "No host found!" error appears, when this problem is solved. Do you have any suggestions?

Thanks and Best regards,

Kent Kleinsteuber

[Former Member]

Hi Kent,

you can configure and regulate this behavior (which profile is used for SNC) over the applications settings.
Please have a look into the Implementation guide for Secure Login 2.0 section 2.6.5 for details.

Manually for the current sessions you can set the Kerberos profile over the context menu, "Use Profile for SAP applications". Then Kerberos should be used for all SNC connections.

For VPN: do you see a new interface, when the VPN will be established (with the command ipconfig /all)?

best regards

Alexander Gimbel

[Former Member]

Hi Alexander,

I have looked at the registry and it looks OK. The only value that was missing was the value for TokenType. I added it and restarted the process, but the result is the same.

I am not logging onto the SSO server with the kerberos ticket in order to receive my X.509 ticket for SAP (SPNEGO). This is marked to be used for the SSO login onto SAP. It is the first step of logging onto the SSO Server that is causing the problem.

Like is wrote up above, the SLC is using my SAP Service Market Place certificate to log onto the SSO Server and not my Kerberos Ticket. With Release 2. Patch 2, this works just fine.

Please advice. Thanks!

Best regards,

Kent

[Former Member]

Hello,

could you provide my the client traces here ?

thanks

Alexander Gimbel

[Former Member]

HI Alexander,

I was thinking of doing that, but I am worried about any sensitive data, which is contained in such a trace. What I can give you here is that the search for certificates.

CertificateRequest.certificate_authorities<0>: Name        :CN=<our root certificate>, OU=<our OU>

CertificateRequest.certificate_authorities<1>: Name        :CN=<our sub root certificate>, OU=<our OU>

CertificateRequest.certificate_authorities<2>: Name        :CN=SAP Passport CA, O=SAP Trust Community, C=DE

The last one is from SAP is not our Kerberos certificate that should be used to log onto the SSO server.

I found that I can use a Registry value "TokenType" = kerberos, but that does not help. If I use the capfilter I can eliminate the use of my SAP Service market place certificate, but my Kerberos key still does not grab.

CAPIFilter:: Certificate: [CN=<my OSS User> S0004315535, OU=SAP SERVICE MARKETPLACE, O=SAP TRUST COMMUNITY, C=DE] rejected by filter

I hope this helps to explain my dilemma. Thanks for any help.

Best regards,

Kent Kleinsteuber

Message was edited by: Kent Kleinsteuber

Addition to Message above. I reinstalled the version Version 2.0.SP2.PL2 and have to admit, that I see the same behavior as above and it works! So that cannot be the problem. It seems that the Version 2.0.SP3 is trying to use my X.509 Certificate instead of the Kerberos method. I have to take a closer look at the trace files to see the difference. Any ideas what is not working right? Best regards, Kent Kleinsteuber

Another Update:

I just looked at the trace files and put a screen shot from both Vers. 2.0.SP2.PL2 and 2.0.SP3.PL0

The result is that in SP2, the kerberos ticket is used and in the SP3 it is not even taken into consideration. Take a look at the file attached (SCN_Thead_15167649_SLC_SP3.docx).

Thanks for any help!

Best regards,

Kent Kleinsteuber

Message was edited by: Kent Kleinsteuber

Update: The SLC SP2 PL5 has the same behavior as SP3 PL0.

Message was edited by: Kent Kleinsteuber

[Former Member]

Hello Ken,

If the logs contains "CertificateRequest.certificate_authorities" entries, this are SSL specific trace entries, which indicate that the used port for a Secure Login Server Enroll uses SSL client authentication.

Please check if you have enabled SSL client authentication on the Enroll URL used port.

Please check the Netweaver Java SSL configuration and look for "Client Authentication Mode" and change that to "Do not Request".

Alternative generate a different port for the Secure Login Server enrolls, which has not enabled that client authentication mode, if you use the port for NW Portal SSL Client authentication.



best regards

Alexander Gimbel

[Former Member]

Good Morning Alexander,

Thank you again.

As you could read from my updates, the "CertificateRequest.certificate_authorities"  information als occurs in the version 2.0.2.2 from SLC. If you could take a look at the attachment in my last thread, it shows that in in Version 2.0.2.2, the Kerberos ticket is automatically used, in the Version. 2.0.3.0, it is not taken into consideration.

I have not made any changes to the network nor in the SSO configuration. I only install the new version of the SLC. I also see this behavior in the Version 2.0.2.5 of SLC.

I hope you can give me a hint of how to continue. Your hints above cannot be the problem. If one version of SLC works for this configuration, then it should work the for newer version of the SLC.

Thanks in advance and best regards,

Kent Kleinsteuber

[Former Member]

Hello,

I have made some experiments with SSL port configuration and you are right, the Secure Login Client 2.0 SP2 and SP3 has the same behavior with SSL client authentication modes. So this cannot be the root cause of the problem.

Unfortunately I cannot reproduce the problem.

It is difficult to analyze this without the exact client configuration (so applications and
profiles/<used profile>) which works on SP2 and not on SP3.

Is there a possibility to get that information? You can also open a CSS ticket if you want.

best regards

Alexander Gimbel

[Former Member]

Hello Alexander,

I am attaching the full traces for SP2 and SP3. Hope this helps.

The profile that is being used should not be important, as current settings works with SP2 and not with SP3, or do I have to make changes in SSO Server, in order to have it work with SP3?

sbus.2.2.txt.zip

sbus.2.sp3.tx.txt.zip

[Former Member]

Hi,

thanks for the traces, I have started to analyze them.

What Secure Login Server Version do you use. Secure Login Client should be backward compatible, but there was one small issue with Secure Login Server SP02 and Secure Login Client
SP03. Could you make a quick test with protocol version 1 and Secure Login Client Sp03 ?

This can be done easy manually:

1. 1. search in the profile entries in the Registry HKEY_LOCAL_MACHINE\SOFTWARE\Policies\SAP\SecureLogin\profiles\<your profile name>
2. 2. change the parameter EnrollRUL0="https://<host>:<port>/SecureLoginServer/slc2/doLogin?....."
   change the "slc2" to "slc1" and try to enroll.

thanks.

best regards

Alexander Gimbel

[Former Member]

Hello Alexander,

The automatic login with kerberos ticket is now running and working fine. We are using SSO Server 2.0.

I hope this helps to clear up the problem. If you need any more information, please let me know.

Best regards,

Kent Kleinsteuber

[Former Member]

Hello,

so if you use "slc1" (1.0 protocol), the SPNEGO works?
You user Secure Login Server 2.0 SP02?

best regards

Alexander Gimbel

[Former Member]

Hi Alexander,

Yes, it runs properly with "slc1" (1.0 protocol). That is, the login to the SSO Server via Kerberos ticket.

As I took over the service of this system, and not quite set in the internal workings of it, I am not quite sure where to look to find out which SP is installed. Where can I find this information?

Best regards,

Kent

[Former Member]

Hello,

you can check the Secure Login Server version in the Secure Login Server Administrator console (SLAC), on the upper right corner there is a About dialog link.

best regards

Alexander Gimbel 

[Former Member]

Hi Alexander,

Thanks!  Here the infos...

Version: 2.0

Support Package: 1

Patch-Level: 4

Best regards,

Kent Kleinsteuber

[Former Member]

Hello,

One more comment:

The Problem with the not working automatic SPNEGO authentication can be solved by a Secure Login Server update to 2.0 SP03. The workaround to switch to the 1.0 protocol works too with older
Secure Login Servers.

best regards

Alexander Gimbel

[Former Member]

Hello Alexander,

Thanks for the infos. Will look into upgrade the SSO Server to SP3.

Best regards,

Kent