On Fri, Mar 18, 2011 at 6:25 AM, John Hodrien <J.H.Hodrien@xxxxxxxxxxx> wrote:
> On Fri, 18 Mar 2011, Michael B Allen wrote:
>
>> Hi John,
>>
>> Arguably it's not the end-of-the-world to go though CNAMEs. If it
>> works for you, then don't let me deter you.
>
> Indeed it does, and it was the only way I could see you /could/ do this.
> Especially if you're not a domain admin. I'm still not clear your method
> /can/ work. Are you saying you've done it this way and it does? With
> multiple A records if I do:
>
> ssh 10.0.0.1
>
> Which kerberos credential will the remote side use?
>
> With the CNAME approach, there's no ambiguity.
>
>> But you do realize that it requires the client to have logic to see
>> "ah, the record returned is a CNAME so let's use this name to build
>> the principal instead"?
>
> MIT kerberos suggests it uses this to figure out the SPN:
>
> gethostbyaddr(gethostbyname(host))
Hi John,
Actually I think this practice is now considered poor behavior. I look
at a lot of packet captures and I don't recall seeing PTR lookups. At
least not from Windows clients. Also I recall there was a discussion
about this on the Kerberos list and the verdict from one of the MIT
chaps was that it was actually not desirable to use PTR lookups.
> Surely that wouldn't care how I'd done it? That requires the PTR record, and
> that it points back to the name of the pricipal you want to use. With
> multiple PTR records to the same IP I can't work out how this is going to end.
> Will it round-robin and simply work because the remote end has all of them?
True. You cannot have multiple PTR records for an IP. I did not mean
to suggest that you could.
> Clearly sometimes there's not even a domain name to start with. You can quite
> merrily do "ssh 10.0.0.1" and get a kerberised login. With multiple PTRs to a
> single IP, I can only assume you'll round-robin through the credentials. So
> when you add an A and PTR record and forget to add the principal, kerberos
> logins will fail 1/N of the time.
Well you should not use an IP at all really because IPs change. But if
the client is remotely sophisticated it should be able to do a PTR
lookup and try that name.
>
>> And I would not be surprised to see some scenario where the client actually
>> tried to get a ticket with the supplied name and than fell-back to using the
>> CNAME in which case you have extra DNS and Kerberos traffic. If at some
>> point someone wants to use another HTTP client from a cron job or some Java
>> app, is that client going to handle the CNAME correctly?
>
> As far as I can tell, the client will be blissfully unaware.
>
>> What happends if the client application needs the original princpal
>> name for some reason? It will get what the CNAME points to. That could
>> be weird for the app or a developer. And then if you move the website
>> to another server the principal name is now suddenly different?
>
> Yes. But why would the developer care about the service principal name? It's
> not often you're that introspective, you're normally more interested in the
> client's principal.
For very simple scenarios you probably would not care. But here could
be numerous reasons for wanting to know the name of the service you're
talking to.
>> CNAMEs in general are dubious. And not just for Kerberos.
>
> I think that's a little harsh. CNAMEs seem to be unloved for reasons I'm not
> fully convinced by. What is so bad about CNAMEs?
>
>> Also short names are dubios. Is it a NetBIOS name or does the client
>> have a proper DNS search suffix configured? And in the later case it
>> takes extra DNS queries to get the name.
>
> AD always creates both short and FQDN forms of principals, I assume it's as
> you guessed because of a NetBIOSism, or because it's a cruft that can often
> fix broken setups. I don't know, I only ever use the FQDN form.
>
>> Why have all this extra indirection on top of an already fickle protocol?
>
> I haven't actually found kerberos to be too fickle at all.
Kerberos requires that clients have access to the KDC, it depends
heavily on DNS, stale tickets can cause cryptic errors until clients
purge credential caches, etc. It's a great protocol conceptually. But
in practice it's not super robust. It can be difficult to track down
the source of issues. We had a customer who couldn't figure a Kerberos
issue for days. They had checked the time on the machine and thought
it was correct but it was actually off by exactly 12 hours. Meaning it
was set to like 2:43 AM when it was really 2:43 PM.
>> Regarding PTR records, I don't think kerberos would have any problem
>> without them.
>
> As far as I knew MIT kerberos doesn't work at all without them, due to the way
> it calculates service principals. Certainly if you have a pair of A records
> for the same IP, and the PTR record points to the name that doesn't match the
> service principal it all will not work.
My business is all about integrating non-Windows systems into WIndows
environments so I don't look at what MIT is doing much. Windows
clients do not use PTR lookups to build SPNs so our code does not
either.
>> Actually I seem to recall that once upon a time old Kerberos clients used to
>> automatically try PTR lookups to get the primary hostname first but that
>> practice has long since been ruled bad and clients no longer do it. That
>> might be what you're thinking of.
>
> AD 2003 doesn't work correctly if the PTR record doesn't match the service
> principal, even if there's also an A record that does. As far as I'm aware
> the same is true for MIT kerberos.
An HTTP client can authenticate with any principal in the service
keytab and only one of their hostnames is going to have a PTR record.
So I'm not sure I understand your claim here.
>
>> If you're going to have user's trying to use a site with a certain
>> hostname, IMO you should just have a proper A and PTR records. Yeah,
>> it can work without. But not always and it can be a burden for users
>> to figure out the problem and for admins to add the necessary SPN, A
>> and PTR records, get rid of the CNAME, wait for the cache to clear,
>> purge all the old tickets, etc.
>
> But are you suggesting multiple PTR records for the same IP? That's normally
> considered bad DNS practice isn't it, never mind kerberos practice?
>
> I'm just not sure I see any advantage in using multiple A and PTR records.
True. True. I didn't mean to suggest that you have multiple PTR
records for the same IP. Actually it's impossible because the record
key is like "10.1.168.192.in-addr.arpa" so obviously there can be only
one.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
> Thanks for the discussion though, it's really not something I'd overly thought
> about before. There never seems to be enough googlable advice on using
> kerberos out there.
>
> jh
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
