SSO AD Enabling BO4 SP5 Patch 1

[Former Member]

Hello

I'm trying to set up SSO for a BO4 install.

I have SSO for client tools working.

I have silent SSO through working for WebI while I have -Dcom.wedgetail.idm.sso.password=<PASSWORD> in the java settings.

When I add the keytab, change the global.properties file to include idm.keytab and remove the wedgetail from the java silent SSO stops working.

I've followed the instructions to the letter.#

Any clues?

Regards

John

[Former Member]

Hi John,

Is there any update on this issue?

If you could not resolve this issue then I would suggest you to share the wireshark logs with us.

Do let me know your observations.

Regards,

Swapnil

[Former Member]

Hi John,

You can keep the following parameter as it is in the global.properties file:

idm.princ=srv.account

Regards,

Swapnil

[Former Member]

Hi John,

If the SSO is working fine with the Dcom.wedgetail.idm.sso.password=<PASSWORD> in the java options then I do not think that there is any problem in the SSO configuration.

If we look at your global.properties file, there is one parameter for idm.keytab.

I would suggest you to replace the existing idm.keytab parameter in the global.properties file with the following one.

- idm.keytab=C:/Windows/vintela.keytab  (note the FORWARD slashes)

- Remove the wedgetail.password option from the application server‘s java options.

- Restart Tomcat and ensure you still see jcsi.kerberos: ** credentials obtained .. **. in the application server logs

Do let me know in case of any queries.

Regards,

Swapnil

[Former Member]

I'm not seeing jcsi.kerberos: ** credentials obtained .. **. in the stdout.

idm.keytab has forward slashes.

Everything is as it should be.

But it still doesn't work

[Former Member]

Hi John,

Did you check whether the password for the service account is working or not?

Could you please share the command, you have used to generate the keytab file?

Regards,

Swapnil

[Former Member]

Hi Swapnil,

We would have used the standard command:

ktpass -out myname.keytab -princ BOSSO/bossosvcacct.mydomain.com@REALM.COM -mapuser bossosvcacct@REALM.COM -pass yourpw -kvno 255 -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT

This is the same keytab file we use on a number of 3.1 servers that works.  We didn't create a new one.

John

[Former Member]

Hi John,

Before following the below steps, I would suggest you to check the kinit command with the service account and if it does not work with the service account then let me know the error message.

We used to use -mapuser parameter in BO3.1 while generating the keytab file.

As far as my knowledge is concerned, we do not use –mapuser parameter in the command for BI4.0 (sometimes it works but sometime it does not work).

If we use –mapuser parameter then it maps the “-princ BOSSO/bossosvcacct.mydomain.com@REALM.COM” value with the service account “bossosvcacct@REALM.COM”. Just because of this we face some intermittent issues with SSO in BI4.0.

If you are already using this service account and the keytab file for the existing environment (BO3.1) then I would suggest you to create a new service account for the new environment (BI4.0).

For the new service account, you can follow the below procedure:

- Create a new service account.

- Uncheck these two options from the properties of the service account "Use DES encryption types for this account" and "Do not require Kerberos preauthentication".

- Select this option from the properties of the service account "Trust this user for delegation to any service(Kerberos only)".

- Create the following SPNs for the web application host:

  HTTP/HOST

  HTTP/HOST.DOMAIN.COM

  BOCMS/serviceaccount.domain.com

- Run the SIA under the new service account.

- Create the new keytab file for the new service account using following command:

Command:

ktpass -out myname.keytab -princ bossosvcacct@REALM.COM -pass yourpw -kvno 255 -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT

- Mention the new service account and the keytab file in the global.properties file.

- Restart the tomcat.

- Test the SSO.

Do let me know in case of any queries.

Regards,

Swapnil

[Former Member]

John,

You can also follow the SAP Note: 1548417 to troubleshoot this issue.

Regards,

Swapnil

[Former Member]

Hi Swapnil

We get an error when trying to run without mapuser:

NOTE: creating a keytab but not mapping principal to any user.

For the account to work within a Windows domain, the

principal must be mapped to an account, either at the

domain level (with /mapuser) or locally (using ksetup)

If you intend to map srv.account@MY.DOMAIN.COM to an account through other means

or don't need to map the user, this message can safely be ignored.

WARNING: pType and account type do not match. This might cause problems.

And no keytab is created

Can you advise?

John

[Former Member]

Swapnil?  Do you have any guidance?

[Former Member]

Hi John,

Apologize for replying late.

Could you please tell me what operating system you are using on the Domain Controller?

I am using Windows 2003 Server Enterprise Edition with SP1 and I get the following message/warning while creating the keytab file:

Command For Keytab:

C:\Documents and Settings\boserviceacc>ktpass -out testsso.keytab -princ boserviceacc@ABC.COM -pass Test09 -kvno 255 -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT

NOTE: creating a keytab but not mapping principal to any user.

