The domain to realm mapping has security issues, or -all- of this does?_kerberos TXT "EOS.NCSU.EDU"Yes. Note that there are security issues here, and other mechanisms are preferred. (Unless you've got secure DNS set up, that is.)
The domain to realm mapping, if spoofed, can trick a client program into authenticating to the wrong realm. If the appropriate principals exist in that other realm (perhaps set up by a less than scrupulous administrator), and the address record lookup is similarly spoofed (or the traffic is intercepted, or anything similar), then the client would quietly authenticate (successfully) to the wrong server, the user would send his private data, etc.
With the other SRV records, if the software is implemented properly, all that spoofed records can do is cause a denial of service, and generally it would have to be an active attack.
But theoretically we don't like normal clients "bothering" our master. (just a decision we made...) That's why I left those out.
Ah, yes, that's fine too. At MIT, at least, we haven't noticed client exchanges being a significant load, so we don't worry about it. You could also use SRV record priorities (which we support) and weights (which we don't, yet) to express other policies, like using the master if no answer is heard from the slaves, or (if you want to implement weights, hint hint :-) sending a much smaller fraction of the traffic to the master than to any of the slaves, etc.
So, yes, it means TCP Kerberos service isn't supported. But Windows clients aren't the only ones that look for TCP service; MIT's got the code too.
Does 1.2.8 support that? (that's what we're running right now, I haven't
decided to delve us into the 1.3 series just yet) I was to understand
from some changelogs that tcp support there was a 1.3 thing.
Oh. Yeah, I think it was 1.3 when it went in.
Sweet! Let me make sure I understand the realm mappings 100%. My understand is that a default_realm under libdefaults makes it so the domain -> realm mappings aren't that necessary. IE, if I'm on ghidora.unity.ncsu.edu, and my krb5.conf says my default_realm is EOS.NCSU.EDU, then I don't need the mapping to say unity.ncsu.edu = EOS.NCSU.EDU... right?
The default_realm entry applies for the local host, not to all hosts in the domain containing the local host. So yes, you'd still need that mapping.
And, to make it clear, the DNS records may have to go into different domains. For example, if your domain is unity.ncsu.edu and your realm name is EOS.NCSU.EDU (for both krb5 and krb4), as above, then the names of the resource records would be:
_kerberos.ghidora.unity.ncsu.edu (TXT) _kerberos.unity.ncsu.edu (TXT) _kerberos._udp.eos.ncsu.edu (SRV) _kerberos-iv._udp.eos.ncsu.edu (SRV) ...
Ken
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
