The certificate template could not be loaded. Element not found. 0x80070490

Vor wenigen Tagen stieß ich nach der Einrichtung eines neuen Certificate Templates auf einer Microsoft Enterprise CA auf folgende Fehlermeldungen innerhalb des Application Event Logs.

Der Server der SubCA gibt an, dass er das neue Template nicht finden könne. Per ADSI war dieses Template jedoch erfolgreich innerhalb der Domäne repliziert worden. Eine versuchte Ausstellung eines Zertifikats mit jenem Template scheiterte jedoch. Auch der Network Device Enrollment Server meldete, dass entsprechende Template würde von der CA nicht unterstützt.

Die Ursache für die Störung war am Ende, dass ich die Benutzergruppe „Authenticated Users“ auf dem Security-Reiter des Templates entfernt habe und einzig die „Enterprise Admins“, „Domain Admins“ und eine granulare Benutzergruppe für das Template hinzugefügt hatte.

Microsoft verlangt ausdrücklich die Gruppe „Authenticated Users“ (deutsch: Authentifizierte Benutzer) innerhalb der Berechtigungen für ein Certificate Template, wie sie selbst auch im TechNet unter KB283218 erklären.

Umzug des Blogs auf neuen Server

Ich bin die Tage mit dem Blog von Ubuntu 12.04 LTS mit Apache, PHP5 und MySQL auf ein Ubuntu 16.04 LTS mit Nginx, PHP7 und MariaDB umgezogen. Nach aktuellem Stand sollte alles wieder erreichbar und korrekt verlinkt sein, auch ein frisches Letsencrypt-Zertifikat ist wieder mit am Start.

TLS 1.0 in Windows Server 2008 R2 deaktivieren bricht Remote Desktop Services

Nach den vielen Sicherheitslücken in und rund um SSL und TLS geht es ja sinnvollerweise langsam in Richtung der Deaktivierung älterer Verschlüsselungsprotokollen wie TLS1.0. Von diesen Änderungen sind natürlich auch Bestandssysteme nicht ausgenommen, die nur selten auf der aktuellsten Betriebssystemversion betrieben werden.

Bei Microsoft Windows Server 2008 R2 kommen nach der Deaktivierung von TSL1.0 hingegen ein paar weitreichendere Einschränkungen hinzu. So unterstützen die Remote Desktop Services von Haus aus leider nicht Verbindungen mit TLS1.1 oder TLS1.2.

Dieses Feature wird erst mit einem von Microsoft unter KB3080079 bereitgestellten Update nachgereicht. Nach der Installation ist ein Neustart des Systems notwendig.

Printbrm.exe – The following error occurred: 0x80004005. Unspecified error.

Da Microsoft leider nicht die Möglichkeit eines Print-Clusters vorsieht, müssen andere Möglichkeiten ergriffen werden, sofern es zu einem Ausfall eines Printservers kommt. Eine Möglichkeit wäre die Einspielung eines aktuellen per PrintBRM erstellten Backups auf einem Reserve-Server.

Ein regelmäßig laufendes Scheduled Task kann das Backup zum Beispiel an zentraler Stelle ablegen. Etwas unglücklich ist, wenn das Tool mir dem leider nicht sehr aussagekräftigen Fehler 0x80004005 abbricht und kein Backup erstellt wird.

Normalerweise wird das Backup von PrintBRM im CAB-Format abgespeichert. Dieses Format wurde laut Microsoft nie für Dateien über 2 GByte konzipiert. Sofern ein PrintBRM-Backup diese Größte erreicht, wird das Tool mit dem genannten Fehler abbrechen.

Dieser Fehler ist beschränkt auf Microsoft Windows Server 2008 bis 2008 R2. Mit Microsoft Windows Server 2012 wurde das Tool um die Funkion erweitert, dass Backups im OPC-Format gespeichert werden und diese auch bei mehr als 2 GByte nicht schlapp machen.

Damit ist das Problem jedoch für Print Server auf Basis von Windows Server 2008 R2 nicht vom Tisch. Microsoft liefert die Verbesserungen jedoch innerhalb eines Hotfixes nach, sodass man auch dort Backups im OPC-Format anlegen kann.

Hinzu kommen noch eine ganze Reihe weiterer Verbesserungen. Ein Einspielen lohnt sich also ggf. trotz der endlichen Laufzeit der Systeme.

 

„Do you trust this printer?“ trotz konfigurierter „Point and Print Restrictions“

