Ich verwende Application Request Routing 3.0 auf Windows Server 2012 R2, um die Last der internen Webdienste auf einem Lync 2013-Front-End-Pool auszugleichen.nichtIch verwende es als Reverse-Proxy für die externen Webdienste (dafür gibt es einen separaten Reverse-Proxy). Ich verwende es nur als Lastenausgleich, da diesem Kunden keine andere Lösung zum Lastenausgleich zur Verfügung steht.
Ich habe DNS so konfiguriert, dass alle URLs der internen Lync-Webdienste auf den ARR-Server verweisen. Ich habe eine Serverfarm definiert, die die beiden Lync-Front-End-Server im Pool umfasst, und ich habe ARR so konfiguriert, dass alle HTTP- und HTTPS-Anfragen unabhängig von der URL oder dem Hostnamen an diese Farm weitergeleitet werden. Die Standardwebsite in IIS auf dem ARR-Server ist nur für die anonyme Authentifizierung konfiguriert.
Die Anfragen werden korrekt weitergeleitet, aber bei allen authentifizierten Lync-Webdiensten (und das sind viele) schlägt die Authentifizierung kläglich fehl.
Ich habe festgestellt, dass das Problem bei der Kerberos-Authentifizierung liegt, und eine schnelle Google-Suche ergab, dass viele Leute Authentifizierungsprobleme haben, wenn sie authentifizierte Websites/Dienste über ARR mit Kerberos-Authentifizierung veröffentlichen. Ich habe versucht, die Authentifizierungsmethode „Negotiate“ in IIS auf den Lync-Servern manuell zu deaktivieren und nur „NTLM“ zu belassen, und mit dieser Einstellung funktioniert alles einwandfrei. Dies zeigt tatsächlich, dass das Problem tatsächlich durch die Kerberos-Authentifizierung verursacht wird. Das Herumspielen mit der IIS-Konfiguration auf Lync-Servern wird jedoch überhaupt nicht unterstützt, und jede manuelle Änderung wird wahrscheinlich zurückgesetzt, wenn eine Konfigurationsaktualisierung erfolgt oder ein Lync-Update installiert wird. Daher kann ich IIS nicht einfach manuell auf diese Weise konfigurieren.
Ich suche nach einer (unterstützten!) Möglichkeit, die Authentifizierung bei internen Lync-Webdiensten zum Funktionieren zu bringen, wenn die Anforderungen über einen ARR-Server weitergeleitet werden.
Ist das möglich? Und wie?
Antwort1
Nach langem Suchen haben wir keine Möglichkeit gefunden, die Kerberos-Authentifizierung über ARR zum Laufen zu bringen. Als Workaround haben wir einfach den ARR-Server aus der Domäne entfernt: Dadurch wurde er gezwungen, die Kerberos-Authentifizierung vollständig zu überspringen, und alles funktionierte sofort.
Ich akzeptiere diese Antwort, weil sie das Problem behoben hat und uns die Verwendung von ARR zum Lastenausgleich der internen Webdienste von Lync ermöglicht. Wenn jedoch jemand eine Antwort findet, mit der die Kerberos-Authentifizierung tatsächlich funktioniert, werde ich sie gern annehmen.
Antwort2
Kerberos erfordert, dass der SPN für das Dienstkonto, auf dem Lync ausgeführt wird, für die Anforderungs-URL festgelegt wird, die von Ihrem ARR-Server kommt. Sie müssen den SPN sowohl für den Servernamen als auch für den internen FQDN festlegen, indem Sie einen Befehl wie den folgenden verwenden:
setspn -S http/<servername> domain.com\<Svc_Acct>
setspn -S http/<servername>.domain.com domain.com\<Svc_Acct>
Eine sehr gute Zusammenfassung der SPNs finden SieHier.
Darüber hinaus müssen Sie die Active Directory-Eigenschaften des ARR-Servers ändern, damit dieser für die Delegierung als vertrauenswürdig eingestuft wird. Dies wird über die Eigenschaften des ARR-Serverobjekts in AD-Benutzer und -Computer festgelegt. Aktivieren Sie auf der Registerkarte „Delegierung“ das Optionsfeld „Diesem Computer für die Delegierung an alle Dienste vertrauen (nur Kerberos)“.
Eine Diskussion über Delegation finden SieHier.