Perversitäten der EDV – Windows 2012

Ich hatte ja schon einmal auf die Seite „Perversitäten der EDV“ aufmerksam gemacht. Hier berichtet ein manchmal genervter IT’ler von seinen Erlebnissen, die man durchaus das eine oder andere Mal als Perversitäten bezeichnen kann. Seitdem ich (vor gut einem Jahr) meine Netzwerkumgebung auf Windows 2012 umstellen musste, erlebe ich fast täglich Ähnliches. Die letzte Perversität bringt mich dazu, mal wieder meine Antipathien gegenüber Produkten der Firma aus Redmond zum Ausdruck zu bringen.

Wie geschrieben, stellte ich seit Anfang letzten Jahres die Server unseres Firmennetzwerkes von Linux auf Windows 2012 um. Nachdem der Mailserver und diverse Kleinigkeiten umgestellt waren – ich bin immer noch verblüfft, wie viele „Zusatzprogramme“ (natürlich nicht kostenlos) Exchange braucht, um Anforderungen zu erfüllen, die z.B. bei Groupwise „out of the box“ funktionieren – folgte nun der Einsatz eines Datenservers. Waren die Umsetzung diverser Anforderungen per Group Policies zwar auf ungewohntem Wege, aber doch fehlerfrei umsetzbar, traten nun beim Dateizugriff einige Probleme auf. Die User beschwerten sich über lange Zugriffszeiten auf Freigaben bzw. lange Wartezeiten beim Öffnen von Dateien auf Netzlaufwerken. Das Setzen der Netzwerkfreigaben als permanent per GPO brachte nur kurzzeitig Besserung, ebenso war die Erhöhung des Netzwerkpuffers erfolglos.

Erst die Umstellung der Netzwerkfreigabe vom DNS-Namen des Datenservers auf die IP-Adresse brachte scheinbar Erfolg (also statt „\\se1.domain.local\Freigabe“ „z: \\IP_Adresse_des_Servers\Freigabe“ verwenden). Obwohl der Dateiserver in der Windows-Domain eingebunden und auch beim DNS-Server registriert ist, verzögert die DNS-Auflösung den Zugriff auf das Netzwerklaufwerk erheblich. Einziger Anhaltspunkt war die Meldung „Kontaktiere  \\se1.domain.local\Freigabe“ beim Öffnen der Dateien durch Word, Excel & Co.

Für mich durchaus eine Perversität  beim Serverbetriebssystem Windows 2012 …

 

PaloAlto Firewall – Its a Bug, not a feature

Bereits seit 3 Jahren setzen wir auf PaloAlto bei den Firewalls in der Firma. Bisher war ich mit der Leistung, vor allem aber mit den umfangreichen Konfigurationsmöglichkeiten der bei uns eingesetzten Firewall PA-500 sehr zufrieden. Insbesondere die Möglichkeiten, die eine Anbindung von Remote-Clients per VPN und  zur LAN-LAN-Kopplung fanden und finden in unseren Umgebung breite Anwendung. Besonders hier stellt Palo Alto seine Fähigkeiten unter Beweis. Die Sicherheitsfeatures, neben SSL-VPN u.a. Antivirus, Anti-Malware und applikationsbasierte Zugriffssteuerung, arbeiten zuverlässig und effizient.

Der Zugriff per VPN erfolgt für Windows und iOS über einen separaten Client, der auf die Komponenten der Firewall zugreift. Auf der Firewall selbst werden die Sicherheitsfeatures für das VPN konfiguriert und hier gibt es alles was das Adminherz begehrt: SSL, TLS, verschiedene Protokolle von OpenVPN bis IPSec, Verzeichnisintegration (LDAP und AD), verschiedene Authentifizierungsmöglichkeiten usw. usf. Die Anbindung von Linux- und Android-Clienten stellt(e) ebenfalls kein Problem dar: auf meinen Linuxbüchsen nutze ich den Cisico-basierten Client (VPNC), auf den Androiden habe ich mit VPNCilla sehr gute Erfahrungen gemacht.

Die Anbindung funktionierte tadellos bis, ja bis Dezember letzten Jahres. Nach einem Update der PANOS genannten Firmware der Firewall war der Aufbau eines VPNs von den Clients aus nicht mehr möglich, die LAN-LAN-Kopplung hingegen werkelte weiter ohne Probleme vor sich hin. Für die Windows-Clients erledigte sich das Problem relativ schnell: eine neue Version der GlobalProtect genannten Clientsoftware wurde bereit gestellt und alles war wieder in Butter. Nur ich selbst – der ich mich immer noch ohne Windows in der digitalen Welt bewege – konnte ums Verrecken keine Verbindung mehr zu „meinem“ Netzwerk herstellen. Natürlich suchte ich die Ursache in der Konfiguration der Clients, aber es gelang mir nicht, den Fehler einzukreisen.

