Ticket History #5916: Re: Reading kerberos-adm from DNS: when will MIT-krb support this?

Ken Raeburn <raeburn@mit.edu> writes:

This should help.

- a


diff --git a/src/lib/kadm5/alt_prof.c b/src/lib/kadm5/alt_prof.c
index bb87f88..48b1792 100644
--- a/src/lib/kadm5/alt_prof.c
+++ b/src/lib/kadm5/alt_prof.c
@@ -416,10 +416,31 @@ krb5_error_code kadm5_get_config_params(context, kdcprofile, kdcenv,
params.admin_server = strdup(params_in->admin_server);
if (params.admin_server)
params.mask |= KADM5_CONFIG_ADMIN_SERVER;
- } else if (aprofile &&
- !krb5_aprof_get_string(aprofile, hierarchy, TRUE, &svalue)) {
- params.admin_server = svalue;
- params.mask |= KADM5_CONFIG_ADMIN_SERVER;
+ } else if (aprofile) {
+ if (!krb5_aprof_get_string(aprofile, hierarchy, TRUE, &svalue)) {
+ params.admin_server = svalue;
+ params.mask |= KADM5_CONFIG_ADMIN_SERVER;
+ } else {
+ struct addrlist addrlist;
+ int i;
+ krb5_data drealm;
+ drealm.data = (void*)params.realm;
+ drealm.length = strlen(params.realm);
+ if (!krb5int_locate_server(context, &drealm, &addrlist, 0,
+ "admin_server", "_kerberos-adm", 1,
+ DEFAULT_KPASSWD_PORT, 0, 0)) {
+ for (i=0;i<addrlist.naddrs;i++ ) {
+ struct addrinfo *a = addrlist.addrs[i];
+ if (a->ai_family == AF_INET) {
+ params.admin_server = strdup(inet_ntoa(sa2sin(a->ai_addr)->sin_addr));
+ params.kadmind_port = ntohs(sa2sin (a->ai_addr)->sin_port);
+ params.mask |= KADM5_CONFIG_ADMIN_SERVER;
+ params.mask |= KADM5_CONFIG_KADMIND_PORT;
+ break;
+ }
+ }
+ }
+ }
}
if (params.mask & KADM5_CONFIG_ADMIN_SERVER) {
char *p;

Hi, I've never sent a message to you before, so my spam filter trapped
your email. If you're really a human being and not an evil spammer,
please click the link below or paste it into a web browser; doing so will
add you to my list of non-spammers (so you won't get this email in the future)
and it will move your message from my spam folder to my incoming mail folder.

Thanks!

- Adam

http://www.megacz.com:8025/whitelist/xrt-5916-26184.6.86270769200704%40krbdev.mit.edu.txt


About this message:

NOTE: SPAMCOP DOES NOT CONSIDER THIS TO BE SPAM; see this:

http://www.spamcop.net/fom-serve/cache/369.html

and examine the "x-originally-received" header on this message
for the required "chain of custody" information.

Only one of these challenge messages is ever generated in response to
a given inbound SMTP connection; it cannot be used to amplify spam
attacks, and in fact actually retards them while also stripping the
advertisement they were meant to convey.

Only one delivery attempt for this challenge is ever made, and it is made
DURING the SMTP delivery of the message being challenged (that is,
between C:DATA and S:250); the deliverer of the possibly-spam message
must remain SMTP connected to my server during the entire process or else
the delivery will immediately abort. These challenge messages are NEVER,
EVER queued for multiple delivery attempts

For more information, please see:

http://www.templetons.com/brad/spam/crgood.html

On Jun 21, 2009, at 13:42, megacz@cs.berkeley.edu via RT wrote:

Hi, Adam. I'm sorry it took so long to get back to this one. I've
looked at the patch in more detail, and see some problems in using it
with the current code:

First, a minor point, the source code you're patching has changed.
There are now a macro and helper function used to fetch a string
parameter from either the command-line data or supplied profile. That
change probably doesn't need to be undone, it merely means the patch
doesn't apply trivially.

Second, also a minor point, locate_server is going to check the
profile referenced in the context. It should use a subset of the
config files supplied in the profile argument passed in, and in the
same order, so it shouldn't get wrong results if the profile search
has already failed, but it is doing redundant work. That could be
worked around a couple of ways -- supply an explicit profile to
locate_server through yet another argument, or have it skip the use of
the profile if the relevant string argument is instead a null
pointer. I haven't checked to see if that will do something
reasonable when invoking service-location plugins though, and that
should be supported here as well. (Using locate_server will get that
support, so it is the right way to go.) If it turns out to be
difficult or ugly, we can probably just live with the redundant checks
for now and not worry about it; locating the kadmin server is rarely
something performance-critical.

Third, more serious: One of the changes in the kadmin code in recent
years was to add support for using kadmin/serverhostname as an
alternative service principal name. Logically, we should probably use
the name presented in the SRV record, rather than having to go look
the address up again in DNS. (Currently kadm5_get_admin_service_name
does use DNS to get the canonical name, but we should keep that
mistake localized to one place where we can fix it later when we've
got solid name canonicalization support, and we should use the same
process for getting the principal name whether we got the host name
from the config file or from DNS. And, the CNAME processing done by
gethostbyname is not necessarily going to give the same result that
gethostbyaddr/getnameinfo will return for an address.)

This may get messier to fix than the others... I think we want all of
the mechanisms that can be used to get a server address, including
plugins (and the sample Python plugin) to supply a host name, probably
in addition to the address, not instead of it. This will probably
mean changing some of the internal interfaces. I'm uncertain whether
that interface should permit a null pointer or empty string, and what
that should mean -- should the library look up the address to get a
name, or should it not fall back to host-based principal naming for
that case? And a smart plugin could know that for the KDC case we
don't care about the host name, and omit it. (Should it return a
service principal name instead/too?)

Fourth, and related to ticket #5890, kadm5_get_admin_service_name will
need tweaking for the DNS SRV usage, too; might as well fix the
various problems at once. (Or fix 5890 first, designing the changes
with the future SRV support in mind.)

Ken

--
Ken Raeburn / raeburn@mit.edu / no longer at MIT Kerberos Consortium