locked
kerberos delegation problems through hardware load balancer RRS feed

  • Question

  • We have a MOSS 2007 farm with two servers in the WFE role and a hardware load balancer that distributes load across both servers.  I have a third party web part that uses delegation to access information from another service.  The web part works fine in the test farm (not load balanced) but fails in the production farm.  We configured the SP app pool account and the WFE servers for delegation in both farms.  If I sidestep the load balancer (by changing my hosts file to point to directly at the WFE) the web part starts working.  When I go through the load balancer, it fails.  Any idea how we can configure this so it works through the hardware LB?

     

    Monday, January 24, 2011 2:49 PM

Answers

  • I had a similar issue in my environment, where I had two WFEs behind a hardware load balancer.  My setup was as follows (names changed to protect the innocent):

    • The wfes were wfe1.mydomain.com and wfe2.mydomain.com
    • I had a vanity URL of portal.mydomain.com
    • The Virtual IP on the load balancer had a dns entry of loadbalancer.mydomain.com

    Although I had SPNs created for wfe1.mydomain.com, wfe2.mydomain.com, and portal.mydomain.com, Kerberos authentication was not working when using the network load balancer.  The final step was to set an SPN for the load balancer DNS entry using the account running the web app on my SharePoint servers (e.g. setspn -a http/loadbalancer.mydomain.com mydomain.com\sharepointwebappaccount).

    After that, Kerberos authentication worked as expected.

    Monday, February 21, 2011 3:28 PM

All replies

  • OK, I've determined that the problem is not delegation per se.  Kerberos is not working through the load balancer at all.  When we hit the farm now, we're using NTLM.  Verified this using klist and enabling kerberos logging on clients.  When we try to access the farm, a kerberos error is raised as there is no spn.

    Here's how we have it set up:

    • A virtual IP with a DNS A record of "loadbal", this goes to the "internet" side of the load balancer.  The "farm side of the load balancer connects to the two WFEs in the production farm.
    • CNAME of "portal.mydomain.com" for the same IP, with AAM and host headers set for the SharePoint app
    • CNAME of "ssp1.mydomain.com" for the same IP, with AAM and host headers set for the SSP
    • CNAME of "mysite.mydomain.com" for the same IP, with AAM and host headers set for the MySites app

    The kerberos SPNs are set for the CNAMEs (e.g. http/portal and http/portal.mydomain.com) and mapped to the appropriate app pool service accounts.

    What seems to be happening is this: user requests http://portal.mydomain.com/ to get to SharePoint.  They get the expected 401 prompt with www-authenticate:negotiate in the response header.  The client then requests a kerberos ticket for "loadbal.mydomain.com" which fails because there's no such SPN.  The load balancer is not even a machine in the AD domain, it's an appliance (presumably linux).  The failure is evident both as an error in the system log and in the fact that no ticket is added (checked with klist).

    We saw some guidance on the intarweb about "never use CNAMES in kerberos SPNs" but it is always simply stated, never explained.  There is also some stuff on technet that seemed to indicate that the CNAME vs. A-record problem was an IE 6 thing that was fixed in IE 8--we're all IE 8 so we thought it would work.  And it DOES work in the test farm, but there's no load balancer there.

    In the test farm, the settings are like this:

    • WFE is a domain member "testwfe" with all the usual SPNs that would come from being a domain server.
    • CNAME of "testportal.mydomain.com" for the same IP.
    • CNAME of "testssp.mydomain.com" for the same IP.
    • CNAME of "testmysite.mydomain.com" for the same IP.
    • SPNs, AAM, host headers are all set for the CNAMEs, not for the WFE NetBios name.

    What I see when I access the test farm is: we get a kerberos ticket for "http/testwfe.mydomain.com" and we get no kerberos error messages.  Also, the web part that uses delegation works, so we can safely assume that we're using kerberos auth in the test farm.

    Monday, January 24, 2011 10:16 PM
  • http://support.microsoft.com/default.aspx?scid=kb;EN-US;938305

    Explains that IE uses the HOST when requesting the kerberos ticket, even when the CNAME is the service name.  Provides a registry change that should tell IE to use the CNAME.   Target browser in this KB is IE 7, I'm trying it in IE 8 but so far no success, I'm still seein the kerberos error where it tries to get the ticket for the HOST record and not the CNAME.

    Anyone done this on IE 8 before?

    Monday, January 24, 2011 10:47 PM
  • I had a similar issue in my environment, where I had two WFEs behind a hardware load balancer.  My setup was as follows (names changed to protect the innocent):

    • The wfes were wfe1.mydomain.com and wfe2.mydomain.com
    • I had a vanity URL of portal.mydomain.com
    • The Virtual IP on the load balancer had a dns entry of loadbalancer.mydomain.com

    Although I had SPNs created for wfe1.mydomain.com, wfe2.mydomain.com, and portal.mydomain.com, Kerberos authentication was not working when using the network load balancer.  The final step was to set an SPN for the load balancer DNS entry using the account running the web app on my SharePoint servers (e.g. setspn -a http/loadbalancer.mydomain.com mydomain.com\sharepointwebappaccount).

    After that, Kerberos authentication worked as expected.

    Monday, February 21, 2011 3:28 PM
  • Thanks James, that was indeed the fix.  As long as the service ticket is encrypted with the right credentials it will work.  Another way we found to fix it (ends up same result anyway) was to change the dns A record entry for the load balancer address to be the same as the vanity URL.

    Thursday, March 31, 2011 3:02 PM