[BI 4.x] Enabling Keytab File For SSO - SBOP 4.2 SP2

[system]

Hi All,

I am trying to set up a clean SAP BusinessObjects 4.2 SP2 environment. Everything is set up and working ok from an Windows AD and SSO perspective, except for when I try to use the keytab file. When I have the password hard coded in either the Java options of tomcat (-Dcom.wedgetail.idm.sso.password=PASSWORD), or in the global.properties file using idm.password=PASSWORD everything works perfectly and SSO logins to BI Launchpad are fine. As soon as I comment out the idm.password line however, and uncomment the idm.keytab line,

idm.keytab=C:/Windows/bodev.keytab  
# idm.password=PASSWORD  

I get the following errors in the tomcat stderr.log when attempting an SSO login

com.crystaldecisions.sdk.exception.SDKException$InvalidArg: The argument has an invalid value null (FWM 02024)  
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)  

I have tried rebooting the server after making the change.
Confirmed that the following is still appearing in the tomcat logs on startup after applying the keytab file:

jcsi.kerberos: ** credentials obtained .. **  

Everything else seems to be working ok when the password is passed via idm.password in global.properties.

The SPN is set as follows in the global.properties:

idm.princ=BICMS/ServiceAcccount.Name.BUSINESS.DOMAIN.COM  

I have confirmed this matches the UPN on the account

BICMS/ServiceAccount.Name.BUSINESS.DOMAIN.COM  
 

And the same SPN exists too (in addition to all the other HTTP SPN’s for the host names - short and FQDNs).

I can test the keytab from the server successfully by running

 
kinit -k -t C:\Windows\bodev.keytab BICMS/ServiceAccount.Name.BUSINESS.DOMAIN.COM  

And I get a

 
New ticket is stored in cache file C:\Users\graeme.smith\krb5cc_graeme.smith  

This SPN is the same one that is set up in the CMS -> Authentication -> Windows AD -> SPN
Use Kerberos Authentication is enabled.
Cache security context is not enabled.
Enable SSO is enabled.

I have checked for duplicate SPN’s in AD using

setspn -x

I think I have read just about every SAP note and post on the web about this area, but cannot find much on this specific error message.

Any help or ideas would be greatly appreciated (I’m about to jump out a window!).

Thanks and Regards,

Graeme

---

GraemeSmith (BOB member since 2002-08-16)

[system]

Did you use the -mapuser parameter in ktpass?

---

joepeters (BOB member since 2002-08-29)

[system]

Hi Joe,

Yes - I had initially tried without that (I didn’t have permissions in AD to run it), but had it executed by our AD team before posting. The syntax used was as per below:

ktpass -out bodev.keytab -princ BICMS/ServiceAcccount.Name.BUSINESS.DOMAIN.COM@BUSINESS.DOMAIN.COM -mapuser ServiceAcccount.Name@BUSINESS.DOMAIN.COM -pass "Iama^Complex!Password" -kvno 255 -ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT  

I think this worked ok, as I previously had problems where kinit would not return a ticket with special characters in the password, but after wrapping them in double quotes it worked ok, and also, in this instance I am able to successfully generate a ticket from the keytab file.

I was also able to see that the userPrincipalName attribute was updated to be:

BICMS/ServiceAcccount.Name.BUSINESS.DOMAIN.COM@BUSINESS.DOMAIN.COM

and I can also see the SPN using SETSPN -l, and can generate a ticket using the keytab file for the SPN.

C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\sapjvm\bin>kinit -k -t C:\Windows\bodev.keytab BICMS/ServiceAcccount.Name.BUSINESS.DOMAIN.COM  
New ticket is stored in cache file C:\Users\graeme.smith\krb5cc_graeme.smith  

One extra thing I just tried was regenerating the keytab file with the KVNO matching that of the service account.

C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\sapjvm\bin>ktab -l -k C:\Windows\bodev.keytab
Keytab name: C:\Windows\bodev.keytab
KVNO Principal
---- ------------------------------------------------------------------
   4 BICMS/ServiceAcccount.Name.BUSINESS.DOMAIN.COM@BUSINESS.DOMAIN.COM
 

This KVNO of 4 matches the msDS-KeyVersionNumber attribute on the service account. The admin guide suggests using a KVNO parameter of 255, but I have tried with both now, but it does not appear to have made a difference.

See KB 1853668 for more details.

Thanks for the suggestion though.

Regards,

Graeme

---

GraemeSmith (BOB member since 2002-08-16)

[system]

Ok. The reason I asked is when when I originally did SSO, I did NOT use -mapuser, and the configuration is slightly different without it. The idm.princ parameter is just:
idm.princ=service_account

