Ports für Exchange syncronisation über pptp

[Velius 10]

ok

 

aber wenn er die kommunukation tunnelt ists eh egal !

 

 

Nicht ganz...

So wie ich das Ganze verstehe werden die Ports innerhalb des Tunnels gefiltert. Ich weiss, dass das nicht Jedermann für sinnvoll hält....

 

 

Wie auch immer.

 

 

Gruss

Velius

[Displex2003 10]

Also um euren Spekulationen mal Aufklärung zu geben!

 

Ich habe den Exchange Server in der Hosts Datei auf meinem Rechner eingetragen! Ja die Pakete werden innerhalb des Tunnels nochmal gefiltert weil ich einer normalen PPTP Verbindung mit 128 BIT nicht die absolute Sicherheit zutraue und wir zu klein sind um uns eine richitge DMZ einzurichten!

 

Das mit den RPC calls hab ich noch nicht ganz verstanden!

[Hr_Rossi 10]

ok !

 

nicht so schnell !

 

schritt für schritt !

schau einmal ob sich das outlook synchronisiert OHNE jegliche Filter, einfach nur über pptp !

dann schuan wir weiter wie wir dann die verbindung filtern !

funktioniert die namensauflösung schon !?

 

lg

[Velius 10]

Off-Topic:
Mal 'ne kleine OT Frage zwischendurch: Braucht ihr eigentlich sonst auch immer so viele [!]???? :suspect: :suspect:

[Displex2003 10]

Also ohne Filter über PPTP funkt das Problemlos! Ich denke das hängt mit den dyn Ports zusammen! Meine Aussendienstler haben mir schon gesagt das es viel besser funktioniert seit ich bei Service Any stehen hab! Ich meine kann man das bei einer PPTP Verbindung machen????? Ist das nicht unsicher?????? oder besser gesagt zu unsicher!

[Displex2003 10]

so viele Threads???

[Velius 10]

nein ...

 

[!] ...waren gemeint.

[Hr_Rossi 10]

nein ...

 

[!] ...waren gemeint.

 

lol egal !

gott sei dank hat jeder seinen eigenen stil hehe :)

 

also um vom OT zurückzukehren !

PPTP ist eigentlich nicht unsicher vorausgesetzt du verwendest Passwörter > als 13

Stellen. (hab einen Punkt gemacht :D )

 

Wenn du jetzt die Verbindugn filtern willst musst du RPC auf einen port binden, diese wiederum hat den nachteil das du nur pro port einen client anhängen kannst,

du könntest aber auch für die RPC port ranges konfigurieren ..... design sache.

 

hier mal ein link um dir zu verdeutlichen was es fü administrativer aufwand ist die rpc´s z.b an http zu binden.....

 

http://support.microsoft.com/default.aspx?scid=kb;de;833401

 

lg

rossi

 

edit1:

http://www.msexchange.org/tutorials/outlookrpchttp.html

[Velius 10]

 

 

 

Wenn du jetzt die Verbindugn filtern willst musst du RPC auf einen port binden, diese wiederum hat den nachteil das du nur pro port einen client anhängen kannst,

 

 

Das stimmt nicht.

[Displex2003 10]

Was stimmt dann?

[Hr_Rossi 10]

Das stimmt nicht.

 

Hi

 

kannst du mich mal aufklären bitte ?

bin immer davon ausgegangen, wenn ich RPC über irgendeinen Port steuere, dann kann immer nur ein Client darauf zugreifen .. oder nicht

das heisst es könne sich die cleints den port teilen oder wie ist das jetzt ?

[Velius 10]

Oh man..... :rolleyes: :wink2:

 

 

Das mit den Ports verstehst du völlig falsch. Die Ziel- Ports werden vom TCP/IP Stack verwendet, nicht etwa um verschiedene Clients zuzuweisen, sondern um die gewünschte Anwendung, wie etwa SMTP, anzusteuern. Ohne die Zielport angabe wäre der Stack nicht in der Lage zu erkennen, an welche Anwendung das Packet gerichtet ist. Die RPC-Calls sind insofern speziell, weil ausgehen vom RPC Endpoint-mapper Port 135 eine "entfernte Prozedur" ausgeführt wird. Der Computer wird sozusagen aufgefordert, etwas auszuführen und nicht wie bei anderen Protokollen zur Ausführung "gezwungen" (aktiv/passiv). Je nach Anforderung kann der Port aber dynamisch zugewiesen werden, da es, so denke ich mal, zu viele Prozeduren gibt, um diese einem bestimmten Port zuweisen zu können. Jeder RPC-Call hat auch deswegen eine RPC-UID, die in etwa so aussieht f5cc5a18-4264-101a-8c59-08002b2f8426. Im Falle von MS kann man diese Calls aber auf einen bestimmten Port festlegen, nachteil dabei ist aber, dass der Port frei sein muss und möglichst auch nicht bereits reserviert sein darf.

 

Siehe auch: RPC: Remote Procedure Call Protocol Specification Version 2

 

 

Ist das jetzt etwas klarer?

[Hr_Rossi 10]

Oh man..... :rolleyes: :wink2:

 

 

Das mit den Ports verstehst du völlig falsch. Die Ziel- Ports werden vom TCP/IP Stack verwendet, nicht etwa um verschiedene Clients zuzuweisen, sondern um die gewünschte Anwendung, wie etwa SMTP, anzusteuern. Ohne die Zielport angabe wäre der Stack nicht in der Lage zu erkennen, an welche Anwendung das Packet gerichtet ist. Die RPC-Calls sind insofern speziell, weil ausgehen vom RPC Endpoint-mapper Port 135 eine "entfernte Prozedur" ausgeführt wird. Der Computer wird sozusagen aufgefordert, etwas auszuführen und nicht wie bei anderen Protokollen zur Ausführung "gezwungen" (aktiv/passiv). Je nach Anforderung kann der Port aber dynamisch zugewiesen werden, da es, so denke ich mal, zu viele Prozeduren gibt, um diese einem bestimmten Port zuweisen zu können. Jeder RPC-Call hat auch deswegen eine RPC-UID, die in etwa so aussieht f5cc5a18-4264-101a-8c59-08002b2f8426. Im Falle von MS kann man diese Calls aber auf einen bestimmten Port festlegen, nachteil dabei ist aber, dass der Port frei sein muss und möglichst auch nicht bereits reserviert sein darf.

 

Siehe auch: RPC: Remote Procedure Call Protocol Specification Version 2

 

 

Ist das jetzt etwas klarer?

 

ok jo thx :p

 

gebe aber an dieser stelle ab an dich velius, da du ja sicherlich Displex2003

bei seinem Vorhaben mehr unterstützen kann als ich...

expert ist halt Expert und dies dürfte ein Expert Thema sein...

 

lg

[Velius 10]

Ich würde es einfach halten:

 

Wenn eine Tunnelfilterung erwünscht ist, beispielsweise wenn man sicherstellen will, dass sich andere Programme wie Viren und dergleichen nicht über unbenötigte Ports "fortpflanzen" können, dann würde ich auf RPC over HTTPS setzen. Voraussetzung ist aber OL2K3. Mit der Boardsuche findest du mehr heraus. :wink2:

[Tallasar 10]

So mal wieder was von mir:

 

Velius hat Recht mit den fixieren der Ports! Wir haben DS und IS auf 5001 und 5002 gesetzt und freigeschaltet, wie MS im KB 155831 beschrieben hat, um Outlook mit Exchange zu kommunizieren zu lassen. Und natürlich auch 135 für RPC freigeschaltet.

 

Gruß Tallasar