Vintella SSO performance BI4.1 SP04

[former_member190781]

Hello All,

Need your valuable inputs to resolve the following issue.

Issue: SSO is taking delay of 20-30 seconds to log in BI4.1 SP04 (Full build) newly deployed environment.

Environment:

Windows 2008 R2

Tomcat

MSSQL 2012

I have 4 environments, 2 clustered and 2 standalone on all the environments I can see the same issue. post reviewing fiddler traces I found that its VintelaServlet taking most of the time ~80% to process the request. I am attaching fiddler traces here (Please rename the attached file to .rar after download)

Login is quick when I use manual windows AD authentication or enterprise authentication.

Note: The service account used to configure SSO is been used in other environments as well, other SPNs are also registered with it if it may lead to this issue.

Any inputs would be of great help.

Thanks in advance,

Sohel

fiddler traces.txt.zip

[former_member190781 · Accepted solution]

Hello All,

Apologize for responding to this thread after a long time. The issue was resolved after hardcoding the closest DC in global.properties file. with parameter idm.kdc=FQDN of DC.

You can refer KBA 1958936

[Stefan_Backhaus]

Hi!

We are having a similar performance/latency problem with SSO via Vintela/Kerberos. We are on 4.1 SP2. Manual AD-Login is quite fast, SSO takes about 6-8 Seconds longer.

We find it very tough to get to the root cause of the problem.

Sohel, could you make any progress in the meantime?

Any suggestions would be appreciated.

Best regards

Stefan

PS: I just found this and testing it right now:

http://scn.sap.com/thread/1042409

[julian_jimenez]

Stefan,

If using TCP as default protocol doesn't improve the time for the SSO, I would suggest to use the end-to-end traces:

http://scn.sap.com/community/bi-platform/remote-supportability/blog/2012/11/06/how-to-generate-and-c...

You should be able to identify where the time is taken: Tomcat, your own client resolving, the CMS...

Regards,

Julian

[former_member190781]

Stefan,

I raised an incident with SAP and the engineer suggested me to bind the SSO requests to a specific DC so that it will not go through all 250+ DCs in our environment, however I am not confident on this solution as I read it somewhere on SCN that post 3.1 sp3 the vintella plugin already has this feature.

We are yet to impliment this as we are not sure the consequences of this solution.

I already tried the recommendations posted in the SCN link you referred however it didnt make any difference.

[former_member197037]

Hi Sohel,

As suggested by Julian, collect the end to end traces and share with us. They'll probably help us in drilling down the issue.

Also, you can try setting up an AD site under Tomcat >> Java Options

-Djcsi.kerberos.site=mysite

Note: mysite is to be replaced by a DC(FQDN)

Yes the vintela plugin has improved when it comes to contacting a DC but i think trying to bind a DC is worth a try.

Hope it helps.

Regards,

Nagendra

[former_member190781]

Hi Nagendra, Julian,

Thank you for your suggestion, I will try your recommendations and will fetch the E2E traces and upload.

Thanks,

Sohel

[former_member205064]

Is the behavior same for IP and FQDN url.?

[former_member190781]

Thank you @Raunak, the issue can be replicated with IP address and fqdn as well.

[former_member189884]

I would suggest isolating the account to limit the interference with other systems and delegation. That may help, is HTTPS or Contrained Delegation in place?

[former_member190781]

Thanks for your input Josh, its http only we are not using https. Isolating the service account is tough call for us, I would check if we can get a fresh service account. Is there anything else we can do in troubleahooting to find the root cause?

[former_member189884]

the fiddler does not show much I would suggest installing wireshark on the server/client to see if you can see where the delay is occurring, whether it is on the AD side with requesting the ticket or our side with logging in.

Chances are it is with the AD side but you'd need to verify this with the logs.

-Josh

[former_member136842]

Hello,

do you have the Kerberos debugger activiated per default? If yes this creates a massive log over the time and can decrease the performance.

If not it would be interesting to activate it and do a SSO Login. Maybe your nearest Domain Controller passes the Login request to another domain controller with a high latency in between. This could cause the delay.

So go for the Kerberos debugger and check whats in the log.

Regards

-Seb.