CoolBlue

Hallo, ein Kunde arbeitet mit Terminal Clients (Wyse) auf einen 2008 R2 Server zu mit aktivierter Desktop Experience (quasi Windows 7). Wegen seiner WaWi möchte er an einigen Stationen die Taste F6 gesperrt haben, damit die Mitarbeiter die Funktion in der Wawi nicht mehr auslösen können. Gibt es da unter Windows Möglichkeiten dies zu bewerkstelligen?

Ja so kann man auch kontern *grins* Nochmal als Klarstellung. Ich bin Dienstleister und ich bin immer dran dem Kunden auf was neues zu bewegen, da mir diese technsichen Probleme sehr wohl bekannt sind, genauso wie Norbert es schreibt. Ich bin als Techniker (nicht als Chef) aber auch der Meinung das Exchange 2003 solange Marktberechtigung hat, wie MS es pflegt. Sie hätten es doch problemlos vor 2-3 Jahren schon einstellen können.. Aber nein große Firmen die den einsetzen haben MS gebeten die Nutzungsdauer zu verlängern, weil sie es grade nicht schaffen zu migrieren. Dadurch entstehen doch diese elendig langen extended Supportzeiten. Ich finds gut das Microsoft sich überhaupt darauf einlässt. Wenn ich da Linux sehe... ohne die Enterprise Long-Term Distributionen wären Admins alle 6 Monate am Updaten mit unendlich hohen Risiken das plötzlich nix mehr geht. Ich hab selber 4 Jahre im Enterprise Segment (Firma > 1000 Leuten) gearbeitet und habe seit dem verstanden warum es manchmal länger dauert. Die unglaubliche Schier an Abhängigkeiten in solchen Firmen und natürlich die langsame Bürokratie (die ist aber nicht immer schuld!) führen dazu das Updates ewig dauern. Erst recht wenn Hersteller XY her kommt und die gesamte Plattform umwirft und dem entsprechend die halbe Umgebung neu gemacht werden muss.

Hey Norbert, ich schreibe immer ein wenig über spitzt. Das neue Versionen nicht sofort unterstützt sind ist ärgerlich aber nicht schlimm, denn das kann man ja vorher prüfen, bevor die Lösung implementiert wird. Ich bin auch für verbesserungen in der Netzkommunikation. Am liebsten würde ich SMTP einfach so gegen was neues sicheres (spam befreites) ersetzen. Geht halt nicht. Ich finds gut wenn große Firmen neue Standards setzen. Aber ich denke das hätte man auch auf April 2013 verschieben können... Wenn der kleine Nischen-MTA z. B. MDaemon probleme kriegt.. who cares... Aber Exchange 2003 wird sicherlich noch im großen maße eingesetzt, denn die firmen sagen sich "das dingen tut und MS supported es" Nen Auto (muss) ich auch erst dann kaufen wenn der TüV abläuft und nicht weil es nur 140kmh... Microsoft hat ja seit der Misere von den 2003er/XP Produkten ja auch geschworen nun schneller neue Releases zu bringen.. aber so lange halten wir halt alle noch mit IE6, Office 2003 und eben Exchange 2003 durch... Große Firmen wie GMX und WEB.DE müssen sowas vorher ankündigen find ich.. mehrere Monate vorher. Im Internet hab ich einige Threads über Exim z.b. gefunden der bei einer bestimmten Distributionsversion ebenfalls damit Probleme bekommen hat. Hätte GMX das angekündigt, inkl ein Manifest der Änderungen, hätten direkt alle Admins los gebrüllt.. "EXCHANGE 2003 MUSS JETZT RAUS". Denn sowas geht problemlos durch die Presse. Gggf noch ne Seite machen a la "www.gmx.net/istihrmtakompatibel". IP eintragen.. Test drücken.. und jeder Admin hätte agieren können, statt nun in panik reagieren. Auch wenn ich es albern finde das viele GMX, T-Offline und WEB.DE für geschäftlich WICHTIGE E-Mails nutzen.. ist dies jedoch leider so und die betroffene Firma die ne eigene Domain hat bekommt plötzlich keine geschäftlich wichtigen mails mehr und das geschrei ist groß. Und ich denke nicht das die Firma daran Schuld ist das sie noch Exchange 2003 einsetzt. Wir sind zwar alle daran interessiert durch updates Geld zu verdienen.. aber wenn ein Produkt seinen Dienst mit Bravur verrichtet.. warum ständig auf was neues Updaten? Ich als Chef kann auch nicht jedes Jahr n neuen Bürotisch, Computer, Fenster.. or whatever kaufen. :-)

