67
(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 ...
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 ...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 9628
Url: https://administrator.de/tutorial/apache-reverse-proxy-fuer-rpc-over-https-exchange-access-9628.html
Ausgedruckt am: 22.12.2024 um 02:12 Uhr
67 Kommentare
Neuester Kommentar
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:
Ich bekomme dann folgendes Verhalten, wenn ich mein Outlook (zu Hause) auf RPC-over-HTTP(s) einrichte:
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
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
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
<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 ...
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
- DNS/Router/WINS-IP entspricht der Firewall#
<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 ...
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
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
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!
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!
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
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
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
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
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
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
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
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
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
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
Also: habe auch schon an der Reg. herum_gespielt, aber HTTP RPC lies sich nicht aktivieren ...
Exchange SP2 behebt den fehler *G*
MFG
Exchange SP2 behebt den fehler *G*
MFG
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
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
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.
Ich hoffe, dass ich hier endlich eine Konstellation hinbekomme die funktioniert... Das kann doch nicht so schwer sein.
Gruß
Dennis
ä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.
Ich hoffe, dass ich hier endlich eine Konstellation hinbekomme die funktioniert... Das kann doch nicht so schwer sein.
Gruß
Dennis
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
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
- kleine Anleitung -
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">
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
<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">
- Nach dem ganzen geupdate und "hoffentlich" fehlerfreien System wird jetzt erstmal RPC eingerichtet! #
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
Grüße
gib uns bitte mal einen Link, wir wären gerne daran interessiert
Mit freundlichen Grüßen Daniel
gib uns bitte mal einen Link, wir wären gerne daran interessiert
Mit freundlichen Grüßen Daniel
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!
!!! 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!
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?
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?
PDF HowTo:
http://media.plominski.de/docs/Xampp-ReverseProxy-fuer-Exchange-RPCover ...
Mit freundlichen Grüßen Daniel!
http://media.plominski.de/docs/Xampp-ReverseProxy-fuer-Exchange-RPCover ...
Mit freundlichen Grüßen Daniel!
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
Grüße
Christian
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
Grüße
Christian
Hi,
also ich konnte das Problem lösen.
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
also ich konnte das Problem lösen.
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
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
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
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
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
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
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
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
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
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
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
Ü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!
"<font color="BLUE">Hauptname des Proxyservers:</font>"
<font color="RED">msstd:</font><font color="GREEN">... ... ...</font>
Frohes Fest!
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
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
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
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
Gut
einfach wie bei folgendem ServiceDienstLeister vorgehen:
http://www.synserver.de/support/faq.php?Q591
Mit freundlichen Grüßen
einfach wie bei folgendem ServiceDienstLeister vorgehen:
http://www.synserver.de/support/faq.php?Q591
Mit freundlichen Grüßen
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
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
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
"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
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
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
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
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
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>
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>
- Outlook Web Access
- Outlook Mobile Access
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>
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
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
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
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
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
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
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
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
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
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
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
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...
Gruß
Dennis
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...
Gruß
Dennis
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
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
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.
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.
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
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
Hallo Daniel
1. Vielen dank für deine bemühungen
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
--- 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
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? ...
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
--- 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
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
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
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
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
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 ?
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 ?
Also der RPC over HTTPS funktioniertiert in
der DMZ Umgebung über den Apache Reverse
?
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.3Ich 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
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 ....
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 ....
Hallo...
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
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
Grüße
als erstes solltest du wirklich einen
separaten XP SP2 Client mit Outlook SP2 ins
DMZ hängen ...
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 ich1.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 ....
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
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
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
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
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
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
### 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>
### ####### ###
<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>
### ####### ###
### 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
<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
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
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
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
!!! 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
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
bekomme ich eine verbindung über https zum apachen und dann ab dem apachen eine http zum exchange?
grüße
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 ...
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 ...
auch wenn ich nur einen exchangeserver als backend habe?
internet -> reverse proxy -> postfachserver (exchange)
internet -> reverse proxy -> postfachserver (exchange)
100%
100%
100%
99% (sofern man den Dreh mit den TimeOuts heraus hat)
Grüße (christianbln2k)
schonmal das Modul für Apache 2.x (Xampp 1.4) kompiliert?
MFG
schonmal das Modul für Apache 2.x (Xampp 1.4) kompiliert?
MFG
