Quoth Russ Allbery <[EMAIL PROTECTED]>:
| Jeffrey Altman <[EMAIL PROTECTED]> writes:
|
| > If you can describe a good way to write the rule that says, replace
| > address FOO with address NAT we can certainly make the change in the
| > code. The problem in most cases is that there is no good way to know
| > what the NAT address is in the first place.
|
| I think there used to be patches for this around somewhere for something
| of the 1.0.x vintage, because I forward-ported them to 1.2 until I started
| just using addressless tickets. That patch took the approach of requiring
| one to configure the NAT IP address in krb5.conf, which would work in some
| situations.
Sounds to me like two ways to describe the same problem: "there is no
good way to know what the NAT address is" vs. "would work in some
situations."
If you're going to configure Kerberos for a several thousand people
whose ISPs are pushing NATs, and who have only a glimmer of a notion
what that means and will be using a variety of implementations, and
whose only recourse if it doesn't work is probably to have you come
over to their house, addressless tickets is the only option, right?
(i.e., "noaddresses = true" in "[lib-defaults]" in krb5.conf.)
I understand that has been working for most applications. The only
problem seems to be ftp (Fetch), where GSS channel bindings bring
the local address back to cause more trouble. Would someone mind
confirming that any GSS ftp client will necessarily have this problem,
and it isn't something the application could handle?
Thanks,
Donn Cave, [EMAIL PROTECTED]
