Windows clients, in this case browsers, are configured to ignore DNS CNAME records when building Kerberos ticket requests to send to a KDC. If you have a CNAME it will also resolve the A records the CNAME is pointing at and use the A record's FQDN when building the request. This can be overridden:
- IE (https://support.microsoft.com/en-us/help/938305/error-message-when-you-try-to-log-on-to-a-web-site-that-requires-kerbe)
- Chrome (https://www.chromium.org/administrators/policy-list-3#DisableAuthNegotiateCnameLookup).
My scenario is similar but involves a middle tier between the client browser and the back-end. The client authenticates to the front-end using Kerberos, this works just fine, and the front-end delegates the client's credentials to the back-end using Kerberos Constrained Delegation, this also works fine.
We recently discovered a problem with this configuration. Some of our back-end services are behind AWS ELBs, which in turn have CNAMES in front of them so they can be redeployed.
So now the question is: is it possible to change the behavior of the front-end servers' Kerberos client to use the CNAME of the back-ends ELB to form the Kerberos request when delegating the client's credentials, just like you can do on browsers?
Some qualifiers:
- The middle tier is written in ASP.NET and is running on IIS.
- We cannot configure A records in our DNS zones to point to the back-end ELBs because they use AWS SDN features to have multiple IPs configured which may change.
