Client side Kerberos problem with Mac OSX 10.9 and Safari 7.0.2

There is a bug defect in Safari (All platforms) where a cookie set on a 302 redirect will not set the cookie. And it definitely manifests itself when performing 401 response auth rather than form based which works fine. By default on 11.3 and higher, session id rotation is enabled. So it will set a different cookie for each step in the access policy evaluation. It still ends in the same session id value (LastMRH_Session cookie is the same and the ending of the MRHSession cookie equal to the LastMRH_Session (SessionID) but different value before it). For example, Cookie: LastMRH_Session=07f180b2; MRHSession=6e28aa1fed2168da5f4636d507f180b2 AND Cookie: LastMRH_Session=07f180b2; MRHSession=3f28aa1eed1168da5e2346e407f180b2

So when Safari receives the 302 to /my.policy, it sends the second set-cookie and Safari sends the first one again which is incorrect for the session. Thus an errorcode=20 which is most likely what you are seeing. To resolve that, disable session id rotation by the following db variable setting: tmsh modify sys db apm.rotatesessionid value disable tmsh save sys config

You should at least get past the session invalid issue with this modification. Then you can concentrate on the kerberos authentication itself. I noticed when offered negotiate and basic, safari tried kerberos everyctime even if not quite confifured and then it would fail, then try basic auth in the same session. Not sure that an APM policy would allow a client to change from negotiate to basic in the same session so watch out for that since I believe it would follow one branch in the tree. But I am definitely curious of your results after you get by the session invalidation. Good Luck and please post an update of your results!