none
Zugang zu Sharepoint per Client Zertifikat liefert Fehler RRS feed

  • Frage

  • Hallo,

    ich habe auf einem Sharepoint Server Zugriff per Client Zertifikat eingestellt. Auf den Server wird von extern eine Domain weitergeleitet. Das Client Zertifikat ist auf einer Maschine innerhalb des SP Server Netzwerks und auf einer Maschine außerhalb des Netzwerks installiert.

    Wenn ich von innerhalb des gleichen Netzwerkes zugreife klappt alles wunderbar (über den lokalen Namen des SP Servers). Versuche ich allerdings von außen über die Domain zuzugreifen, dann komme ich zur Zertifikatsauswahl und dann auch noch zu dem Userlogin, dann wird allerdings keine Seite ausgeliefert.Es kommt nur die Meldung "Die Webseite kann nicht angezeigt werden".

    Weitere Fakten:

    SSL Zertifkat auf dem SP installiert, ausgestellt auf den externen Domainnamen.

    Beim Login von Intern kommt es zu der Meldung, dass das Zertifikat nicht mit dem Servernamen übereinstimmt.

    Derzeit geht die Anmeldung von extern nur über Port 443 (SSL).

    Hat jemand ne Idee woran das liegen könnte ?

    Montag, 29. April 2013 10:24

Antworten

  • Hallo nochmal,

    das Problem hat sich geklärt. Wir hatten auf dem SP die Anwendung für die sichere Verbindung mit Client Zertifkat auf Port 8000 laufen. Auf der Firewall ist eine Porttranslation von 443 auf 8000 erfolgt. Im IE hatte man nix gesehen. Ich hatte dann einen test mit Firefox gemacht und habe dort gesehen, dass nach der Anmeldung der interne Port 8000 an den Browser geschickt wurde. Der Browser hat dann versucht über den Port 8000 zu kommunizieren und nicht mehr über 443. 8000 war natürlich nicht erlaubt von extern.

    Jetzt läuft alles über 443 und es klappt wunderbar.

    Danke für deinen Einsatz.

    • Als Antwort markiert MLang_HSE Freitag, 3. Mai 2013 14:23
    Freitag, 3. Mai 2013 14:23

Alle Antworten

  • Hallo,

    liegt ein Veröffentlichungssserver UAG/TMG/ISA zwischen dem externen Eingang und dem SharePoint Server? Welches Gerät macht die Weiterleitung? Firewall? Steht der vollständige Domänenname in dem Zertifikat? computer.domäne.de? ...und handelt es sich um ein öffentliches Zertifikat? Ist der vollständige Zertifikatsweg gesichert oder wird dem Zertifikat auf deinem Client vertraut?

    Die Meldung, dass die Seite nicht korrekt lädt, ist aber ungewöhnlich. Ist der vollständige Pfad konfiguriert? Alternative Zugriffszuordnung korrekt?

    Grüße


    kind regards Jochen Reinecke // MCSA '08 '12

    Montag, 29. April 2013 12:14
  • Hallo,

    also es liegt eine Firewall zwischen SP und Client. Hier wird eine Portweiterleitung durchgeführt von extern 443 auf intern Port XXXX. Ansonsten haben wir weder Forefront, noch ISA oder ähnliches laufen.

    Es handelt sich um ein Multidomain Zertifikat, welches für die öffentliche Adresse ausgestellt wurde. Das Zertifikat ist von einer öffentlichen CA unterschrieben, also ohne eigene CA. Derzeit läuft noch eine weitere Domain auf die gleichen Ports, welche wir jetzt abstellen lassen.

    Was ist mit vollständigem Pfad und Zertifikatsweg gemeint ?

    Danke schonmal für die bisherige Prüfung und Hilfe.

    Montag, 29. April 2013 12:28
  • Hallo,

    die Zertifizierungsfrage "Pfade" hat sich geklärt, wenn es öffentlich ist. Damit vertraust du ja der CA. Dann bleibt noch die alternative Zugriffszuordnung in SharePoint Server und die Frage, wie sich die Firewall nach der Portweiterleitung an dem SharePoint Server authentifiziert. NTLM? Standard? Integriert? Radius? Im Prinzip authentifizierst du ja zwei mal.. Einmal Client zu Firewall und einmal Firewall zu SPS.

    Grüße


    kind regards Jochen Reinecke // MCSA '08 '12

    Montag, 29. April 2013 12:40
  • Hallo,

    soweit ich weiss wird die Authentifizierung an den SP weitergeleitet. Wir haben ein AD im internen Netz des SP Servers und es wird sich mit den Windows Benutzerdaten authentifiziert.

    An der Firewall selber erfolgt meines Wissens nach keine Authentifizierung, hier wird wirklich nur eine Portweiterleitung durchgeführt, mehr nicht.

    Gruß

    Montag, 29. April 2013 12:48
  • ...dann bleibt noch die alternative Zugriffszuordnung in SharePoint Server ...


    :-)


    kind regards Jochen Reinecke // MCSA '08 '12

    Montag, 29. April 2013 12:50
  • Also für die Applikation gibt es 3 Zoneneinstellungen:

    1 Standard: Lokaler Servername

    2 Intranet: Lokaler Server mit Porterweiterung für SSL (nicht 443)

    3 Internet: Externer Domainname mit Zertifikat

    Die externe URL wird ja mittels Portweiterleitung auf die 8000 weiter geleitet.

    Gruß und Danke für die bisherige Mühe

    Montag, 29. April 2013 13:11
  • Mittels Tracert eine Routenverfolgung versucht? Kommen Pings am Ziel an?

    kind regards Jochen Reinecke // MCSA '08 '12

    Dienstag, 30. April 2013 06:14
  • Guten Morgen,

    also ein Tracert landet "direkt" an der Firewall ... bis dahin also alles okay. Ich bekomme ja auch beim Aufruf der externen Webseite im Browser die Clientzertifikatsauswahl. Danach konnte ich beim ersten Mal auch noch die Benutzerdaten eingeben. Spätestens dann ist Feierabend mit einer leeren Seite und der Meldung "Seite kann nicht geladen werden".


    • Bearbeitet MLang_HSE Dienstag, 30. April 2013 07:24
    Dienstag, 30. April 2013 07:24
  • Hallo,

    das klingt alles durchaus korrekt. Wichtig ist, dass eure Firewall integrierte (NTLM)-Authentifizierung unterstützt. Also die Authentifizierung zwischen Firewall und SharePoint Server. Wird diese auch akzeptiert?

    Grüße


    kind regards Jochen Reinecke // MCSA '08 '12

    Donnerstag, 2. Mai 2013 11:26
  • Hallo nochmal,

    das Problem hat sich geklärt. Wir hatten auf dem SP die Anwendung für die sichere Verbindung mit Client Zertifkat auf Port 8000 laufen. Auf der Firewall ist eine Porttranslation von 443 auf 8000 erfolgt. Im IE hatte man nix gesehen. Ich hatte dann einen test mit Firefox gemacht und habe dort gesehen, dass nach der Anmeldung der interne Port 8000 an den Browser geschickt wurde. Der Browser hat dann versucht über den Port 8000 zu kommunizieren und nicht mehr über 443. 8000 war natürlich nicht erlaubt von extern.

    Jetzt läuft alles über 443 und es klappt wunderbar.

    Danke für deinen Einsatz.

    • Als Antwort markiert MLang_HSE Freitag, 3. Mai 2013 14:23
    Freitag, 3. Mai 2013 14:23