berndroessl 10 Geschrieben 30. März 2006 Melden Teilen Geschrieben 30. März 2006 hallo leute, hat jemand von euch schon mal "RPC over HTTP" zum laufen gebracht? ich hab mal dieses Tutorial und dieses Tutorial befolgt, hab aber leichte problem, das ding wirklich umzusetzen :( mein aktueller status: * der Netzwerk-Dienst "RPC über HTTP-Proxy" hab ich installier - Leider sehe ich keinen passenden Dienst und auch keinen Eintrag im Eventlog, Lediglich das Virtuelle Verzeichnis "RPC" im IIS ist vorhanden * Ich habe ein Zertifikat erstellt, um Web's per SSL zu verfügung zu stellen * Das Virtuelle Verzeichnis "RPC" ist auf SSL konfiguriert und auch per https erreichbar (der aufruf https://mailsrv/rpc/ bringt den geforderten login mit anschliessendem 403er - also ok) * Outlook ist entsprechen konfiguriert (Verbindung mit HTTP; Url: https://mailsrv; HTTP bei schneller und bei langsamer Verbindung; Standardauthentifizierung) * Die Ports vom Exchange hab ich in der Registry kontrolliert - stimmen mit dem tutor überein * Der Test scheitert :( (Der Aufruf von outlook /rpcdiag zeigt, dass alle Verbindungen über TCP/IP aufgebaut werden und nicht über HTTPS) bisher leuft alles intern, also keine firewall dazwischen. Der Exchange und der DomainController sind auf zwei getrennten Rechnern. Ich habe sämtliche Konfigurationen auf dem mailsrv (also dem Exchange) gemacht. auf dem dc01 (dem DomainController) hab ich lediglich den Netzwerkdienst "RPC über HTTP-Proxy" installiert. Wie gesagt, ich habe keinen sichtbaren Dienst "RPC Proxy" und keine Einträge im Eventlog zu diesem Dienst...Ich denke das dürfte das Problem sein, nur wie kann ich es beheben? Was kann bzw. muss ich noch machen, damit Outlook per HTTPS verbindet? Danke für eure Hilfe Gruss, Bernd Zitieren Link zu diesem Kommentar
berndroessl 10 Geschrieben 31. März 2006 Autor Melden Teilen Geschrieben 31. März 2006 gut, mittlerweile bekomme ich die einträge im ereignisprotokoll :) auch im log vom iis kann ich sehen, dass sich was tut :), leider verbindet outlook immer noch über tcp/ip :( der iis-log sieht folgendermassen aus: 2006-03-31 08:22:13 W3SVC1 192.168.110.3 RPC_OUT_DATA /rpc/rpcproxy.dll dc01.dom.gmc.li:6004 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:13 W3SVC1 192.168.110.3 RPC_IN_DATA /rpc/rpcproxy.dll mailsrv.dom.com:6001 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:13 W3SVC1 192.168.110.3 RPC_OUT_DATA /rpc/rpcproxy.dll mailsrv.dom.com:6001 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:13 W3SVC1 192.168.110.3 RPC_IN_DATA /rpc/rpcproxy.dll dc01.dom.gmc.li:593 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:13 W3SVC1 192.168.110.3 RPC_OUT_DATA /rpc/rpcproxy.dll dc01.dom.gmc.li:593 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:13 W3SVC1 192.168.110.3 RPC_IN_DATA /rpc/rpcproxy.dll mailsrv.dom.com:593 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:13 W3SVC1 192.168.110.3 RPC_OUT_DATA /rpc/rpcproxy.dll mailsrv.dom.com:593 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:15 W3SVC1 192.168.110.3 RPC_IN_DATA /rpc/rpcproxy.dll mailsrv.dom.com:6001 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:15 W3SVC1 192.168.110.3 RPC_OUT_DATA /rpc/rpcproxy.dll mailsrv.dom.com:6001 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:15 W3SVC1 192.168.110.3 RPC_IN_DATA /rpc/rpcproxy.dll mailsrv.dom.com:593 443 dom\br 192.168.110.57 MSRPC 500 0 203 2006-03-31 08:22:15 W3SVC1 192.168.110.3 RPC_OUT_DATA /rpc/rpcproxy.dll mailsrv.dom.com:593 443 dom\br 192.168.110.57 MSRPC 500 0 203 was hat 203 beim sc-win32-status zu bedeuten? Der port 593 hat was mit dcom zu tum oder? kann das meine probleme verursachen? was ist mit den anfragen an den domaincontroller dc01? recht es wirklich, wenn ich auf dem domaincontroller den einen entrag in der registry gemacht hab (ncacn_http:6004 )? hat jemand noch ne idee !! gruss, bernd Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 31. März 2006 Melden Teilen Geschrieben 31. März 2006 Hi, Ich habe das Tutorial von deinem 2. Link auch mal durchgearbeitet, konnte aber die Verbindung erfolgreich über HTTPS herstellen. Error 500 deutet darauf hin, dass das Zertifikat möglicherweise auf den falschen Namen ausgestellt wurde. Damit RPC/HTTPS funktioniert, muss bei der Anforderung des Zertifikats der FQDN des Exchange eingegeben werden, und zwar beim Namen für das Zert. und beim Namen der Website. /edit: habe dazu aber auch noch eine Frage, siehe http://www.mcseboard.de/showthread.php?t=86556 Christoph Zitieren Link zu diesem Kommentar
MikeKellner 10 Geschrieben 1. April 2006 Melden Teilen Geschrieben 1. April 2006 Hast Du das Exchange Zertiifkat schon auf dem Client installiert ? Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 1. April 2006 Melden Teilen Geschrieben 1. April 2006 Das Exchange Zert. selbst braucht nicht auf dem Client installiert zu werden (davon steht auch nix im Tutorial und ich habe es bei meinen Tests auch nicht gemacht ;) ), aber der Client sollte in der Lage sein, das Serverzert. bis zu einer vertrauten Root CA zu verifizieren, ggf. muss also das Root CA Zertifikat vom Exchange exportiert und auf dem Client importiert werden. Christoph Zitieren Link zu diesem Kommentar
MikeKellner 10 Geschrieben 2. April 2006 Melden Teilen Geschrieben 2. April 2006 Das Exchange Zert. selbst braucht nicht auf dem Client installiert zu werden (davon steht auch nix im Tutorial und ich habe es bei meinen Tests auch nicht gemacht ;) ), aber der Client sollte in der Lage sein, das Serverzert. bis zu einer vertrauten Root CA zu verifizieren, ggf. muss also das Root CA Zertifikat vom Exchange exportiert und auf dem Client importiert werden. Christoph Steht sehr wohl im Tut, aber ist auch egal, ob Du es nun wie im Tut beschrieben importieren oder installieren nennst ist auch egal. Ich mache das in der Praxis immer so :D , ich öffne auf dem Client die Seite des OWA und installiere (der Button heißt nun mal so) das Zertifikat. Dann sollte beim zweiten aufruf des OWA keine Fehlermeldung des Zertifikates erscheinen. Ab diesem Punkt funktioniert auch der Zugriff mittels Outlook. Gruß Mike Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 2. April 2006 Melden Teilen Geschrieben 2. April 2006 ich öffne auf dem Client die Seite des OWA und installiere (der Button heißt nun mal so) das Zertifikat. Gruß Mike Das sind aber zwei ganz verschiedene Paar Schuhe.... BerndRoessl spricht von RPC/HTTP, d.h. er will Outlook mit dem Exchange über das HTTP/S Protokoll verbinden, von OWA (sprich Zugang zur Mailbox über einen Browser) ist hier nicht die Rede... Christoph Zitieren Link zu diesem Kommentar
MikeKellner 10 Geschrieben 2. April 2006 Melden Teilen Geschrieben 2. April 2006 Davon spreche ich auch, aber irgendwie muss der Client dem Zertifikat ja nun mal vertrauen wenn der Vorgang über Https stattfinden soll. Es gibt zwei Wege wie dies funktionieren kann. Entweder wird ein vertrauenswürdiges Zertifkat beschafft oder der Client hat die Möglichkeit das Zertifikat selbst über den Browser zu installieren. Dazu kann halt z.B. Owa oder jede andere Https Seite vom Exchange SRV verwandt werden. Hat der Client das Zertifikat installiert kommt es auch zu keiner weiteren Fehlermeldung. Wie willst Du es den z.B schaffen, dass ein Client einem Zerifikat von einem Server EXCH.meinefirma.local vertraut? Gruß Mike Zitieren Link zu diesem Kommentar
MikeKellner 10 Geschrieben 2. April 2006 Melden Teilen Geschrieben 2. April 2006 Lies Dir mal die beiden Artikel durch und erklär mir mal wie Du das ind der Praxis sonst so lösen willst. http://support.microsoft.com/default.aspx?scid=kb%3Bde%3B555261 http://support.microsoft.com/default.aspx?kbid=297681 PS: in den Tuts wird auch immer vergessen, dass die Hosts Datei in manchen fällen angepasst werden muss. Gruß Mike Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 2. April 2006 Melden Teilen Geschrieben 2. April 2006 In beiden Artikeln steht nichts davon, dass das Zertifikat des Exchange Servers auf dem Client installiert werden muss, wenn doch, bitte hier den Wortlaut posten... Was da steht, und was ich bereits erwähnt habe in Post #5, ist, dass der Client in der Lage sein muss, dass Zertifikat der CA zu überprüfen, die das Zertifikat des Exchange Servers ausgestellt hat. In der Praxis wird es meistens so sein, dass der RPCoverHTTP/OWA-Anbieter ein Zertifikat einer öffentlichen Zert.-Stelle erwirbt und dieses für den Webserver verwendet, oder derjenige, der dem Zert. vertrauen soll, muss eben das Root-Zertifikat auf seinem Rechner den vertrauenswürdigen Stammzertifizierungsstellen hinzufügen. Hier noch mal ein Zitat aus dem 2. von dir verlinkten Artikel: Problembeschreibung Wenn Sie im Internet zu einer sicheren Website browsen, wird möglicherweise die folgende Meldung angezeigt: Das Sicherheitszertifikat wurde von einer Firma ausgestellt, die Sie nicht als vertrauenswürdig eingestuft haben Ursache Das Stammzertifikat der Zertifizierungsstelle, die das Zertifikat der Website ausgestellt hat, befindet sich nicht im Speicher für vertrauenswürdige Stammzertifizierungsstellen des Clientbrowsers. Diese Meldung hat keinen Einfluss auf die Einrichtung einer SSL-Sitzung (Secure Sockets Layer) zwischen dem Client und dem Server. Gruß Christoph Zitieren Link zu diesem Kommentar
MikeKellner 10 Geschrieben 2. April 2006 Melden Teilen Geschrieben 2. April 2006 Hallo Christoph, hier der gewünschte Wortlaut Lösung aus Artikel 2Mithilfe der unten stehenden Schritte installieren Sie das Stammzertifikat im Clientbrowser. Dadurch wird die Sicherheitsmeldung beim nächsten Besuch der Website nicht mehr angezeigt. Beachten Sie, dass diese Schritte nur bei Microsoft Internet Explorer-Browsern funktionieren. Hinweis: Das Zertifikat der Zertifizierungsstelle muss nur installiert werden, wenn es sich um nicht vertrauenswürdige Zertifizierungsstellen wie Microsoft Certificate Server handelt Das installieren ist ja auch nur ein von mehreren Wegen einer Cert Stelle zu vertrauen. Sicher ist es besser ein öffentliches Zert zu verwenden, aber dass ist leider nicht immer der Weg mancher Kunden. In der Praxis begegnen mir leider sehr wenige Zertifikate aus öffentlichen Zertifizierungsstellen und für diese Zertifikate ist die Installation über den Browser doch ein praktikabler Weg. In beiden Artikeln steht nichts davon, dass das Zertifikat des Exchange Servers auf dem Client installiert werden muss, wenn doch, bitte hier den Wortlaut posten... Was da steht, und was ich bereits erwähnt habe in Post #5, ist, dass der Client in der Lage sein muss, dass Zertifikat der CA zu überprüfen, die das Zertifikat des Exchange Servers ausgestellt hat. In der Praxis wird es meistens so sein, dass der RPCoverHTTP/OWA-Anbieter ein Zertifikat einer öffentlichen Zert.-Stelle erwirbt und dieses für den Webserver verwendet, oder derjenige, der dem Zert. vertrauen soll, muss eben das Root-Zertifikat auf seinem Rechner den vertrauenswürdigen Stammzertifizierungsstellen hinzufügen. Hier noch mal ein Zitat aus dem 2. von dir verlinkten Artikel: Gruß Christoph Zitieren Link zu diesem Kommentar
MikeKellner 10 Geschrieben 2. April 2006 Melden Teilen Geschrieben 2. April 2006 Du hattest mir meine Frage noch nicht beantwortet. Wie willst Du es den z.B schaffen, dass ein Client einem Zerifikat von einem Server EXCH.meinefirma.local vertraut? Mich würde mal Dein Lösungsansatz interessieren. Gruß Mike Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 2. April 2006 Melden Teilen Geschrieben 2. April 2006 Das Stammzertifikat ist aber nicht das des Ex.-Servers, sondern das der das Zertifikat ausstellenden CA... Wenn dieses Zertifikat (der ausstellenden CA) als gültig anerkannt wird, ist damit auch das Zertifikat, das der Ex.-Server präsentiert, als gültig anerkannt. Die Antwort auf deine Frage lautet also: schau in das Zertifikat, gehe auf den Zertifikats Pfad und installiere alle Zertifikate, die dem des Ex. übergeordnet sind, in die entsprechenden Zertifikatsspeicher (hier: die des Users) auf dem Client. (also trusted root CAs und ggf. intermediate CAs). Das ist genau das, was in dem von Dir selbst mehrfach zitierten Artikel steht. Ich habe das mehrfach in VM-Umgebungen getestet und es funktioniert. Christoph Zitieren Link zu diesem Kommentar
MikeKellner 10 Geschrieben 2. April 2006 Melden Teilen Geschrieben 2. April 2006 Komisch auf Seite 1 erklärst Du das installieren wäre falsch. Wenn dieses Zertifikat (der ausstellenden CA) als gültig anerkannt wird, ist damit auch das Zertifikat, das der Ex.-Server präsentiert, als gültig anerkannt. Die Antwort auf deine Frage lautet also: schau in das Zertifikat, gehe auf den Zertifikats Pfad und installiere alle Zertifikate, die dem des Ex. übergeordnet sind, in die entsprechenden Zertifikatsspeicher (hier: die des Users) auf dem Client. (also trusted root CAs und ggf. intermediate CAs). Es ist doch so. Berndbroessel hat sich selbst ein Zertifikat erstellt. Dieses ist keines Falls vertrauenswürdig. Dies kann mit dem Aufruf https://owa.meinserver.egal überprüft werden. Kommt es bei diesem Aufruf zu einem Fehler, kann das Zertifikat installiert werden und somit ist es vertrauenswürdig. Beim zweiten Aufruf von OWA sollte es zu keinem weiteren Fehler kommen( Es sei den, es ist abgelaufen oder der Name passt nicht) Dann sollte der im zertifikat verwandte Name im OL eingetragen werden und es sollte funktionieren. Oder, wa ist daran Falsch? Gruß Mike Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 3. April 2006 Melden Teilen Geschrieben 3. April 2006 Hi, wenn ich dich richtig verstanden habe, wolltest du auch das Zert. des Exchange Servers auf dem Client installieren und das ist nicht nötig. Installierst Du das Zert. der CA, die dem Ex. dessen Webserver Zert. ausgestellt hat, funktioniert es. Aber das sage ich eigentlich schon die ganze Zeit :suspect: Christoph Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.