Korrekt. Aber es geht um was anderes. Produkte großer Konzerne müssen von anderen großen Konzernen solange supported werden, bis sie offiziell abgeschrieben sind. Schau dir die Windows Third-Party Welt an. JEDER Hersteller supportet Windows XP, Outlook 2003, Exchange 2003. Egal ob Virenscanner oder Plugin. Sobald der 08.04.2014 vorbei ist und dann z.b. eine neue Version eines Virenscanners raus kommt, wird er für Exchange2003 nicht mehr funzen.

Schreib denen mal zurück das Microsoft Exchange 2003 noch nicht abgeschrieben hat. Der Extended Support geht bis zum 08.04.2014. Genauso wie bei Windows XP.

Ah verstehe du hast dort parallel angefragt und über FB schneller eine Antwort erhalten. Toll das geschäftlicher Support nun auch über Facebook abgewickelt werden muss....

Komisch.. wieso bekomme ich die nicht?

Office 365 werde ich meinen Kunden nicht empfehlen. Schau mal in Deutschland, da gibs einige Microsoft Cloud Dienstanbieter. Natürlich kosten die mehr als was MS haben will (den Preis kann nunmal niemand wegen Lizenzkosten erreichen!) Aber Daten die nach USA gehen sind absolut nicht mehr kontrollierbar, außerdem ist der Service eines Dienstleisters besser, als die Massencloud von MS Ich versuche mich mit dieser Dienstleistung auch gerade stark zu machen. Bei Interesse kannst du mich ja mal kontaktieren. P.S. Mein obige Meinung dient nicht dazu meine Dienstleistungen anzupreisen. Ich finde es sehr schade das es keinen SBS 2013 gibt.. der ist auch heutzutage definitiv noch erforderlich! Viele Firmen brauchen sowieso einen Server um ihre Wawi laufen zu lassen oder andere Spezial-Windows-Proggys... da kann man problemlos auch Exchange drauf knallen, wenn die Lizenzkosten vernünftig wären und MS die Installation auf dem AD erlauben würde.

Mehr Klartextdaten für die NSA.

Der IIS ist erst dann ohne Zerttifikat wenn du es beim HTTP Adapter entfernst bzw im IIS selbst. Wir reden hier aber nur vom SMTP Adapter... genauso wie du beim POP3/IMAP Adapter ebenfalls manuell die Zertifikate einpflegen musst. Jedes Protokoll einzelnd eben.

Gut das wir die exakte Namensgebung nun geklärt haben..... SSL Zertifikat entfernt?

Natürlich hat der einen... frag mich nicht nach dem genauen namen.. unterhalb des ExchangeServers/Postfachdingsbums.. neben IMAP/POP3/HTTP.

Einfach das Zertifikat beim SMTP Empfangs-Connector entfernen.

Fortinet sollte das können. Nen SMTP Relay (Proxy reicht nicht) wäre auch eine Idee. Aber nicht leicht einzurichten, da ein AD E-Mail Adressen Sync stattfinden muss, damit keine NDAs generiert werden.

Nö

Oh mann danke Newbie, die Lösung hätte mir doch sofort einfallen können. Ich hatte zwar an einen zweiten SMTP Server gedacht, jedoch dann nur an die MX Records gedacht und da gibs keine Problemlösung.. aber der Kunde hat ja ne gute Firewall dort kann ich ja nen Source-Routing einstellen, anhand der GMX Adressenbereiche. Ist natürlich auch etwas komplex die Konfiguration aber machbar.

