plominski
Goto Top

(Apache) Reverse Proxy für RPC over HTTPS Exchange Access

Grüße

folgendes Szenario ist gewünscht:

Client (mit Outlook2003) -> ANFRAGE -> <- Firewall -> Webserver (Apache SSL) -> <- Exchange (RPC)

bis jetzt sind mir im Netz nur Anleitungen in Bezug auf Microsoft ISA Server aufgefallen ...

MFG Daniel

http://media.plominski.de/docs/Xampp-ReverseProxy-fuer-Exchange-OWA-09. ...

http://media.plominski.de/docs/Xampp-ReverseProxy-fuer-Exchange-RPCover ...

Content-Key: 9628

Url: https://administrator.de/contentid/9628

Ausgedruckt am: 28.03.2024 um 12:03 Uhr

Mitglied: lutz.wolf
lutz.wolf 20.04.2005 um 10:38:51 Uhr
Goto Top
http://support.microsoft.com/kb/833401

Hier ohne ISA-Server. Aber ob das mit dem Indianer geht?
Mitglied: Balubaer
Balubaer 09.12.2005 um 14:08:33 Uhr
Goto Top
Hiho!

Eigentlich ist dieser Beitrag (von April diesen Jahres) ja schon fast "outdated", aber ich habe derzeit noch ordentlich Probleme, diese Konstellation auf die Reihe zu bringen.

