IBM Connections with Exchange Back-end – Chrome and Kerberos Delegation

First of all, thanks to my new found friend Michele Buccarello who had shared this document earlier last month on some very good pointers about how to integrate Exchange with IBM Connections.  With that document and some guesswork as to encryption settings between WAS and Exchange I was able to solve the problem – 90% of the way. We got it to work with IE and FireFox but Chrome was balking and getting into a log-out cycle. I used Fireshark to take a look and noticed it was an auth.redirect action by the HOMEPAGE app that was followed by a rest API call to Opensocial calendar settings .for my acocunt – and then righ back to the auth.redirect …. a classic redirect loop.
As things were working in FF and IE I knew it was not a system issue but rather a problem localized to Chrome so I looked up some technotes and knowledge base articles and here is how I solved it:
Chrome can be taught to work with Kerberos delegation just as IE and FF. For “normal” SPNEGO it takes it’s settings from IE and will accept them but with Exchange there is delegation going on (if you look at the Connections documentation it has you change two settings for both IE and FF, one of them refers to delegation) and Chrome needs to get a whitelist of which website it accepts delegation tickets from:
Option 1: Command line
Change the command line that starts Chrome to include a command switch:
chrome.exe –auth-negotiate-delegate-whitelist=*
Set the value to either [*] (make sure there are NO QUOTES surrounding the [*] as some documentation in various articles will have you enter it as) or any combination of the actual url you are connecting to i.e.: [*] to limit it to anything inside the intranet domain or [] for only the Connections website itself. Apparently this can also be a comma separated list of entries if that works for you.
Option 2: Create Windows Registry entry
Create this entry: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
In it create a string entry: [AuthNegotiateDelegateWhitelist]
Any of the values used in the above command line example will work in this registry entry so I suggest to try it above first.
Enjoy – you’re welcome!

SPNEGO: Map SPNs and Create Combined Keytab Files In One Step

I have been wanting to blog about my SPNEGO install guide for a while but have been just a bit busy lately (my usual excuse). However, I just had to help a client setup SPNEGO for their IBM Connections environment so I decided the time for procrastination is over.


If you look at the IBM documentation, the process to create the SPNEGO keytab files and mapping the correct URLs and Fully Qualified Hostnames of servers to the AD account is rather onerous. IBM documentation will have you create separate keytab files for each url/FQHN that you want to include in the SPNEGO config and then merge them. For the normal user that is setting up SPNEGO for the fist time that is painful indeed and confusing. My process below does it all in one step (one step per URL/fqhn) and adds all the settings to ONE keytab file. I am usually done in 5 minutes and then create the config file using wsadmin commands and am up and running in SPNEGO in under an hour.

Note: all commands below have to happen ON AN AD DOMAIN CONTROLLER, running them on your workstation will not work.


Environment / Variables:

  • SPNEGOAD account: SPNEGOAccount@DOMAIN.COM – domain\SPNEGOAccount
  • Server FQHN:,,, etc.
  • Connections URL (c-record):

Check Current SPN mappings for SPNEGO AD Account:

  • setspn -l SPNEGOAccount
    (review output)

Step 2: Add SPN mapping to SPNEGOAccount
 and create Keytab files

[setspn -s] or [setspn -a] could be used just to add/map the SPNs to the account, but this does not create the keytab files.

  • setspn -s HTTP/ SPNEGOAccount
  • setspn -s HTTP/ SPNEGOAccount


Run commands to create a SINGLE keytab file AND map accounts at the same time:

  • ktpass -princ HTTP/ -ptype KRB5_NT_PRINCIPAL -mapUser SPNEGOAccount -mapOp set -pass password1A -in C:\Temp\KRB\krb5.keytab-out C:\Temp\KRB\krb5.keytab
  • ktpass -princ HTTP/ -ptype KRB5_NT_PRINCIPAL -mapUser SPNEGOAccount -mapOp add -pass password1A -in C:\Temp\KRB\krb5.keytab -out C:\Temp\KRB\krb5.keytab


Note: the first command has the command [set], all the following commands (one for each url/fqhn you want to add) has the command [add]. If you do not use the [add] command, each of your subsequent commands will override your previous one, leaving your AD account with only one fqhn/URL mapped to it. THIS IS IMPORTANT!
Check whether the SPNS are all correct:

  • setspn -l SPNEGOAccount
    (get output and show it has mappings)
  • ldifde -f c:\temp\new-output1.txt -r “(servicePrincipalName=HTTP/”
  • ldifde -f c:\temp\new-output2.txt -r “(servicePrincipalName=HTTP/”
    (Get output files and review)



Some Gotchas

Which  URLs/c-records and server FQHNs to map:

I map EVERYTHING. The main reason is that often your C-record for the site (our example will point to the fqhn of a server or a load balancing device. In that case you need BOTH of them mapped. I mal all webservers/HIS, WAS servers and (if existing) the LB address (this s usually overkill and not necessary … but paranoia pays off sometimes).

Command errors:

Depending you your AD forest, the above ktpass command might need the AD account your are mapping to either in the [ACCOUNTNAME@DOMAIN.COM] format or [DOMAIN\ACCOUNTNAME] format. You will see the error right away when you run it for the first time.

SPNEGO setting in WebSphere:

If you go by the IBM documentation (there is allot flying around) you will see they generally tell you to add the fqhn of the Deployment Manager as the HOSTNAME in SPNEGO. Keep in mind that works for them because generally they testers tend to work with single server test installs where ALL the systems run on one server and the Dmgr is also the HIS server and often they don’t bother to change the URL for the Connections setup. What you need in there is the C-Record your users will be putting into their browsers to get to Connections in in our example Should the C-record point to the FQHN of a web server then you could input that address as well. That is why I generally map EVERYTHING, that way you have maximum flexibility should you need to finagle with your architecture and move functionality around.

Oops, you forgot something …

If you suddenly notice you have to add servers to the SPNEGO setup (maybe you are migrating) – DO NOT ADD MORE MAPPINGS TO THE SPNEGO AD ACCOUNT. That will invalidate the existing keytab files and you will have a n SSO outage. To add additional files you have to stop all WebSphere servers involved , add the mappings with the ktpass command using the [ADD] variable and use the existing keytab file from one of your WebSphere servers. Then recreate the config file using wsdmin and replace the old keytab files with the new one.