hwimmer 10 Geschrieben 18. Mai 2006 Melden Teilen Geschrieben 18. Mai 2006 Hallo, in einem unserer Standorte steht ein Windows 2003 Domänencontroller auf dem auch Exchange 2003 installiert ist! Jetzt habe ich das Problem das OWA auf diesem Server nicht funktioniert. OWA ist ja eine ASP.NET Anwendung. Könnte es evtl. daran liegen, das ASP.Net auf einen DC keine lokalen USER ASPNET anlegen kann und darum die Anwendung nicht funktioniert ? Vielen Dank für Eure Hilfe ! hwimmer Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 18. Mai 2006 Melden Teilen Geschrieben 18. Mai 2006 Hi. Sollte eigentlich schon laufen. Der SBS 2003 ist ja auch DC mit Exchange und da läuft OWA ohne Probleme. Welche Fehlermeldungen erhältst du denn ? LG Günther Zitieren Link zu diesem Kommentar
hh2000 10 Geschrieben 18. Mai 2006 Melden Teilen Geschrieben 18. Mai 2006 Funktioniert, habe ich mehrfach im Betrieb. Windows 2k3 SP1, Exchange 2k3 SP2 Fehlermeldungen? Gruß Kai Zitieren Link zu diesem Kommentar
hwimmer 10 Geschrieben 19. Mai 2006 Autor Melden Teilen Geschrieben 19. Mai 2006 Hallo, im IE bekomme ich den Fehler "Die Seite kann nicht angezeigt werden" Im Ereignisprotokoll habe ich auch nichts Auffälliges gesehen. Die IIS-Dienste laufen alle ordnungsgemäß! Danke hwimmer Zitieren Link zu diesem Kommentar
hh2000 10 Geschrieben 19. Mai 2006 Melden Teilen Geschrieben 19. Mai 2006 Was hast Du eingegeben? - http://servername/exchange oder mit https ? - stimmen die eingestellten Ports im IIS Manager (z.B. für https) - DNS, Namensauflösung funktioniert ? - vom Client probiert oder auch direkt am Server? Gruß Kai Zitieren Link zu diesem Kommentar
hwimmer 10 Geschrieben 19. Mai 2006 Autor Melden Teilen Geschrieben 19. Mai 2006 ich habe http://servername/exchange eingegeben Formularbasierende Auth. ist nicht aktiviert, d.h. Verbindungen mit http sollten auch funktionieren! Im IIS ist für http Port 80 eingestellt, bei https steht kein Port drin DNS-Auflösung funktioniert. Ich habs vom Client und auch direkt am Server probiert. Jeweils das gleiche Problem Zitieren Link zu diesem Kommentar
giffy 10 Geschrieben 19. Mai 2006 Melden Teilen Geschrieben 19. Mai 2006 Hi gehen tut alles......... Blos......??? Habt ihr keine Angst um eure Sicherheit bei dieser Lösung Was ist wenn der Server kompromitiert wird??Ist denn alles auf sicherheit gehärtet?? (Schluck) Ich bin nicht der große Sicherheits Guru. Hab auch nicht die Erfahrung. Hoffe es melden sich noch einige um hwimmer zu unterstützen. Aber ich hätte Angst. Diese Konfiguration, erfolgt weil vielleicht nur ein Gerät da ist und kein Geld (blablabla), würde ich nur unter ausdrücklicher schriftlicher Weisung meines Vorgesetzten installieren. Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 19. Mai 2006 Melden Teilen Geschrieben 19. Mai 2006 Hi. Stell einmal die Berechtigungen für OWA wieder her - http://www.msexchange.org/tutorials/Fixing-Damaged-Incorrectly-Configured-OWA-2003-Installation.html LG Günther Zitieren Link zu diesem Kommentar
hwimmer 10 Geschrieben 22. Mai 2006 Autor Melden Teilen Geschrieben 22. Mai 2006 Hallo, @ giffy Der Zugriff von Aussen läuft natürlich über SSL. Bei uns macht das aber nicht der OWA selbst, sondern die Firewall über einen Reverse-Proxy! Nur die Kommunikation zwischen Reverse-Proxy und OWA läuft über http! Also, du brauchst dir vorerst keine Sorgen über unsere Sicherheit machen! @ GuentherH Danke für den Tipp. Es hat aber leider nichts gebracht. Selber Effekt wie vorher Danke hwimmer Zitieren Link zu diesem Kommentar
ChristianHemker 10 Geschrieben 22. Mai 2006 Melden Teilen Geschrieben 22. Mai 2006 Also, du brauchst dir vorerst keine Sorgen über unsere Sicherheit machen! Es ging eher darum das Exchange auf einem Server läuft, der sämtliche Kennwörter und Benutzernamen speichert: dem Domänencontroller. Zitieren Link zu diesem Kommentar
hwimmer 10 Geschrieben 22. Mai 2006 Autor Melden Teilen Geschrieben 22. Mai 2006 Warum bietet dann Microsoft den SBS 2003 (ist ja auch DC mit Exchange) an, wenn das eine so schlimme Konfiguration ist ? Zitieren Link zu diesem Kommentar
voggench 10 Geschrieben 22. Mai 2006 Melden Teilen Geschrieben 22. Mai 2006 Beitrag von Gadget beim DC hat Security einfach vorrang deswegen sollte folgendes beachtet werden: DC + IIS / Bitte nicht => Sicherheitsanfälligkeit DC + SQL / Noch schlimmer => Sicherheitsanfälligkeit .. siehe auch SQL-Slammer DC + ISA / Niemals => Aus Sicherheitsgründen werde diese Kombination der Horror schlechthin DC + Terminalservices / Auch ganz schlechte Idee => Wer bitte lässt seine User auf nem DC arbeiten DC + MOM / Bringt nix wen ein DC ausfällt sollte MOM diese ja bitteschön melden, wie soll das aber gehen wenn MOM schon auf nem DC is außerdem siehe: 1. u. 2. DC + Sharepoint Portal / siehe 1. u. 2. DC + Fileserver / Wenns sein muss, sind meistens die zwei wichtigsten Systeme außer dem Mailserver vielleicht ... DC + Printserver / Nein bitte nicht der Stabilität verschiedener Druckertreiber vertraue ich überhaupt nicht u. ich hab schonmal am eigenen Leib erlebt, dass ein verbuggter Treiber das System zum erliegen brachte: HPBPRO.EXE killing my serverhttp://forums1.itrc.hp.com/service/forums/questionanswer.do?admit=716493758+1112194702349+28353475&threadId=370850 für alle anderen Produkte / Dienste (z.B. Live Communication server) gilt folgendes fast alle benötigen IIS und / o. SQL u. sollten deshalb auf nem DC tunlichst vermieden werden. Natürlich kann man SBS hier als Aussrede hinstellen u. sagen, da laufen doch auch viele Dienste zusammen, aber imho wurde MSFT sozusagen dazu gezwungen solch ein Produkt herauszubringen. Der Markt wollte es so, da der Geldbeutel mehr Bedeutung hatte als der reine Sicherheitsgedanke. Der SBS ist eben ein kalkuliertes Riskio u. wird immer ein "single point of failure" bleiben, was aber in manchen Umgebungen i.O. ist da die möglichen Ausfallzeiten einkalkuliert sind. In Umgebungen in denen die Downtime auf ein minium reduziert werden muss, ist eben eine solche Konfiguration nicht hinnehmbar da alle Risiken soweit wie irgend möglich ausgeschlossen werden müssen. BTW: Leider hat sich aufgrund von verschiedenen Umständen bei uns innerhalb einer Domäne die ich betreue auch ein ähnliches ungewolltes Szenario ergeben (DC + Exchange) was aber in kürze behoben wird. U. um Ressourcen (Geld + Zeit) zu sparen wird die Umgebung virtualisiert sprich mittels Virtual Server 2k5 R2 werden die Dienste auf verschiedene Gastsysteme verteilt. LG Gadget Zitieren Link zu diesem Kommentar
giffy 10 Geschrieben 22. Mai 2006 Melden Teilen Geschrieben 22. Mai 2006 Es ging eher darum das Exchange auf einem Server läuft, der sämtliche Kennwörter und Benutzernamen speichert: dem Domänencontroller. ja genau Stimme Kohn komplett zu Zitieren Link zu diesem Kommentar
hwimmer 10 Geschrieben 23. Mai 2006 Autor Melden Teilen Geschrieben 23. Mai 2006 Dann ist eigentlich nicht primär die Kombination DC + Exchange, sondern DC + IIS das Problem hier, oder ? Zitieren Link zu diesem Kommentar
ChristianHemker 10 Geschrieben 23. Mai 2006 Melden Teilen Geschrieben 23. Mai 2006 Beides. Sowohl der IIS als auch der Exchange reißen potentielle Sicherheitslücken ins System. Beide Dienste können ja dafür sorgen, dass Code von außen reinkommt und unter Umständen ausgeführt wird. Nur so als Beispiel. 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.