Vermutlich das gleiche AES Algho Problem. Da hat MS wohl einen halb fertigen Patch rausgebracht ohne QS.

Solange mich der Kunde nicht zu dieser Lösung drängt, werde ich die Verschlüsselung nicht deaktivieren. Man muss es ja nicht drauf ankommen lassen.. viele MTAs nutzen die TLS Funktion Status Update: 1) Der Patch KB948963 macht meinen Server kaputt. Die AES algorithmen bringen die TLS Verbindung zum absturz. Weder checktls.com noch gnutls oder openssl können via SSL kommunizieren. Beim ersten Befehle nach STARTTLS bricht die Verbindung ab. Schließe ich AES aus, so dass er einen anderen Algho nimmt, gehts wieder einwandfrei. Also hab ich den KB wieder runtergeworfen.. nun gehen die Verbindungen wieder. 2) Mein Intermediate Zertifikat war nicht richtig installiert + der Tipp mit dem deaktivieren der alten Root CA hat den gewünschten Zertifikatschain Erfolg gebracht. Danke 3) GMX und WEB mögen Exchange 2003 immer noch nicht. Also alles wieder beim alten. Ich gebe jetzt auf und stelle den Kunden vor die Wahl: a) Kostenpflichten Microsoft Support kontaktieren. (Ich habe wenig Hoffnung das das ernsthaft was bringt) B) TLS abschalten mit der Konsequenz das gar nichts mehr verschlüsselt wird c) Update auf Exchange 2010/2013 (leider ist dazu auch eine neue Hardware Infrastruktur notwendig) d) Abwarten und Tee trinken. Wenn sich genug beschweren, reagiert GMX vielleicht. Noch ist Exchange 2003 offiziell supportet bei M$, also darf es nicht sein das große globale Unternehmen die Software ausschließen. Gute Nacht.

Also der Test oben schlägt bei mir mit dem dritten Zertifikat fehl. Allerdings bekomme ich IIS6.0 auch nicht dazu das dritte Zertifikat auszuliefern. Lokal wenn ich das SSL123 öffne zeigt er mir den Chain mit dem DV SSL und der Root CA an und sagt auhc ist gültig. Habe ebenfalls mal alle Thawte CAs gelöscht und als Paket von deren Website neu heruntergeladen und installiert. Das hilft nix. Der Exchange 2010 STMP Server liefert aber auch immer nur 2 ab. Reicht ja eigentlich auch, wenn am Client die Root CA bekannt ist. Also mein Exchange 2003 ist nun im ars***! Jede Verbindung nach einem STARTTLS wird nach MAIL FROM disconnected.. egal wer mir was sendet.... Sprich ich kann jetzt gar keine TLS Mails mehr empfangen.. hmpf.

Ja dort habe ich meinen Fall bereits geschildert und warte noch auf Antwort.

