Dieser Beitrag ist eine Fortsetzung der kleinen Artikelserie zur Optimierung der HTTP-Header für mehr Sicherheit auf der Webseite und für alle Webseitenbesucher. In Teil 1 ging es um die zwei noch recht einfachen Header HSTS und X-XSS-Protection. Teil 2 wird nun den recht komplexen aber mächtigen Header Content-Security-Policy behandeln.
Es benötigt vom Webmaster schon einiges an Vorbereitung und Testing, um mit diesem Header nicht auch Schaden anzurichten, aber der Zugewinn an Schutz gegenüber Angriffen oder Code Injection ist bemerkenswert.

CSP für umfangreiche Datenherkunftseinschränkung

Der Content-Security-Policy Header überprüft die Art und Herkunft von Daten und Anfragen während des Ladens und kann darauf reagieren. So können beispielsweise bestimmte Datentypen wie Skripte oder Stylesheets, die von einer anderen URL als der gerade zu ladenden Webseite angefragt werden, geblockt werden. Damit wird verhindert, dass unerwünschte, fremde oder gefährliche Inhalte geladen und ausgeführt werden. Das ist für gewöhnlich das Ziel von XSS-Angriffen, welche über zahlreiche Tricks versuchen, schädliche Inhalte in vertrauenswürdige Seiten einzubinden.
Damit das jedoch so funktioniert, muss der Webmaster für alle oder einzelne Inhaltstypen die jeweiligen vertrauenswürdigen Quellen definieren. Hier wird es knifflig. Vergisst der Admin eine vertrauenswürdige Quelle, werden Inhalte von dort nicht mehr geladen und fehlen auf der Webseite. Das kann dazu führen, dass Schriftarten oder Bilder fehlen, Skripte und somit ganze Funktionen nicht mehr laufen und die Webseite sich in andere Seiten nicht mehr einbetten lässt. 
Die vertrauenswürdigen Ursprünge sind entweder bekannt oder müssen erarbeitet werden.

1. Informieren

Eine zu restriktiv gesetzte CSP kann die Webseite wie gesagt teilweise beschädigen. Ich empfehle daher die mehrstufige Vorgehensweise: Informieren, testen, optimieren und schlussendlich aktivieren.

Ein erster Blick lohnt beispielsweise bei MDN. Hier sehen wir, welche Direktiven und welche Werte möglich sind. Ich gehe später nochmal genauer auf die einzelnen Werte ein. Erst einmal solltet ihr euch einen groben Überblick holen. Nutzt für weitere Informationen neben diesem Artikel auch die Intros von html5rocks.com, SelfHTML, den Mehrstufen-Ansatz von dareboost.com und die dort verlinkten weiteren Artikel zu CSP-Basics und auch die vielen kleineren Webseiten und Blogger mit deren CSP-Empfehlungen.

2. Testen

Wir beginnen mit Tests, die keine Schäden anrichten können. Dazu nutzen wir das Report-Only Feature der CSP. Hierfür wird eine valide CSP über Content-Security-Policy-Report-Only gesetzt, angewendet aber nicht ausgeführt. Es werden Warnungen und Fehler ausgegeben, aber keine Anfragen tatsächlich blockiert. Gesetzt wird es wie gehabt in der .htaccess der Webseite:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; img-src 'self' https://secure.gravatar.com https://s.w.org https://wordpress.org https://ps.w.org data:; font-src 'self' fonts.gstatic.com data:; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; connect-src 'self'; child-src 'self'; report-uri https://report-uri.de/report.php;"
</IfModule>

Der Inhalt dieser CSP ist erst einmal nur kopiert von kittpress.com und angepasst an das Report-Only Feature via .htaccess. Von hier arbeite ich mich dann weiter.

Die CSP wird nun theoretisch angewendet, aber nicht endgültig ausgeführt. Nun könnt ihr anhand der Browser-eigenen Dev-Tools und der Reports die Problemstellen identifizieren.
Wie ihr eine Report-Schnittstelle einrichtet, die beispielsweise Reports in eine Logdatei schreibt, habe ich im ersten Teil dieser Artikelserie erklärt. Ihr könnt auch genau dieselbe Reportschnittstelle hierfür nutzen, das funktioniert einwandfrei. Alternativ könnt ihr auch externe Report Services wie diesen als Ziel für eure Reports wählen.
Gegenüber euren Browsertools haben die Reports den Vorteil, dass jede CSP-Verletzung jedes Website-Besuchers an euch gemeldet wird – ohne, dass ihr dafür dann noch etwas tun müsst. Außerdem habt ihr alle Meldungen dann in einer großen und zentralen Server-Log (ggf. auch per Mail) und müsst nicht selbst rumsurfen und die Devtools abkopieren. Es geht ansonsten aber auch ohne report-uri.

3.1 Optimieren

Bei meinem ersten Test landeten weit über 100 Reports innerhalb von 1 Minute in der Report-Log – das reicht für eine erste Optimierung. Also habe ich die CSP erst einmal wieder deaktiviert/auskommentiert und die ersten Ausnahmen erstellt. Dazu habe ich mir jeden Report einzeln angesehen, wenn nötig eine Ausnahme erstellt, alle Logeinträge dieses spezifischen Problems entfernt, nächten Report angesehen. So lange, bis die Report-Log wieder leer war.
Anschließend die neue CSP wieder einkommentieren und wieder dreistellige Reports sammeln.
Diesmal dauert es länger und es kommen kleinere oder speziellere Probleme zum Vorschein: Von externen Seiten eingebundene Bilder oder Medien, alte http:// embeds von z.B. alten Google Maps Projekten, extern genutzte Services, Einbindungen von Inhalten noch über meine alte Domain hannes-schurig.de, externe Inhalte in Kommentaren usw.
Ich habe hier durchaus 2-3 Stunden verbracht, alte Blogartikel zu bearbeiten, Links zu korrigieren, meine alte Domain überall zu ersetzen, Kommentare zu korrigieren und mehr.
Nach 4-5 Iterationen über 3 Tage ist meine CSP nun ganz gut und die letzten 24 Stunden ergaben nur noch Reports, die geblockt werden können. Es verbleiben Logs von geblockten Domains wie countmake.cool, loadsource.org und eluxer.net – fragt mich nicht, was das ist. Manche Blocks kommen durch data, blob oder chrome-extension, ich denke das ist auch okay zu ignorieren.

