Or how everything turned into a nail
Maybe this should be titled, how everything turned into a nail when I got a hammer. There are a couple of use cases I want to discuss first, and then why krb5_cc_[gs]et_config() isn't useable for everything.
First out is Windows, you just talked to a Windows AD KDC to get your TGT, but you need to do slight tweeks to make it work better on
Windows, so turn on insecure^HWindows behavior when we use this this credential cache. We make it up with a global setting using krb5_cc_[sg]_config().
Next thing that comes is negative caching of TGS requests (fetching service tickets). Now this seems very stupid to do, but for practical reason is not.
If you want to use HTTP Negotiate and have it default turned on in you http client, you can get bad behaviors in case of the webserver announces support for Negotiate and the client can't get service tickets for that realm. You don't want to have the performance loss of having to ask the KDC over and over again for the same ticket that you can't get.
The the state HTTP negotiate doesn't work should probably be in the http client instead, but sometimes that not possible, just think of running curl in a shell script and looping a couple of times, when you are tired enough of DNS timeouts, not answering KDC, referrals that doesn't lead anywhere, etc, you can let me know.
Third problem is ticket forwarding, it will get you into the same problem. If you want to do a lot of forwarding of your ticket, again maybe because of HTTP Negotiate, then you don't want to hit the KDC for every request. Again we can use krb5_cc_[gs]et_config to store the
forwarding credential for this entry.
So when is krb5_cc_[gs]et_config not useful
So when you renew your credentials you loose all your state, so if you want to keep your state you better store it somewhere else. So that said, having the Windows behavior flag in the krb5_cc_[gs]et_config is probably not good idea. There needs to be somewhere else that this kind of information is stored.
Skicka en kommentar