Unsere Kollegen vom Client Service haben erfahren müssen, dass Security Update KB3170455 die mittels Gruppenrichtlinie konfigurierten Einstellungen der „Point and Print Restrictions“ ad absurdum führt.

Microsoft beschreibt den Patch wie folgt:

„Dieses Sicherheitsupdate behebt Sicherheitsanfälligkeiten in Microsoft Windows. Das größere Sicherheitsrisiko könnte die Remoteausführung von Code ermöglichen, wenn ein Angreifer einen Man-in-the-Middle-Angriff (MiTM) auf einer Arbeitsstation oder einem Druckserver ausführen oder einen nicht autorisierten Druckserver im Zielnetzwerk einrichten kann.“

Nach der Installation des Updates ignoriert ein Windows Client die dort getätigten Einstellungen, fragt ob man dem Drucker vertrauen würde und bittet zu alledem noch um administrative Berechtigungen, um den Treiber installieren zu können.

image002

Es scheint dabei jedoch nur Druckertreiber zu erwischen, die noch nicht „Packaged“ sind, primär also ältere Druckertreiber. Neuere Druckertreiber, die schon im neuen Format gepackt wurden, werden weiterhin ordnungsgemäß ohne Abfrage installiert. Das Thema ist auch schon im Microsoft Forum angekommen und wird dort diskutiert.

Lets Encrypt – SSL-Zertifikat fürs Blog umgestellt

Die Verbindung zum Blog ist seit bestehen ausschließlich per TLS erreichbar und war bis vor wenigen Tagen noch per Class 2 Zertifikats von StartCom verschlüsselt. Die Initiative der Zertifizierungsstelle Lets Encrypt verschlüsselte Verbindungen zum Standard werden zu lassen, gefällt mir daher ausgesprochen gut. Es gibt im Web eigentlich keine Gründe mehr, nicht auf eine verschlüsselte Verbindung zu setzen. Eine Ausnahme gibt es oft noch bei Seiten mit eingebettetem Inhalt Dritter wie z.B. Foren, wo man jedoch die Login-Bereiche entsprechend absichern sollte.

Da mein StartCom-Zertifikat ohnehin im Januar ausgelaufen wäre und erneuert werden musste, habe ich mich gleich dazu entschieden auf Lets Encrypt zu wechseln. Die Installation auf einem Ubuntu Server 12.04 ist überraschend einfach und geht wie folgt. Da der Port 80 bei mir jedoch weiterhin in Benutzung ist, setze ich auf die Webroot-Methode und nicht auf den temporär laufenden LetsEncrypt-Webserver.

cd /opt/
git clone https://github.com/letsencrypt/letsencrypt
cd /opt/letsencrypt/

Sollte euch git fehlen, so ist dies mit folgendem Befehl zu installieren.

aptitude install git

Damit ist LetsEncrypt erstmal auf eurem Webserver installiert und einsatzbereit. Bevor wir uns jedoch ein Zertifikat ausstellen, sollten wir den Webserver entsprechend vorkonfigurieren. Ich gehe generell von einer laufenden SSL-Konfiguration aus, sollte diese nicht vorliegen verweise ich gerne auf eine kleine Anleitung meinerseits.

Wir starten mit der Einrichtung einer Config-Datei zur einfachen Definierung der Parameter für das neue Zertifikat. Diese Config-Datei benennen wir übersichtshalber nach unserem zu nutzenden Domänennamen und nutzen .cli als Suffix.

nano /etc/letsencrypt/Logikkreise.de.cli

Da ich nicht bereit bin meinen laufenden Webserver temporär zur Ausstellung eines Zertifikats zu beenden, nutze ich die Webroot-Methode zur Domänen-Validierung.


 This is an example of the kind of things you can do in a configuration file.
# All flags used by the client can be configured here. Run Let's Encrypt with
# "--help" to learn more about the available options.

# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096

# Always use the staging/testing server
# server = https://acme-staging.api.letsencrypt.org/directory

# Uncomment and update to register with the specified e-mail address
email = email@domain.tld

# Uncomment and update to generate certificates for the specified
# domains.
# domains = example.com, www.example.com
domains = domain.tld, www.domain.tld

# Uncomment to use a text interface instead of ncurses
# text = True

# Uncomment to use the standalone authenticator on port 443
# authenticator = standalone
# standalone-supported-challenges = tls-sni-01

# Uncomment to use the webroot authenticator. Replace webroot-path with the
# path to the public_html / webroot folder being served by your web server.
authenticator = webroot
webroot-path = /path/to/webroot/

