Laden...

WCF-REST in IIS per SSO mit Kerberos führt zu 401.1 und 401.2

Erstellt von roYaL-TS vor 7 Jahren Letzter Beitrag vor 7 Jahren 4.126 Views
R
roYaL-TS Themenstarter:in
53 Beiträge seit 2012
vor 7 Jahren
WCF-REST in IIS per SSO mit Kerberos führt zu 401.1 und 401.2

Hallo zusammen,

ich habe einen Webservice, welchen ich mit SSO über Kerberos ansteuern möchte. Leider klappt dies nicht so wie gewünscht.

Hier mein bisheriges Setup:
Ich habe mich grundsätzlich erstmal an diesen Guide gerichtet: Setting up Kerberos

Der AppPool-ausführende User hat SPNs für den Server und die Domain gesetzt bekommen.

Wenn ich nun eine Anfrage an den Webservice setze, so greift zum einen der SSO nicht und ich muss meine Credentials angeben. Dies wiederhole ich dann 4 mal ehe es zur Fehlermeldung 401 kommt.

In den IIS-Logs finde ich für den AppPool folgendes:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2016-10-24 11:27:34 10.11.0.121 GET /webservices/restservice.svc/projects/test|user/2016-06-01/2016-10-01/ - 8443 - 10.11.0.130 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/53.0.2785.143+Safari/537.36+OPR/40.0.2308.90 401 2 5 0
2016-10-24 11:27:52 10.11.0.121 GET /webservices/restservice.svc/projects/test|user/2016-06-01/2016-10-01/ - 8443 - 10.11.0.130 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/53.0.2785.143+Safari/537.36+OPR/40.0.2308.90 401 1 2148074245 124

Im Eventviewer habe ich leider keine Einträge hierzu gefunden.

Hat jemand eine Idee woran das liegen kann? Fehlen evtl. konfigurationen im AD? Wie erwähnt habe ich mich komplett an den oben erwähnten Guide gehalten (bis einschließlich Punkt 8).

Sollten weitere Infos benötigt werden die ich hier vergessen habe, kann ich die natürlich gern nachreichen. Ich ärgere mich nun seit über eine Woche mit diesem Problem rum und wäre über jede Art von konstruktiver Hilfe dankbar.

Gruß
roYaL-TS

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
 John Woods

16.834 Beiträge seit 2008
vor 7 Jahren

Welchen Browser nutzt Du? Nur Chrome und IE senden per default das Kerberos Ticket mit bzw. verwendet Chrome den Credential Cache des IE und verhält sich hier identisch.
Firefox / Opera (IIRC) müssen jeweils dafür gesondert konfiguriert werden.

R
roYaL-TS Themenstarter:in
53 Beiträge seit 2012
vor 7 Jahren

Hallo,

ich verweden den IE10 auf dem Server und IE11 auf den Clients.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
 John Woods

16.834 Beiträge seit 2008
vor 7 Jahren

Und in den Einstellungen ist auch sicher das Senden des Tickets aktiviert und nicht via Group Policy deaktiviert?
Funktionierts auf anderen Webservern? Funktioniert auf anderen Sites des gleichen Servers?

R
roYaL-TS Themenstarter:in
53 Beiträge seit 2012
vor 7 Jahren

Hallo,

das senden der Tickets ist aktiviert. Auch habe ich auf dem Server für alle Zonen das Senden der Credentials aktiviert.

Von anderen Servern / Endgeräten funktioniert der Zugriff ebenfalls nicht. Andere Sites von dem Server werden normal angezeigt, diese verwenden allerdings kein Kerberos bzw. generell keine Windows-Auth.

Was mich verwundert, auf dem angehangenen Screenshot ist zu sehen, dass die Anmeldemethode unbekannt ist, wie kann das sein?

EDIT: Der Screenshot ist nicht gut zu erkennen, hier ein Link dazu: https://s21.postimg.org/yrr8wbp8n/401error.jpg

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
 John Woods

16.834 Beiträge seit 2008
vor 7 Jahren

Beim Umstellen des Kernel Modes, hast Du auch den IIS neu gestartet?

R
roYaL-TS Themenstarter:in
53 Beiträge seit 2012
vor 7 Jahren

Nach einem IIS-Reset erhalte ich nun den Anwendungsfehler

Fehlermeldung:
Die für IIS konfigurierten erweiterten Schutzeinstellungen stimmen nicht mit den für den Transport konfigurierten Einstellungen überein. Die ExtendedProtectionPolicy.PolicyEnforcement-Werte stimmen nicht überein. IIS hat den Wert WhenSupported, und der WCF-Transport hat den Wert Never.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
 John Woods

16.834 Beiträge seit 2008
vor 7 Jahren

Du machst nen REST Service über WCF? Wieso denn das?
Dafür gibts die ASP.NET WebAPI. WCF ist obsolete.

R
roYaL-TS Themenstarter:in
53 Beiträge seit 2012
vor 7 Jahren

Der WCF Service ist bereit seit längeren Bestandteil der Umgebung und intern über http erreichbar. Dieser soll nun nach außen über https erreichbar gemacht werden und durch die Kerberos-Authentifizierung gesichert werden. Daher wird hier WCF genutzt.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
 John Woods

16.834 Beiträge seit 2008
vor 7 Jahren

Okay da bin ich dann raus, weil das im IIS/WCF meines Wissens nach irgendwas mit dem Security Mode und dem Service Behavior/Impersonation war.
Da kann ich nicht mehr weiter helfen.

R
roYaL-TS Themenstarter:in
53 Beiträge seit 2012
vor 7 Jahren

Nach kurzer Suche über google konnte ich den Fehler finden. Der erweiterte Schutz in den erweiterten Einstellungen der Windows-Auth muss deaktiviert werden. Danach ging die Verbindung reibungslos.

Trotzdem danke für die Hilfe, das Thema kann damit geschlossen werden.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
 John Woods