> Sorry for the slow response time. krb5 user-to-user auth is a little
> off the beaten track of Kerberos usage, but this is the intended use
> case.
Awesome, thanks. And yes, the entire reason I'm using Kerberos is to
avoid rolling my own security protocol, so I'm glad I happened across
the u
On Wed, Jul 6, 2011 at 10:27 AM, wrote:
> Does anyone on this list intentionally rely on PTR lookups for
> Kerberos hostname canonicalization?
>
Yes, for "ssh host". In our case, the canonicalization is done by the ssh
client itself though, not by the krb5 library. Now that I'm aware of the
is
On Wed, Jul 06, 2011 at 01:27:24PM -0400, Greg Hudson wrote:
> We are considering turning off rdns by default in MIT krb5 1.10. In
> the past we've shied away from changing the default because we've been
> afraid of creating upgrade pain. But after consideration, we're not
> sure there's likely t
On 7/6/2011 4:29 PM, Simo Sorce wrote:
> Jeffrey, as far as I understand the proposal it to simply change the
> default, I have seen no request to remove the rdns parameter, so if you
> need reverse resolution at most you'll have to change rdns = true in
> krb5.conf on clients.
>
> It may be annoy
On Wed, 2011-07-06 at 16:02 -0400, Jeffrey Altman wrote:
> On 7/6/2011 2:22 PM, Simo Sorce wrote:
> > I would resolve all these issues by using aliases at the KDC level, but
> > thank you for explaining, it's valuable data on the way KDC/DNS are used
> > to keep track off.
>
> The primary thing th
On 7/6/2011 2:22 PM, Simo Sorce wrote:
> I would resolve all these issues by using aliases at the KDC level, but
> thank you for explaining, it's valuable data on the way KDC/DNS are used
> to keep track off.
The primary thing that the Kerberos development team needs to keep in
mind every time a c
>> I admit that these issues are not insurmountable. But I am just answering
>> the question that Greg asked.
>
>Thanks, that's useful. Do you have any Heimdal clients in your
>environment, and do they cause problems with the hosts in question? (My
>understanding is that Heimdal never does rever
On Wed, 2011-07-06 at 14:01 -0400, Ken Hornstein wrote:
> I admit that these issues are not insurmountable. But I am just answering
> the question that Greg asked.
Thanks, that's useful. Do you have any Heimdal clients in your
environment, and do they cause problems with the hosts in question?
On Wed, 2011-07-06 at 14:01 -0400, Ken Hornstein wrote:
> >On Wed, 2011-07-06 at 13:41 -0400, Ken Hornstein wrote:
> >> >Does anyone on this list intentionally rely on PTR lookups for
> >> >Kerberos hostname canonicalization?
> >>
> >> "Yes".
> >>
> >> (I can go into detail if you really care).
>
On Wed, Jul 6, 2011 at 1:01 PM, Ken Hornstein wrote:
> The answers:
>
> - Multihomed hosts (we want to connect to a particular interface, but
> we want to use one canonical name, because adding a new keytab for a
> new interface is more of a pain than simply changing the reverse DNS).
> This al
On Wed, 2011-07-06 at 13:41 -0400, Ken Hornstein wrote:
> >Does anyone on this list intentionally rely on PTR lookups for
> >Kerberos hostname canonicalization?
>
> "Yes".
>
> (I can go into detail if you really care).
I am interested if you can explain.
Simo.
--
Simo Sorce * Red Hat, Inc * N
I would also recommend finding a way to get rid of the forward
resolution as well. That's more difficult because
krb5_sname_to_principal() lacks context that might be helpful to
hostbased principal canonicalization. One approach might be to add a
new form(s) of that function that accepts addition
>On Wed, 2011-07-06 at 13:41 -0400, Ken Hornstein wrote:
>> >Does anyone on this list intentionally rely on PTR lookups for
>> >Kerberos hostname canonicalization?
>>
>> "Yes".
>>
>> (I can go into detail if you really care).
>
>I am interested if you can explain.
The answers:
- Multihomed host
Getting rid of the reverse dns lookups for canonical name resolution is
the right thing to do and will finally bring MIT Kerberos into
compliance with RFC 4120. It will impact the help desks of a large
number of sites. I believe that as part of such a change MIT should
change the version number t
>Does anyone on this list intentionally rely on PTR lookups for
>Kerberos hostname canonicalization?
"Yes".
(I can go into detail if you really care).
--Ken
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/
ghud...@mit.edu writes:
> Does anyone on this list intentionally rely on PTR lookups for
> Kerberos hostname canonicalization?
We used to (we used to have load-balanced A records), but we stopped a
while back. As long as CNAMEs are resolved, we shouldn't notice.
--
Russ Allbery (r...@stanford.
On Fri, 2011-07-01 at 15:33 -0400, checker wrote:
> But, I happened across the user-to-user credentials stuff, and this
> seems like it's the better way to go because it doesn't require both
> clients to talk to the TGS, and it establishes just one session key
> for both, rather than having two? S
When creating service principals from hostnames, MIT krb5 performs two
canonicalization steps by default:
1. Ask getaddrinfo() for the canonical name of the host, which
converts non-fully-qualified domain names to fully-qualified ones
and also resolves CNAME records in DNS.
2. Use getname
Hi,
When you enable kerberos authentication against a UNIX KDC, you must
have a principal host/fqdn@DEFAULT_REALM in the KDC.
I would like to keep on using DEFAULT_REALM as the default realm
EXPECT for my host principals. Those host principals will be stored in
another realm (ie HOST.DEFAULT_REAL
19 matches
Mail list logo
