K2, Kerberos and HOST (A) Records
An area which people often neglect when building their K2
environments and process is the power of using HOST (A) records in DNS as
aliases. In a distributed environment proper use of these records can provide
you with increased scalability and flexibility. How you may ask, well let me
explain.
When using these record types you are not tying references
in your code and configuration files to a machines HOST record in DNS. This
means you can freely move your web services and other components around without
the need to reconfigure, this is key when you want to utilize a disaster
recovery site on cold standby.
Why do we use a HOST (A) record and not a CNAME? The reason
here is to support Kerberos authentication without the need to make changes to
your SPNs. Kerberos authentication will always resolves to a HOST record. In
the case of a CNAME this will point to a HOST record and during authentication
an SPN for the HOST record will be expected, for example;
My DNS server has a CNAME of mysite.k2.com which is an alias
for my servers HOST record of “server.k2.com”. When the user browses to the web
site using “mysite.k2.com” this will resolve to “server.k2.com” which resolves
to the IP address of 192.168.1.2. “server.k2.com” is the final address in the
chain which resolves to a IP address as this is the case an SPN bound to this
address will be expected. Using a HOST record as an alias we can set the SPN on
the account we are using to run our service and control which server we are
going to use by changing the IP in DNS without having to change our SPN, the
account on the servers used must however remain the same!
We can also apply the same to give scalability, in this
example I am throwing in a load balancer in front of my web farm hosting my K2
application and changing the HOST record to point to the NLB address.
This type of setup does not only apply to “client to server” but also in
scenarios where we have a “client to server to
server”, in this scenario we can maintain the users identity during delegation
providing that flexibility and support for DR sites that I mentioned earlier.
The below diagram better explains how to leverage the potential.
Mark Green