Mein Kunde benötigt SSO in der Windows-Domäne für meinen Linux-basierten Web-/Anwendungsserver. Der Server hat seine eigene Keytab installiert und alles funktioniert einwandfrei. Die Windows-Domäne (EXAMPLE.ORG) hat ein Service-Benutzerkonto mit zugeordnetem SPN HTTP/server.example.org. Mein Anwendungsserver (WildFly) erfordert Kerberos-Authentifizierung und verweigert NTLM-Authentifizierung.
Ich habe eine Testdomäne (basierend auf 2016), die mit Standardeinstellungen erstellt wurde. Ich versuche, dieses Setup in der Testdomäne zu wiederholen, und ich kann Kerberos nicht zum Laufen bringen. Ich sehe eine Verhandlungsanforderung vom Server, aber der Client gibt immer ein NTLM-Ticket zurück.
WWW-Authenticate: Negotiate (request)
Authorization: Negotiate TlRMTVNTU..... (reply)
In der Kundeninfrastruktur sehe ich dasselbe mit Kerberos-Tickets
WWW-Authenticate: Negotiate (request)
Authorization: Negotiate YIIHmAYGKw.... (reply)
Der einzige Unterschied (abgesehen von GPO), den ich sehe, ist, dass mein SPN nicht in derselben DNS-Domäne liegt. Meine AD-Domäne ist tdm.sample.org und der Server ist server.sample.org, ich weiß nicht, ob das wichtig ist.
Vor einiger Zeit hatte ich dasselbe Problem auch innerhalb der Domäne. Sowohl der IE-Client als auch Windows Server 2016 mit IIS in derselben Domäne verwendeten ebenfalls NTLM.
Ich glaube, es gibt einige GPO-Einstellungen, die regeln, wie der Client eine Autorisierung erteilen kann oder nicht, aber keines der Dokumente, die ich gelesen habe, hat geholfen.
Gibt es eine klare Beschreibung der Einschränkungen der Kerberos-Client-Authentifizierung oder einen Hinweis oder eine Debugging-Strategie, die angewendet werden kann?
Antwort1
Es gibt verschiedene Einschränkungen, wenn Windows nicht einmal versucht, eine Kerberos-Autorisierung durchzuführen.
1. SPN verweist auf PTR, nicht auf Web-Alias
Wenn Ihr Webserver, der kein Domänenmitglied ist, einen Alias hat, müssen Sie diesem Alias keinen SPN zuweisen. Er wird mit dem echten DNS-Eintrag dieses Servers verglichen.
Nehmen wir an, Sie haben Folgendes:
A record server.example.org -> 10.0.0.1
PTR record 10.0.0.1 -> server.example.org
CNAME record webapp.example.org -> server.example.org
Zugriffwebapp.example.orgSie benötigen keinen SPNHTTP/webapp.example.org, sollten SieHTTP/server.beispiel.orgNUR zum Servicedatensatz. Ich glaube, es sollte auch eine IP-Adresse sein, wenn kein PTR-Datensatz vorhanden ist.
2. Domänenmitglieder sollten NICHT mit anderen Namen angesprochen werden.
Ich habe einen Domänenmitgliedsserver mit aktiviertem IIS und integrierter Windows-Authentifizierung. Aufgrund meiner Netzwerkkonfiguration ist DNS sowohl im Nichtdomänen- als auch im Domänennetzwerk eingerichtet:
srv.example.org -> 10.0.0.1
10.0.0.1 -> srv.example.org
Und es ist auch in der Domäne registriert:
srv.tdm.example.org -> 10.0.0.1
Dieser Server lässt Kerberos nicht zu, wenn er als srv.example.org aufgerufen wird. Kerberos funktioniert nur, wenn er als srv.tdm.example.org aufgerufen wird. Es funktioniert nicht einmal, wenn der Zugriff über eine IP-Adresse erfolgt.
Ich vermute, dass dies auf die Namensauflösung von Windows in der Domäne zurückzuführen ist, die normalerweise vor DNS erfolgt.
Ich werde weiter suchen und diese Antwort aktualisieren.