gss_acquire_cred with GSS_C_BOTH usage option
pcmoore at sandia.gov
Mon Oct 3 17:57:04 EDT 2005
My reading of RFC1964, where it says . . .
"However, when the Kerberos 5 mechanism attempts to obtain initiating
credentials for a service principal which are not available in a
credentials cache, and the key for that service principal is
available in a Kerberos 5 key table, the mechanism should use the
service key to obtain initiating credentials for that service."
... implies that Heimdal has the right approach.
What we sometimes do here as a workaround is run a cron job or a
background process that continually acquires a cred cache from a keytab.
Then our keytab-based gssapi initiators work when asking for an
'initiator' or 'both' cred.
>>sam> I see your point and I agree the Heimdal behavior is useful in
>>sam> case you describe.
>>sam> However it seems to violate the principle of least surprise. If
>>sam> change my application to start requesting initiator credentials
>>sam> instead of both credentials then initiator credentials can stop
>>sam> working if I don't have a current cache.
nathan> Actually with Heimdal's code I don't think it will since it
nathan> fall back to the keytab whether you ask for initiator creds or
nathan> both. The application should still behave the same.
>>sam> I'm not sure how to resolve these requirements.
Nathan Huff Nathan.Huff at ndsu.edu
Information Technology Services (701) 231-6145 (Voice)
Room 242H, IACC Building
North Dakota State University, Fargo, ND 58105-5164
More information about the krbdev