SSO issue. Manual authentication working fine.

[Former Member]

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

SSO-Issue_Log.txt.zip

[former_member926196 · Accepted solution]

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-

[Former Member · Accepted solution]

Thanks Ambarish.

We had discussed it with SAP Support and confirmed our suspicion that the SSO was indeed going to various KDCs that are unavailable from the server. For the time being we have specified a specific KDC using idm.kdc and are in talks with the IT support team about availability of other KDC servers.

[s0007128803 · Accepted solution]

Hi everyone,

does anyone know if idm.kdc can be used for multiple KDCs?  If so, could you please provide a sample string?

idm.kdc has worked well for me but I would like to provide more resilience to the config and offer more than one KDC to avoid a single point of failure situation.

Thank you.

[Former Member · Accepted solution]

Hi Peter,

I believe this cannot be done since we use this parameter in the global.properties file to force all the SSO requests to be sent on a particular active directory server.

As far as I know this parameter can only have a single value to be specified in the global.properties file.

In case of manually AD authentication, this can be done in KRB5.ini file but nor for SSO.

Hope it helps.

~SwapnilY

[former_member193635 · Accepted solution]

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.

[former_member193635]

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

[Former Member]

Hi,

We had already checked the above steps. As mentioned in a below answer, the server was trying to connect to DCs that did not show up in the nslookup command.

Thanks

Antony