vs:
idm.princ=BICMS/service_account@DOMAIN

if you do use mapuser

I’m not sure it would help (sounds like you know way more about this topic than I do), but you could try re-running ktpass without mapuser and change the idm.princ parameter. The full ktpass format is:

ktpass -out bosso.keytab -princ service-account-name@REALM.COM –pass service-account-password -kvno 255-ptype KRB5_NT_PRINCIPAL -crypto RC4-HMAC-NT

---

joepeters (BOB member since 2002-08-29)

[system]

Thanks Joe. I tried that out yesterday before I had the ktpass run by our AD team with the mapuser parameter. I was originally unable to run the ktpass with mapuser due to my lack of permissions in AD. As such, I tried that out yesterday, using first the SPN

BICMS/ServiceAcccount.Name.BUSINESS.DOMAIN.COM@BUSINESS.DOMAIN.COM

and also just with the service account name (which is what the UPN on the account was at the time before running the ktpass with mapuser). From what I read, the mapuser basically updates the UPN of the account specified to the be the same as the SPN passed to ktpass.

ServiceAcccount.Name

After getting the AD team to run ktpass with the mapuser option this morning, I have confirmed in AD that the UPN (userPrincipalName attribute) has been updated to the SPN (BICMS/ServiceAcccount.Name.BUSINESS.DOMAIN.COM@BUSINESS.DOMAIN.COM). I have tried both modes since, but my current setting is:

idm.princ=BICMS/ServiceAcccount.Name.BUSINESS.DOMAIN.COM

Don’t worry - I really don’t know anything about this - I’m just fumbling around from one KB article to the next!

The strange thing is that it works perfectly as soon as I comment out the keytab line and uncomment the password line in the global properties.

#idm.keytab=C:/Windows/bodev.keytab
idm.password=IaM!APassword

But even with the keytab enabled, I still see the ** credentials obtained… ** being logged to the stderr.log in tomcat. They do look subtly different however (I have just been comparing the logs from alternate attempts).

Logs when using keytab (SSO not working):

Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: Available KDC found: /123.123.123.21:88
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: Sending message to KDC: /123.123.123.21:88
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: Sending TCP request: /123.123.123.21:88
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos:     connected;  sending length and request...
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos:     sent request;  reading response length...
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos:     read length;  reading 398-byte response...
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: --- got 398-byte response, initial byte = 0x7e
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: Message sent sucessfully to KDC: /123.123.123.21:88
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: Resolving KDC for realm: BUSINESS.DOMAIN.COM
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: Available KDC found: /123.123.123.21:88
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: Sending message to KDC: /123.123.123.21:88
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: Sending TCP request: /123.123.123.21:88
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos:     connected;  sending length and request...
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos:     sent request;  reading response length...
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos:     read length;  reading 2002-byte response...
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: --- got 2002-byte response, initial byte = 0x6b
Thu Jul 28 13:21:38 BST 2016 jcsi.kerberos: Message sent sucessfully to KDC: /123.123.123.21:88
Thu Jul 28 13:21:39 BST 2016 jcsi.kerberos: ** credentials obtained .. **

Logs when using idm.password (SSO working):

Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Available KDC found: /123.123.123.24:88
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Sending message to KDC: /123.123.123.24:88
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Sending TCP request: /123.123.123.24:88
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos:     connected;  sending length and request...
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos:     sent request;  reading response length...
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos:     read length;  reading 245-byte response...
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: --- got 245-byte response, initial byte = 0x7e
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Message sent sucessfully to KDC: /123.123.123.24:88
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: ** KDC requires pre-authentication **
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Acceptable PA type: 19
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Acceptable PA type: 2
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Acceptable PA type: 16
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Acceptable PA type: 15
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: ETypeInfo:
    ETypeInfo2Entry:
    etype: 18
    salt: BUSINESS.DOMAIN.COMBICMSServiceAcccount.Name.BUSINESS.DOMAIN.COM

    ETypeInfo2Entry:
    etype: 23

Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: ** Adding encrypted timestamp pre-auth **
  encryption type: 18
  salt: BUSINESS.DOMAIN.COMBICMSServiceAcccount.Name.BUSINESS.DOMAIN.COM
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: ** Sending request to KDC .. **
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Resolving KDC for realm: BUSINESS.DOMAIN.COM
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Available KDC found: /123.123.123.24:88
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Sending message to KDC: /123.123.123.24:88
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Sending TCP request: /123.123.123.24:88
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos:     connected;  sending length and request...
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos:     sent request;  reading response length...
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos:     read length;  reading 2086-byte response...
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: --- got 2086-byte response, initial byte = 0x6b
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: Message sent sucessfully to KDC: /123.123.123.24:88
Thu Jul 28 15:10:21 BST 2016 jcsi.kerberos: ** credentials obtained .. **