Gestern stiess ich nun auf den lapidaren Kommentar zu einem Artikel über die Anbindung von Android-Clients per IPSec an die PaloAlto:

If you upgrade from some lower version to 7.x there is a bug which can be fixed by removing the gateway config and configuring to again or by changing a keyword from „any“ to Any.

Also wer ein ähnliches Problem hat: es reicht tatsächlich, die Gatewaykonfiguration zu löschen und sie mit genau denselben Einstellungen neu zu erstellen (achtet darauf das eure Dokumentation aktuell ist 😉 ). Diese Einstellungen dann auf die Firewall übertragen, fertig! Der Zugriff sowohl vom Androiden als auch den Linuxrechnern ist wieder ohne Probleme möglich.

Microsoft und die Sicherheit

Ich bin ja sehr für Sicherheit, auch und gerade am Rechner. U.a. deshalb setze ich privat kein OS aus Redmond ein. Nun gehöre ich nicht zu den Religionskriegern – auch nicht was Betriebssysteme betrifft – aber so manches „Feature“ von Windows, MS-Office usw. läßt mich doch am gesunden Menschenverstand der Programmierer und/oder Verantwortlichen bei Microsoft zweifeln.

Heute wurde ich in der Firma mit einer solchen Glanzleistung konfrontiert. Als Office-Programm setzen wir MS-Office 365 ein. Neben der leidigen „Online-Featuritis“ (die umgehbar ist) und dem ebenso umgehbaren Zwang alle Komponenten des Paketes zu installieren, überwiegen tatsächlich die Vorteile dieser Variante. Vor allem preislich auch wegen der erworbenen Upgraderechte eine interessante Option.

Ich vermeide es aber grundsätzlich die von Microsoft vorgeschlagenen Standardeinstellungen zu übernehmen, zu leidvoll meine Erfahrungen mit den „Features“ diverser Programme von Microsoft in der Vergangenheit. Einer meine User, nein einer meiner „Poweruser“ teilt allerdings weder meine Abneigung gegen die Politik der Redmonder Firma noch meine Vorsicht im Umgang mit den Programmen derselben. Das Ergebnis war mal wieder niederschmetternd.

Von einem Tag auf den anderen ließen sich Dateien auf Netzlaufwerken nicht mehr öffnen. Lapidarer Kommentar von Word, Excel und Co.: „Die Datei x.x ließ sich leider nicht öffen.“. Die Auswertung der Ereignismeldungen führte nicht zu Lösung, da ähnlichen Informationsgehalts.

Nach einigem Stöbern im Internet kam die Ursache für dieses Verhalten schließlich ans Licht: seit Office 2013 setzt Microsoft wohl wieder einmal auf mehr „Sicherheit“. Über das in Office implementierte „Trustcenter“ werden sichere Speicherorte definiert und nur dort abgelegte Dateien lassen sich öffnen. Netzlaufwerke gehören grundsätzlich nicht dazu. Diesen Fakt musste ich erst einmal verarbeiten.

Ich schätze das ca. 90% aller MS-Office-Lizensen von Firmen erworben werden und die wiederum speichern geschätzte 99% ihrer Dateien auf Netzlaufwerken! Da für Windows auch Cloudspeicher nichts anderes als Netzlaufwerke sind, wird der Wahnsinn noch offenkundiger. Ich vermute allerdings, dass Microsofts Onedrive von diesem Misstrauen ausgenommen ist (wir setzen es nicht ein). Zumindest wäre das für mich die einzige halbwegs plausible Erklärung dieses hirnrissigen „Features“.

In dem geschilderten Fall half allerdings weder die Definition der Netzlaufwerke als „sicher“ noch die Neuinstallation von Office 365 – die auf ihnen abgelegten Office-Dateien liessen sich nicht öffnen. Erst eine komplette Neuinstallation der Arbeitsstation lösten das Problem.

Unfassbar auf welche Art und Weise „Product Placement“ durch Microsoft betrieben wird! An Fehler oder Dummheit der Programmierer und/oder Entscheider will ich nicht glauben. Das wäre allerdings noch desaströser …