18
Exchange over Https, Relay in der DMZ welche Möglichkeiten habe ich?
Mein Chef hat bei einem Kunden (vor meiner Zeit) einen Exchangeserver eingerichtet. Nun will er exchange over https nutzen, damit Endgeräte für exchange nicht immer die vpn nutzen müssen.
Meine Frage bezieht sich auf eure Erfahrungen damit. Kennt jemand eine günstige / kostenlose Lösung ein Relay einzurichten, das dann in der DMZ sitzt und das exchange Zertifikat ohne es aufzulösen einfach nur durchreicht an den Exchange der hinter der DMZ sitzt?
http://lostcommunication.de/index.php/apache-reverse-proxy-fur-exchange ...
sowas zum Beispiel: wichtig ist halt nicht nur das https relay, sondern das weiterreichen vom exchange zertifikat ohne dieses aufzulösen.
Wäre über eure Anregungen sehr erfreut!
http://lostcommunication.de/index.php/apache-reverse-proxy-fur-exchange ...
sowas zum Beispiel: wichtig ist halt nicht nur das https relay, sondern das weiterreichen vom exchange zertifikat ohne dieses aufzulösen.
Wäre über eure Anregungen sehr erfreut!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 187682
Url: https://administrator.de/contentid/187682
Printed on: April 16, 2024 at 19:04 o'clock
18 Comments
Latest comment
Und was spricht jetzt gegen die von Dir gepostete Lösung mit dem Apache?
weil apache seit 3 jahren bei größeren rpc paketen einen bug hat der nicht gefixed wird ;/
nginx, oder der leichter zu konfigurierende pound kann das auch 
vielen dank! ich werde die beiden proxy's morgen testen und berichten.
Moin,
also Apache würde ich gleich wieder vergessen! Da ist die Performance unter alter Sau!
Wir haben überall nginx im Einsatz und sind sehr zufrieden. Ob aber RPC inzwischen problemlos klappt bezweifel ich. Nginx supporter NTLM noch nicht...
Grüße,
Dani
also Apache würde ich gleich wieder vergessen! Da ist die Performance unter alter Sau!
Wir haben überall nginx im Einsatz und sind sehr zufrieden. Ob aber RPC inzwischen problemlos klappt bezweifel ich. Nginx supporter NTLM noch nicht...
Grüße,
Dani
Hallo,
"einfach durchreichen" von Datenpaketen ist das, was jeder Router macht.
Nicht einfach durchreichen, sondern die Verbindung terminieren und eine neue aufbauen (und dabei auch neu verschlüssel [wofür man bei Wunsch aber das gleiche Zertifikat nehmen kann]) tut jeder Reverse-Proxy.
Gruß
Filipp
das exchange Zertifikat ohne es aufzulösen einfach nur durchreicht
Was willst du damit denn sagen?"einfach durchreichen" von Datenpaketen ist das, was jeder Router macht.
Nicht einfach durchreichen, sondern die Verbindung terminieren und eine neue aufbauen (und dabei auch neu verschlüssel [wofür man bei Wunsch aber das gleiche Zertifikat nehmen kann]) tut jeder Reverse-Proxy.
Gruß
Filipp
ok vielen Dank für eure Antworten. Ich habe mich nun für den Squid auf Ubuntu entschieden.
Da der Proxy kein Webproxy darstellen soll, sondern ausschließlich für rpc over https gedacht ist, damit der Exchange nicht mit einem Bein im Internet steht, habe ich mir eine entsprechende config file gesucht.
Da die OWA Lösung bereits über das VPN realisiert ist, möchte ich hier ausschließlich RPC darüber abwickeln. Daher würde ich die config abspecken, so dass auschließlich darüber rpc läuft. Kann mir jemand sagen, ob ich die owa Einträge damit einfach aus der o.g. config löschen kann?
Das Zertifikat (SSL) wird vom Exchange vorgegeben und daher brauche ich kein eigenes auf dem Squid zu erstellen.
Pardon falls dem einen oder anderen die Frage zu banal scheint, aber ich arbeite mich gerade erst wirklich ein - vorher habe ich mich kaum mit Proxys etc beschäftigen müssen.
Danke für eure Hilfe.
Da der Proxy kein Webproxy darstellen soll, sondern ausschließlich für rpc over https gedacht ist, damit der Exchange nicht mit einem Bein im Internet steht, habe ich mir eine entsprechende config file gesucht.
visible_hostname owa.Beispiel.local
extension_methods RPC_IN_DATA RPC_OUT_DATA
https_port 443 cert=/path/to/external/cert
key=/path/to/external/cert.key defaultsite=external.owa.domain.name
cache_peer ip.address.of.exchange parent 443 0 no-query originserver login=PASS
ssl sslflags=DONT_VERIFY_PEER sslcert=/path/to/exchange/cert.crt sslkey=/path/to/exchange/certkey.pem name=owaServer
acl OWA dstdomain external.owa.domain.name
cache_peer_access owaServer allow OWA
never_direct allow OWA
http_access allow OWA
http_access deny all
miss_access allow OWA
miss_access deny allDas Zertifikat (SSL) wird vom Exchange vorgegeben und daher brauche ich kein eigenes auf dem Squid zu erstellen.
visible_hostname owa.Beispiel.local
extension_methods RPC_IN_DATA RPC_OUT_DATA
cache_peer ip.address.of.exchange parent 443 0 no-query originserver login=PASS
ssl sslflags=DONT_VERIFY_PEER sslcert=/path/to/exchange/cert.crt sslkey=/path/to/exchange/certkey.pem name=owaServer
http_access deny all
miss_access allow OWA
miss_access deny allPardon falls dem einen oder anderen die Frage zu banal scheint, aber ich arbeite mich gerade erst wirklich ein - vorher habe ich mich kaum mit Proxys etc beschäftigen müssen.
Danke für eure Hilfe.
Moin,
funktioniert RPCoHTTPS mit dieser Konfiguration überhaupt?! Da wäre doch erstmal wichtig, danach kannst du die Konfiguration verkleinern.
Grüße,
Dani
funktioniert RPCoHTTPS mit dieser Konfiguration überhaupt?! Da wäre doch erstmal wichtig, danach kannst du die Konfiguration verkleinern.
Das Zertifikat (SSL) wird vom Exchange vorgegeben und daher brauche ich kein eigenes auf dem Squid zu erstellen.
Hmm... da wäre ich mir nicht sicher. Unser RevProxy benötigt ein eigenständiges gültiges Zertifikat.Da die OWA Lösung bereits über das VPN realisiert ist, möchte ich hier ausschließlich RPC darüber abwickeln.
Auch eine Möglichkeit...Grüße,
Dani
Hallo Dani,
job Outlook Anywhere (RPCoHTTPS) funktioniert soweit mit Squid
siehe:
siehe: http://atlina.com/blog/?p=8
Das Problem ist bei diesen Lösungen ist immer OWA mit drin und ich suche halt nach einer configfile bzw. eine Befehlsreferenz zum Configfile, habe nicht wirklich bisher etwas passendes gesehen. Das Problem ist halt nicht das Verständnis, sondern die Quelle.
job Outlook Anywhere (RPCoHTTPS) funktioniert soweit mit Squid
siehe:
siehe: http://atlina.com/blog/?p=8
Das Problem ist bei diesen Lösungen ist immer OWA mit drin und ich suche halt nach einer configfile bzw. eine Befehlsreferenz zum Configfile, habe nicht wirklich bisher etwas passendes gesehen. Das Problem ist halt nicht das Verständnis, sondern die Quelle.
Probier's mal so:
Grüße,
Dani
acl OWA dstdomain external.owa.domain.name/rpcGrüße,
Dani
Danke für die Antwort Dani und sorry ich musste mich um einen Notfall die letzten Tage kümmern, deswegen komme ich erst jetzt dazu hier zu lesen.
Wie meinst du das genau? Soll ich nur diese Zeile dort eintragen?
lieben Gruß
Wie meinst du das genau? Soll ich nur diese Zeile dort eintragen?
lieben Gruß
Einfach Zeile 12 mit meiner Zeile austauschen.
Grüße,
Dani
Grüße,
Dani
Ok nach gründlicher Recherche bin ich nun ein ganzes Stück weitergekommen. Trotzdem sind noch ein paar Fragen offen.
Da ich wie schon vorher erwähnt das erste mal mich mit Proxy Servern beschäftige fiel mir das Verständnis nicht ganz so leicht und die vielen Forenbeiträge im Internet verwirren bei dem Thema schon sehr. Ich bin zuerst davon ausgegangen, das der Squid in der Lage ist das SSL Zertifikat das vom IIS (auf dem Exchange) ausgestellt ist selber für die interne Verschlüsselung zu nutzen und auch dieses Zertifikat zu nutzen um die SSL Verschlüsselung zum Client zu gewährleisten. Dieser Gedanke ist an sich jedoch völlig falsch was sich dann gezeigt hat. Squid ist jedoch in der Lage mit der sogenannten Connect -request Methode sämtliche Protokolle 1:1 weiterzuleiten ohne die Verbindung zu terminieren.
http://www.warp9.de/pub/BO07RevProxy.pdf hier sagt jemand das es mit der Version 2.6 definitiv möglich ist RPCoHTTPS zu betreiben.
Ok. Soweit so gut nun habe ich mich an die ersten Schritte gemacht und nochmal bei 0 begonnen.
Zuerst ist es wichtig zu wissen, das Squid an sich in der Grundkonfiguration nicht SSL beinhaltet und man daher das Paket neu kompilieren muss.
1. installieren von OpenSSL und kompilieren des Squid Paketes mit dem Parameter --enable-ssl
herunterladen von Squid,extrahieren und kompilieren.
2. Danach überprüft man, ob Squid nun SSl inkludiert hat.
squid -v
3. Nun macht man sich an die Configfile
Hier habe ich verschiedene Methoden gefunden ich hoffe das jemand nun dort Erfahrung hat und mir vielleicht noch helfen kann.
ein configfile das vielversprechend aussieht fand ich hier: http://wiki.squid-cache.org/ConfigExamples/Reverse/ExchangeRpc
und eine andere hier: http://www.unixboard.de/vb3/showthread.php?49100-Squid-proxy-f%FCr-rpc- ...
Ok wie oben beschrieben gibt in dieser Konstellation der IIS vom Exchange das SSL Zertifikat vor. Damit haben wir 3 Zertifikate beim Server
root.cert
CA.cert
Client.cert
wenn man sich jetzt oben das configfile ansieht denkt man als erstes "ok ich muss nun das CA & Client.cert auf dem Squid hochladen und die Pfade angeben."
Das habe ich dann auch gemacht. Eine Abfrage vom Client mit Outlook gestartet. Sehe auf dem Router auch die eingehende Verbindung, jedoch leitet der Squid die Anfrage nicht weiter.
Dann habe ich nochmal recherchiert und bin auf die o.g. Methode gestoßen "Connect Method". Also das der Squid gar nichts mit den Zertifikaten an sich zu tun hat und im Grunde nur die Pakete an den Exchange durchreicht ohne dabei zu cachen bzw. zu loggen. (wäre mir auch nicht wichtig)
Im Grunde soll der Squid nur als Schutzschild dienen, damit der Exchange nicht das erste Glied der Kette ist.
Folgender Foren Beitrag hat mir dann die Connect request Methode gezeigt. http://debianforum.de/forum/viewtopic.php?t=65898
Squid also supports these encrypted protocols by ``tunelling'' traffic between clients and servers. In this case, Squid can relay the encrypted bits between a client and a server.
Normally, when your browser comes across an https URL, it does one of two things:
The browser opens an SSL connection directly to the origin server.
The browser tunnels the request through Squid with the CONNECT request method.
The CONNECT method is a way to tunnel any kind of connection through an HTTP proxy. The proxy doesn't understand or interpret the contents. It just passes bytes back and forth between the client and server.
Alles klar nun will ich diese Connect Request Methode testen und hoffe dort mehr Erfolg zu haben. Wenn jemand in der Lage ist mir hier zu helfen wäre ich ihm sehr dankbar. Ich werde auch gerne nach der erfolgreichen Arbeit ein PDF in diesem Forum hochladen das dann alles von Installation bis zur Configfile beschreibt, damit dann alle deutschen Admins die sowas machen wollen etwas davon haben.
Wie gesagt für weitere Hilfe bin ich sehr dankbar!
Da ich wie schon vorher erwähnt das erste mal mich mit Proxy Servern beschäftige fiel mir das Verständnis nicht ganz so leicht und die vielen Forenbeiträge im Internet verwirren bei dem Thema schon sehr. Ich bin zuerst davon ausgegangen, das der Squid in der Lage ist das SSL Zertifikat das vom IIS (auf dem Exchange) ausgestellt ist selber für die interne Verschlüsselung zu nutzen und auch dieses Zertifikat zu nutzen um die SSL Verschlüsselung zum Client zu gewährleisten. Dieser Gedanke ist an sich jedoch völlig falsch was sich dann gezeigt hat. Squid ist jedoch in der Lage mit der sogenannten Connect -request Methode sämtliche Protokolle 1:1 weiterzuleiten ohne die Verbindung zu terminieren.
http://www.warp9.de/pub/BO07RevProxy.pdf hier sagt jemand das es mit der Version 2.6 definitiv möglich ist RPCoHTTPS zu betreiben.
Ok. Soweit so gut nun habe ich mich an die ersten Schritte gemacht und nochmal bei 0 begonnen.
Zuerst ist es wichtig zu wissen, das Squid an sich in der Grundkonfiguration nicht SSL beinhaltet und man daher das Paket neu kompilieren muss.
1. installieren von OpenSSL und kompilieren des Squid Paketes mit dem Parameter --enable-ssl
apt-get install opensslsu -
passwort eingeben
wget http://www.squid-cache.org/Versions/v3/3.0/
cd /root
tar xvf *.gz
./configure --prefix=/usr --includedir=${prefix}/include --enable-ssl --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libexecdir=${prefix}/lib/squid3 --disable-maintainer-mode --disable-dependency-tracking --srcdir=. --datadir=/usr/share/squid3 --sysconfdir=/etc/squid3 --mandir=/usr/share/man --enable-inline --enable-async-io=8 --enable-storeio=ufs,aufs,diskd,null --enable-removal-policies=lru,heap --enable-delay-pools --enable-cache-digests --enable-underscores --enable-icap-client --enable-follow-x-forwarded-for --enable-auth=basic,digest,ntlm --enable-basic-auth-helpers=LDAP,MSNT,NCSA,SASL,SMB,YP,getpwnam,multi-domain-NTLM --enable-ntlm-auth-helpers=SMB --enable-digest-auth-helpers=ldap,password --enable-external-acl-helpers=ip_user,ldap_group --with-filedescriptors=65536 --with-default-user=proxy --enable-epoll --enable-linux-netfilter -with-openssl=/usr/include/openssl/
make
make install2. Danach überprüft man, ob Squid nun SSl inkludiert hat.
squid -v
3. Nun macht man sich an die Configfile
Hier habe ich verschiedene Methoden gefunden ich hoffe das jemand nun dort Erfahrung hat und mir vielleicht noch helfen kann.
ein configfile das vielversprechend aussieht fand ich hier: http://wiki.squid-cache.org/ConfigExamples/Reverse/ExchangeRpc
# Publish the RPCoHTTP service via SSL
https_port ip_of_squid:443 accel cert=/path/to/clientcertificate defaultsite=rpc_domain_name
cache_peer ip_of_exchange_server parent 443 0 no-query originserver login=PASS ssl sslcert=/path/to/certificate name=exchangeServer
acl EXCH dstdomain .rpc_domain_name
cache_peer_access exchangeServer allow EXCH
cache_peer_access exchangeServer deny all
never_direct allow EXCH
# Lock down access to just the Exchange Server!
http_access allow EXCH
http_access deny all
miss_access allow EXCH
miss_access deny allund eine andere hier: http://www.unixboard.de/vb3/showthread.php?49100-Squid-proxy-f%FCr-rpc- ...
# Publish the RPCoHTTP service via SSL
https_port Proxy_IP:443 accel cert=/etc/squid3/cert/zertifikat.pem defaultsite=exchange.domain.de
cache_peer Exchange_IP parent 443 0 no-query originserver login=PASS ssl sslflags=DONT_VERIFY_PEER ssl sslcert=/etc/squid3/cert/Zertifikat.pem name=exchangeServer
#cache_peer Exchange_IP parent 80 0 no-query originserver login=PASS front-end-https=on name=exchangeServer
acl localhost src 127.0.0.1/255.255.255.255
acl local src Netzwerk/255.255.255.0
acl to_localhost dst 127.0.0.0/8
#zugriff auf folgende URLs Erlauben, EXCH dient nur als frei wählbarer Parameter
acl EXCH url_regex -i ^https://exchange.domain.de/rpc/rpcproxy.dll.*$
acl EXCH url_regex -i ^https://exchange.domain.de/exchange.*$
acl EXCH url_regex -i ^https://exchange.domain.de/exchweb.*$
acl EXCH url_regex -i ^https://exchange.domain.de/owa.*$
acl EXCH url_regex -i ^https://exchange.domain.de/Microsoft-Server-ActiveSync.*$
acl EXCH url_regex -i ^https://exchange.domain.de/ecp.*$
acl EXCH url_regex -i ^https://exchange.domain.de/public.*$
acl EXCH url_regex -i ^https://exchange.domain.de/cert.*$
cache_peer_access exchangeServer allow EXCH
cache_peer_access exchangeServer deny all
never_direct allow EXCH
# Zugriffe für Parameter EXCH
http_access allow EXCH
http_access deny all
miss_access allow EXCH
miss_access deny all
#erweitertes Logging
debug_options ALL,1 33,2Ok wie oben beschrieben gibt in dieser Konstellation der IIS vom Exchange das SSL Zertifikat vor. Damit haben wir 3 Zertifikate beim Server
root.cert
CA.cert
Client.cert
wenn man sich jetzt oben das configfile ansieht denkt man als erstes "ok ich muss nun das CA & Client.cert auf dem Squid hochladen und die Pfade angeben."
Das habe ich dann auch gemacht. Eine Abfrage vom Client mit Outlook gestartet. Sehe auf dem Router auch die eingehende Verbindung, jedoch leitet der Squid die Anfrage nicht weiter.
Dann habe ich nochmal recherchiert und bin auf die o.g. Methode gestoßen "Connect Method". Also das der Squid gar nichts mit den Zertifikaten an sich zu tun hat und im Grunde nur die Pakete an den Exchange durchreicht ohne dabei zu cachen bzw. zu loggen. (wäre mir auch nicht wichtig)
Im Grunde soll der Squid nur als Schutzschild dienen, damit der Exchange nicht das erste Glied der Kette ist.
Folgender Foren Beitrag hat mir dann die Connect request Methode gezeigt. http://debianforum.de/forum/viewtopic.php?t=65898
Squid also supports these encrypted protocols by ``tunelling'' traffic between clients and servers. In this case, Squid can relay the encrypted bits between a client and a server.
Normally, when your browser comes across an https URL, it does one of two things:
The browser opens an SSL connection directly to the origin server.
The browser tunnels the request through Squid with the CONNECT request method.
The CONNECT method is a way to tunnel any kind of connection through an HTTP proxy. The proxy doesn't understand or interpret the contents. It just passes bytes back and forth between the client and server.
Alles klar nun will ich diese Connect Request Methode testen und hoffe dort mehr Erfolg zu haben. Wenn jemand in der Lage ist mir hier zu helfen wäre ich ihm sehr dankbar. Ich werde auch gerne nach der erfolgreichen Arbeit ein PDF in diesem Forum hochladen das dann alles von Installation bis zur Configfile beschreibt, damit dann alle deutschen Admins die sowas machen wollen etwas davon haben.
Wie gesagt für weitere Hilfe bin ich sehr dankbar!
keine eine Idee? Ich brauche speziell eine kurze Erklärung für die Authentifizierung. Also muss ich NTLM nutzen? Oder muss der Squid sein eigenes Zertifikat haben?
Moin,
wenn es dir zu lansagem geht hast du zwei Möglichkeiten.
a) anderes Forum
b) TMG kaufen
Wir sind hier nicht beim kostenlosen Systemhaus support. Wir haben alle noch ein Hobby das uns 8-12 Stunden jeden Tag in Anspruch nimmt und selbst vllt. ein Proble zu lösen!
WArum hast du nochmal von vorne angefangen? Oben schreibst du das es funktioniert.
Grüße,
Dani
wenn es dir zu lansagem geht hast du zwei Möglichkeiten.
a) anderes Forum
b) TMG kaufen
Wir sind hier nicht beim kostenlosen Systemhaus support. Wir haben alle noch ein Hobby das uns 8-12 Stunden jeden Tag in Anspruch nimmt und selbst vllt. ein Proble zu lösen!
WArum hast du nochmal von vorne angefangen? Oben schreibst du das es funktioniert.
Grüße,
Dani
war eigentlich eher ein Push auf den Thread und kein Gehetze...
Ich habe oben geschrieben das es laut der Quelle funktioniert. Jedoch ist die Konstellation eine ganz andere dort (mit Apache als Webproxy dahinter)
Das einzige Problem was ich momentan noch habe ist die Fehlermeldung "Failed to acquire SSL certificate '/etc/squid3/cert/zertifitkat.cer' : error: 0906d06c:PEM routines:PEM_red_bio:no start line
Vielen Dank!
Liebe Grüße zurück!
Ich habe oben geschrieben das es laut der Quelle funktioniert. Jedoch ist die Konstellation eine ganz andere dort (mit Apache als Webproxy dahinter)
Das einzige Problem was ich momentan noch habe ist die Fehlermeldung "Failed to acquire SSL certificate '/etc/squid3/cert/zertifitkat.cer' : error: 0906d06c:PEM routines:PEM_red_bio:no start line
Vielen Dank!
Liebe Grüße zurück!
Moin,
hier eine funktionierende Lösung für Squid als Reverse PRoxy für alle Exchange-Dienste.
Grüße,
Dani
hier eine funktionierende Lösung für Squid als Reverse PRoxy für alle Exchange-Dienste.
Grüße,
Dani
Vielen Dank für das Howto Dani!! Sorry für die sehr verspätete Antwort ich war in den Staaten auf Projektarbeit...
Liebe Grüße!!
Liebe Grüße!!