Skip to Content
author's profile photo Former Member
Former Member

SSO issue. Manual authentication working fine.

Hi Everybody,

We have configured SSO in our DEV & TEST environments without any issues but in Production it has been nothing but issues. Manual authentication works fine though. Also, stdout is giving a log and I have attached it herewith. I think the issue is either network related or SPN related but I am not able to put my finger on it.

The service account and KDC (Krb5.ini info) are the same for DEV, TEST & PROD.

I could use some help on figuring this out.

We are using BI 4.0 with Tomcat 6.

Thanks

Antony

Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • Best Answer
    Posted on Nov 27, 2014 at 02:18 PM

    Hi Antony,

    Is the issue intermittent or the SSO completely fails?

    Logs indicates that the request is going to certain KDC's which are not available or found.

    [DEBUG] Thu Nov 27 16:35:25 GMT+05:30 2014 jcsi.kerberos: Resolving KDC for realm: CORP.COMPANY.COM

    [DEBUG] Thu Nov 27 16:35:25 GMT+05:30 2014 jcsi.kerberos: KDC not available: /10.41.74.35:88

    [DEBUG] Thu Nov 27 16:35:25 GMT+05:30 2014 jcsi.kerberos: KDC not available: /10.21.90.33:88

    [DEBUG] Thu Nov 27 16:35:25 GMT+05:30 2014 jcsi.kerberos: KDC not available: /10.6.14.35:88

    [DEBUG] Thu Nov 27 16:35:25 GMT+05:30 2014 jcsi.kerberos: KDC not available: /10.5.135.34:88

    [DEBUG] Thu Nov 27 16:35:25 GMT+05:30 2014 jcsi.kerberos: Available KDC found: /10.22.0.35:88

    [DEBUG] Thu Nov 27 16:35:25 GMT+05:30 2014 jcsi.kerberos: Sending message to KDC: /10.22.0.35:88

    [DEBUG] Thu Nov 27 16:35:25 GMT+05:30 2014 jcsi.kerberos: Sending TCP request: /10.22.0.35:88

    [DEBUG] Thu Nov 27 16:35:46 GMT+05:30 2014 jcsi.kerberos: Message send unsuccessful to KDC: SOMECOMPasadeldc01.CORP.COMPANY.COM/10.22.0.35:88

    [DEBUG] Thu Nov 27 16:35:46 GMT+05:30 2014 jcsi.kerberos: Resolving KDC for realm: CORP.COMPANY.COM

    [DEBUG] Thu Nov 27 16:35:46 GMT+05:30 2014 jcsi.kerberos: KDC not available: /10.5.135.34:88

    [DEBUG] Thu Nov 27 16:35:46 GMT+05:30 2014 jcsi.kerberos: KDC not available: /10.41.74.35:88

    [DEBUG] Thu Nov 27 16:35:46 GMT+05:30 2014 jcsi.kerberos: KDC not available: /10.21.83.35:88

    [DEBUG] Thu Nov 27 16:35:46 GMT+05:30 2014 jcsi.kerberos: Available KDC found: /172.16.4.48:88

    If the issue is intermittent you can use "idm.kdc=value_of_kdc" in global.properties file

    To find out for duplicate HTTP/ SPN's as suggested you can run setspn -x on your server and also find using AD explorer as mentioned in http://service.sap.com/sap/support/notes/1387370

    -Ambarish-

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Peter Babbington

      Hello Peter,

      I agree with what Swapnil has said for the manual authentication, there you can mention your backup KDCs as failsafe.

      However this parameter idm.kdc is available for RestFul Webservice SSO methods as far as I know, though I have not tried using it with BI Launchpad SSO mechanism, may be you can try and let me know. But as far as using multiple values is concerned, Swapnil is right. You can specify only 1 value and cannot reuse it in next line again for another value.

      As far as as KDC autodiscovery is concerned, you can rely on it, as it automatically finds the available KDC for you and works on similar lines of nslookup on your domain, so all the DCs that are returned as results there, are the ones that compete for answering the SSO requests.

  • author's profile photo Former Member
    Former Member
    Posted on Nov 27, 2014 at 12:01 PM

    Dear Antony,

    - Your log does give: credentials obtained

    - The clock skew is acceptable

    - Even delegation is enabled

    > Are you using keytab ?, if yes, ensure that keytab is commented and first check with hard coded password in tomcat properties.

    > To check duplicate SPN, try the command: setspn -X

    > Do note that SSO does not work on server hosting Tomcat, you need to check it from the client machine.

    > Ensure that in global.properties file the "idm.princ" value is your user logon name (Usually people end up changing it when they run the wrong ktpass command). Hence verify it again from AD user's account properties tab

    To check network things:

    > Do: nslookup <domain.com>

    >You will get a list of all the DCs that would answer an authentication request.

    > Make sure that all the DCs that comeup. You can do telnet on port 88 to each of them and ensure that it works.

    Hope the above helps.

    Regards,

    Sarvjot Singh

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.