MetaCarta used Kerberos for single-sign-on support company wide.<\/p>\n
Now, given that MetaCarta was a bunch of MIT hackers, this shouldn’t be particularly shocking. \ud83d\ude42 It was generally a very nice thing to have — although it got me used to the idea that I *shouldn’t* type my password 20 times per day, a notion that Nokia has tried very hard to dissuade me from. <\/p>\n
However, Kerberos support in Safari never worked for MetaCarta’s web services. It was never clear to me why, it was just clear that it didn’t work. Googling showed me many people saying it did work, and no people saying it didn’t, so I figured it was some quirk of my system and didn’t bother to fix it.<\/p>\n
Now, at Nokia, I’m in the same boat: for services run by the Group Formerly Known as MetaCarta, we use Kerberos for everything. The difference is, falling back to Basic auth — which was fine in MetaCarta times — is a Very Expensive path to take in the new world; our auth services are slow Microsoft AD services hosted thousands of miles away on the other side of multiple high-latency firewalls, so when Kerberos doesn’t work — it hurts. <\/p>\n
So, after getting fed up with this behavior yesterday, I started digging in. I didn’t make a lot of progress last night, but this morning, I stumbled across a post documenting that Safari does not work with hosts that are CNAMEs<\/a>. With that one small pointer, I found other evidence<\/a> of people running into this, and an option to reproduce the Safari-like behavior in chrome: “–disable-auth-negotiate-cname-lookup”. (The option documentation points to HttpAuthHandlerNegotiate::CreateSPN in http auth handler<\/a> for more details.)<\/p>\n