Hab ich auch schon geprüft.. beide haben ein SSL123 Zertifikat von Thawte mit der gleichen CA Chain, die laut gnu-tls auch immer mit geschickt wird, was ich ebenfalls verglichen habe. :-(

So ich hab neues Futter! Nach googles Recherchen unterstützen nur Windows 7 und Windows 2008 R2 TLS 1.1 und TLS 1.2. Hinzu kommt das beide Protokolle dort standardmäßig deaktiviert sind und in der Registry erst aktiviert werden müssen. Ich hab dies gerade mal verfiziert mit einem Exchange 2010 auf Windows 2008 R2 Server. Eine TLS 1.0 verbindung geht. Eine TLS 1.1/1.2 Verbindung wird abgelehnt *** Fatal error: A record packet with illegal version was received. *** Handshake has failed random usage: poolsize=600 mixed=7 polls=25/2 added=37/3360 outmix=2 getlvl1=2/9 getlvl2=0/0 GMX E-Mails werden jedoch auf Exchange 2010 einwandfrei empfangen! Was sagt ihr nun? Das klingt für micht nicht nach einem TLS 1.1/1.2 Problem! Ich denke das Protokoll ist auch aus Sicht von GMX/WEB.de noch zu neu um es pauschal für alle Welt zu forcieren. Ebenfalls kann TLS 1.0 die neusten Alghoritmen (AES 256 CBC SHA1). Was 1.0 nicht kann ist SHA256.. aber auch das ist brandneu und zu früh um es zu forcieren. Das Problem liegt woanders.. Andere Tipps? --- Haben wir vielleicht kein gemeinsames Problem und bei mir könnte es vill. ein TCP/IP Offloading Problem sein? Wobei dann sicherlich nicht nur GMX und WEB.de betroffen wären.. hmmm

Sagt euch das was mit - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted ?? mein gnutls-cli test zeigt jedoch das seit dem Patch nun auch AES zur Verfügung steht. Immerhin einen guten Schritt nach vorn. (Sowohl 128 als auch 256) |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[0x25ca9c0]: SERVER HELLO DONE was received [4 bytes] |<2>| ASSERT: gnutls_handshake.c:1286 |<3>| HSK[0x25ca9c0]: CLIENT KEY EXCHANGE was sent [262 bytes] |<3>| REC[0x25ca9c0]: Sent ChangeCipherSpec |<3>| HSK[0x25ca9c0]: Cipher Suite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Initializing internal [write] cipher sessions |<3>| HSK[0x25ca9c0]: FINISHED was sent [16 bytes] |<3>| HSK[0x25ca9c0]: Cipher Suite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x25ca9c0]: Initializing internal [read] cipher sessions |<3>| HSK[0x25ca9c0]: FINISHED was received [16 bytes] |<2>| ASSERT: ext_server_name.c:262 - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `OU=Go to https://www.thawte.com/repository/index.html,OU=Thawte SSL123 certificate,OU=Domain Validated,CN=mail.beba-energie.de', issuer `C=US,O=Thawte\, Inc.,OU=Domain Validated SSL,CN=Thawte DV SSL CA', RSA key 2048 bits, signed using RSA-SHA, activated `2013-01-22 00:00:00 UTC', expires `2016-02-21 23:59:59 UTC', SHA-1 fingerprint `6c6ad5d769c0901a475283136dfb76a71753c09d' - 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=(c) 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA, activated `2010-02-18 00:00:00 UTC', expires `2020-02-17 23:59:59 UTC', SHA-1 fingerprint `3ca958f3e7d6837e1c1acf8b0f6a2e6d487d6762' - The hostname in the certificate matches 'mail.beba-energie.de'. |<2>| ASSERT: dn.c:1210 |<2>| ASSERT: verify.c:281 |<2>| ASSERT: verify.c:474 - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.0 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL Dateiversion passt. Patch wurde also angenommen. Beweißt ja auch mein gnutls trace. Hmm Exchange Update ist zwar in Planung aber so Adhoc nicht möglich. Leider

Bei uns eilt es auch.. allerdings stehe ich auf dem Standpunkt das geschäftlich relevaten E-Mails bei GMX und WEB.de nix zu suchen haben. Update: Das Hotfix KB2655992 war bei uns defekt. Habe es neu installiert. Nun ließ sich auch das KB948963 installieren. Server startet gerade neu. Bin gespannt. ---- Also in der Registrierung unter SecurityProviders sind nun die neuen Verschlüsselungsmethoden (AES) usw. aufgeführt. E-Mails von GMX werden vom SMTP Dienst aber dennoch nicht angenommen. Muss für den SMTP Connector irgendwo in der Registry diese Chipsers vill freigeschaltet werden?

Oh man für was es alles Patches gibt.. Direkt mal einspielen :-) Bei mir ist schon der Patch http://support.microsoft.com/kb/2655992/de installiert, der eine höhere Versionsnummer von Schannel.dll enthält als der von dir empfohlene Patch, daher weigert sich der Patch auch zu installieren. Sind da wohl schon die neuen Ciphers enthalten aus Patch 948963? Interessant ist jedoch das in der Registrierung keine modernen Chipers sind. (Sind kleine Bildanhänge nicht mehr erlaubt? Jegliches Hochladen verweigert mir das Board.. hmpf)