On Thu, Mar 17, 2011 at 6:18 AM, John Hodrien <J.H.Hodrien@xxxxxxxxxxx> wrote:
> On Wed, 16 Mar 2011, Michael B Allen wrote:
>> I don't know what the official view is on going through a CNAME but I
>> think that is probably a dubious practice. The proper way to handle
>> this scenario would be to add another servicePrincipalName value for
>> HTTP/www.friendly and a corresponding keytab entry for
>> HTTP/www.friendly@KRB-REALM.
>
> Dubious why? If I go with your method at the very least I now need more
> records in AD for machines that don't exist, and I'm guessing I'll be creating
> them by being a domain administrator, which is inconvenient in large
> organisations.
>
> I'm assuming I'll also be needing to add A records for these domains.
> Kerberos surely won't be a fan of there not being a PTR record, so I assume
> you'd need multiple PTR records. Is this really the path you're suggesting
> going down? I'm genuinely interested here, I'm not having a dig.
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.
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"? 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?
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?
CNAMEs in general are dubious. And not just for Kerberos.
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.
Why have all this extra indirection on top of an already fickle protocol?
Regarding PTR records, I don't think kerberos would have any problem
without them. 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.
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.
Mike
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
