Stephen Frost wrote:
> * Henry B. Hotz (hbhotz@oxy.edu) wrote:
>> On Jun 22, 2007, at 9:56 AM, Magnus Hagander wrote:
>>> Most likely it's just checking the keytab to find a principal with the
>>> same name as the one presented from the client. Since one is
>>> present, it
>>> loads it up automatically, and verifies against it.
>> Bingo!
>>
>> The server uses the keytab to decrypt the token provided by the
>> client. By using the GSS_C_NO_CREDENTIAL arg on the server anything
>> put in the keytab is OK. (The server doesn't need to authenticate
>> itself to Kerberos, it just accepts authentication. Mutual
>> authentication is done using the same keys.) The documentation needs
>> to reflect that.
>
> I agree there's some disconnect there between the documentation and the
> apparent implementation but I'm not sure I'm in favor of changing the
> documentation on this one. Personally, I'd rather it return an error if
> someone tries to use GSS_C_NO_CREDENTIAL when accepting a context than
> to just be happy using anything in the keytab.
How about doing both, then? Set the principal name if it's specified in
the config file. If it's explicitly set to an empty string, use
GSS_C_NO_CREDENTIAL. Seems straightforward enough to me, and shouldn't
be hard to implement.
>> If we do do that, then we need to allow for the ways Microsoft mucks
>> with the case of the name. (Kerberos is supposed to be case
>> sensitive, but Microsoft work that way.) In particular I think we
>> may need both postgres/<server> and POSTGRES/<server> in the keytab
>> in order to support the to-be-written native Windows SSPI client at
>> the same time as the current Kerberos 5 and GSSAPI Unix clients.
>
> Supporting multiple, specific, keys might be an interesting challenge,
> but I'm not too keen on worrying about it right now regardless. I'd
> also much rather err on the side of "overly paranoid" than "if it works,
> just let it in". If someone ends up having to support both windows SSPI
> clients and unix Kerberos/GSSAPI clients it's entirely possible to
> suggest they just make it POSTGRES and configure the clients
> accordingly.
Yeah, that's how we do it today with Kerberos. But it *would* be handy
if this was easier ;-)
//Magnus