Mit dieser Endfassung bin ich nun also ganz zufrieden und werde diese nun endgültig aktivieren:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; \
script-src 'self' 'unsafe-inline' 'unsafe-eval' www.google-analytics.com https://*.googleapis.com https://www.google.com https://www.gstatic.com https://*.vgwort.de https://*.it-stack.de; \
img-src 'self' https://*.gravatar.com https://*.w.org https://*.wordpress.org www.google-analytics.com https://*.vgwort.de https://www.gstatic.com https://*.it-stack.de data:; \
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://*.it-stack.de https:; \
font-src 'self' data: https:; object-src 'none'; \
child-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
frame-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
worker-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https; \
connect-src 'self' wss://it-stack.de www.google-analytics.com https://*.vgwort.de; \
report-uri https://report.tld/report.php"
</IfModule>

Die Backslashes am Ende der Zeilen ermöglichen Zeilenumbrüche in .htaccess Dateien zur besseren Lesbarkeit.

3.2 Verstehen

Ein paar kleinere Hinweise oder Ergänzungen dazu:

default-src ’self‘ wird angewendet, wenn eine andere Direktive, die für eine Anfrage gebraucht wird, gar nicht vergeben wurde. Ist eine Direktive gesetzt, wird default-src komplett überschrieben, dortige Werte werden nicht vererbt. Beispiel: img-src abc.com würde das ’self‘ von default-src nicht vererben, ’self‘ sollte daher fast immer mit angegeben sein.

Mir ist klar, dass unsafe-inline/-eval die größte Schwachstelle der CSP sind, allerdings auch das größte Problem bei WordPress Blogs mit etlichen Plugins, Google Analytics und mehr. Der Aufwand, diese zwei Attribute zu entfernen, kann sehr aufwändig und langwierig werden. Ich betrachte diese CSP jetzt vorerst als (wenn auch schon fortgeschrittenes) MVP – minimum viable product 😉

CSS-Stylesheets wirken eher harmlos, enthalten schließlich nur kosmetische Informationen, wieso einschränken? Es ist nicht zu unterschätzen, wieviel Spionage auch durch CSS-Angriffe wie z.B. „CSS Exfil“ möglich ist.

Ebenso Fonts, ist das nicht etwas too much? Nein, auch Fonts können zu Keyloggern umfunktioniert und müssen daher ebenso gut eingeschränkt werden.

child-src ist noch CSP Version 2 und wird angeblich (laut dieses Validators) in Version 3 durch frame-src und worker-src ersetzt. Ich habe also vorsichtshalber einfach mal alle drei Direktiven so gesetzt. Parallel am besten immer noch mit Google’s Validator testen.

4. Aktivieren

Nachdem die CSP nun definiert und einige Stunden ohne neue benötigte Regel im Testbetrieb lief, kann sie nun aktiviert werden. Dazu einfach nur Content-Security-Policy-Report-Only in Content-Security-Policy umschreiben und fertig. Beobachtet selber noch einmal die Webseite, auch das Admin Backend und wenn alles funktioniert, ist es geschafft!

Ich werde vorerst die Log noch im Blick behalten, bin aber erstmal froh, auch diesen Punkt soweit erledigt zu haben:

Es wird langsam… 3 Security Header gesetzt, CSP ist neu

mehr-website-sicherheit-mit-http-header-hsts-xss-protection-banner

Zum Start dieser kleinen Serie, inspiriert durch einen Sicherheitsreport meines Blogs von enginsight.com (dazu mehr im November), erst einmal die Grundlagen der HTTP-Header:

Was sind HTTP-Header und wofür brauche ich sie?

HTTP-Header, oder in diesem Artikel vor allem die HTTP-Header-Respond-Felder, sind ein Teil der Antwort eines Webservers an den anfragenden Client (mehr dazu). Sie enthalten Anweisungen, Informationen und Einschränkungen der Verbindung zwischen Browser und Server, aufgebaut als eine Vielzahl an Schlüssel-Wert-Paaren.
Der Betreiber einer Webseite oder eines Webservers kann diese Antwortfelder teilweise konfigurieren und damit die Sicherheit der Webseite und des Verbindungsaufbaus erhöhen. Die Felder, die speziell für mehr Sicherheit entwickelt wurden, werden auch kurz HTTP-Security-Header genannt.

Die Anpassung der Header kann unterschiedlich erfolgen und ist vom Webserver oder der Webhosting Umgebung abhängig. Webserver bieten für HTTP gewöhnlich Konfigurationsdateien an, teilweise gibt es diesen Zugriff auch in root-Webhosting-Lösungen. Für „normales“ Webhosting geht das größtenteils auch über eine .htaccess in der obersten Ebene. Das könnte im Falle meines Webhosters All-Inklusive beispielsweise sein:
/www/htdocs/w00bxxxx/.htaccess

Mögliche Probleme mit .htaccess bei Shared Webhosting

