>>>>> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> writes:
>> Since we use NIS as the primary source for hostname >> resolution, all host lookups render a single IP address, >> even for multihomed machines. Moving to DNS is not an >> option at the moment. Ken> I have to ask ... you're STILL using NIS for hostname resolution? Ouch. Thanks for the sympathy. Unfortunately, in our case, migrating to DNS is not a trivial effort, but let's not go there. >> That said (barring hacks to application protocols that >> would allow target hosts to send IP addresses back to >> the source host, then having the client embed the full set >> of tickets), the way to address this would be to have >> the target host obtain new tickets will a full set of >> IP addresses. >> >> 1 - is this possible? Ken> The trick here is that one of the IP addresses in the target ticket Ken> _must_ be the IP address used to talk to the KDC; otherwise, you're Ken> outta luck. >> 2 - is it within the limits of the specification? Ken> Yes. Ken> It occurs to me that you could save yourself some pain and simply get Ken> a completely addressless ticket. There is a school of thought in the Ken> Kerberos world that suggests IP addresses in tickets are not that useful. OK. let's reset a bit. What I neglected to mention was that we are a former CyberSafe customer, with remnants of CyberSafe code still in production. (Now I'll be getting pity, not sympathy.) Since the move to MIT has also been driven by the deployment of platforms not supported by CyberSafe (e.g., linux), we have focused primarily on application infrastructure. That said, the core CyberSafe KDCs are still in place, in addition to a variety of other KDC based services, either homegrown or adopted to work with a CyberSafe KDB. Admittedly, I'll have to assess the current dependencies that we have on IP addresses. The implementation of krb524d that we currently use requires IP addresses, or it barfs. This may well be the only dependency that we really have. Client krb524 code has already been migrated to MIT. That said, I'll investigate if we have any more dependencies on IP addresses in tickets and start working on porting krb524d to the CyberSafe KDB. Unfortunately, I can't use it as is for now, until we migrate the all the KDC services to MIT krb5 (or perhaps Heimdal, since incremental propagation is a must have). Nonetheless, we have all sorts of applications that obtain initial credentials (various homegrown apps, PAM modules, sitecheck binaries for irix) which would need to "corrected". Ticket forwarding was my immediate objective. But I'll submit I was looking for the lazy way out. Ken> --Ken _______________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