Folgendes Szenario:

  • Windows Exchange 2003 auf Windows Server 2003 (der als DC fungiert) (mit Beispielnamen xchserver.intranet.local)
  • dieser Server liegt im internen Netz und der Kontakt zur Außenwelt geht über einen Linux-Server (nach aussen unter Beispielnamen proxy.firma.de)
  • Apache-Proxy für OWA ist auf dem Linux-Rechner eingerichtet und funktionert tadellos
  • Einrichtung nach MS KB 833401 vorgenommen (ebenso als Quelle diente http://3cx.org/item/46#rpcoverhttp)

Ich bekomme dann folgendes Verhalten, wenn ich mein Outlook (zu Hause) auf RPC-over-HTTP(s) einrichte:

  • start von Outlook mit Parameter /rpcdiag
  • Anzeige, dass Verbindung zu Server "proxy.firma.de" hergestellt wird
  • PopUp für Nutzer/Kennwortdaten kommt auf
  • Eingabe der Nutzerdaten (diverse Versionen, mit/ohne Domäne, Domäne in Kurz-/Langschreibweise)
  • anschliessend Wechsel der Anzeige, dass Verbindung zu "xchserver.intranet.local" aufgebaut wird (was von meinem Rechner aus natürlich nicht geht!)

Das Problem scheint also irgendwie darin zu liegen, dass der Proxy für den Kontakt von Outlook zum Server übergangen wird/werden soll.

Hat also vielleicht jemand eine Idee/einen Anhaltspunkt, was ich nun noch tun kann, um RPC-over-HTTP zu ermöglichen?

Danke,
Dennis
Mitglied: Plominski
Plominski 12.12.2005, aktualisiert am 17.10.2012 um 16:24:18 Uhr
Goto Top
Grüße<font color="Blue">

da ich auch persönlich daran ein "großes" Interesse besitze, würde ich vorschlagen, das wir uns Intensiv mit der Problematik auseinander setzen.

In den letzten Nächten, habe ich eine komplette "virtuelle" LAN Umgebung aufgebaut:
</font><font color="Green">
Rechner: VMWare WinXP SP2 <-> VMWare Firewall -> VMWare Windows 2003 SBS

Client: LAN=10.10.10.10/255.0.0.0

Firewall: RED=10.10.10.1/255.0.0.0
GREEN=192.168.10.1/255.255.255.0

SBS Server: LAN=192.168.10.10/255.255.255.0
</font><font color="Blue">
- dem Client habe ich jeweils die Resolv-Einträge in die "C:\WINDOWS\system32\drivers\etc\hosts" verpasst.
</font><font color="Red">
### ### ### ### ### ### ### ### ###
10.10.10.1/255.0.0.0 fw1test.extern.local
### ### ### ### ### ### ### ### ###
</font><font color="Blue">
- die Firewall läuft auf der EXTERNEN Adresse unter: "fw1test.extern.local"
- INTERN jedoch unter: "fw1test.intern.local"
</font><font color="RED">
### Firewall /etc/hosts beträgt ### ### ###
192.168.10.10 srv1test.intern.local
### ### ### ### ### ### ### ### ###
</font><font color="Blue">
- der Win2003 SBS Server ist auf "srv1test.intern.local" gemappt

  1. DNS/Router/WINS-IP entspricht der Firewall#
</font>
<HR><font color="Blue">
Software:

Client - Windows XP SP2 mit Outlook 2003 SP

Firewall - Linux mit Kernel 2.4.31 sowie "Apache (+ReverseModule) 2.5.x

! Ports von RED nach GREEN sind alle "gesperrt" | außer "443" auf Apache SSL (Firewall)

Server - Windows 2003 Small Business Server (wahlweise SP1 und Exchange2003 SP1)

### ### ### Die Apache Konfiguration entspricht erstmal der OWA PDF ### ### ### ###

http://media.plominski.de/docs/Xampp-ReverseProxy-fuer-Exchange-OWA-09. ...

bzw:

(Apache) Reverse Proxy für OutlookWebAccess
</font>
<HR><font color="Blue">
Der "httpd.conf" noch folgende Zeilen ergänzt:
</font><font color="Red">
ProxyPass /rpc https://srv1test.intern.local/rpc
ProxyPassReverse /rpc https://srv1test.intern.local/rpc
</font>
<HR><font color="Blue">
Mit dieser Konstellation habe ich mich an folgenden Beispielen orientiert:

Exchange RPC over HTTP/S mit ISA: http://www.msisafaq.de/Anleitungen/2004/Firewallrichtlinien/RPCHTTPS.ht ...
Exchange RPC over HTTP/S als SingleServer: http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm

sowie deiner geposteten Quelle:
</font>
<HR><font color="Blue">
### Ein Problem bei dem ganzen ist mir (zuerst) aufgefallen, das beim aufrufen von https://srv1test.intern.local/rpc nach der Benutzereingabe
eine (ungewollte) wiederholende Abfrage folgt.

Somit bastelte ich etwas an dem "Virtuellen Verzeichnis" RPC des IIS herum, und stellte folgende Werte ein:
</font><font color="Red">
"Serververwaltungskonsole" -> "Erweiterte Verwaltung" -> "InternetInformationsDienste" -> "SRV1TEST" -> "Websites" -> "Standartwebsites" -> "RPC" -> "Verzeichnissicherheit":

YES: "Integrierte Windoiws-Authentifizierung"
YES: "Standartauthentifizierung"
NO: ".Net Passport"
</font>
--- Server restart ---
<HR><font color="Blue">
Nur hatte ich leider schon das "Service Pack 1" eingespielt, wodoch expliziet Seiten von "RPC Problemen nach SP1" berichten.
</font>
<HR><font color="Blue">
Dann habe ich einfach mal unter:
</font><font color="Red">
EXCHANGE "System-Manager" -> "Server" -> "SRV1TEST" -> "RPC-HTTP" (Option ab winSP1) mal Zwanghaft "Back-End-Server" eingestellt!
</font>
--- Server reboot ---
<font color="Blue">
Ergebnis:

Jetzt kommt man lokal bis zur Exchange OWA Seite, nach der Auth Übertragung meldet jedoch die Seite, das der Dienst "4xx" nicht zur Verfügung stehen würde!!!

Das spannende Jetzt an der Sache ich jedoch, wenn ich mich JETZT über den ReverseProxy einlogge:

Client -> (Apache)Firewall <-> Win2003 SBS Exchange OWA # funtkioniert es wie gewohnt!!!
</font>
<HR><font color="Blue">
Ich werde mich die nächsten Stunden daran setzten, jene Exchange Umgebung neu aufzubauen...
Diesmal Win2003 ohne SP1 zu installieren und zu schauen ob der Flaschenhals nicht schon das mangelnde RPC Handling jenes WinServers ist ...
</font>
bis dahin ...
Mitglied: Plominski
Plominski 13.12.2005 um 02:26:00 Uhr
Goto Top
Also: Jetzt hab ich es definitiv, das ab SP1 etwas "vermodelt" wird!

ist aber auch nach_zu_lesen unter:

http://www.msexchangefaq.de/admin/servicepackwin.htm
<HR>555316 Error 401.3 when configuring RPC over HTTP on Exchange 2003 after installing Windows Server 2003 SP1
<HR>
*G*
MFG
Mitglied: Plominski
Plominski 13.12.2005 um 02:47:29 Uhr
Goto Top
Mitglied: Plominski
Plominski 13.12.2005 um 03:46:13 Uhr
Goto Top
Gut, nachdem ich nun jeweils auf der Test Maschine (ohne SP) und auf unserem Produktiven Server mit SP1 erfolgreich eine Outlook HTTPS Verbindung aufbauen konnte, schließe ich jetzt weitere WindowsSeitigeEventualitäten aus.

Damit Du/Ihr es auch nachvollziehen könnt:

Exchange-Proxyeinstellungen
- https://winsbs.domain.local

- Standartauthentifizierung

--- Outlook mit "Outlook /rpcdiag" gestartet! ---

Jetzt liegt es wohl ganz allein daran, eine passende Apache Config zu erstellen !

Gute Morgen!
Mitglied: Plominski
Plominski 13.12.2005 um 05:00:57 Uhr
Goto Top
Outlook hängt sich auf!
Apache Log:

10.0.0.101 - - [13/Dec/2005:04:54:41 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?server.Privat.local:6001 HTTP/1.1" 104 719
10.0.0.101 - - [13/Dec/2005:04:54:41 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?server.Privat.local:6001 HTTP/1.1" 104 719
10.0.0.101 - - [13/Dec/2005:04:55:04 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?server.Privat.local:6002 HTTP/1.1" 104 719
10.0.0.101 - - [13/Dec/2005:04:54:41 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?server.Privat.local:6001 HTTP/1.1" 200 1794
10.0.0.101 - - [13/Dec/2005:04:54:41 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?server.Privat.local:6001 HTTP/1.1" 200 148
10.0.0.101 - - [13/Dec/2005:04:55:04 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?server.Privat.local:6002 HTTP/1.1" 200 148
10.0.0.101 - - [13/Dec/2005:04:54:42 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?server.Privat.local:6001 HTTP/1.1" 104 719
10.0.0.101 - - [13/Dec/2005:04:54:42 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?server.Privat.local:6004 HTTP/1.1" 104 719
10.0.0.101 - - [13/Dec/2005:04:54:42 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?server.Privat.local:6001 HTTP/1.1" 200 148
10.0.0.101 - - [13/Dec/2005:04:54:42 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?server.Privat.local:6004 HTTP/1.1" 200 148

MFG
Mitglied: Balubaer
Balubaer 13.12.2005 um 10:56:26 Uhr
Goto Top
Hi Plominski,

ich habe vermutlich vergessen zu erwähnen, dass ich (glücklicherweise?) bereits mit Win2k3 SP1 und (seit kurzem) Ex2k3 SP2 versorgt bin.

Abgesehen davon, funktioniert es ja intern via RPC-over-HTTP! Nur von extern, also über den Apache-Proxy, bekomme ich keinen Aufbau zum Exchange-Server hin.

Aus meiner Sicht kann es ja fast nur die Namensumschreibung (von proxy.firma.de nach xchserver.intranet.local) sein, denn xchserver.intranet.local ist natürlich von aussen nicht erreichbar!

Was ich mich aber nun Frage, warum Outlook nicht weiter versucht, über den Proxy die Verbindung aufzubauen? Oder bedarf es noch besonderer Einstellungen am Apache?

Gruß
Dennis
Mitglied: Plominski
Plominski 13.12.2005 um 13:06:06 Uhr
Goto Top
Genau das ist ja der punkt!

In meiner Test Umgebung habe ich ja expliziet alle "IP Adressen (intern/extern)" schon fest deren Namenszuordnung durch die Hosts Dateien zugewiesen.

(SSL Cert Fragen von "Exchange->Reverse" sowie "Reverse->Client" auch sauber eingebunden)

Nach meinem Verständnis funktioniert es so:

Client mit Outlook -> MAPI Anfrage wird in HTTP/S Paket gewickelt.

Sende HTTP/S Paket an -> "Proxy" http/s://reverseproxy.domain.extern

Jetzt schickt der "ReverseProxy" -> ja nichts weiter als das HTTP/S Paket an sein "Reverse" Ziel

  1. /rpc https://exchange.domain.intern/rpc #

Diese "RPCproxy.dll" -> wandelt jetzt wieder den "HTTP/S" Strom in Datenpakete an seinen "RPC to MAPI" Connect mittels Ports 6001/6002/6004 um

### Das selber sollte jetzt auch wieder ZuRück passieren ###

Irgendwo steckt im Apache der Wurm, denn nach öfteren Outlook hängern, hat es einfach so paar mal "Verzeichnisse/Emails" über HTTP/S gesynct!

und mögliche MAPI Connects, kann ich in dem Falle definitiv auschließen, da die Firewall eben nur 443 (Apache) offen stehen hat!

... Suchen wir Weiter ...
bzw.: würde mich interessieren wie es die Jungs unter: http://mail2web.com/ gelöst haben ???

Gibt es Überhaupt jemanden, der 100% bestätigen kann, das Apache "RPC over HTTP" reversen kann ?

MFG
Mitglied: Plominski
Plominski 13.12.2005 um 14:58:26 Uhr
Goto Top
Also im großen und ganzen macht mich etwas die RPC "Auth" stutzig...

Wenn im IIS (RPC) - "Win-Auth" + "Standart-Auth" sowie
"SSL Only" aktiv sind, funktioniert der Zugriff auf:

https://sbs.domain.local/rpc sowie https://sbs.domain.local/rpc/rpcproxy.dll

Dagegen wenn im IIS (RPC) - "Win-Auth" + "Standart-Auth" sowie
"SSL Off" aktiv sind, funktioniert der Zugriff auf:

http://sbs.domain.local/rpc sowie http://sbs.domain.local/rpc/rpcproxy.dll

ebenso:

DOCH man muss jetzt in der "Proxy Konfig" von "Outlook" statt "Standart-Auth"

"NTLM-Auth" aktivieren um "ohne SSL" RPC nutzen zu dürfen, doch dann schlägt die Outlook Auth Sync jedesmal fehl ?

... werde jetzt mal den Client in die Domaine einfügen und mal schauen ob es dann mit der Outlook "NTLM-Auth" besser funktioniert!

... MFG
Mitglied: Plominski
Plominski 13.12.2005 um 16:52:36 Uhr
Goto Top
Also: habe auch schon an der Reg. herum_gespielt, aber HTTP RPC lies sich nicht aktivieren ...

Exchange SP2 behebt den fehler *G*

MFG
Mitglied: Plominski
Plominski 14.12.2005 um 02:24:16 Uhr
Goto Top
Also ich habe jetzt eine saubere "erst" Verbindung zustande bekommen!

Client -> Apache SSL -> Exchange RPC over HTTP/SSL!!!

Outlook startet, syncronisiert, und das auch mehrmals...

Doch nach dem beenden und erneuten starten funktioniert es nicht mehr, (Apache) restart hilft auch nicht ...

... Entweder liegt es an einer "Un"sauberen RPC Abmeldung, oder an einem TimeOut Interval ...

MFG Daniel
Mitglied: Balubaer
Balubaer 14.12.2005 um 09:53:50 Uhr
Goto Top
Hi Daniel,

ähhh.... hast Du jetzt noch irgendwo was an den Einstellungen (speziell dem Apache) verändert oder hast Du nur eine Neuinstallation von Windows und/oder Exchange aufgesetzt?

Mein Problem ist, dass ich hier derzeit keinerlei Testumgebung aufsetzen kann, um die Sache selbst nochmal mit einer "sauberen" Netzstruktur zu testen. face-sad

Ich hoffe, dass ich hier endlich eine Konstellation hinbekomme die funktioniert... Das kann doch nicht so schwer sein.

Gruß
Dennis
Mitglied: christianbln2k
christianbln2k 14.12.2005 um 14:53:05 Uhr
Goto Top
Hallo Plominski,
hallo an alle anderen.

Zur Konfiguriation des Apachen als OWA Proxa haben ein paar Leute
vom Board eine gute Step by Step Anleitung geschrieben.
(Links kann ich gerne posten)

Ich würde vorschlagen die notwendigen Schritte um den Apachen zum
RPC Proxy zu machen (auch für den Windows Server) ebenfalls zu
dokumentieren, damit alle was davon haben.

Ich bastel momentan selber an einen Apache-RPC Proxy, daher ist der
Vorschlag/die Frage nicht ganz uneigennützig.

Habt ihr Zeit und Lust dazu?

Eine Frage in dem Kontext habe ich auch gleich:
Muss der Exchange Server zwingen Globaler Katalog sein?

Grüße
Christian
Mitglied: Plominski
Plominski 14.12.2005 um 15:00:11 Uhr
Goto Top
- kleine Anleitung -
Mitglied: Plominski
Plominski 14.12.2005 um 15:20:00 Uhr
Goto Top
Da ich die letzten Tage etwas Zeit hatte, konnte ich intensiv Tag/Nacht herum_probieren ;)
<font color="Blue">
Also die ganzen Dokumentationen im Netz, wo man erst in der Reg. herum pfuscht, um ein Stand-Alone Server einzurichten, bzw andere Seiten wieder eine "Back-End" "Apache-Front-End" Konstellation suggerieren taugen nix ...
</font><font color="Brown">
Man geht wie folgt vor:
</font><font color="Blue">
Windows 2003 Small Business Server installieren/einrichten
dann:</font><font color="Green">
- Windows 2003 Service Pack 1
- SharePoint SP
- Exchange Service Pack 1
- XP Client(bereitstellungs) Service Pack 2
-- Windows 2003 SBS Service Pack 1!
</font><font color="Brown">
Jetzt noch sämtliche "Online-Updates" einspielen

und - Service Pack 2 für Exchange 2003 !!!

(Ganz Wichtig, unbedingt die 5 Updates vor dem "SP2 for Exchange2003" installieren, sonst kommt es (war zumindest in einer Testumgebung bei mir) bei erneutem Server start zu deinem Exchange DB crash!)
siehe dazu auch:
</font>
http://www.microsoft.com/technet/downloads/winsrvr/servicepacks/sp1/def ...

http://www.msexchangefaq.de/admin/servicepackwin.htm
<HR><font color="Brown">
  1. Nach dem ganzen geupdate und "hoffentlich" fehlerfreien System wird jetzt erstmal RPC eingerichtet! #
</font>
http://www.msisafaq.de/Anleitungen/2004/Firewallrichtlinien/RPCHTTPS.ht ...

http://www.msxfaq.de/clients/rpcinternet.htm
<font color="Brown">
RPC Service Installieren!

Setzt im IIS für den "Virtuellen Order" RPC - NUR die "Standart-Authentifizierung" !!!

Aktiviert "zwanghaftes" SSL 128 Bit !!!

!!! jetzt aber NICHT die vorgeschlagenen Reg. Einträge abändern, sondern nur überprüfen ob:
</font><font color="Green">
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy</font><font color="Brown"> mit dem "Lokalen" Exchange Server übereinstimmt!

genauso wie: </font><font color="Green">HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters</font><font color="Brown"> !!!

Dies dürfer aber Standartmäßig auf einem Windows 2003 SmallBusinessServer sowie Windows 2003 Server mit Exchange aufsatz, der als DomainController läuft der Fall sein!!!
</font>
--- WinServer neustart ---
<HR><font color="Brown">Apache konfiguriert Ihr wie folgt!
</font>
http://media.plominski.de/docs/Xampp-ReverseProxy-fuer-Exchange-OWA-09. ...
<font color="Brown">
PS: Mir ist aufgefallen das seit, Xampp 1.5.0 kein Upload von Datenanhängen im OutlookWebAccess mehr funktioniert!!!

Fügt noch folgende Einträge hinzu:
</font><font color="Green">
ProxyPass /rpc https://192.168.0.xxx/rpc/
ProxyPassReverse /rpc https:// 192.168.0.xxx/rpc/
CacheDisable *
</font>
--- Apache restart ---
<HR><font color="Brown">Outlook konfiguriert Ihr folgendermaßen!
</font>
http://www.msxfaq.de/clients/mobil.htm

http://www.msexchange.org/tutorials/Outlook_2003_Connect_Exchange_2003. ...
</font><font color="Brown">
Ganz wichtig an dieser Stelle wäre zu nennen, öffnet im IE die OWA (sofern erreichbar) Seite und importiert euch in euer System das gültige SSL "Apache" Cert, ebenso solltest ich auch per hand das gültige Exchange Cert importieren(direkt über die interne OWA Page(sofern einreichbar bzw. per VPN))!!!

--- Outlook in der Console mit "</font><font color="Green">Outlook /rpcdiag</font><font color="Brown">" starten ---
Als LoginNamen "</font><font color="Green">SubDomain.Domain\Name</font><font color="Brown">" verwenden!!!
Jetzt sollte der "erste" saubere HTTPS Connect statt finden !!!</font>
<HR></font><font color="Blue">Doch bevor ich dies jetzt als PDF Doc erstelle, muss noch ein Problem geklärt werden!!!
Die EreignisConsole Meldet:
</font><font color="Red">
RPc Proxy wurde im InternetInformationsDienste-Modus (IIS) ordnungsgemäß gestartet 6.0
</font><font color="Blue">
Nur wenn Outlook beendet und wieder neu gestaret wird, funktioniert der sync nicht mehr!!!
... Ob das nun mit einem vorgegebenen ConnectionTimeOut oder wie auch immer zu lösen ist, wäre noch zu klären! ...
</font>
Mit freundlichen Grüßen Daniel
Mitglied: Plominski
Plominski 14.12.2005 um 15:35:18 Uhr
Goto Top
Grüße

gib uns bitte mal einen Link, wir wären gerne daran interessiert

Mit freundlichen Grüßen Daniel
Mitglied: Plominski
Plominski 14.12.2005 um 16:34:50 Uhr
Goto Top
ALLES Funktioniert !!!

!!! Man muss nur Outlook 1-2 Minuten laufen lassen (sync.) und dann funktioniert es auch wieder nach einem erneuten Outlook start !!! ;)

Jetzt sollten wir nur noch Möglichkeiten finden, den Stream zu kontrollieren z.b mit rewrite usw ...

Mit freundlichen Grüßen Daniel!
Mitglied: Balubaer
Balubaer 15.12.2005 um 01:26:35 Uhr
Goto Top
Hi Daniel!

Ich gratuliere Dir, auch wenn ich noch immer verzweifle:

ich habe nochmals versucht, eine Verbindung herzustellen und erhalte aus dem Apache-Protokoll folgende Mitteilungen:

85.178.144.212 - - [15/Dec/2005:01:09:00 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?xchserver.intranet.local:593 HTTP/1.1" 503 - "-" "MSRPC"
85.178.144.212 - - [15/Dec/2005:01:09:00 +0100] "RPC_IN_DATA rpc/rpcproxy.dll?xchserver.intranet.local:593 HTTP/1.1" 104 615 "-" "MSRPC"

Wobei ich mich frage, für was der Port 593 angesprochen werden soll? Welcher Service steht denn dahinter?

Ich erhalte dann immer beim Verbindungsaufbau-Versuch die Meldung von Outlook, ob ich Offline, die Verbindung nochmals oder abbrechen möchte.

Wenn ich dann "abbrechen" drücke, erscheint dann noch folgende Apache-Meldung:

85.178.144.212 - - [15/Dec/2005:01:08:21 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?xchserver.intranet.local:6004 HTTP/1.1" 104 615 "-" "MSRPC"
85.178.144.212 - - [15/Dec/2005:01:08:21 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?xchserver.intranet.local:6004 HTTP/1.1" 200 128 "-" "MSRPC"

Ein/zwei Mal habe ich dann noch diese Zeilen nur mit Port 6002 erhalten! Ich steige so langsam nicht mehr durch!! Sollte ich vielleicht doch noch was an der Registry von Windows (zurück)verändern?

Gut's Nächtle,
Dennis

Nachtrag: Okay, der Port 593 ist für die DCOM-Kommunikation. Der Part ist also geklärt. Nur nicht, warum ich keine Connection zum Exchange-Server bekomme?
Mitglied: Plominski
Plominski 17.12.2005 um 22:31:09 Uhr
Goto Top
Mitglied: christianbln2k
christianbln2k 22.12.2005 um 12:38:33 Uhr
Goto Top
Hallo Leute,

ich habe mich zwar ziemlich genau an die Anleitung von Daniel gehalten
(an der Stelle mal ein großes Dankeschön!), aber leider funktioniert die
Verbindung noch nicht so ganz...

Wenn ich in der Outlook Konfiguration den Exchange Server eingebe funktioniert
die Verbindung per HTTP(S). Ist der Apache Proxy eingetragen versucht Outlook
eine SSL Verbindung zum Apache Server aufzubauen, schafft es aber nicht.

Im Apache Log habe ich dann folgende Einträge (FQDN natürlich abgewandelt):

192.168.10.47 - - [22/Dez/2005:12:07:29 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?exchange.xxx.net:593 HTTP/1.1" 104 600
192.168.10.47 - - [22/Dez/2005:12:07:29 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?exchange.xxx.net:593 HTTP/1.1" 503 -

Wofür steht der Statuscode "104"? Sollte da nicht eigentlich irgendetwas mit 3xx (redirect) stehen ?

Der Exchange 2003 läuft auf einem Windows 2003 Server alle SP´s und Fixe installiert.
Exchange läuft ebenfalls aktualisiert (SP2).

Der Server ist DC/GC.

Danke im vorraus für jeden Tip face-smile

Grüße
Christian
Mitglied: christianbln2k
christianbln2k 23.12.2005 um 13:45:35 Uhr
Goto Top
Hi,

also ich konnte das Problem lösen. face-smile

Es lag entweder daran dass ich XAMP 1.5 statt 1.42 verwendet habe oder
aber am SSL Zertifikat des Exchange-Servers.

Ein paar Probleme und Fragen habe ich aber noch.

Wenn ich mich per rpc over https mit dem Exchange verbinde funktioniert dass immer genau einmal. Ein ähnliches Verhalten hatte Daniel ja schon beschrieben. Bei mir funktioniert es aber erst wieder nachdem ich den IIS Dienst neu gestartet habe. Wird da irgendeine Session nicht richtig geschlossen?

Hat "CacheDisable *" als Parameter in der httpd.conf etwas damit zu tun? Wird er überhaupt benötigt?

Die andere Frage bezieht sich auf den Zugriff von extern. Brauche ich eine split-DNS Konfiguration um RPC over HTTPS zu betreiben wenn ich für meine AD Domäne intern den gleichen Namen verwende wie für die Internetdomain?

Wäre toll wenn jemand ein paar Tips hat.

Danke,Grüße und frohe Weihnachten!
Christian
Mitglied: christianbln2k
christianbln2k 28.12.2005 um 11:18:42 Uhr
Goto Top
Hallo Leute,

has jemand eine Möglichkeit gefunden um die nervige Eingabe des
Benutzernamens/Passworts zu vereinfachen?

Aus Sicherheitsgründen sollte das Passwort bei der Standardauthentifizierung
ja nicht lokal gespeichert werden, aber die Eingabe von "Domäne\Benutzername"
bei jedem Start von Outlook ist doch extrem nervig...

Viele Grüße und Danke im vorraus für jeden Tip
Christian
Mitglied: Plominski
Plominski 29.12.2005 um 19:42:25 Uhr
Goto Top
Grüße

also ich teste gerade Active-Sync über Reverse und habe ähnliche Phänomene entdeckt:

ERSTER / ZWEITER Sync geht, dann läuft "PocketPC ActiveSync" unendlich im Leerlauf ...

Das Problem betrifft eindeutig den IIS, da er wohl erst nach 1-2 Minuten eine "close" Session Message bekommt.
Im Falle des ActiveSync Transfers:

Apache Log:
<font color="RED"><font color="BLUE">(EXTERNE IP)</font> - - [29/Dec/2005:19:28:38 +0100] "POST /Microsoft-Server-ActiveSync?User=<font color="BLUE">Plominski</font>&DeviceId=<font color="BLUE">XXX</font>&DeviceType=PocketPC&Cmd=GetItemEstimate HTTP/1.1" 200 340</font>

Bei dem allerersten Sync, entstehen mehrere Einträge, erst nach ca. 30sec-1min folgt dann "<font color="RED">GetItemEstimate HTTP/1.1" 200 340</font>" genau ähnlich verhält es sich mit Outlook2003.

Ein funktionierender Betrieb sollte damit gelöst werden, indem Outlook beim "starten" einmal synct -> und dann im Intervall aller 5 min ...

Was die nervige Login Prozedur anbelangt: "<font color="RED">NTLM Auth</font>" scheint nicht zu funktionieren, auch wenn der Client ein Domäne-Mitglied ist ... ??? ...

Mit freundlichen Grüßen
Mitglied: christianbln2k
christianbln2k 30.12.2005 um 09:49:06 Uhr
Goto Top
Hi Daniel,
Hallo an alle anderen!

NTLM funktioniert leider nicht ohne weiteres über "unsere" Konfiguration.
Es gibt für den Apachen ein NTLM over HTTP Modul [1] mit dem es funktionieren könnte.

Auf eventuelle Sicherheitsprobleme bei der Verwendung von NTLM macht diese [2]
Seite aufmerksam.

Ein Technologieberater von MS hat mir gestern gesagt, dass der Dialog der Standardauthentifizierung definitiv kein Speichern der Daten vorsieht, aber
irgendeinen "work-around" muss es doch geben ?!?!

Kennt jemand ein Freeware-Tool um solche Dialoge automatisch auszufüllen?
Mit RoboForm 6.6 soll es gehen (halbautomatisch), aber das ist keine Freeware
und halbautomatisch ist für unsere User auch schon zuviel Arbeit face-wink

btw:
Ich möchte noch anregen die Ausführung von "/opt/lampp/lampp security" in
deine Anleitung aufzunehmen.

Beste Grüße
Christian


[1] http://modntlm.jamiekerwick.co.uk/
[2] http://www.securiteam.com/securityreviews/5OP0B2KGAC.html
Mitglied: Plominski
Plominski 30.12.2005 um 11:21:05 Uhr
Goto Top
Grüße

also mit "<font color="RED">unofficial</font>" Modulen wollte ich gar nicht erst anfangen...

Da sollen sich lieber die User -> 1-2mal mit der Auth. quälen als, "SecuriTeam" zufolge, weitere Angriffslöcher zu öffnen...

Habe mir "heute" in der früh mal die "<font color="RED">Apache Current Change(s) Log</font>" angeschaut, und wurde wieder "nüchtern" eines besseren belehrt, das auch der Indianer (heute noch) etliche "Security Bugs" aufweist ...

Habe bis heute morgen, 2-3 Verschiedene <font color="RED">Nessus</font> scans laufen lassen, obwohl die Resultate eine "Sichere Apache Conf" suggerierten, werde ich dennoch dann weitere "Schritte" hier beschreiben, die das ganze auch mit den zukünftigen Xampp (Apache 2.2.x) usw. Versionen funktionierend beschreiben werden...

z.B. Ab <font color="RED">Apache 2.1.xx</font> werden auch diverse <font color="RED">Mängel</font>: z.B. <font color="RED">MOD_Proxy</font> "<font color="BLUE">%</font>" Log Anzeigen <font color="RED">behoben</font>...

Was das Ausführen von "<font color="RED">lampp security</font>" angeht sehe ich den Xampp als <font color="BLUE">sicherer einzustufen wenn</font> er nach "Außen" als <font color="BLUE">"leerer" Apache Server vorgegaukelt wird</font>" z.B. mit der Standart Apache "<font color="RED">Test Page</font>", "<font color="RED">ServerTokens Prod</font>" usw?" als <font color="RED">irgendwelche .htaccess</font> mit der DICKEN <font color="RED">Überschrift "Lampp Access" zu aktivieren</font>...

Was die Passwortvergabe für FTPd/MySQL sowie (MySQL auf Localhost Ebene zu beschränken) angeht, reicht ein "<font color="RED">lampp startssl</font>" für <font color="RED">reinen Apache SSL Dienst</font> ...

PS: das löschen von "<font color="RED">rm -r /opt/lampp/phpmyadmin/*</font>" "<font color="RED">rm -r /opt/lampp/cgi-bin/*</font>" sowie "<font color="RED">rm -r /opt/lampp/icons/*</font>" schadet auch nicht ;)

Mit freundlichen Grüßen
Mitglied: Plominski
Plominski 31.12.2005 um 02:32:23 Uhr
Goto Top
Übrigens scheint die Option - den RPC transfer noch stabiler zu machen:

"<font color="BLUE">Hauptname des Proxyservers:</font>"
<font color="RED">msstd:</font><font color="GREEN">... ... ...</font>

Frohes Fest!
Mitglied: christianbln2k
christianbln2k 02.01.2006 um 15:59:23 Uhr
Goto Top
Konfiguriert man den IIS für die Verwendung von UPN Login-Namen
können die Anwender Ihre E-Mail Adresse als Benutzernamen verwenden.
Aus dem Benutzernamen domain.local\user01 wird so user01@domain.local
Für manche ist das eventuell leichter zu merken/schneller zu tippen.

Um den IIS entsrechend zu konfigurieren:

1.
In den Eigenschaften der Standardwebseite (bzw. Exchange,RPC) unter der
Registerkarte "Verzeichnissicherheit", bei Authentifizierung und Zugriffssteuerung auf
Bearbeiten klicken.

2.
Sowohl bei der "Standarddomäne" als auch unter "Bereich" einen Backslah "\" eintragen.

3.
Wie oben beschrieben kann für die Authentifizierung am OWA und für RPC over HTTP
als Benutzername nun die E-Mail Adresse verwendet werden.

ABER:

Irgendeine Möglichkeit muss es doch geben Benutzernamen und Passwort automatisch
eintragen zu können. Hat schon jemand eine Lösung parat? Mich macht das ganz verrückt.

Viele Grüße
Christian
Mitglied: Plominski
Plominski 03.01.2006 um 05:12:51 Uhr
Goto Top
Grüße

mal jetzt aber eine ganz "komische" andere Sache...

Ich habe bei einem Kunden Outlook2003 SP2 für RPC over HTTPS einrichten wollen.
Doch wenn er bei der Ersteinrichtung, nicht den Namen auflösen kann, bietet er auch keine RPC over HTTPS Funktion an ?

Das mit dem "BackupSlash" werd ich mal testen ...

Mit freundlichen Grüßen
Mitglied: Plominski
Plominski 03.01.2006 um 06:01:17 Uhr
Goto Top
Gut

einfach wie bei folgendem ServiceDienstLeister vorgehen:

http://www.synserver.de/support/faq.php?Q591

Mit freundlichen Grüßen
Mitglied: christianbln2k
christianbln2k 03.01.2006 um 09:23:10 Uhr
Goto Top
Hallo,

wenn Outlook das RPC Feature nicht "erlaubt" einfach unter

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Outlook\RPC

einen DWORD mit dem Namen: EnableRPCTunnelingUI
und dem Wert : 1

eintragen.

1= RPC over HTTP anzeigen
0= nicht anzeigen

Grüße
Christian
Mitglied: christianbln2k
christianbln2k 03.01.2006 um 09:25:31 Uhr
Goto Top
Hallo,

"Gut einfach wie bei folgendem ServiceDienstLeister vorgehen:
http://www.synserver.de/support/faq.php?Q591;

War das auf dein Outlook Problem oder das mit der nevigen Anmeldung bezogen?

Grüße
Christian
Mitglied: Plominski
Plominski 12.01.2006 um 03:03:26 Uhr
Goto Top
Grüße

Danke für den Tip, hatte das ganze mal unter Windows 2000 versucht ...

... läuft wohl erst ab Win XP SP1 ...

Mit freundlichen Grüßen
Mitglied: schneidwui
schneidwui 20.01.2006 um 15:37:15 Uhr
Goto Top
Hallo,

ich habe OWA und OMA zum Laufen bekommen, aber bei RPC over HTTPS hakts noch

was ich am meisten verwundert und was ich auch für die Ursache halte, ist diese Fehlermeldung in den Apache-Logfiles

[Fri Jan 20 14:26:46 2006] [warn] proxy: No protocol handler was valid for the URL rpc/rpcproxy.dll. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

[Fri Jan 20 14:27:14 2006] [warn] proxy: No protocol handler was valid for the URL /rpc. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

...diese Fehler treten auf, wenn ich "manuell" von außen (extern) das Verzeichnis https://mysite/rpc oder https://mysite/rpc/rpcproxy.dll aufrufe.

Verhält sich Outlook da anders? oder stößt es dort auf die selben Fehler?

ich habe noch keine Verbindung über RPC zu Stande bekommen, kriege aber die "Benutzerauthentifizierung" und das einloggen funktioniert auch.. nur wird unter "Verbindungsstatus" immer nur probiert eine Verbindung herzustellen, ohne Erfolg.

Wisst ihr noch einen Rat?

Achso was hat es mit den Ports 6001-6004 auf sich also ich habe sie so eingerichtet

NETBIOS-Name des Servers:6001-6002;FQDN des Servers:6001-6002;NETBIOS-Name des Servers:6004;FQDN des Servers:6004

mit freundlichen Grüßen

schneidwui
Mitglied: schneidwui
schneidwui 21.01.2006 um 12:57:44 Uhr
Goto Top
Ok.. also ich hab noch mal ein bisschen recherchiert...

also das Problem tritt auch beim Verbindungsaufbau von Outlook auf.. die selben Fehlermeldungen in den Apache Logfiles.

hier noch ein paar Infos...

es ist ein Apache 2.0.55 der unter Debian läuft .. nicht selbst kompiliert sondern .deb Files über apt-get installiert.

Im Ordner /etc/apache2/mods-enabled habe ich folgende Module über symbolic links geladen...

cgi.load
expires.load
headers.load
mime_magic.conf
mime_magic.load
php4.conf
php4.load
proxy.load ---> (ladet proxy_http automatisch mit)
proxy_connect.load
proxy_ftp.load
proxy_html.load
rewrite.load
ssl.conf
ssl.load
unique_id.load
userdir.conf
userdir.load

wenn ich apache2 -l aufrufe zeigt er folgende Module als "hardcoded"

Compiled in modules:
core.c
mod_access.c
mod_auth.c
mod_log_config.c
mod_logio.c
mod_env.c
mod_setenvif.c
prefork.c
http_core.c
mod_mime.c
mod_status.c
mod_autoindex.c
mod_negotiation.c
mod_dir.c
mod_alias.c
mod_so.c

die apache2.conf habe ich nicht verändert..

hier meine httpd.conf


Servername owa.myserver.de

ServerTokens Full

User xxxxxxx
Group xxxxxxxx

Options -Indexes FollowSymLinks ExecCGI Includes

SSLPassPhraseDialog exec:/etc/apache2/PassPhrase.sh

NameVirtualHost xxx.xxx.xxx.xxx:443

<VirtualHost owa.myserver.de:443>
    1. Outlook Web Access
    ServerAdmin webmas...@myserver.de
    DocumentRoot /data/www-data/owa
    Servername owa.myserver.de

    AddDefaultCharset Off
    #AddDefaultCharset UTF-8

    RequestHeader unset accept-encoding

    HostnameLookups Off
    UseCanonicalName Off

    ProxyPreserveHost On

    ProxyRequests Off

    <Proxy *>
    Order deny,allow
    Allow from all
    </Proxy>

    SSLProxyEngine On
    SSLProtocol All
    SSLEngine On

    ProxyPass /exchange https://iis.myserver.de/exchange/
    ProxyPassReverse /exchange http://iis.myserver.de/exchange/

    ProxyPass /exchweb https://iis.myserver.de/exchweb/
    ProxyPassReverse /exchweb http://iis.myserver.de/exchweb/

    ProxyPass /exchweb/bin/auth https://iis.myserver.de/exchweb/bin/auth/
    ProxyPassReverse /exchweb/bin/auth
    http://iis.myserver.de/exchweb/bin/auth/

    ProxyPass /public https://iis.myserver.de/public/
    ProxyPassReverse /public http://iis.myserver.de/public/

    ProxyPass /Microsoft-Server-ActiveSync
    https://iis.myserver.de/Microsoft-Server-ActiveSync/
    ProxyPassReverse /Microsoft-Server-ActiveSync
    https://iis.myserver.de/Microsoft-Server-ActiveSync/

    ProxyPass /rpc /https://iis.myserver.de/rpc/
    ProxyPassReverse /rpc /https://iis.myserver.de/rpc/

    CacheDisable *

    ErrorLog /var/log/apache2/owa_ssl_error_log
    TransferLog /var/log/apache2/owa_ssl_access_log

    SSLCertificateFile /etc/apache2/ssl/owa_cert.pem
    SSLCertificateKeyFile /etc/apache2/ssl/owa_pub-sec-key.pem
    SSLCACertificateFile /etc/apache2/ssl/ca_cert.pem

    #Redirect permanent / https://owa.myserver.de/exchange

    </VirtualHost>

    <VirtualHost oma.myserver.de:443>
      1. Outlook Mobile Access
      ServerAdmin webmas...@myserver.de
      DocumentRoot /data/www-data/oma
      Servername oma.myserver.de

      AddDefaultCharset Off
      RequestHeader unset accept-encoding
      HostnameLookups Off
      UseCanonicalName Off
      ProxyPreserveHost On
      ProxyRequests Off

      <Proxy *>
      Order deny,allow
      Allow from all
      </Proxy>

      SSLProxyEngine On
      SSLProtocol All
      SSLEngine On

      ProxyPass /oma https://iis.myserver.de/oma/
      ProxyPassReverse /oma https://iis.myserver.de/oma/

      ErrorLog /var/log/apache2/oma_ssl_error_log
      TransferLog /var/log/apache2/oma_ssl_access_log

      SSLCertificateFile /etc/apache2/ssl/oma_cert.pem
      SSLCertificateKeyFile /etc/apache2/ssl/oma_pub-sec-key.pem
      SSLCACertificateFile /etc/apache2/ssl/ca_cert.pem

      </VirtualHost>



      Vielleicht kann mir da jemand bei helfen...

      Mit freundlichen Grüßen

      schneidwui
Mitglied: Plominski
Plominski 05.02.2006 um 15:38:23 Uhr
Goto Top
Grüße

HTTP Keep Alive muss auf dem IIS aktiv "bleiben" da sonst kein direkter "ActiveSync" mit einem PocketPC mehr funktioniert!

... ansonsten wenn in der IIS "Standartwebsite" Umgebung der TimeOut auf 60 Sekunden gesetzt wurde ->
... im Apache der TimeOut auf 120 Sekunden und dort JETZT noch im ?Standart? sowie ?VirtualHost? Verzeichnis - "KeepAlive Off" gesetzt wurde ->

Funktioniert die Microsoft ActiveSync über (Apache Reverse) zuverlässiger, und die Outlook RPC Verbindung stabiler!!!

Mit freundlichen Grüßen
Mitglied: Plominski
Plominski 05.02.2006 um 15:39:46 Uhr
Goto Top
Grüße

HTTP Keep Alive muss auf dem IIS aktiv "bleiben" da sonst kein direkter "ActiveSync" mit einem PocketPC mehr funktioniert!

... ansonsten wenn in der IIS "Standartwebsite" Umgebung der TimeOut auf 60 Sekunden gesetzt wurde ->
... im Apache der TimeOut auf 120 Sekunden und dort JETZT noch im ?Standart? sowie ?VirtualHost? Verzeichnis - "KeepAlive Off" gesetzt wurde ->

Funktioniert die Microsoft ActiveSync über (Apache Reverse) zuverlässiger, und die Outlook RPC Verbindung stabiler!!!

Mit freundlichen Grüßen
Mitglied: christianbln2k
christianbln2k 19.02.2006 um 21:49:35 Uhr
Goto Top
Hallo,

meine RPC over HTTPS Knfiguration läuft jetzt schon eine Weile ganz gut,
jetzt bin ich aber auf ein ernsthaftes Problem gestoßen. Vielleicht kann mir ja
jemand weiterhelfen.

Active Sync benötigt die Windows integrierte Authentifizierung auf dem
virtuellen Exchange Verzeichnis. Leider muss aber damit der OWA Zugang
funktioniert die Basic Auth. aktiviert sein. Aktiviere ich beides zusammen
funktioniert der OWA nicht.

Kann das hier
http://www.petri.co.il/problems_with_forms_based_authentication_and_ssl ...

eventuell weiterhelfen ?

Hat jemand eine Idee?

Vielen Dank

Christian


Hat sich erledigt, der von mir gepostete Link hat das Problem gelöst...
Wenn noch jemand das gleiche Problem hat....

Grüße
Christian
Mitglied: Balubaer
Balubaer 08.03.2006 um 14:57:27 Uhr
Goto Top
Hallo!

Und da melde ich mich mal wieder zu Wort. Ich bin mal wieder dabei, dem Problem auf die Spur zu kommen, warum das bei uns noch immer nicht funktioniert.

Ich denke mal, es hat mit den Zertifikaten zu tun, bin mir aber nicht wirklich sicher.

Anleitungen, an die man sich halten kann, gibt es ja zu genüge und somit schließe ich die eigentliche Konfiguration (Apache/IIS) mal aus, zumal bis dahin auch alles so klappte, wie beschrieben wurde (dazu besonderen Dank nochmals an Daniel).

Zu den Zertifikaten: wir haben ein offizielles, gekauftes Zertifikat, welches beim Apache installiert ist, und ein eigens erstelltes Zertifikat für den Exchange-Server (da dessen Name nicht zum gekauften Zertifikat passt; schließlich ist unsere interne Domäne nicht gleich der externen Internet Domäne).

Wenn ich mich nun von extern über Outlook versuche zu verbinden (Outlook /rpcdiag) versucht er kurz, eine Verbindung herzustellen und kurz darauf erhalte ich die Meldung, dass der Server nicht zur Verfügung steht (Optionen: Erneut verbinden, Offline arbeiten oder Abbrechen).

Wenn ich dazu mir die Logs vom Apache und IIS ansehe, bin ich ein wenig verblüfft (Domain-Namen wurden natürlich verändert):

IIS:
2006-03-08 10:07:30 W3SVC1 192.168.12.243 RPC_IN_DATA /rpc/rpcproxy.dll internet.domain.name:6002 443 windowsdomain.xoz\dgalander 192.168.12.5 MSRPC 200 0 0
2006-03-08 10:07:30 W3SVC1 192.168.12.243 RPC_OUT_DATA /rpc/rpcproxy.dll internet.domain.name:6002 443 windowsdomain.xoz\dgalander 192.168.12.5 MSRPC 200 0 0
2006-03-08 10:07:30 W3SVC1 192.168.12.243 RPC_IN_DATA /rpc/rpcproxy.dll internet.domain.name:593 443 windowsdomain.xoz\dgalander 192.168.12.5 MSRPC 200 0 0
2006-03-08 10:07:30 W3SVC1 192.168.12.243 RPC_OUT_DATA /rpc/rpcproxy.dll internet.domain.name:593 443 windowsdomain.xoz\dgalander 192.168.12.5 MSRPC 200 0 0
2006-03-08 10:07:32 W3SVC1 192.168.12.243 RPC_IN_DATA /rpc/rpcproxy.dll internet.domain.name:6004 443 windowsdomain.xoz\dgalander 192.168.12.5 MSRPC 200 0 0
2006-03-08 10:07:32 W3SVC1 192.168.12.243 RPC_OUT_DATA /rpc/rpcproxy.dll internet.domain.name:6004 443 windowsdomain.xoz\dgalander 192.168.12.5 MSRPC 200 0 0
2006-03-08 10:07:32 W3SVC1 192.168.12.243 RPC_IN_DATA /rpc/rpcproxy.dll internet.domain.name:593 443 windowsdomain.xoz\dgalander 192.168.12.5 MSRPC 200 0 0
2006-03-08 10:07:32 W3SVC1 192.168.12.243 RPC_OUT_DATA /rpc/rpcproxy.dll internet.domain.name:593 443 windowsdomain.xoz\dgalander 192.168.12.5 MSRPC 200 0 0

Apache:
85.178.188.177 - - [08/Mar/2006:11:07:29 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?internet.domain.name:6002 HTTP/1.1" 503 -
85.178.188.177 - - [08/Mar/2006:11:07:29 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?internet.domain.name:6002 HTTP/1.1" 104 615
85.178.188.177 - - [08/Mar/2006:11:07:30 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?internet.domain.name:593 HTTP/1.1" 503 -
85.178.188.177 - - [08/Mar/2006:11:07:29 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?internet.domain.name:593 HTTP/1.1" 104 615
85.178.188.177 - - [08/Mar/2006:11:07:31 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?internet.domain.name:6004 HTTP/1.1" 503 -
85.178.188.177 - - [08/Mar/2006:11:07:31 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?internet.domain.name:6004 HTTP/1.1" 104 615
85.178.188.177 - - [08/Mar/2006:11:07:32 +0100] "RPC_OUT_DATA /rpc/rpcproxy.dll?internet.domain.name:593 HTTP/1.1" 503 -
85.178.188.177 - - [08/Mar/2006:11:07:31 +0100] "RPC_IN_DATA /rpc/rpcproxy.dll?internet.domain.name:593 HTTP/1.1" 104 615

Während der IIS behauptet, die Verbindung geht ok, erhält der Apache die Meldung, daß der Service nicht zur Verfügung steht....

Und da gehen bei mir die Lichter aus und ich stehe ratlos vor dem Problem, was ich noch tun könnte, um ENDLICH RPC-over-HTTP zu ermöglichen. Ist vielleicht die Zertifikats-Kombination ein Problem? Woher kommen die unterschiedlichen "Aussagen" der beiden Webserver?

Weiß Jemand vielleicht Rat?

Gruß
Dennis
Mitglied: schneidwui
schneidwui 20.03.2006 um 14:29:32 Uhr
Goto Top
Hallo Dennis (Balubaer),

hast du das Problem inzwischen schon behoben?

ich habe nämlich das gleiche oder zumindest ein ähnliches Problem, und vermute auch das es an den Zertifikaten liegt..

Grüße
Rene
Mitglied: Balubaer
Balubaer 20.03.2006 um 14:46:16 Uhr
Goto Top
Hi Rene,

nee, leider noch immer nicht. Ich kann mich immer nur partiell darum kümmern und komme halt nicht so recht voran.

Da es aber intern bei uns via RPC-over-HTTP funktioniert würde ich es tatsächlich mit dem Zertifikat erklären wollen. Nur eine Lösung habe ich dazu nicht... face-sad

Gruß
Dennis
Mitglied: minibit
minibit 23.08.2006 um 16:13:35 Uhr
Goto Top
Hallo

Nun versuche ich schon seit längerem nach dem HowTow von D.Plominski eine Verbindung von OL auf den Internen Exchange Server über RPC over HTTPS zu realisieren. Leider bis jetzt ohne erfolg, der zugriff auf OWA funktioniert jedoch einwandfrei.


Meine Konfiguration:

Internet -> Firewall 1 -> DMZ (RProxy) -> Firewall 2 -> Exchange

IP Konfiguration
DMZ Proxy 212.xxx.xxx.3
Firewall 2 212.xxx.xxx.4
Exchange 192.xxx.xxx.20

- Apache ProxPass zeigt auf IP 212.xxx.xxx.4 der Firewall 2
- Die Firewall 2 Forwardet den Port 443 zum Exchange Server


Der Zugriff von Outlook auf den Exchange Server per RPC over HTTPS im INTERNEN Netzwerk funktioniert.
Habe ich nun aber Outlook auf einem Externen Client oder sogar auf dem RProxy Outlook (zum testen) Installiert und Konfiguriert funktioniert der Zugriff RPC over HTTPS nicht.

Alle Test die im HowTow von D. Plominski beschrieben sind funktionieren, aber es kommt leider immer noch nicht zu einer Verbindung.
Einzig die Seite 38 der Anleitung verstehe ich nicht ganz denn die beschriebenen Einträge im Hosts befinden sich ja alle im gleichen Netz was mir Irgendwie nicht einleuchten will, vielleicht kann mir ja hier jemand Nachhilfe geben.

Hosts der Anleitung

172.16.0.1 webserver.privat.local
172.16.0.2 server.privat.local
172.16.0.254 firewall.privat.local

mfg
Adrian
Mitglied: minibit
minibit 23.08.2006 um 16:54:49 Uhr
Goto Top
Und weiter gehts

Ich konnte nun das Outlook auf dem RProxy welcher in der DMZ steht zum laufen bringen.


Mein Hosts Eintrag
212.xxx.xxx.4 server1 #Exchange Server im Internen Netzwerk

Im Outlook habe ich den Exchange Server auf "server1" und den HTTPS Server auf 212.xxx.xxx.4 (Firewall 2) gestellt.

Leider Funktioneirt der zugriff von einem Externen OL über den Reverse Proxy immer nocht nicht.
Mitglied: Plominski
Plominski 23.08.2006 um 18:37:18 Uhr
Goto Top
Also wenn ich das richtig verstanden habe:

INTERNET -> Port 443 SSL -> Firewall Extern (RED IP) SSL 443 Port Route to DMZ -> Apache Reverse Proxy (SSL Externen Zertifikat) (212.xxx.xxx.3) -> [Reverse zum Firewall2] -> Firewall2 INTERN (INTERN IP) (212.xxx.xxx.4) SSL 443 Port Route to Exchange -> Exchange SSL Port 443 (Exchange Cert.) (192.xxx.xxx.20) <->

Also der Externe Client landet nach dem SSL Zugriff über die Firewall1 direkt auf dem DMZ stehenden Apache, der durch Firewall2 route die Pakete vom Exchange reversed? right? ...

soviel zur Theorie ...

--- Zuerst muss sichergestellt werden, das das RProxy Zertifikat sauber auf dem Client implementiert wurde (das Exchange INTERNE Cert. spielt dabei keine Rolle) ...

--- Zweiten wird Outlook SP2 sowie Exchange SP2 vorrausgesetzt!

--- Drittens darf keine Firewallregel bzw. IP Adressraumbeschränkungsregel auf dem Exchange oder im IIS konfiguriert sein!

--- Viertens müssen alle HOST Einträge ab der "lokalen" Zone jeweils in den Servern eingerichtet werden....

[Die in der HowTo beschriebenen Beispiele waren anhand eines VMware virtualisierten Netztes entstanden]

somit auf ALLEN Servern sollte die hosts wie folgt aussehen:

GREEN IP firewall1.firma.local firewall1
212.xxx.xxx.3 reverse.firma.local reverse
212.xxx.xxx.4 firewall2.firma.local firewall2
192.xxx.xxx.20 exchange.firma.local exchange

sofern der Firewall2 NAT zulässt -> sollte ein Ping von dem Exchange an Firewall2, sowie dem Reverse als auch Firewall1 möglich sein!

MFG
Mitglied: minibit
minibit 23.08.2006 um 19:01:41 Uhr
Goto Top
Hallo Daniel

1. Vielen dank für deine bemühungen

Also wenn ich das richtig verstanden habe:

INTERNET -> Port 443 SSL -> Firewall
Extern (RED IP) SSL 443 Port Route to DMZ
-> Apache Reverse Proxy (SSL Externen
Zertifikat) (212.xxx.xxx.3) -> [Reverse
zum Firewall2] -> Firewall2 INTERN (INTERN
IP) (212.xxx.xxx.4) SSL 443 Port Route to
Exchange -> Exchange SSL Port 443
(Exchange Cert.) (192.xxx.xxx.20) <->

Also der Externe Client landet nach dem SSL
Zugriff über die Firewall1 direkt auf
dem DMZ stehenden Apache, der durch Firewall2
route die Pakete vom Exchange reversed?
right? ...

RICHTIG


soviel zur Theorie ...

--- Zuerst muss sichergestellt werden, das
das RProxy Zertifikat sauber auf dem Client
implementiert wurde (das Exchange INTERNE
Cert. spielt dabei keine Rolle) ...

Zertifikat des RProxy ist auf dem Client Installiert


--- Zweiten wird Outlook SP2 sowie Exchange
SP2 vorrausgesetzt!

Exchange ist nocht SP2 muss ich wohl nachholen face-smile


--- Drittens darf keine Firewallregel bzw.
IP Adressraumbeschränkungsregel auf dem
Exchange oder im IIS konfiguriert sein!

? Kenne ich nicht! Kannst du mir sagen wo so was stehen sollte?

--- Viertens müssen alle HOST
Einträge ab der "lokalen" Zone
jeweils in den Servern eingerichtet
werden....

[Die in der HowTo beschriebenen Beispiele
waren anhand eines VMware virtualisierten
Netztes entstanden]

somit auf ALLEN Servern sollte die hosts wie
folgt aussehen:

GREEN IP
firewall1.firma.local firewall1
212.xxx.xxx.3 reverse.firma.local
reverse
212.xxx.xxx.4 firewall2.firma.local
firewall2
192.xxx.xxx.20 exchange.firma.local
exchange

Werde ich so machen (auf dem Exchange und RProxy ?)


sofern der Firewall2 NAT zulässt ->
sollte ein Ping von dem Exchange an
Firewall2, sowie dem Reverse als auch
Firewall1 möglich sein!

Ja NAT ist ON




Seit heute erhalte ich folgende Meldung auf dem Indianer:
[Wed Aug 23 18:40:00 2006] [error] (OS 10054)Eine vorhandene Verbindung wurde vom Remotehost geschlossen. : proxy: prefetch request body failed to 212.xxx.xxx.4:443 (server1) from 84.73.178.2 ()

Hilft das eventuel etwas ?

Also werde ich jetzt die Host Einträge machen und den Exchange auf SP2 Updaten.

PS. Gehe ich richtig in der Anname das RedIP für Internet INET und Green IP für INTERN steht?

Gruss und Danke
Adrian
Mitglied: Plominski
Plominski 23.08.2006 um 20:18:08 Uhr
Goto Top
Grüße

GENAU!

Die IIS Settings findest du in der IIS Konfiguration in den "Standart" Website Instanz Eigenschaften ...

befolge auch folgende Anleitung http://media.plominski.de/docs/Xampp-ReverseProxy-fuer-Exchange-RPCover ... besonders was Exchange angeht ...

Meine empfohlene Vorgehensweise ...

1. Client an 192.xxx Netz und Outlook direkt mit RPC over HTTPS auf Exchange ausprobieren (hier ist das genaue Implementieren des Exchange INTERNEN Zertifikates auf dem Client wichtig, und die in der HowTo beschriebenen "Fehler" Ausgaben wenn man direkt mit dem IE Zugreift, müssen erfolgen) !!!

2. - dannach Exchange Zertifikat auf die Adresse der Firewall2 mappen, neu einrichten, auf dem Client neu einfügen und über die Firewall2 probieren (wahlweise mal in den Outlook RPC over HTTPS Settings unter "Hauptname des Proxyservers: msstd:firewall2.firma.local" eingeben!

WENN DAS GEHT!

3. Client ins DMZ hängen, Zertifikat vom Apache installieren ... RPC over HTTPS Proxy Adresse auf "apache.firma.local" setzten ... und Apache logs abwarten!!!

Und falls dies wieder gehen sollte! dann mal vom RED (Externen) Interface aus ...

MFG
Mitglied: minibit
minibit 24.08.2006 um 23:22:43 Uhr
Goto Top
Hallo Daniel

Also das SP2 des Exchange ist jetzt drauf.

Wenn ich vom Externen Client versuche eine Verbindung aufzubauen funktioniert dies nicht. (OWA Funktioniert Einwandfrei)

Konfiguration Outlook auf dem Externen Client:
Exchange Server: SBS2003.mydomain.local # 192.xxx.xxx.20
HTTPS Server: proxy.mydomain.com # Öffentliche ip 212.xxx.xxx.3 des Proxy's

Apache Logs:
Im SSL Error Log steht:
[Thu Aug 24 22:58:20 2006] [error] (OS 10054)Eine vorhandene Verbindung wurde vom Remotehost geschlossen. : proxy: prefetch request body failed to 212.xxx.xxx.4:443 (SBS2003) from 84.73.178.2 ()

Im SSL Access Log steht:
84.73.178.2 - - [24/Aug/2006:22:55:09 +0200] "RPC_IN_DATA /rpc/rpcproxy.dll?SBS2003.mydomain.local:6002 HTTP/1.1" 730054 537
84.73.178.2 - - [24/Aug/2006:22:55:09 +0200] "RPC_OUT_DATA /rpc/rpcproxy.dll?SBS2003.mydomain.local:6002 HTTP/1.1" 200 68

Wie ich festgestellthabe lautet mein Zertifikat auf dem Exchange Server auf SBS2003 und nicht wie ich angenommen habe auf SBS2003.mydomain.local könnte das der Fehler sein dass ich ein neues Zertifikat auf dem Exchange Installieren muss?

Wenn ich eine Konfiguration von Outlook auf dem Proxy in der DMZ mache geht es wenn die Konfiguration von Outlook wie folgt ist. (Der Proxy wird also ausgelassen!)
Exchange Server: SBS2003 # Hosteintrag auf 212.xxx.xxx.4 (Firewall 2)
HTTPS Server: SBS2003

Im Apachen zeigt der ProxyPass auf https://SBS2003/rpc/ wie auch der ProxyPassReverse, dabei ist SBS2003 wieder der Hosts Eintrag auf 212.xxx.xxx.4 (Firewall 2)
Stimmt die Apachen Konfiguration so?

Hast du noch eine Idee

PS. Wie ich noch gesehen habe gibt es auf dem Exchange Sever eine Einstellung RPC over HTTP (Aus, Backend, Frontden) das hat nichts mit dem Problem zu tun oder ?

Grüsse
Adrian
Mitglied: Plominski
Plominski 25.08.2006 um 00:37:50 Uhr
Goto Top
Also der RPC over HTTPS funktioniertiert in der DMZ Umgebung über den Apache Reverse ?

naja dann also einfach ein neues zertifikat für den Apache erstellen (firewall1 Externer Name) und in der Outlook Config in der ersten spalte https://firewall1.firma.extern eingeben ... HAUPTSERVER eintrag frei_lassen, 2x Häckchen setzten und unten "Standart" Auth auswählen ...

dann sollte es doch auch über die Firewall1 gehen ... oder ?

MFG
PS: welche Apache Version benutzt du ?
Mitglied: minibit
minibit 25.08.2006 um 12:06:40 Uhr
Goto Top
Also der RPC over HTTPS funktioniertiert in
der DMZ Umgebung über den Apache Reverse
?

NEIN
- Outlook ich auf dem Proxy Server Installiert.
- Wenn ich NICHT über den Apache Reverse gehe funktioniert es.
Wenn ich versuche über den Apachen Reverse zu gehen funktioniert es nicht.

PS: welche Apache Version benutzt du ?
Version 2.2.3

Ich glaube du hast mich nicht richtig verstanden, über den Reverse Proxy krieg ich keine verbindung hin.

Frage kann ich auch mal ohne SSL einen Versuch machen damit ich sicher sein kann dass der Reverse Proxy richtig Funktioniert? Oder geht das dann gar nicht?

mfg
Adrian
Mitglied: Plominski
Plominski 25.08.2006 um 13:43:20 Uhr
Goto Top
Grüße

als erstes solltest du wirklich einen separaten XP SP2 Client mit Outlook SP2 ins DMZ hängen ...

verstehe ich das richtig, das Outlook auf dem Apache Proxy läuft ? handelt es sich dann um ein Windows System ???

zweitens ... versuch es mal mit Xampp 1.4.13/14/xx nicht mit dem Apache 2.2.xxx

drittens geht es vom Prinzip her, aber das würde zuviele Änderen um IIS vorraussetzen ...

MFG
erholsames Wochenende ....
Mitglied: minibit
minibit 25.08.2006 um 15:05:16 Uhr
Goto Top
Hallo...

Grüße

als erstes solltest du wirklich einen
separaten XP SP2 Client mit Outlook SP2 ins
DMZ hängen ...

Kann ich (meines wissens) nicht da wir Öffentliche IP's in der DMZ verwenden. Und ich keine IP mehr frei habe.

verstehe ich das richtig, das Outlook auf
dem Apache Proxy läuft ? handelt es sich
dann um ein Windows System ???

Richtig Win2003

zweitens ... versuch es mal mit Xampp
1.4.13/14/xx nicht mit dem Apache
2.2.xxx
Mach ich

drittens geht es vom Prinzip her, aber das
würde zuviele Änderen um IIS
vorraussetzen ...
OK habe nur gedacht mann könnte dann mal die Fehlerquelle SSL ausschalten

MFG
erholsames Wochenende ....
dir auch danke
Mitglied: Plominski
Plominski 26.08.2006 um 08:59:34 Uhr
Goto Top
Grüße

Warum muss unbedingt ein Windows Server als "Proxy" Server laufen ?

ansonsten setzte halt unter einer vmware ein Linux auf (z.b ipcop.org) und pak dort den Apache Reverse hinein ...

MFG
Mitglied: minibit
minibit 26.08.2006 um 13:26:38 Uhr
Goto Top
Hallo Daniel

Kenne micht zuwenig mit Linux aus. Und selbst wenn es läuft muss es ja auch noch Administrierbar sein für mich. In diesem sinne habe ich mich für ein Windows entschieden.
Das Problem ist xampp unter win hat keine ssl unterstützung.

mfg
Adrian
Mitglied: Plominski
Plominski 26.08.2006 um 13:52:42 Uhr
Goto Top
Grüße

also wenn du SSL deaktiviert (nicht benutzen) möchtest - lässt Outlook nur NTLM Auth zu, nur das geht nicht standartmäßig über Apache (Reverse), dazu wird ein Drittanbieter (develop.) Modul benötigt!

wenn man die "klartext" (Outlook RPC over HTTP/S - Standardauth) Übertragung möchte, setzt Outlook eben SSL vorraus!

also bleibt dir erstmal nix anderes übrig als Apache (Xampp for Win) sauber mit SSL unter Windows zum laufen zu bekommen ...

mach doch einfach mal ein httpd -t um zu sehen ob auch wirklich alle Plugins im Apache geladen werden ...

MFG
Mitglied: Plominski
Plominski 30.09.2006 um 12:39:46 Uhr
Goto Top
### URLScan ###
<Location />
#AllowOverride None

<Limit GET POST SEARCH POLL SUBSCRIBE BMOVE BCOPY MOVE PROPFIND PROPPATCH BPROPPATCH DELETE BDELETE MKCOL RPC_IN_DATA RPC_OUT_DATA>
Order allow,deny
Allow from all
</Limit>

<LimitExcept GET POST SEARCH POLL SUBSCRIBE BMOVE BCOPY MOVE PROPFIND PROPPATCH BPROPPATCH DELETE BDELETE MKCOL RPC_IN_DATA RPC_OUT_DATA>
Order deny,allow
Deny from all
</LimitExcept>

</Location>
### ####### ###
Mitglied: Plominski
Plominski 30.09.2006 um 12:43:04 Uhr
Goto Top
### URLScan ###
<Location />
#AllowOverride None

<Limit HEAD OPTIONS GET POST SEARCH POLL SUBSCRIBE BMOVE BCOPY MOVE PROPFIND PROPPATCH BPROPPATCH DELETE BDELETE MKCOL RPC_IN_DATA RPC_OUT_DATA>
Order allow,deny
Allow from all
</Limit>

<LimitExcept HEAD OPTIONS GET POST SEARCH POLL SUBSCRIBE BMOVE BCOPY MOVE PROPFIND PROPPATCH BPROPPATCH DELETE BDELETE MKCOL RPC_IN_DATA RPC_OUT_DATA>
Order deny,allow
Deny from all
</LimitExcept>

</Location>
### ####### ###

Link: http://www.microsoft.com/germany/technet/datenbank/articles/600989.mspx
Mitglied: Peer
Peer 02.10.2006 um 19:10:16 Uhr
Goto Top
Hallo

Habe dank der Anleitung ein soweit laufendes System erstellen können.
Der Apache steht in der DMZ und verweist auf den Exchange-Front-End
im internen Netz. Damit kann ich über OWA aber nur Postfächer erreichen,
die auf dem Backend liegen, der im gleichen Netz steht, wie der Front-End.

Die Subnetzte der Backends sind per VPN verbunden und das Mailrouting der
Backends untereinander funktioniert problemlos.

Weiß jemand Rat?

Gruß
Peer
Mitglied: Plominski
Plominski 10.10.2006 um 16:04:14 Uhr
Goto Top
Grüße

!!! kann ich bestätigen, alles über Xampp 1.4.13 funktioniert nicht mehr ordnungsgemäß mit RPC over HTTPS!!!

meine Tests ergaben aber eine stabilere RPC over HTTPS Verbindung mit Outlook 12 (Beta2), bei den neueren Apache Versionen habe ich das noch nicht getestet ... (wäre mal Wert)

MFG
Mitglied: fury
fury 14.11.2006 um 09:40:20 Uhr
Goto Top
habe in den posts leider nicht rauslesen können ob active sync über apache reverse funktioniert.

bekomme ich eine verbindung über https zum apachen und dann ab dem apachen eine http zum exchange?

grüße
Mitglied: Plominski
Plominski 14.11.2006 um 15:26:37 Uhr
Goto Top
Grüße

ERSTENS: klar geht ActiveSync [Eintrag für: HTTPS "/Microsoft-Server-ActiveSync"] siehe HowTos

ZWEITENS: es können nur "gleiche" Reversen funktionieren!

HTTP <-> HTTP

HTTP/S <-> HTTP/S

aber keine "Mischformen", zumindest hat es bei mir nicht funktioniert!

z.b:
HTTP <-> HTTP/S (Port 444) für SSL SharePoint äquivalent
HTTP/S <-> HTTP (HostNameReverse) beides endet mit fehlern ...
Mitglied: fury
fury 14.11.2006 um 15:42:13 Uhr
Goto Top
auch wenn ich nur einen exchangeserver als backend habe?

internet -> reverse proxy -> postfachserver (exchange)
Mitglied: Plominski
Plominski 14.11.2006 um 18:43:53 Uhr
Goto Top
100%
Mitglied: Plominski
Plominski 14.11.2006 um 18:49:38 Uhr
Goto Top
100%
Mitglied: Plominski
Plominski 14.11.2006 um 18:55:31 Uhr
Goto Top
100%
Mitglied: Plominski
Plominski 14.11.2006 um 19:09:18 Uhr
Goto Top
99% (sofern man den Dreh mit den TimeOuts heraus hat)
Mitglied: Plominski
Plominski 13.01.2007 um 10:05:52 Uhr
Goto Top
Mitglied: Plominski
Plominski 13.01.2007 um 10:09:34 Uhr
Goto Top
Grüße (christianbln2k)

schonmal das Modul für Apache 2.x (Xampp 1.4) kompiliert?

MFG