Jump to content

viragomann

Members
  • Gesamte Inhalte

    23
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von viragomann

Contributor

Contributor (5/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Hi! Letzten Freitag habe auch ich endlich eine Antwort vom GMX Service erhalten: Inhaltlich wird das für die meisten nichts neues sein, doch meine ich, dass die Verbindung seitens des GMX-Servers abgebrochen wird. Wie auch immer, nun wissen wir, dass GMX das Problem erkannt hat, aber nichts dagegen tun will. Damit bleibt uns nur das, was hier schon von mehreren Leuten empfohlen wurde: Den Exchange upgraden und bis dahin einen der hier bereits genannten Workarounds einzurichten. Kroteskes Detail am Rande: Die Antwort von GMX habe ich auf meinem Exchange-Server vom Server mbulk.1and1.com über TLS bekommen, dem andere GMX-Server sämtliche Postweitergabe über TLS verweigern, obwohl ich auch eine GMX-Mailbox für die Antwort bekannt gegeben habe. Grüße
  2. TLS zu erzwingen, hatte ich bislang ohnehin noch nicht gewagt. Weiß nictht, ob das schon jeder, der Post schicken will, unterstützt. Warum nicht? Man kann doch für eine Netzwerkschnittstelle mehrere IPs konfigurierenden und den 2. SMTP auf einer dieser lauschen lassen. Oder gleiche IP und anderer Port. Für die Trennung je nach Verbindungs-Quell-IP muss man allerdings davor im NAT auf jeden Fall Sorgen. Wenn der Server direkt im Internet hängt, was ich nicht annehme, sehe ich keine Möglichkeit.
  3. Ja, genau. Man benötigt dafür eine Firewall / Router, die / der den Mailverkehr, der von den GMX-Servern auf Port 25 ankommt, auf einen anderen, nicht benötigten Port (z.B. 26) bzw. auf eine andere IP als der 1. SMTP weiterleitet. Üblicherweise erledigt das das NAT in der Firewall. Aber nicht bei jeder kann man dabei nach Quell-IP filtern, was hier nötig ist. Den 2. SMTP konfigurierst du, dass er auf diese andere IP/Port-Kombi lauscht, und bis auf das Zertifikat gleich wie den 1. Wenn du hierfür eine zusätzlich IP verwendest, vergiss nicht, diese auch auf der Netzwerkschnittstelle einzutragen.
  4. Hallo! Ehe ich hier als fauler Sack bezeichnet werde, der nur die anderen machen lässt, will ich erst mal meine relative Untätigkeit in der Sache rechtfertigen: Der Server, der dieses Problem hat, gehört meinem Chef, ich bin aber zur Zeit im Urlaub. Größten Dank gebührt hier aber CoolBlue, der nun wohl auf der Empfänger-Seite alles versucht hat. Es bleibt nun wirklich nur noch eine Reaktion von GMX abzuwarten. Ein Update des Exchange wäre auch bei uns für Ende des Jahres geplant, aber bis dahin muss der Mailtransfer funktionieren. Verschlüsselung abschalten käme für mich nur auf Verlangen meines Chefs in Frage. Bislang gab es aber offenbar keine Beschwerden. Jedenfalls keine, die massive genug sind, meinen Urlaub zu stören. Ich bin mal auch dem Link oben von NeMiX gefolgt, und habe dort mein Problem Kund getan. Vielleicht wird man bei GMX eher tätig, wenn es mehrere Beschwerden gibt. Mal sehen. Sollte es seitens GMX keine Lösung geben, würde mir als Abhilfe nur einfallen, für GMX (und andere betroffene Netze) einen eigenen virtuellen SMTP-Server ohne TLS zu konfigurieren. Die Trennung der Verbindung müsste dann durch ein quellselektives Routing erfolgen.
  5. Laut meinem Anbieter muss die gesamte Zertifikatskette am Server korrekt installiert sein, damit es keine Probleme gibt. Jedoch überprüfen dies die Webbrowser üblicherweise nicht. Auf einem Win 2k3 ist ein altes Primary Root-CA standardmäßig installiert. Das hat sich aber einmal geändert und muss erst deinstalliert oder deaktiviert werden. Siehe dazu hier Step 5: https://search.thawte.com/support/ssl-digital-certificates/index?page=content&actp=CROSSLINK&id=SO15447 Wenn die Kette passt, werden alle 3 Stufen angezeigt.
  6. Also mit meiner Logik bin ich hier längst am Ende. Die Kommunikation zwischen GMX und Exchange 2010 funktioniert, aber nur über TLS 1.0. Auch trotz AES256 und SHA1 kommt keine Übertragung auf den Exchange 2003 zustande. Ich sehe dann nicht, wo hier der Unterschied zwichen den Exchange Versionen liegt, der zum Problem führt. @CoolBlue: Mit den Updates bist du ja schon ein ganzes Stück weiter. Aber der Sache mit dem Zertifikat solltest du auf den Grund gehen, denn bei mir meldet gnutls-cli (V3.0) dieses Problem nicht und ich verwende ein gleiches Zertifikat. Vielleicht hast du das TLS schon soweit auf Vordermann, aber es scheitert nun am Zertifikat. Hier sieht das so aus: - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `OU=Go to https://www.thawte.com/repository/index.html,OU=Thawte SSL123 certificate,OU=Domain Validated,CN=firma.at', issuer `C=US,O=Thawte\, Inc.,OU=Domain Validated SSL,CN=Thawte DV SSL CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2012-07-11 00:00:00 UTC', expires `2015-07-11 23:59:59 UTC', SHA-1 fingerprint `3d237c273e9a796f634e9628bb17adf1c3b691e5' - Certificate[1] info: - subject `C=US,O=Thawte\, Inc.,OU=Domain Validated SSL,CN=Thawte DV SSL CA', issuer `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=© 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-02-18 00:00:00 UTC', expires `2020-02-17 23:59:59 UTC', SHA-1 fingerprint `3ca958f3e7d6837e1c1acf8b0f6a2e6d487d6762' - Certificate[2] info: - subject `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=© 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', issuer `C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,EMAIL=premium-server@thawte.com', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-17 00:00:00 UTC', expires `2020-12-30 23:59:59 UTC', SHA-1 fingerprint `1fa490d1d4957942cd23545f6e823d0000796ea2' - Version: TLS1.0 - Key Exchange: RSA - Cipher: ARCFOUR-128 - MAC: MD5 - Compression: NULL - Handshake was completed Hier gibt es 3 Zertifikate in der Kette. Bei dir fehlt offenbar die ROOT-CA "thawte Primary Root CA". Überprüfe deine Installtation mal hiermit: https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO9555&actp=LIST&viewlocale=en_US
  7. Hallo! Haben hier genau dasselbe Problem und hab mir eben erst die Logs dazu angesehen: Exchange 2003 Thawte SSL 123 STARTTLS aktiviert GMX Mails kommen nicht an GMX meldet dem Versender irreführend "A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address failed: <user>@gmx.at" Auf die Idee, dass dieses Problem mit dem Zertifikat zusammenhängen würde, wäre ich wohl nicht so schnell gekommen. Andere Server, darunter Banken und Versicherungen, die für restriktive Sicherheitseinstellungen bekannt sind, haben damit aber kein Problem. GMX hat seine Server laut den Logs am 5. 8. nacheinander auf TLS umgestellt. Seitdem kommen die Mails nicht mehr an. Habe auch nach einem Service-Kontakt bei GMX gesucht, wo ich das melden könnte, aber nur kostenpflichtige Telefonnummern gefunden. Dann bin ich auf diesen Thread gestoßen. Bin gespannt, was dir GMX antwortet. Grüße
  8. Als ob ich mit diesem Problem nicht schon genug abgestraft worden wäre, muss ich noch die Standard-Belehrung über mich ergehen lassen :cry: Vielleicht kann mich das ein wenig entschuldigen: Ich habe leider keinen 2k8 Testserver zur Verfügung und auf 2 2k3 Testserver lief die Sache ohne Probleme.
  9. Hallo NG! Ich möchte hier alle, die einen SMTP-Server auf Win2k8 betreiben warnen: Nach dem Update KB976323 vom 13. April, das Sicherheitsprobleme von Exchange- und SMTP-Server lösen soll, auf einem Windows Web Server 2008 x64 war die gesamte Konfiguration des SMTP-Servers weg. Damit war kein Mailversand über dem Server möglich, weil die Liste der zugriff-berechtigten Computer leer war. :( Gar nicht nett auf einem Produktivserver, der nach dem Update den nötigen Neustart irgendwann nachts duchführt. In einem anderen Forum meldete ein Geschädigter gleiche Auswirkungen bei Server 2k8 u. 2k8 R2. Also Vorsicht! Ich empfehle denjenigen, denen das Update noch bevor steht, zuerst die Metabasis des SMTP zu sichern und nach dem Update einfach wieder zu laden. Grüße viragomann
  10. Verstehe ich das richtig, die Site liegt nicht lokal sondern im Netzwerk auf eine Freigabe? Das bedeutet, dass die Authentität des Benutzer der sich im IIS anmeldet ans Dateisystem weitergegeben wird und dieser benötigt dann auch die NTFS-Freigabe. Wenn du anonyme Auth verwendest und die Site liegt lokal wird diese Berechtigung vom IIS automatisch vergeben (IUSR), nicht aber, wenn die Site im Netzwerk liegt. Hier hat IUSR keinen Zugriff. Dann musst du einen Benutzer in der Ziel-Domäne anlegen und diesem Zugriff auf die Freigabe geben und im IIS unter "verbinden als" diesen Benutzer samt Passwort angeben. Grüße, Richard
  11. Hallo! Die gleichen Zugangsdaten wie bei der anonymen Auth? Bei der anonymen verlangt der IIS doch keine Zugangsdaten. Und was für ein Script? Grundsätzlich muss jeder User sich nicht nur beim IIS authentifizieren, er muss auch autorisiert sein, auf die jeweiligen Daten zuzugreifen. D.h. er benötigt die entsprechenden NTFS-Berechtigungen am lokalen oder UNC-Pfad oder in deinem Fall auf die Freigabe. Wenn du die anonyme Authentifizierung verwendest, wird diese Berechtigung vom IIS 7 automatisch gesetzt, ohne sie im System anzuzeigen. Der Benutzer bekommt dann vom IIS die Authentität des IUSR. Beim IIS 6 musste man dieses noch manuell einrichten. Wenn du aber die Windows-Authentifizierung verwendest, muss der Benutzer, der sich anmeldet oder besser die Gruppe Zugriff auf die Freigabe haben, zumindest "Lesen" oder "Lesen + Ausführen", wenn dort Scripte (ASP, etc.) liegen. Und das musst du in jedem Fall manuell einrichten. Grüße, Richard
  12. Hallo allerseits! Wir haben auf einem 2k8- Webserver eine Anwendung laufen, deren Benutzer sich über Digest-Auth im AD anmelden müssen. Je nach Einstellung im AD sollen die User gezwungen werden ihr Kennwort zu ändern. In 2k8 wurde aber das Modul IISADMPWD, das in den Vorversionen zum Ändern von Benutzerkennwörter benutzt wurde, ersatzlos (imho) gestrichen. Kennt jemand einen Weg, diese Funktionalität auf 2k8-Server wieder zu bekommen? Ich habe zwar im Netz einiges zum Thema gefunden, doch alle Artikel boten fast ausschließlich Lösungen für OWA. Danach muss man das IISADMPWD-Verzeichnis auf 2k8 kopieren und dort die entspr. DLL registrieren und den Link in OWA entsprechend setzen. Die Scripte zur KW-Änderung funktionieren dann auch, nicht aber die automatische Weiterleitung zum IISADMPWD-Script obwohl ich die IIS 6-Metabasisverwalungskompatibilität installiert habe und mit IIS Metabase Explorer die jeweiligen Records AuthExpiredURL, AuthChangeURL, usw. für die Website eingetragen habe. Diese Records scheinen den IIS 7 einfach nicht zu interessieren, was sich so äußert: Wenn im AD-Konto "Benutzer muss Kennwort bei der nächsten Anmeldung ändern" gesetzt ist, meldet der IIS "HTTP-Fehler 401.1 - Unauthorized - Die angegebenen Anmeldeinformationen berechtigen Sie nicht, dieses Verzeichnis oder diese Seite anzuzeigen." Für das IISADMPWD-Verzeichnis ist jedoch die anonyme Auth eingerichtet. Der Benutzer wird einfach nicht dort hin geleitet. Jemand eine Idee? Grüße Richard
  13. Moin, danke für eure Antworten. Es sind einige interessante Anätze dabei, die Sache wohl besser zu lösen. Die Variante mit dem Dienst von NilsK finde ich gut. Doch müssen wohl die entsprechenden Berechtigungen, diesen Dienst zu starten wohl auch erst erteilt werden. Die Lösung mit der ASP.Net Seite von de.le könnte ich mir auch ganz gut vorstellen. Ich wollte aber für den einen 2k8 Webserver nicht soviel Aufwand treiben und die Bedienung des Ganzen hätte ich gern serverunabhängig gehabt. Ich werd mir die Lösungen durch den Kopf gehen lassen. Immer noch unbeantwortet ist allerdings die Frage, wie man auf dem 2k8-Server ein Script mit erhöhten Privilegien ausführen kann, oder muss ich jetzt fragen, ob dies überhaupt möglich ist? Und heißt unter Server 2k8 "als Administrator ausführen" dass das Programm unter dem Konto des lokalen Administrators ausgeführt wird. Als Domain-Admin angemeldet zu sein, reicht ja wohl nicht. Anmerken möchte ich noch, dass die User die das Script starten auch Administratoren in ihrem Bereich sind und auf den Rechner, auf dem sie es starten, haben auch nur Administratoren Zugriff; auf dem Rechner, auf dem die Funktionen ausgeführt werden, haben sie administrative Berechtigungen. Darum hatte ich mir über die Sicherheit bislang keine ernsthaften Sorgen gemacht. Grüße, viragomann
  14. Hallo! Die Frage hatte ich in folgenden zwei Sätzen gestellt, wenn auch nicht so direkt: Ich hätte gedacht, ich hätte alles nötige aufgezählt. Wenn ich alle möglichen Funktionen beschreibe, würde das Seiten füllen, die wohl niemand lesen möchte. Das eine Problem ist das Werkzeug Appcmd.exe das aus dem Script am entfernten Server aufgerufen wird und höhere Privilegien erfordert. Das andere Problem ist, dass auch in Dateien des User-Rechners eine Rückmeldung geschrieben werden soll. Ersteres erfordert, Stand meines Wissens, lokale Admin-Rechte, das zweite zumindest Domain-Benutzer-Rechte. Für etwaige nötige Verbesserung wäre ich sehr dankbar. Funktionen am enternten Server im Überblick: Website stoppen Application Pools recyclen über CollabNet SVN ein Verzeichnis aus dem Repository (erfordert Authentifizierung in dessen String) aktualisieren Website umleiten Website-Konfiguration wieder in ursprünglichen Zustand setzen Website starten Logs und Rückmeldungen generieren diese auf den auslösenden Rechner kopieren bzw. per Mail (bmail.exe) versenden einen geplanten Task (Aufgabe in W2k8isch) löschen Alles, was den Webserver betrifft macht appcmd.exe. So würd ich es mir jedenfalls wünschen. Wenn du mich auch prügelst, ich weiß nicht, was ich dazu mehr aufzählen sollte. Gruß, viragomann
  15. Dieses Konstrukt erledigt verschiedene Dinge, die tlw. Admin-Rechte erfordern. Die entsprechende Konfiguration dafür (Pfade, virt. Server) holt sich erst das Script am jeweiligen Server, das psexec dort ausführt. Das ursprünglich gestartete Script soll also verschiedene Server bedienen. Das heikelste ist wohl das temporäre Anhalten eines virtuellen Webservers, weil es diesen wieder automatisch starten soll, wenn der User etwa darauf vergisst und es dadurch aktiv bleiben muss. Dazwischen sind Rückmeldungen an den User nötig. Keine Idee, wie ich das anstellen soll :confused:. Der User, der die Sache startet, hat eben nicht die benötigten Rechte und bei W2k8 sind noch dazu (glaube ich) lokale Admin-Rechte nötig. Ob letzteres auch tatsächlich so ist, war eine der eigentlichen Fragen. CPAU.exe kenne ich nicht, werde mich aber auf die Suche machen. Danke. Gruß, Richard
×
×
  • Neu erstellen...