For the account to work within a Windows domain, the principal must be mapped to an account, either at the domain level (with /mapuser) or locally (using ksetup)

If you intend to map boserviceacc@ABC.COM to an account through other means or don't need to map the user, this message can safely be ignored.

WARNING: pType and account type do not match. This might cause  problems.

Key created.

Output keytab to testsso.keytab:

Keytab version: 0x502

keysize 48 boserviceacc@ABC.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 255 etype 0x17 (RC4-HM

AC) keylength 16 (0x24dbc38317c51cafbdd99514d8eb4994)

Description :

1) “C:\Documents and Settings\boserviceacc>” This is the location where the keytab file will be created/stored.

2) “NOTE: creating a keytab but not mapping principal to any user.” This means, It is creating a keytab file but it will not map the specified service account (boserviceacc@ABC.COM) with any windows AD user.

3) “Key created. Output keytab to testsso.keytab:” This message shows that this command has successfully created the keytab file and the keytab file name is testsso.keytab.

4) “ Keytab version: 0x502 keysize 48 boserviceacc@ABC.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 255 etype 0x17 (RC4-HM AC) keylength 16 (0x24dbc38317c51cafbdd99514d8eb4994) ” These are the contents of the keytab file.

5) In short, we can ignore the above error/warning message but you should get the message “Key created. Output keytab to testsso.keytab:”

6) If you do not see “Key created. Output keytab to testsso.keytab:” message then I would suggest you to contact your Windows AD admin for this.

7) You can also try to update the support tools on your Domain system as the support tools contains ktpass.exe .

😎 You can also temporarily use the ktpass.exe from the other machine where you have Windows 2003 Server Enterprise Edition with SP1. ( Just copy and paste ktpass.exe and use it. Make sure you go the complete path in the command prompt where you save the new ktpass.exe file. )

9) Point Number: 8 is not recommended but if you want, it can save your time.

Do let me know your observations.

Regards,

Swapnil

[christian_fruehwirth]

Hi Swapnil,

I was in the same position as John.

The solution was to change backslashes to forward slashed as you said.

Thanks a lot!

Regards,

Christian

[Former Member]

Hello John,

Can you please share the solution, I am having the same situation and my logs are almost same as yours.

Thanks

K

[former_member136842]

Hello Harthik,

did you checked the idm.keytab Paramter in your global.properties file? You need to use slashes in the path instead of backslashes.

D:\FILES\SSO\bi4.keytab = NO!

D:/FILES/SSO/bi4.keytab = YES!

Maybe you doublecheck.

Regards

-Seb.

[Former Member]

Hello Seb,

I fixed the issue, it was with the princ names (SPN ) .

Thanks

Karthik

[former_member189884]

If you have ran the command with mapuser it may have changed the name of the account which could affect the settings in the global.properties file please verify if sso with the password still works if so the you should be ok and can continue if not you may need to change the setting in the idm.princ parameter to the HTTP SPN.

[Former Member]

Hello John,

Do you see any error message when using keytab?

Best Regards,

Sastry

[Former Member]

Hi Sastry

With global.properties as:

sso.enabled=true

siteminder.enabled=false

vintela.enabled=true

idm.realm=MY.DOMAIN.COM

idm.princ=srv.account

idm.allowUnsecured=true

idm.allowNTLM=false

idm.logger.name=simple

idm.logger.props=error-log.properties

idm.keytab=C:\Windows\vintela.keytab

and the wedgetail removed

On Bootup stdout shows:

log4j:WARN No appenders could be found for logger (org.apache.commons.digester.Digester).

log4j:WARN Please initialize the log4j system properly.

log4j:WARN No appenders could be found for logger (com.sun.faces.config.ConfigureListener).

log4j:WARN Please initialize the log4j system properly.

log4j:WARN No appenders could be found for logger (org.apache.commons.digester.Digester).

log4j:WARN Please initialize the log4j system properly.

log4j:WARN No appenders could be found for logger (com.sun.faces.config.ConfigureListener).

log4j:WARN Please initialize the log4j system properly.

com.businessobjects.webpath.rebean3ws.Activator

On attempting log on this appends with:

Debug is  true storeKey false useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false

        [Krb5LoginModule] user entered username: @MY.DOMAIN.COM

Acquire TGT using AS Exchange

        [Krb5LoginModule] authentication failed

Generic error (description in e-text) (60)

Does that tell you anything?

John

[Former Member]

John,

Could you please do the following and test the issue?

Remove Service account at idm.proinc and give user log on name of the service account.

Restart Tomcat and test the issue.

If this does not work then please give a try with the following SAP article to test the keytab file.

https://websmp230.sap-ag.de/sap/support/notes/1359035

[Former Member]

Hi Sastry

I tried idm.princ=BOSSO/svc.account.MY.DOMAIN.COM

and

idm.princ=svc.account@MY.DOMAIN.COM

Neither worked, same error.  I also tested the keytab file against kinit as per your article, that was fine ticket stored in cache as expected.

John