Nach Erstellen der Konfiguration können wir durch auskommentieren der Server-Zeile zwischen den Test/Staging-Server von Lets Encrypt und dem produktiven Server wechseln. Nur letzterer stellt euch ein vertrauenswürdiges Zertifikat aus, mit ersterem testet Ihr jedoch eure Konfiguration.

Nach Anlegen der Config-Datei erstellen wir für unseren Apache Webserver Symlinks zu den baldigen SSL-Zertifikaten. Dieser Schritt kann auch nach Erstellung der Zertifikate erfolgen.

Die Zertifikate von Lets Encrypt werden automatisch an folgendem Ort abgelegt.

/etc/letsencrypt/live/

 

Pro Domain wird Unterordner im genannten Pfad erstellt und darunterliegend die drei Zertifikate gespeichert. Das öffentliche (cert.pem), das private (privkey.pem), die Zertifikatskette (fullchain.pem). Die Pfade lauten also beispielsweise wie folgt:

/etc/letsencrypt/live/logikkreise.de/cert.pem /etc/letsencrypt/live/logikkreise.de/privkey.pem /etc/letsencrypt/live/logikkreise.de/fullchain.pem

 

Ich habe mich dazu entschieden diese Dateien nicht in das SSL-Verzeichnis vom Apache zu kopieren, sondern nur sogenannte Symlinks zu erstellen, also Verknüpfungen.

ln -s /etc/letsencrypt/live/domain.tld/cert.pem /etc/apache2/ssl/domain.tld.cert.pem ln -s /etc/letsencrypt/live/domain.tld/privkey.pem /etc/apache2/ssl/domain.tld.privkey.pem ln -s /etc/letsencrypt/live/domain.tld/fullchain.pem /etc/apache2/ssl/domain.tld.fullchain.pem

 

Sollten die Pfade widererwarten doch anders sein, so sind die Symlinks einfach anzupassen. Danach passen wir ebenfalls die Pfade innerhalb der Apache-Konfiguration an.

nano /etc/apache2/sites-enabled/domain.tld SSLEngine on SSLCertificateFile /etc/apache2/ssl/domain.tld.cert.pem SSLCertificateKeyFile /etc/apache2/ssl/domain.tld.privkey.pem SSLCertificateChainFile /etc/apache2/ssl/domain.tld.fullchain.pem

 

Nach dem Abspeichern der Konfiguration können wir uns endlich das Zertifikat von Lets Encrypt ausstellen lassen.

/opt/letsencrypt/letsencrypt-auto certonly -c /etc/letsencrypt/domain.tld.cli

 

Ein erfolgreiches Ausstellen der Zertifikate wird euch mit einer entsprechenden Meldung quitiert. Startet im Anschluss euren Apache Service einmal durch und prüft durch Besuchen eurer Webseite ob das neue Zertifikat korrekt eingebunden wurde.

service apache2 restart

Ein korrekt eingerichtetes Zertifikat sieht wie folgt aus:

Zertifikat

Windows Store: Update auf Windows 8.1 nicht möglich

Ich habe im Zuge der Veröffentlichung von Windows 10 vor kurzem eine komplette Neuinstallation meines privaten Primär-Rechners durchgeführt. Gestartet bei meiner damals gekauften Windows 8.0 Pro DVD, mit einem Upgrade auf Windows 8.1 über den Windows Store und gefolgt von Windows 10.

Leider wollte trotz sauberer Neuinstallation der Windows Store das Windows 8.1 Upgrade nicht installieren und mein Upgrade-Pfad zu Windows 10 wurde blockiert. Die Lösung des Problems ist die schlicht Neuinstallation / Reparatur vom Windows Store.

Man gibt dazu den folgende Befehl in eine administrativ gestartete PowerShell-Sitzung ein:

Add-AppxPackage -DisableDevelopmentMode -Register $Env:SystemRoot\WinStore\AppxManifest.XML

Sollte der Befehl aufgrund der ExecutionPolicy nicht erlaubt sein, ist folgender Befehl vorzuziehen. Der zweite Befehl stellt den Wert wieder auf die „sichere“ Variante und ist nach einem funktionierenden Windows Store auszuführen.

PowerShell -ExecutionPolicy Unrestricted

PowerShell -ExecutionPolicy RemoteSigned

Mozilla Firefox – Suchmaschinen-Feld aus neuem Tab entfernen

