ADFS zertifikatsauthentifizierung http 500

[StefanWe 14]

Hallo,

 

Habe hier https://social.technet.microsoft.com/Forums/en-US/999e232d-bf23-4a91-84fb-bb03792f4abd/user-certificate-authentication-gets-http-500?forum=ADFS schon gefragt. Ggf. Kann jemand von hier noch weiterhelfen.

 

Habe einen ADFS und wap 2016 konfiguriert mit einem san Zertifikat für alternate Hostnamen Bindung certauth.

Hab dann unter primäre Authentifizierung für extranet neben formfill auch user Zertifikate angeklickt.

Der der Authentifizierung bekomm ich die Möglichkeit ein Zertifikat auszuwählen, wenn ich das tue, werde ich auf die sub URL certauth... umgeleitet und erhalte dann ein http 500 Fehler.

Ich möchte mich gerne mit dem Zertifikat am o365 anmelden.

Richtiger upn usw. Ist im Zertifikat enthalten.

 

Die Anmeldung mit Benutzer und Kennwort klappt ohne Probleme.

 

Eine Idee warum ich ein http 500 bekomme? Im eventlog steht leider nichts.

[NilsK 2.968]

Moin,

 

ADFS und Zertifikate ist ... nicht eben toll. Spätestens wenn du von einem Hotel oder so kommst, wo der extra benötigte TCP-Port 49443, den ADFS für Zertifikatsanmeldung braucht, nicht frei ist, wirst du das merken. Vielleicht ist das auch hier schon der Grund.

 

Was ist denn der Grund für die Einbindung von Zertifikaten? Die haben ja schon prinzipiell eine Reihe von Nachteilen.

 

Gruß, Nils

[StefanWe 14]

Hi Nils,

 

Mit 2016 gibt es eine Alternative zu Port 49443.

https://docs.microsoft.com/de-de/windows-server/identity/ad-fs/operations/ad-fs-support-for-alternate-hostname-binding-for-certificate-authentication

 

Genau das versuche ich. Klappt nur leider nicht :(

[NilsK 2.968]

Moin,

 

Schau an, gut zu wissen. Es bleibt aber dabei, dass Client-Zertifikate für Webseiten großer M*st sind.

 

Gruß, Nils

[StefanWe 14]

Moin,

 

Schau an, gut zu wissen. Es bleibt aber dabei, dass Client-Zertifikate für Webseiten großer M*st sind.

 

Gruß, Nils

 

Ändert aber leider nichts an meinem Problem  ;)

[NilsK 2.968]

Moin,

 

mag sein, aber du hast meine Frage auch noch nicht beantwortet, warum es denn Clientzertifikate sein sollen.

 

Gruß, Nils

[StefanWe 14]

Moin,

 

mag sein, aber du hast meine Frage auch noch nicht beantwortet, warum es denn Clientzertifikate sein sollen.

 

Gruß, Nils

 

Der Kunde wünscht eine Kennwortlose Authentifizierung in seinem Unternehmen.

[NilsK 2.968]

Moin,

 

also nur Zertifikate, kein MFA?

 

In dem Fall würde ich prüfen, ob sich das per Smartcard oder auf andere Weise lösen lässt. Clientzertifikate auf dem Rechner haben eine Reihe von Einschränkungen und Nachteilen:

• Die Zertifikate müssen erst einmal beim User oder auf dem Device landen.
• Hat der User mehr als ein Zertifikat, dann muss er jedes Mal auswählen, welches er denn zücken will. Das kann ein typischer User aber kaum unterscheiden.
• Automatisch verteilte Zertifikate haben immer nur einen Indizienwert, keinen Nachweiswert: Der User könnte sein Zertifikat exportieren und auf ein anderes Device bringen (oder jemand anderem als Kopie geben).
  (Ja, das geht auch, wenn die Zertifikatsvorlage keinen Export zulässt.)
• Je nach Browser kann es passieren, dass der Browser das Zertifikat jeder Webseite übermittelt, die danach fragt - was eine prima Möglichkeit ist, an Daten des Users zu gelangen.
• ...

Wie ist denn die Anforderung genau definiert? Reicht ein "seamless SSO" nicht vielleicht schon aus, sodass man sich nur um die Windows Integrated Authentication kümmern müsste?

 

Gruß, Nils

bearbeitet 11. September 2017 von NilsK

[StefanWe 14]

Ja, es werden später Smartcards. Bzw. es sind jetzt schon Smartcards. Nur in meiner Testumgebung nutze ich ein Clientzertifikat. Das Verhalten des ADFS ist allerdings identisch, egal ob Smartcard oder Zertifikat. Ich erhalte ein HTTP 500.

 

Es betrifft ausschließlich den externen Zugriff über den WAP. Intern wird per Smartcard an Windows angemeldet und anschließend funktioniert WIA SSO gegen den ADFS einwandfrei.

 

Von extern soll dann die Smartcard + Pin genutzt werden.  

[NilsK 2.968]

Moin,

 

Verstehe. Zu dem 500 kann ich auf der Ferne leider wenig sagen. Hast du schon die verschieden logging-Methoden eingesetzt?

 

Gruß, Nils

[StefanWe 14]

ja, habe auch schon das Debug Logging aktiviert. Dort taucht nichts auf. Ich könnte mir vorstellen, dass es am WAP liegt, aber auch hier sehe ich leider nichts.

 

Werde wohl einen Case bei MS zu dem Thema aufmachen müssen.

[StefanWe 14]

Interessant - es dauert auf dem WAP etwa 30 Sekunden bis im Log eine Fehlermeldung auftaucht. Dort ist dann diese zu sehen:

 

 

The federation server proxy was unable to complete a request to the Federation Service at address https://certauth.adfs.lab.com ....

 

Auf dem ADFS selbst aber wie gesagt keine Meldung.

Die SSL Bindings mit netsh http show sslcert habe ich auch geprüft, hier sind alle entsprechend vorhanden.

[NilsK 2.968]

Moin,

 

geht es denn über den WAP, wenn du mit Kennwort authentisierst?

 

Gruß, Nils

[StefanWe 14]

Ja tut es. 

Verdammter mist. Case bei Microsoft aufgemacht und Fehler gefunden. Der WAP muss natürlich auch certauth.adfs.lab.com erreichen. Dieser muss auf den ADFS zeigen.

 

Ja natürlich - logisch. Allerdings bin ich davon ausgegangen, dass der WAP auf adfs.lab.com weiterleitet... 

 

Das ärgert mich nun...

[NilsK 2.968]

Moin,

 

naja, immerhin ist das Problem identifiziert und behebbar.

 

Jetzt, nach deinem Hinweis, finde ich dazu auch dies. Das gab es bislang nicht als Requirement, weil die Port-443-Verbindung an der Stelle ja neu ist.

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-2016-requirements

 

Danke für die Rückmeldung!

 

Gruß, Nils