I'm using Application Request Routing 3.0 on Windows Server 2012 R2 to load balance the internal web services on a Lync 2013 front-end pool; I'm not using it to reverse proxy the external web services (there is a separate reverse proxy for that), I'm only using it as a load balancer because this customer doesn't have any other load balancing solution available.

I've configured DNS to point all Lync internal web services URLs to the ARR server, I've defined a server farm including the two Lync Front-End servers in the pool, and I've configured ARR to route all HTTP and HTTPS requests to this farm, regardless of the URL or host name; the default web site in IIS on the ARR server is configured only for anonymous authentication.

The requests are routed correctly, but for all the authenticated Lync web services (which are many), the authentication fails miserably.

I've determined the problem lies in Kerberos authentication, and a quick Google search found lots of people having authentication problems when publishing authenticated web sites/services through ARR with Kerberos authentication; I've tried manually disabling the "negotiate" authentication method in IIS on the Lync servers, leaving only "NTLM", and with this settings everything works fine; this indeed shows the problem is actually caused by Kerberos authentication. However, tinkering with the IIS configuration on Lync servers is totally unsupported, and any manual change is likely to be reset when a configuration update happens or a Lync update is installed, thus I can't just manually configure IIS this way.

I'm looking for a (supported!) way to make authentication work on internal Lync web services when the requests are routed through an ARR server.

Can this be done? How?


After much struggling, we found no way to make Kerberos authentication work through ARR; as a workaround, we simply removed the ARR server from the domain: this forced it to skip Kerberos authentication altogether, and everything started working instantly.

I'm accepting this answer because it fixed the problem and let us use ARR to load balance Lync's internal web services, but if/when someone comes up with an answer which can actually make Kerberos authentication work, I'll be glad to accept it.


Kerberos requires the the SPN for the service account running lync be set for the request URL coming from your ARR server. You would need to set the SPN for both the server name and the internal FQDN using use a command such as:

setspn -S http/<servername> domain.com\<Svc_Acct>
setspn -S http/<servername>.domain.com domain.com\<Svc_Acct>

A very good summary of SPNs can be found here.

In addition, you will need to modify the active directory properties of the ARR server so that it is trusted for delegation. This is set from the properties of the ARR server object in AD Users and Computers. On the Delegation tab, check the "Trust this computer for delegation to any service (Kerberos only)" radio button.

A discussion of delegation can be found here.

  • There is no service account running Lync, and there can't be (it's automatically configured by the Lync setup to use several IIS application pools running as NetworkService and such, and it can't be changed); also, the URL for those web services are different than the server name(s), and there are multiple Lync servers. What and how should I configure there? – Massimo Mar 10 '15 at 6:58
  • I am not familiar with the specifics of Lync's installation, but if the service is using a BUILTIN\Service account you would use the computer name instead. For multiple services you may have to set the SPN individually. It would be dependent on the URL you are using to make the request. If each service is using a different sub-domain or server name you will need a SPN for each. If the services are in different sub-folders you would only need one. – JMB Mar 14 '15 at 11:58
  • I know I could use a computer name, but there's an additional catch here: there are two servers in the Lync Front-End Pool, and then there's the ARR server; all of them should use the same SPNs, but a SPN can only be associated with a single account, not three of them; and I can't use a user account to run the IIS application pools, because this is not configurable in Lync. – Massimo Mar 14 '15 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.