Ich bin eigentlich ein Freund von Opera 12, leider wurde der Browser ja eingestellt und dem Neustart mit Blink fehlen noch allerhand Funktionen, die Ihn mit seinem Vorgänger ebenbürtig machen würde. Drum habe ich, um mit der Zeit beim Thema Surfgeschwindigkeit nich gänzlich abgehängt zu werden, mich an den Firefox gewöhnen und mir mit ein paar Extensions ein wenig Opera-Flair verschaffen müssen.

Was mich bis zuletzt jedoch immer wahnsinnig gemacht hat ist das große Suchmaschinen-Feld innerhalb eines neuen (SpeedDial)-Tabs. Dieses kann man aber zum Glück relativ einfach ausblenden. Die Lösung dazu habe ich auf askvg.com gefunden und habe nur hinzuzufügen, dass man den Ordner „chrome“, sollte er nicht vorhanden sein, einfach erstellen kann. Firefox wird diesen und die darin befindlichen Dateien dann automatisch nutzen.

*.msu-Dateien nicht per Windows Powershell Remoting installierbar

Vor wenigen Tagen wollte ich mit Hilfe von Windows PowerShell Remoting eine kleine Software auf eine bestimmte Anzahl von Servern installieren. Vorraussetzung für diese Software sind einige Patches und optionale Updates, die nachinstalliert werden müssen.

wusa.exe <update> /quiet /norestart

Leider schlug diese Installation regelmäßig fehl und offenbarte folgende Fehlermeldung im Windows Setup-Log.

Log Name:      Setup
Source:        Microsoft-Windows-WUSA
Date:          29.01.2015 12:14:56
Event ID:      3
Task Category: None
Level:         Error
Keywords:
Description:
Windows update could not be installed because of error 2147942405 „Access is denied.“ (Command line: „“C:\Windows\system32\wusa.exe *.msu /quiet /norestart“)

Hintergrund bildet folgender TechNet-Artikel von Microsoft: http://support.microsoft.com/kb/2773898

Installing an update using WUSA or the WUA APIs on a remote machine is not supported.

Abhilfe schafft es also die MSU-Datei wahlweise per wusa.exe oder expand.exe zu entpacken und die Installation mit dem Deployment Image Servicing and Management-Tool (dism.exe) durchzuführen.

wusa.exe <update> /extract:<destination>

dism.exe /online /norestart /quiet /add-package /PackagePath:<Path_To_Package>\*.cab

Achtung beim McAfee ePolicy Orchestrator Upgrade von 4.6.x auf 5.1.1

Vor wenigen Tagen haben wir bei einem in der Transition befindlichen Kunden die dort laufende Installation des McAfee ePolicy Orchestrator in der Version 4.6.2 aktualisiert.

McAfee ePolicy Orchestrator 4.6.2
Microsoft Windows Server 2008 R2 SP1
Microsoft SQL Server 2005 (32-Bit)

Der Weg sollte zu einem McAfee ePolicy Orchestrator 5.1.1 gehen. Ein Stolperstein könnte die letzte Upgrade-Kompatible Version des McAfee ePolicy Orchestrators sein. Im Download-Portal von McAfee.com findet man nämlich die Version 4.6.8, diese bietet jedoch keinen Upgrade-Pfad zur aktuellen Version 5.1.1 an. Stattdessen muss die Vorversion 4.6.7 gewählt werden.

Auch beim Upgrade der kleinen lokalen Microsoft SQL Server 2005 Datenbank in der 32-Bit Ausführung muss man etwas aufpassen. So bringt einem natürlich die 64-Bit Ausgabe des Microsoft SQL Server 2008 R2 SP2 nicht viel, sofern man nur ein schnelles Upgrade durchführen möchte und erst später die Migration auf den Datenbankcluster plant.

Nach dem Upgrade, sofern man die Standardeinstellungen des Setups übernimmt, wird der McAfee ePolicy Orchestrator Server-Dienst nicht mehr starten können weil er die Instanz des SQL-Servers nicht mehr findet.

Dazu muss man sich auf folgende Seite verbinden und dort den Instanznamen entfernen.

https://<servername>:8443/core/config

Diese wird bei einer Standard-Instanz zur Verbindung nicht benötigt bzw. akzeptiert. Dabei handelt es sich zwar um nichts neues, ich vergesse es jedoch doch immer wieder und ärgere mich für wenige Minuten unnötigerweise. In der Hoffnung hilft mir dieser Beitrag also selber als eine Art Gehirntraining.