Achtung: Eventuell werden Header Anpassungen von eurem Hoster geblockt/entfernt. Das liegt dann an der Art und Weise der Webserver-Konfiguration.
Sidestory: Bei meinem Hoster All-Inklusive, dessen Shared Hosting Server größtenteils PHP über FPM/FastCGI realisieren, ist das beispielsweise der Fall. Hier müssten die Einstellungen direkt im VHost gesetzt werden, das kann nur der Hoster selbst. Freundlicherweise hat mich All-Inkl nach einer Nachfrage auf eine moderne Serverfarm umgezogen, wo ich mittels .htaccess auch Header setzen kann.
Sollte das für euch nicht möglich sein, funktioniert für WordPress auch der Workaround über die functions.php, den ihr auf dieser Seite ganz unten im letzten Absatz findet. 
Teilweise kann es auch sein, dass die Einträge durch Einstellungen im Admin-Backend überschrieben werden. So kann es sein, dass HSTS, „Enforce SSL“ und ähnliche Domain-basierte Eigenschaften in der Domänenverwaltung angepasst werden und die .htaccess Angaben überschreiben.

Hier die Analyse meines Blogs von securityheaders.com vor der Optimierung der Security Header:

mehr-website-sicherheit-mit-http-header-hsts-xss-protection-header-analyse-davor
Security Header Analyse vorher mit der Endwertung D, nicht so vorteilhaft…

Kein sehr gutes Bild. Wird Zeit, daran zu arbeiten! Wir beginnen mit zwei recht unkomplizierten Security Feldern, HSTS und XSS-Protection. Sie bieten einen guten Einstieg in das Themengebiet und benötigen jeweils nur 1 Zeile in der .htaccess. Aber nun in die Details:

HTTP Strict Transport Security – SSL & HTTPS, bis dass der Tod uns scheidet

HSTS (HTTP Strict Transport Security) sollte ausschließlich aber unbedingt dann konfiguriert werden, wenn die Webseite SSL verschlüsselt (über https) erreichbar ist und nicht mehr über unverschlüsseltes HTTP erreichbar sein soll. HSTS gibt vor, dass und für welchen Zeitraum in der Zukunft alle Anfragen über SSL vom Client zum Server geschickt werden müssen.

<IfModule mod_headers.c>
  # Die einfache HSTS Variante, halbes Jahr Zeitfenster
  # Header always set Strict-Transport-Security "max-age=15778463"
  # oder noch sicherer mit Subdomains, preload und allen Subdomains
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Zwei Werte sind hier wichtig: max-age und der optionale Parameter includeSubDomains. max-age ist die Zeitangabe in Sekunden, wie lange der Zugriff in Zukunft für diesen gerade aufrufenden Client ausschließlich über SSL erfolgen muss. Der Wert 31536000 steht demnach für 1 Jahr. Ist die Webseite innerhalb dieser Zeit nicht über https erreichbar, weil beispielsweise das Zertifikat abgelaufen ist, kann sie nicht mehr geöffnet werden. Browser geben dann diese Art von Fehlermeldung und für den Nutzer ist hier Endstation. Das kann jetzt für den Nutzer doof sein, sorgt aber für ein hohes Sicherheitsminimum, das nicht unterschritten werden darf. Eigentlich ein Plus.

Ein Blick in die weiteren Eigenschaften von HSTS lohnt sich

Die zusätzliche Angabe includeSubDomains erweitert dieses Verfahren auf alle Subdomains, ein Wildcard-Zertifikat ist hier also von Nöten. 
Zu guter Letzt gibt es noch die preload-Eigenschaft, die noch nicht Teil des offiziellen Standards ist. Es ist die Crème de la Crème der HSTS-Absicherung und implementiert den HSTS-Schutz für eure Domain explizit und direkt in alle modernen Browser (akt: Chr, FF, Opr, Saf, IE11, Edg). Dafür muss die Seite jedoch HSTS ordentlich eingebunden haben und auf dieser Seite registriert werden. Dieser Artikel beschreibt sehr ausführlich und einfach dieses Attribut und all seine Details.
Prüft die HSTS-Eigenschaften eurer Seite beispielsweise hier. Mehr Informationen zu HSTS auch hier. Einen ausführlichen Check eurer SSL-Servereigenschaften könnt ihr hier initiieren – das dauert 2, 3 Minuten, ist aber sehr ausführlich und informativ.

X-XSS-Protection – steckt mehr drin als gedacht

Als nächste Eigenschaft schauen wir auf das Feld X-XSS-Protection. Dieses steuert Browser-Features, welche XSS-Attacken erkennen und verhindern. Diese Mechanismen sind normalerweise aktiviert, können aber von Servern oder vom Nutzer deaktiviert werden; X-XSS-Protection erzwingt die Nutzung dann entsprechend der Angabe. Oft lese ich, dass der Header nur von IE und Chrome, teilweise auch von Safari ausgewertet wird. Laut MDN wird der Header jedoch von allen Browsern bis auf Firefox unterstützt. Folgende Umsetzung via .htaccess:

<IfModule mod_headers.c> 
  # Schutz aktivieren und Rendern verhindern bei einem Angriff
  # Header always set X-XSS-Protection "1; mode=block" 
  # oder noch besser: Seite aufräumen, rendern und Angriff melden:
  Header always set X-XSS-Protection "1; report=http://reportingserver.com/reporting_URI.php
</IfModule>

Relativ einfach: Der erste Wert 1 erzwingt-aktiviert den Schutz, mode=block stoppt das Rendering der Seite und blockiert sie komplett. Ohne mode=block wird die Anfrage gereinigt und dann ausgeführt. Soweit so einfach.

XSS-Protection Reporting – Mitlesen der Angriffe

