Benutzer mit den meisten Antworten
Routing von außen / welches Produkt

Frage
-
Hallo,
ich bin gerade am Erlernen von Windows Netzwerken mit dem Hauptaugenmerk auf SharePoint. Mit dem SharePoint arbeite ich schon länger.
In einem Testsystem erstellte ich eine Domain mit einem SharePoint Server und Clients. Auf dem SharePoint Server laufen einige Webseiten (Intranet, Teamseiten, … alle per HTTPS). Innerhalb der Domain klappt der Zugriff auf die Seiten auch ohne Probleme.
Nun möchte ich den Zugriff auf die Seiten auch von außen (außerhalb der Domain) simulieren. Welches MS Produkt aus der Forefront Serie kann ich nutzen um den Zugriff zu gewähren?
Ziel ist es durch Eingabe der https://IP/Teams auf die Teamseite zu routen ähnlich https://IP/ Intranet auf die Intranet Seite. Beide Seiten sollen auf den SharePoint laufen. Gerne möchte ich so auch eine Webseite des Unternehmens simulieren.
Danke für Eure Hilfe
Stefan
Viele Grüße Stefan
Kontakt unter Info@IT-Kiessig.deSonntag, 22. Juli 2012 22:49
Antworten
-
Hi,
das empfohlene Produkt von Microsoft ist Forefront UAG:
http://www.microsoft.com/en-us/server-cloud/forefront/unified-access-gateway.aspx
Aber auch mit Forefront TMG kann man Sharepoint veroeffentlichen:
https://www.microsoft.com/de-de/server/forefront/sicherheit-zugang.aspx
http://www.isaserver.org/tutorials/Publishing-Microsoft-SharePoint-2010-Forefront-TMG-different-authentication-options-Part1.html
Beide Versionen erhaeltst Du auch als Testversion.
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
- Als Antwort markiert Stefan3110 Montag, 23. Juli 2012 10:04
Montag, 23. Juli 2012 04:36 -
Hi,
da der Sharepoint ein selbstsigniertes Zertifikat verwendet musst Du selbiges in den Zertifikatspeicher der vertrauenswuerdigen Stammzertifizierungsstellen am TMG imprtieren - korrekt
Am TMG kannst Du auch ein selbstigniertes Zertifikat verwenden wenn es nur zu Testzwecken verwendet wird und Du die Clients die aus dem Internet ueber den TMG auf den Sharepoint zugreifen in Deiner Kontrolle hast. Dann kannst Du bei den Clients das am TMG ausgestellte Zertifikat ebenfalls auf dem Client in den Zertifikatspeicher der vertrauenswuerdigen Zertifizierungsstellen kopieren um beim Aufruf der Sharepoint URL aus dem Internet keine Zertifikatwarnung zu erhalten
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
- Als Antwort markiert Stefan3110 Montag, 23. Juli 2012 19:15
Montag, 23. Juli 2012 14:27
Alle Antworten
-
Hi,
das empfohlene Produkt von Microsoft ist Forefront UAG:
http://www.microsoft.com/en-us/server-cloud/forefront/unified-access-gateway.aspx
Aber auch mit Forefront TMG kann man Sharepoint veroeffentlichen:
https://www.microsoft.com/de-de/server/forefront/sicherheit-zugang.aspx
http://www.isaserver.org/tutorials/Publishing-Microsoft-SharePoint-2010-Forefront-TMG-different-authentication-options-Part1.html
Beide Versionen erhaeltst Du auch als Testversion.
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
- Als Antwort markiert Stefan3110 Montag, 23. Juli 2012 10:04
Montag, 23. Juli 2012 04:36 -
Hey,
ich schaute mir gerade dieses Tutoriell an.
http://www.isaserver.org/tutorials/TMG-Back-Basics-Part7.html
Es war sehr gut.
Kann ich jetzt auch anstatt external_domain.xx die IP des Rechners angeben?
Was muss ich beachten wenn ich auf beiden HTTPS mit SSL Verschlüsselung nutzen möchte?
Beispiel: https://external/Intranet auf https://internet.domain.loc
Kann ich das Certifikat des SharePoint (es ist auch auf den internen Clients installiert um auf die HTTPS Seiten zuzugreifen) auch für die Verbindung nach außen nutzen?
Danke für Eure Hilfe
Stefan
Viele Grüße Stefan
Kontakt unter Info@IT-Kiessig.deMontag, 23. Juli 2012 12:24 -
Hi,
ja, du kannst auch die IP Adresse angeben. Dazu musst Du am TMG ein Zertifikat erstellen, welches auf den CN / SAN mit der IP Adresse anstatt des FQDN ausgestellt ist. Das Zertifikat kannst Du dann in dem Weblistener verwenden.
Wenn Du SSL zu SSL Bridging durcfuehren willst musst Du sicherstellen, dass der FQDN welchen Du zum Zugriff auf den internen Sharepoint Server verwendest im CN des Zertifikats am Sharepoint Server hinterlegt ist und TMG das Root CA Zertifikat der ausstellenden Zertifizierungsstelle fuer das Sharepoint Zertifikat im lokalen Zertifikatspeicher der vertrauensweurdigen Zertifizierungsstellen gespeichert hat.
Das Sharepoint Zertifikat kannst Du auch verwenden wenn der CN den oeffentlichen FQDN oder die offizielle IP Adresse enthaelt. Du benoetigst dafuer ein SAN (Subject Alternate Name) Zertifikat. Da dieses dann aber auch die/den FQDN Deines internen Servers enthaelt und man im Internet dann in die Zertifikateigenschaften klicken kann und externe user auch den internen FQDN sehen koennen, empfehle ich die Verwendung von zwei Zertifikaten. Einmal am Sharepoint, einmal am TMG.
Des weiteren muss natuerlich das AAM am Sharepoint korrekt konfiguriert sein!
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
Montag, 23. Juli 2012 13:06 -
Danke Marc für Deine schnelle Antwort.
Für die interne Verbindung vom TMG zum SharePoint benötige ich das SharePoint Zertifikat. Dieses muss auch in den vertrauenswürdigen Stammzertifikaten auf dem TMG installiert sein.
Für die externe Verbindung zum TMG benötige ich ein Zertifikat welches ich auf dem TMG erstellen kann.
Das SharePoint Zertifikat ist ein selbst signiertes Zertifikat vom IIS des SharePoints. Ist dies okay so? Kann ich auf dem TMG genauso vorgehen um das externe Zertifikat zu erstellen?
Vg
Stefan
Viele Grüße Stefan
Kontakt unter Info@IT-Kiessig.deMontag, 23. Juli 2012 13:53 -
Hi,
da der Sharepoint ein selbstsigniertes Zertifikat verwendet musst Du selbiges in den Zertifikatspeicher der vertrauenswuerdigen Stammzertifizierungsstellen am TMG imprtieren - korrekt
Am TMG kannst Du auch ein selbstigniertes Zertifikat verwenden wenn es nur zu Testzwecken verwendet wird und Du die Clients die aus dem Internet ueber den TMG auf den Sharepoint zugreifen in Deiner Kontrolle hast. Dann kannst Du bei den Clients das am TMG ausgestellte Zertifikat ebenfalls auf dem Client in den Zertifikatspeicher der vertrauenswuerdigen Zertifizierungsstellen kopieren um beim Aufruf der Sharepoint URL aus dem Internet keine Zertifikatwarnung zu erhalten
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
- Als Antwort markiert Stefan3110 Montag, 23. Juli 2012 19:15
Montag, 23. Juli 2012 14:27 -
Bitte entschuldige Marc aber ich habe noch eine Frage.
Wenn ich 2 Verbindung nach aussen öffnen möchte. Eine per HTTPS für Teamnet und Intranet) und eine für HTTP (für den Webauftritt) muss ich dann 2 HTTP Listener erstellen?
Wie muss ich vorgehen wenn ich https://ip/teams auf intern https://teams.domain.loc und https://ip/intranet auf intern https://intranet.domain.loc routen möchte? Muss ich hier auch mehrere Web Listener erstellen? Oder kann ich für einen mehrere Routen definieren?
Danke
Stefan
Viele Grüße Stefan
Kontakt unter Info@IT-Kiessig.deMontag, 23. Juli 2012 22:05 -
Ich unterstütze mal ;-)
Ja du solltest/musst zwei Listener verwenden. Ein Listener ist immer Beschränkt dadurch, dass er nur 1x den Port freigeben kann bzw. nur 1x das Anmeldeverfahren (also public bzw. keines , Integrated etc).
Würdest du eine Inter- und Intranet Site über einen Listener veröffentlichen (80 und 443) dann würden für beide Sites nur ein Authentifizierungsverfahren gelten. z.b. Integrated. Und das möchte man ja auf der Internetseite nicht ;-)
Das ganze erklärt auch dein 2. Szenario. Wenn beide Seiten das gleiche Anmeldeverfahren nutzen dann kannst du mit einem Listener und ganz wichtig mit einer IP Adresse beide Seite veröffentlichen. Ist das nicht so brauchst du zwei Listener und 2 IP Adressen.
Veröffentlicht wird dann "normal" mit öffentlicher Name = https://ip/teams oder https://ip/intranet auf die jeweilige Interne Seite (HTTPs und IP ist übrigens nicht gut, solltest du Zertifikate nutzen - dann immer mit Namen).
Ganz wichtig, Routen ist an der Stelle der falsche Begriff :-) Reverseproxy trifft es da eher ;-)
VG
Mathias
Dienstag, 31. Juli 2012 19:03