Not sure if it’s relevant or not.

Thanks for the suggestion Joe.

Regards,

Graeme

---

GraemeSmith (BOB member since 2002-08-16)

[system]

For what it’s worth…

In my system (successfully using SSO, no “mapuser”), a logon produces a tomcat log similar to your first example (?SSO not working").

It appears that your Tomcat is successfully connecting, but BOE is not handling it correctly. You might get help from tech support since the problem is in BOE and not with Kerberos.

---

joepeters (BOB member since 2002-08-29)

[system]

Thanks for confirming Joe. I’m running out of options at this point, but I don’t get the impression support like dealing with these types of questions (I know why ;)).

I did read in one of the SAP documents that the account used for the SSO doesn’t have to be the same as the account running the SIA, so another option might be to get a “clean” account configured and see if that resolves it.

Thanks for your input.

---

GraemeSmith (BOB member since 2002-08-16)

[system]

I can’t prove it categorically (as I can’t change the password on the original account we were using), but I had a new account set up with a simpler password with no special characters and it has worked straight away, so it looks on the surface like the complex password was the issue (well, that the software is unable to handle a complex password is the issue). Seems like a fairly major bug to me, especially when this would be an account that you would really want to have highly secured (i.e. due to the delegation capabilities).

Thanks to all for your suggestions and assistance.

One other interesting thing I found in a document titled “Configuring Vintela SSO in Distributed Environments – Complete Guide” from 2008 on the SCN was that you can split the account roles, so the account which tomcat uses can be different from the account running the SIA. This might get us out of a hole by allowing us to run the SIA under the ‘legacy’ account (which has access to various resources and has a complex password we are reluctant to change), and set up Vintela to run under a separate account with a simpler password. The only trick I found with this so far is that you need to set the SPN in the CMC to be that of the account running the SIA, whereas the SPN in the global.properties idm.princ setting needs to be the SPN of the Vintela account (the one with the simple password in our case). The Vintela service account needs all the SPN’s for the HTTP entry points, not the SIA service account. Seems to be working ok, but I need to do more testing.

Regards,

Graeme

---

GraemeSmith (BOB member since 2002-08-16)

[system]

Graeme, I’m just curious - did you execute the same setspn commands for the new account? So you now have two different AD accounts with the same assigned services?

I’m asking because I want to switch one of my test environments from one AD account to another, and I’ll have to run the setspn commands for the second account. I had read somewhere that there could be issues with multiple AD accounts associated with the same services.

---

joepeters (BOB member since 2002-08-29)

[system]

Hi Joe,

I ran the same SPN commands on the new account, with the exception of the one i specify in the CMS (this one needs to be the one attached to the service account running the SIA). The SPN’s for your app servers (starting with HTTP) need to be linked to the Vintela account. I removed all the http SPNs from the legacy account using SETSPN -d.

If you’re doing a full migration to a new account, just make sure you run -a switch on the SETSPN statements for the new account, and -d to remove them from the old one. You can check for duplicates by running SETSPN -x.

Regards,

Graeme

---

GraemeSmith (BOB member since 2002-08-16)

[system]

Thanks, Graeme! Yes, I want to switch one of my two servers to a different ID, so I guess I’ll have to do the -d thing for the services on the one I’m changing.

---

joepeters (BOB member since 2002-08-29)

[system]

If they’re both using the same service account currently, you will need to ‘move’ the “http/xxx” spn’s for the relevant environment, (I.e. SETSPN -d on the old account and -a on the new account), and assuming the old account still needs to run another environment, you will need an additional new SPN for the service account - that’s the one you specify in the CMS and in the idm.princ setting in the global.properties file (if you’re using the same account for SIA and vintela).

Regards,

Graeme

---

GraemeSmith (BOB member since 2002-08-16)

[system]

Got it. What happens if both services are active at the same time? I can’t do the setspn commands myself, so there might be a period of time after the new one is done and the old ones are deleted.

---

joepeters (BOB member since 2002-08-29)

[system]

The SPN updates are quick to run, it will really depend on the complexity and scale of your AD deployment to determine how long things will take to replicate (on which I can’t really comment). It should be fairly quick once that has replicated (I didn’t see any delays once that had happened). If you’re doing it on a live system however, it would definitely be better for over the weekend, just in case something doesn’t go as planned.

Regards,

Graeme

---

GraemeSmith (BOB member since 2002-08-16)

[system]

Ok - thanks again.

---

joepeters (BOB member since 2002-08-29)