Nun kommt jedoch noch eine spannendere Anweisung, die leider auf kaum einer Infoseite beschrieben wird; vermutlich, weil es etwas mehr Text brauch. Denn die report-Anweisung ermöglicht die Angabe einer Reporting-URI, an die ein Bericht des Angriffs geschickt wird. Das dortige Skript kann nun beispielsweise loggen, benachrichtigen oder beliebig anders reagieren. Das finde ich besonders wert- und sinnvoll, daher hier noch der Aufbau:
Beginnen wir mit dem beispielhaften Aufbau eines XSS-Protection Report Requests, welcher mittels POST an die URI geschickt wird:

POST http://test.local/foo HTTP/1.1
Host: test.local
Connection: keep-alive
Content-Length: 116
Pragma: no-cache
Cache-Control: no-cache
Origin: http://test.local
X-FirePHP-Version: 0.0.6
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36
Content-Type: application/json
Accept: */*
DNT: 1
Referer: http://test.local/test.php?foo=%3Cscript%3Ealert(1);%3C/script%3E
Accept-Encoding: gzip, deflate
Accept-Language: cs,en-US;q=0.8,en;q=0.6

{"xss-report":{"request-url":"http://test.local/test.php?foo=%3Cscript%3Ealert(1);%3C/script%3E","request-body":""}}

Nun wird der Request gegen ein PHP-Skript geschickt und dort empfangen, in eine Datei geloggt und per Mail an den Admin geschickt. Dazu habe ich diesen MDN-Code etwas erweitert: Es gibt jetzt mehr Mailing-Optionen und die Möglichkeit, eine E-Mail bei jedem Angriff zu senden, statt nur beim ersten:

<?php
// Start configure
$log_file = dirname(__FILE__) . '/xss-report.log';
$log_file_size_limit = 10000000; // in bytes = 10MB - once exceeded no further entries are added
$email_every_attack = true;
$email_sender = 'phpmailer@mysite.de';
$email_recipient = 'admin@mysite.de';
$email_subject = 'XSS Violation';
$email_charset = 'utf-8';
// End configuration

$current_domain = preg_replace('/www\./i', '', $_SERVER['SERVER_NAME']);
$email_subject = $email_subject . ' on ' . $current_domain;
http_response_code(204); // HTTP 204 No Content
$json_data = file_get_contents('php://input');

// We pretty print the JSON before adding it to the log file
if ($json_data = json_decode($json_data)) {
  $json_data = json_encode($json_data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
  if ($email_every_attack) {
    // Send an email
    $message = "XSS violation on " . $current_domain . ":\n\n" .
      $json_data . "\n\n" .
      "Logfile:" . $log_file;
    $headers =  "From: ".$email_sender."\r\n".
                "Content-Type: text/plain;charset=".$email_charset;
    mail($email_recipient, $email_subject, $message, $headers);
  } else if (filesize($log_file) > $log_file_size_limit) {
    exit(0);
  }
  file_put_contents($log_file, $json_data."\n", FILE_APPEND | LOCK_EX);
}
?>

Am besten testet ihr die Reporting-Funktion vorher, beispielsweise über einen online API-Tester. Baut euch einfach den Request zusammen und schickt ihn an eure Report-URI. Das funktioniert gut und dient mir nun als Informationsquelle, welche XSS-Angriffsversuche mit exakt welchen Anfragen gegen meine Seite gefahren werden. Hier nochmal das Setup visuell:

mehr-website-sicherheit-mit-http-header-hsts-xss-protection-report-setup_thumb
XSS-Protection Reporting Setup mit Logging und Mailing

Es sei erwähnt, dass die X-XSS-Protection durch die neuere und komplexere Content Security Policy (CSP) ersetzt wird. Das schauen wir uns im nächsten Artikel genauer an. Solange dieses Feld aber noch nicht komplett von allen Browsern unterstützt wird, empfiehlt es sich weiterhin, XSS-Protection zu verbauen (zumal es so einfach ist).

Abschluss der ersten Optimierung

Die ersten zwei Security Header sind damit optimiert, ein erster Schritt:

Vorspiel

Ich habe in letzter Zeit auf Arbeit mit einigen Rechnern gekämpft, die die AD-Gruppenrichtlinien nicht mehr ausführen wollten, genau genommen gar keine AD-Verbindung mehr hatten. Die Anzahl der Geräte, die sich bei meinem Deployment-Manager gemeldet haben, sank immer weiter.
Mit den PCs schien ansonsten alles in Ordnung: Domänenmitgliedschaft, Internet, Intranet, Serververbindung mit Netzlaufwerken, alles da.
Wie kommt’s?

Weiterlesen

Die Anleitung in diesem Artikel funktioniert vermutlich immernoch einwandfrei, allerdings bevorzuge ich mittlerweile die wesentlich einfachere Deployment-Methode, die ich in diesem Deployment-Guide beschrieben habe.

Intro

Das Deployment von Adobe Reader DC im Windows Netzwerk via GPO Batch-Startscript ähnelt der Verteilung des alten Adobe Readers sehr – dennoch fasse ich die wichtigsten Steps hier zusammen.

Vorbereitung

Ihr braucht für die Verteilung immer die DC-Basisversion (als .msi) und das aktuellste, gewünschte Update (als .msp).
Außerdem, um die Reader Installation vor dem Deployment anzupassen, den installierten Reader DC Customization Wizard.

Step-by-Step

  1. Lokale AIP-Installation (z.B. C:\adc1516\) der Basisversion mit:
    msiexec /a AcroRdrDC1500720033_de_DE.msi

    Das Bild zeigt den Reader DC Installationsdialog, der durch die AIP gestartet wurde

  2. Aktuellsten Patch in die lokale AIP-Installation Slipstreamen (lokalen .msi Pfad beachten):
    msiexec /a "C:\adc1516\AcroRdrDC1500720033_de_DE.msi" /p AcroRdrDCUpd1501720053.msp

    Das Bild zeigt den CMD Befehl um das aktuelle Reader DC Update in die lokale AIP Installation zu slipstreamen

  3. Im lokalen AIP Ordner C:\adc1516 eine leere setup.ini Datei erzeugen und die AcroRdrDC1500720033_de_DE.msi in AcroRead.msi umbenennen (Letzteres ist nur eine kosmetische Anpassung).
  4. Mit dem Adobe Reader DC Customization Wizard die C:\adc1516\AcroRead.msi öffnen und beliebig anpassen. Änderungen wie vorgegeben als AcroRead.mst speichern.
    Das Bild zeigt den Adobe Reader DC Customization Wizard
  5. (Es müssten jetzt 3 Dateien und 4 Ordner in C:\adc1516\ existieren.) Den lokalen AIP-Ordner auf euer Deployment-Laufwerk verschieben.
    Das Bild zeigt die fertige Reader DC Deployment Installation im Deployment Share
  6. Deployen mit der .msi und .mst:
    start /w msiexec /i "%wd%\deploy\%version%\AcroRead.msi" /qn TRANSFORMS="%wd%\deploy\%version%\AcroRead.mst"

infos, infos, infos, via

Skript und Deploy

Das Deployment habe ich seit Reader 11 etwas verändert. Statt „complete-Ordner“ setze ich nun auf eine Versionsüberprüfung der Programm-exe. Das ist dynamischer und lässt sich differenzierter behandeln. Im Falle von Reader DC ist die Versionierung jedoch etwas seltsam. Beispielsweise lautet das aktuellste Update „AcroRdrDCUpd1501720053.msp“, nach der Installation wird die Dateiversion der .exe jedoch mit 15.17.20050 angegeben. Möglicherweise haben hier die Entwickler geschlampt.

Jedenfalls ist für die Verteilung mit Versionsüberprüfung noch ein Zwischenschritt notwendig:
Schaut im gerade erstellten lokalen AIP-Ordner, bzw. den schon aufs Deployment-Laufwerk kopierten Ordner die Eigenschaften Datei AcroRd32.exe an (liegt unter .\program files\Adobe\Acrobat Reader DC\Reader\) – im Tab Details steht die Versionsnummer, die ihr ins Skript und somit auch als Ordnernamen im Deployment-Laufwerk angeben müsst:
Das Bild zeigt die Dateieigenschaften von AcroRd32.exe und die Verweise auf das Skript und das Deploymentlaufwerk
Außerdem wird die VersionCompare.exe benötigt.

Hier nun das Script:
Code anzeigenDen Code könnt ihr bequem mit den Links/Rechts Pfeiltasten horizontal bewegen.

@echo off & Color 9f & setlocal
set wd=\\server\Deployment\Software\Reader
set log=%wd%\reader-log.txt
set readerEL=999
set retry=0
set forcecleanup=yes
set deactivateToolsSidebar=yes
REM:: ******************
set version=15.17.53
REM:: ******************

REM:: Clientfilter: nur die Computer aus der allowedPCs.txt dürfen installieren
::for /f %%f in (%wd%\allowedPCs.txt) do if "%computername%"=="%%f" goto start
::goto end

REM:: Clientfilter: die Computer aus der deniedPCs.txt dürfen nicht installieren
for /f %%f in (%wd%\deniedPCs.txt) do if "%computername%"=="%%f" goto end

:start
if not exist %wd%\deploy\%version%\complete md %wd%\deploy\%version%\complete
if not exist %wd%\deploy\%version%\complete\%computername% goto beforeinstall

if "%deactivateToolsSidebar%"=="yes" goto restoreToolbar

:beforeinstall
if "%forcecleanup%"=="yes" goto cleanup
goto install

:cleanup
echo %date% %time:~0,8% - %computername% deinstalliert alle Reader Versionen... >> %log%
REM:: uninstall all reader versions
taskkill /im acrord32.exe /t /f
taskkill /im acrord64.exe /t /f
start /w %wd%\cleaner\reader-cleaner-9.exe /silent /product=1
start /w %wd%\cleaner\reader-cleaner-10.exe /silent /product=1
start /w %wd%\cleaner\reader-cleaner-dc.exe /silent /product=1
echo %date% %time:~0,8% - %computername% hat alle Reader Versionen deinstalliert... >> %log%
goto install

:install
echo %date% %time:~0,8% - %computername% startet die Installation... >> %log%
start /w msiexec /i "%wd%\deploy\%version%\AcroRead.msi" /qn TRANSFORMS="%wd%\deploy\%version%\AcroRead.mst"
set readerEL=%errorlevel%

if %readerEL%==1618 goto retry REM:: msiexec process in use, installation already in progress
if %readerEL%==1602 goto retry REM:: user canceled installation
if %readerEL%==1603 goto retry REM:: fatal error, some use it for "already installed" (eg. java)
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%... >> %log%
if %readerEL%==0 md %wd%\deploy\%version%\complete\%computername%
if "%deactivateToolsSidebar%"=="yes" goto restoreToolbar
goto end

:restoreToolbar
if exist "c:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroApp\" set instpath=c:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroApp
move "%instpath%\ENU\disabled\AppCenter_R.aapp" "%instpath%\ENU"
move "%instpath%\ENU\disabled\Home.aapp" "%instpath%\ENU"
move "%instpath%\ENU\disabled\Viewer.aapp" "%instpath%\ENU"
move "%instpath%\DEU\disabled\AppCenter_R.aapp" "%instpath%\DEU"
move "%instpath%\DEU\disabled\Home.aapp" "%instpath%\DEU"
move "%instpath%\DEU\disabled\Viewer.aapp" "%instpath%\DEU"
rd "%instpath%\ENU\disabled"
rd "%instpath%\DEU\disabled"
echo %date% %time:~0,8% - %computername% hat die Installation optimiert >> %log%
goto end

:retry
if %retry%==1 goto retryfailed
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%, retry in 5min... >> %log%
set retry=1
ping localhost -n 300 > nul
goto cleanup

:retryfailed
echo %date% %time:~0,8% - %computername% hat die Installation abgeschlossen, Errorlevel: %readerEL%, retry failed, end >> %log%
goto end

:end
endlocal
exit

Alternatives Deployment

Auf der Seite 404techsupport.com habe ich einen noch einfacheren Deployment-Guide gesehen. Dort wird nur anhand des aktuellsten Installers gearbeitet – leider hatte ich noch nicht die Zeit dieses Deployment zu testen. Das hole ich sicher noch nach und Update dann hier.
Einzige Einschränkung: Das Deployment funktioniert nur über .exe, ist also nicht für das normale GPO Softwaredeployment via .msi geeignet.
Hier die Zusammenfassung, die der Autor mir per Mail zukommen ließ:

I download the latest executable from Adobe’s FTP site for Adobe Reader DC and deploy that with a script.
ftp://ftp.adobe.com/pub/adobe/reader/win/AcrobatDC/1501620039/

I created a transform using the Adobe Customization Wizard and the .msi version of the installer.
My script then installs the executable and uses the transform as a parameter.

\\server.fqdn\share\AdobeReader\LatestReaderDC.exe /sPB /rs /msi TRANSFORMS=\\server.fqdn\share\AdobeReader\ReaderDC.mst

(The script runs at startup assigned by Group Policy. It checks a network location for a „receipt“ for that computer to see if it has run before, and if not, executes the above command. I empty the „receipts“ folder after I download the new installer to the share so that the script executes on their next startup.)

If that works for your deployment options, it’s pretty straight-forward and avoids the annoying .msp patching (security patch or quarterly patch?). If you need an .msi to deploy, you are probably stuck with your steps of creating the admin install.

Kurz notiert:
Dank PowerShell lassen sich bei Microsoft Exchange – in meinem Fall Exchange Online, also ein hosted Exchange – Änderungen gleich für mehrere oder sogar alle Nutzer ausführen. Vor allem bei Änderungen, die normalerweise nicht über die Adminoberfläche administrierbar sind, sondern über den Nutzer direkt eingestellt werden müssen, lohnt sich das enorm.

Verbindung zu Exchange Online in PowerShell herstellen

In PowerShell folgende Befehle nacheinander eingeben:

$UserCredential = Get-Credential

An dieser Stelle dann die Mail-Credentials eines Exchange Admins eingeben.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Speichert die Verbindung zu Exchange Online mit den Credentials in ein Objekt

Import-PSSession $Session

Lädt das Session Objekt

Anschließend könnt ihr auf dem Exchange Befehle ausführen, beispielsweise

Get-Mailbox

:
microsoft-exchange-online-changes-to-multiple-or-all-users-get-mailbox

In den folgenden Beispielen soll die Abwesenheitsmeldung bzw. Automatische Antwort eingestellt werden. Diese Einstellung eines Nutzers lässt sich mit folgenden Befehl abrufen:

Get-MailboxAutoReplyConfiguration -Identity hs@barketing.de

Änderungen für einzelne Benutzer

Aktivieren ohne zeitliche Einschränkung:

Set-MailboxAutoReplyConfiguration -Identity hs@barketing.de -AutoReplyState Enabled -ExternalAudience All -ExternalMessage "Guten Tag<br>Bla bla bla, Urlaub bla.<br>Mit freundlichen Grüßen"

Aktivieren mit Start- und Endzeitpunkt:

Set-MailboxAutoReplyConfiguration -Identity hs@barketing -AutoReplyState Scheduled -StartTime "11/11/2013 00:00" -EndTime "11/13/2013 18:00" -ExternalAudience All -InternalMessage "Guten Tag<br>Bla bla bla, Urlaub bla.<br>Mit freundlichen Grüßen"

(via)

microsoft-exchange-online-changes-to-multiple-or-all-users-set-mailboxautoreply

Änderungen für mehrere/alle Benutzer

Anhand des Pipe-Operators

|

können wieder Ausgaben eines Befehls an den nächsten Befehl zur Weiterverarbeitung übergeben werden.
Alle Benutzer:

Get-Mailbox | Set-MailboxAutoReplyConfiguration -AutoReplyState Enabled -ExternalAudience All -ExternalMessage "Guten Tag<br>Bla bla bla, Urlaub bla.<br>Mit freundlichen Grüßen"

Über

Get-Mailbox

werden alle Mailkonten geladen und an den

Set

-Befehl übergeben, der dadurch keinen

Identity

-Parameter mehr braucht.
Hinweis: Die Massenverarbeitung dauert natürlich entsprechend lange – für die 30 Nutzer bei uns hat der Befehl 4 Minuten gebraucht. Also nicht ungeduldig werden.

Mit Benutzervorauswahl:

Get-User | where {$_.Department -eq "Sales"} | Get-Mailbox | Set-MailboxAutoReplyConfiguration -AutoReplyState Enabled -ExternalAudience All -ExternalMessage [...]

Somit werden Nutzer erst durch den

where

-Befehl gefiltert, deren Postfächer geladen und weitergegeben. (via)

Typisches Problem – es funktioniert nicht

Wichtig:
Damit AutoReply-Regeln tatsächlich auch funktionieren, müssen in den Mailkonten auch wirklich E-Mails eingehen.
Bei Konten, die ihre E-Mails nur via SMTP weiterleiten und keine lokale Kopie der Mails in ihrem Postfach empfangen, funktioniert das Auto-Reply deswegen nicht.
Neben den AutoReply-Einstellungen muss demnach auch die Einstellung, dass beim Weiterleiten der Mails eine lokale Kopie behalten werden soll, gesetzt werden.
microsoft-exchange-online-changes-to-multiple-or-all-users-check-forwarding-settings

Einen Überblick über die Weiterleitungseinstellungen aller Nutzer bekommt ihr mit diesem Befehl:

Get-Mailbox | FL DeliverToMailboxAndForward, ForwardingAddress, ForwardingSmtpAddress

Mit diesem schnellen Überblick könnt ihr euch entweder selbst die Nutzer raussuchen, die eine Weiterleitung eingerichtet haben jedoch keine lokalen Kopien in ihr Postfach kriegen (und somit auch keine Automatische Antwort abschicken).
Oder ihr nutzt einfach folgenden Befehl. Dieser aktiviert diese Einstellung der lokalen Kopie für alle Benutzer, die eine Weiterleitung (intern sowie extern) eingerichtet haben:

Get-Mailbox | Where {$_.ForwardingSmtpAddress -ne $Null -OR $_.ForwardingAddress -ne $Null} | Set-Mailbox -DeliverToMailboxAndForward $True

(via)

Fehler

Folgender Fehler kann bei WordPress auftreten, vermutlich nur bei bestimmten Hostern, nachdem es installiert oder hosterübergreifend umgezogen wurde:
Das Bild zeigt den WordPress Dialog, bei dem FTP Verbindungsinformationen benötigt werden sowie den Fehler, dass diese nicht korrekt seien - egal, welche Daten man eingibt. Das liegt an fehlerhaften Besitzrechten nach der WordPress Installation auf einigen Hostern wie beispielsweise auch All-Inkl und Hosteurope.
Der Fehler erscheint vermutlich bei der Installation oder Aktualisierung von Plugins oder Themes.

Erklärung

Das Bild zeigt den WordPress Dialog, bei dem FTP Verbindungsinformationen benötigt werden. Das Phänomen tritt auf, wenn ihr WordPress von Hand auf euren FTP hochgeladen und danach die Installation ausgeführt habt. Dadurch ist das WordPress Core mit den Besitzerrechten eures FTP Nutzers, mit dem ihr die WordPress Dateien hochgeladen habt, versehen. Alle Tätigkeiten aus dem WordPress System heraus, also beispielweise das Installieren von Plugins über die WordPress „Plugins“ Oberfläche, werden jedoch server-intern von einem anderen Nutzer ausgeführt. Dieser Nutzer heißt je nach System oftmals PHP-User, www-User, www-data oder ähnlich. Nun fehlen dem Nutzer aber die Zugriffsrechte auf die entsprechenden Ordner.

Lösungen

Es gibt mehrere mögliche Lösungen:

1)
Gebt bei der WordPress Nachfrage die FTP-Nutzerdaten ein, mit denen ihr WordPress hochgeladen habt. Den Nutzer könnt ihr, falls ihr es nicht mehr genau wisst, vielleicht mit dem WebFTP-Tool eures Hosters auslesen:
Das Bild zeigt die Oberfläche eines WebFTP Programms mit markierten Besitzerinformationen eines Ordners
Im besten Falle führt WordPress danach alle Plugin Aktionen ohne Klagen aus und ihr hört nie wieder von dem Problem. Aber dann wärt ihr wahrscheinlich auch gar nicht hier gelandet.

2)
Ändert die Besitzrechte von wp-content. Nutzt dafür vom Hoster zur Verfügung gestellte Möglichkeiten der Besitzrechteveränderung (Adminbackend -> Tools).
Zuerst wird der Ordner wp-content auf den PHP-User gestellt, die benötigte WordPress Funktion getestet (z.B. Plugin-Update, sollte jetzt gehen) und dann stellt ihr den Besitzer wieder zurück auf den FTP-User. Bei mir hat das die Probleme dauerhaft behoben und die Besitzrechte sind einheitlich weiterhin auf dem FTP-Nutzer.

3)
Mein zweiter Tipp ist eigentlich der langfristig sicherste: installiert WordPress nicht von Hand sondern über die 1-Click-Install-Methode eures Hosters. Praktisch jeder Webhoster bietet die Installation von bekannter Software auf seinem System an, WordPress ebenfalls. Dabei richtet der Hoster ein fertig installiertes und eingerichtetes System für euch ein, meistens mit nur wenigen Klicks. Dieses System hat definitiv keine Rechteprobleme, ist nun aber frisch installiert. Je nachdem, wie jung oder alt euer Blog ist, kostet es nun weniger oder mehr Aufwand, die Inhalte in das neu installierte System zu transferieren. Aber diese Lösung ist am sichersten und wird keine zukünftigen Probleme mehr machen, ich empfehle das also.
Export/Import: Der Export besteht im Grundlegenden aus 2 Typen: Daten (Beiträge, Kommentare usw), Plugins und Themes.
Daten: Benutzt entweder die WordPress eigene Export-Funktion unter „Werkzeuge -> Daten exportieren“ oder exportiert eure komplette WordPress Datenbank (SQL Export via phpMyAdmin). Diesen Export dann im neuen WordPress bzw. dessen Datenbank.
Plugins/Themes: Entweder ihr installiert im neuen WordPress die Komponenten von Hand (je nachdem wieviele es sind), oder ihr zieht euch direkt vom FTP die Ordner „plugins“ und „themes“ und überschreibt einfach diese Ordner in eurem neuen WordPress System.
Anschließend müsste der neue WordPress Blog die Plugins, Themes (die beide ggf. noch aktiviert werden müssen) und Daten enthalten.
Ich werde aber demnächst nochmal einen ausführlichen Beitrag über gute WordPress Backup Methoden schreiben und eine komplette Backup Lösung konzipieren.

4)
Tragt in eure .htaccess Datei in der Root eures WordPress Blogs (also direkt im obersten Ordner, beispielsweise „/blog/“) folgende Zeile ein:

AddHandler php5-cgi .php

Hintergrund: Link

Neu in meiner Software-Deployment Auflistung ist ab jetzt KeePass 2, eine ziemliche gute und erweiterbare Passwortmanagement-Freeware.
Zu KeePass selbst werde ich in Zukunft noch einige Artikel schreiben, von der Installation bis zur Integration in Browser und Smartphone. Jetzt erstmal schnell das Deployment im Windows Active Directory via Batch Script, im üblichen Stil.

Vorbereitung

Das Bild zeigt die vielen Deploymentparameter und -optionen des KeePass 2 InstallersDer .exe Installer von der Homepage (Pro Version) liefert beim Aufruf mit dem Parameter „/?“ eine lange Liste von Optionen zur Anpassung der Installation. Diese findet ihr hier auch nochmal zur besseren Lesbarkeit in HTML Form.
Praktisch: Ihr könnt mit allen Parametern die Installation anpassen und bei der ersten Installation mit dem Parameter /SAVEINF=filename das Set an Optionen in eine Konfigurationsdatei speichern. Für die nächste Installation reicht als Parameter dann nur noch /LOADINF. So lassen sich beispielsweise unterschiedliche Deploymentprofile erstellen und nutzen.

Plugins

Eine der Stärken von KeePass ist die starke Erweiterbarkeit mit Hilfe der vielen Plugins und Tools. Die Installation und Verteilung ist bei fast allen relativ einfach: es reicht schon die entsprechende Plugin-Datei (z.B. .plgx) in das Programmverzeichnis zu legen, ggf. auch in einen seperaten „plugins“ Unterordner für eine verbesserte Übersicht. Beim nächsten Start von KeePass wird das Plugin automatisch erkannt und geladen.
Aus diesem Grund kopiert das Deployment-Script benötigte Plugins einfach nur in den Installationsordner – fertig!

Deployment

Aktuell: Version 2.34 via .exe
Das im Skript verwendete Programm VersionCompare ist eine Eigenprogrammierung und hier als Download verfügbar.

Code anzeigenDen Code könnt ihr bequem mit den Links/Rechts Pfeiltasten horizontal bewegen.

@echo off && color 9f && setlocal

set wd=\\lea\Deployment\Software\KeePass
set log=%wd%\keepass.log
set tools=\\lea\Deployment\Sonstiges\tools
set instversion=0.0
set versionEL=9
set regEL=999
set exepath=none
set retry=0

REM:: ######## EDIT THIS ####
set newversion=2.34
REM:: #######################

REM:: Clientfilter: nur die Computer aus der allowedPCs.txt dürfen installieren
REM::for /f %%f in (%wd%\allowedPCs.txt) do if "%computername%"=="%%f" goto check
REM::goto end

REM:: Clientfilter: die Computer aus der deniedPCs.txt dürfen nicht installieren
for /f %%f in (%wd%\deniedPCs.txt) do if "%computername%"=="%%f" goto end

:check
if exist "c:\Program Files (x86)\KeePass2\KeePass.exe" set exepath="c:\Program Files (x86)\KeePass2\KeePass.exe"
if exist "c:\Program Files\KeePass2\KeePass.exe" set exepath="c:\Program Files\KeePass2\KeePass.exe"
if %exepath%==none goto install
goto checkversion

:checkversion
for /f "tokens=1-3" %%i in ('%tools%\sigcheck %exepath%') do ( if "%%i %%j"=="File version:" set instversion=%%k )
%tools%\VersionCompare.exe %instversion% %newversion%
set versionEL=%errorlevel%
if "%versionEL%"=="-1" goto install
if "%versionEL%"=="0" echo %date% %time:~0,8% - %computername% hat bereits %instversion% installiert >> %log% & goto plugins
if "%versionEL%"=="1" echo %date% %time:~0,8% - %computername% hat bereits %instversion% (neuer) installiert >> %log% & goto plugins

:install
echo %date% %time:~0,8% - %computername% installiert... >> %log%
TASKKILL /f /im KeePass.exe
start /w %wd%\KeePass-%newversion%.exe /VERYSILENT /SP- /SUPPRESSMSGBOXES /LOG="logs/%computername%.log" /NORESTART /CLOSEAPPLICATIONS /SAVEINF="standardsetup.inf" /DIR="%ProgramFiles%\KeePass2" /GROUP="KeePass 2"
set kpel=%errorlevel%
if %kpel%==1618 goto retry REM:: msiexec process in use, installation already in progress (eg. windows updates running)
if %kpel%==1602 goto retry REM:: user canceled installation (eg. taskkill)
if %kpel%==1603 goto retry REM:: fatal error, some use it for "already installed" (eg. java)
if %kpel%==1638 goto retry REM:: another product is already installed, denies an update
echo %date% %time:~0,8% - %computername% hat Version %newversion% mit EL %kpel% abgeschlossen >> %log%
goto plugins

:plugins
REM:: copy plugins
if exist "c:\Program Files (x86)\KeePass2\KeePass.exe" xcopy /Y /S /I "%wd%\plugins" "c:\Program Files (x86)\KeePass2\plugins"
if exist "c:\Program Files\KeePass2\KeePass.exe" xcopy /Y /S /I "%wd%\plugins" "c:\Program Files\KeePass2\plugins"
goto end

:retry
if %retry%==1 goto retryfailed
echo %date% %time:~0,8% - %computername% hatte den Fehler %kpel%, retry in 500Sek... >> %log%
set retry=1
REM:: 5 Minuten warten
ping localhost -n 500 > nul
goto install

:retryfailed
echo _!_ %date% %time:~0,8% - %computername% hat die Installation abgebrochen, RETRY FAILED! >> %log%
goto end

:end
endlocal
exit