RPC-über-HTTP Zugriff / Problem und Fragen

Blase · 18.04.2008, 20:36

Hallo allerseits,

ich versuche bisher erfolglos die Umstellung von Outlook Web Access auf RPC Zugriff. Gegeben sind:

- Windows 2003 R2 SP2 Standard Server
- Exchange Server 2003 mit SP2
- Outlook 2003 Client-seitig
- Zugriff per DynDNS

Der Server ist der Domaincontroller und DNS Server. Exchange läuft ebenfalls auf ihm. Für "später" gehen wir einfach mal von folgendem aus:

Servername: "NTSERVER.local" mit der IP 192.168.100.1
Dom-Benutzer: Benutzer.domäne.local mit Postfach Vorname.Nachname@Firma.de
DynDNS Adresse: "Firma.dyndns.org"

Bisher griffen die "Externen" Mitarbeiter über outlook web access zu, das funktionierte also einwandfrei über

http://firma.dyndns.org/exchange
Der Port 80 wurde vom Router auf die IP des Servers weitergeleitet.

Für den Zugriff mittels RPC habe ich bisher folgendes gemacht:

1. Die Windows Komponenten "RPC-über-HTTP-Proxy" und "Zertifikatdienste" nachinstalliert
2. Erstellen/Installieren eines neuen "Webserver" Zertifikats - als Name den Name des Servers eingesetzt - im lokalen Speicher aufbewahrt
3. Im IIS in der StandardWebsite das Zertifikat hinzugefügt
4. Im IIS im Bereich Exchange und RPC die SSL Verschlüsselung mit 128 Bit aktiviert
5. IM IIS im Bereich RCP die anonyme Anmeldung raus und Häkchen bei "Windows Authentifizierung" und "Standardauthentifizierung" rein
6. Im Router den Port 443 auf den Server weitergeleitet.
7. Konfiguration des Exchange zum Backend Server

Serverseitig, so dachte ich zumindest, wäre ich hiermit "fertig". Über das WWW sieht es aktuell wie folgt aus:

Outlook Web Access ist nun erreichbar (und funktioniert) über

https://firma.dyndns.org/exchange
Über

https://firma.dyndns.org/rpc kommt eine Benutzerabfrage, doch egal was ich dort eingebe, ich habe angeblich keine Berechtigung. Liegt hier schon das/ein Problem?!

Client-seitig bin ich auch noch nicht sicher, ob ich das richtig eingegeben habe. Bisher sieht das wie folgt aus:

Ich habe in Outlook 2003 ein neues Exchange Konto angelegt. Als Servername habe ich "NTSERVER" genommen, als Benutzer den entsprechenden Namen aus dem AD. Ich habe die Exchange Proxy Einstellungen aktiviert und in etwa so eingestellt:

Exchange Proxy:

https://Firma.dyndns.org
Haken bei SSL und Sitzung gegenseitig authentifizieren
Hauptname des Proxyservers: msstd:firma.dyndns.org

Tatsächlich habe ich an diesen Einstellungen schon was-weiß-ich alles probiert. Letztlich habe ich immer keine Verbindung hinbekommen, bzw. beim Prüfen des Namens wurde der Server nie gefunden.

So einige Fragen habe ich dazu:

1. Natürlich die Frage, wo der Fehler liegt, bzw. warum das nicht funktioniert
2. Die Konfirguration des Exchange zum "Backend-Server" hat keine weiteren Auswirkungen auf den Exchange Betrieb ansonsten? Ein Exchange kann ja entweder Frontend ODER Backend sein, nie beides. Aber ich brauch in meinem Fall keinen Frontend?
3. Der Name des Zertifikates sollte dem Servernamen entsprechen, oder? Egal?
4. Im Bereich Outlook RPC-Proxy - was bedeutet dieses "mssdt:FQDN"? Habe das aus dem www aufgeschnappt, aber was ist "mssdt" - wofür gut?
5. Client-seitig, gebe ich nur die DynDNS ADresse an oder noch mit dem "/RPC"?!

Der Beitrag ist etwas ausführlich geworden - hoffe die Übersicht leidet nicht. Vielen Dank schonmal fürs Lesen

MfG Blase

Joerg · 19.04.2008, 20:35

Zunächst mal solltest Du eine Weiterleitung von dem Webserver-Root auf das Exchange Verzeichnis machen, damit

https://firma.dyndns.org/ direkt auf

https://firma.dyndns.org/exchange verweist.

Auf welche Adresse ist das SSL-Zertifikat ausgestellt?
Wenn auf den Servernamen, dann kannst Du das vergessen. Kommt denn ein Zertifikatsfehler, wenn die Anwender von aussen auf OWA gehen?

RPC over HTTP funktioniert nur, wenn alle Zertifikatsfehler ausgemerzt sind.

Mit der eigenen Zertifikatsstelle kann das nicht gehen, da der Client von aussen diese CA nicht erreichen kann.

Du könntest entweder ein richtiges SSL Cert kaufen, oder auf freie Stellen (

http://www.cacert.org/) zurückgreifen.
Wichtig ist, daß das Cert auf den Namen firma.dyndns.org ausgestellt wird.
Der eigentliche interne Servername wird die von aussen nichts nützen.

Blase · 20.04.2008, 12:00

Mahlzeit Joerg!

Wofür brauche ich die Weiterleitung? Und "/Exchange" ist doch owa, interessiert mich für meinen rpc-Zugriff eigentlch überhaupt nicht, oder verstehe ich Dich jetzt falsch?!

Das Zertifikat habe ich übertragen und installiert. Bin mir auch ziemlich sicher, dass ich kein "offizielles Zertifkat" anfordern muss, bzw. dass mein eigenes an dieser Stelle reicht. Nicht desto trotz habe ich einen Zertifikatfehler, was ja bedeutet, dass ich bei der Erstellung was nicht beachtet habe. Habe tatsächlich den Namen des Zertifikates auf dem Servernamen, also "NTSERVER" ausgestellt, kommt da die DynDNS ADresse rein? Also der Bereich beim Zertifikat ist ja dreigeteilt:

- Ausstellung auf Firma
- Datum des Zertifikates
- Name des Zertifikates

Kann ich grade nicht testen, aber imho waren die oberen beiden Punkte grün i.O. beim letzten Punkt hatte ich halt das gelbe Ausrufungszeichen. Werde dann Serverseitig ein neues Zertifikat ausstellen auf "Firma.dyndns.org".

MfG Blase

linux-luder · 20.04.2008, 12:09

Das Zertifikat muss auf den DNS-Namen lauten, bei Dir dann Firma.dyndns.org.
==> Aufpassen, nicht "www.firma.dyndns.org" draus machen, ergibt einen Zertifikatsfehler wenn man auf "firma.dyndns.org" zugreifen will!

Joerg · 22.04.2008, 00:03

Wenn der Client die Zertifizierungsstelle nicht erreichen kann und das kann er nicht, wenn die CA auf dem Server liegt, dann wirst Du den Cert Error nicht wegkriegen.
Von daher wird das so nicht funktionieren.

Ein Zertifikat an sich reicht nicht. Es muss auch verifiziert werden. Theoretisch könntest Du Deine eigene Stelle als Trusted Root CA eintragen, was dann aber wieder an der fehlenden Erreichbarkeit scheitert.

Dafür habe ich das nun schon zu oft eingerichtet