Windows 10: PKI – was muss man beachten

Zur Übersicht und Einleitung der Blogserie “Windows 10 und ConfigMgr Deployment Serie”

Die Verwendung einer Public Key Infrastructure (PKI) ist in den meisten Fällen eine optionale Möglichkeit bei Windows 10 – abhängig vom jeweils verwendeten Feature. Für DirectAccess ist die Verwendung einer PKI jedoch zwingend erforderlich. Daher besitzt fast jedes Feature, das die Möglichkeit der Verwendung einer PKI bietet, noch eine alternative Option, die stattdessen genutzt werden kann. Meistens ist sogar die Alternative die bevorzugte Wahl gegenüber der PKI, da nicht jedes (Enterprise-) Unternehmen zwangsläufig eine PKI im Einsatz hat. Im Folgenden werden einige Features genannt, die als optionale Möglichkeit die Verwendung einer PKI erlauben.

Feature „Microsoft Passport“

Passport ersetzt unter Windows 10 die Verwendung von Kennwörtern durch eine zweistufige Authentifizierung. Diese umfasst ein registriertes Gerät und ein biometrisches Merkmal (Windows Hello) oder alternativ eine PIN.
Bevor man Microsoft Passport in einer Enterprise Umgebung nutzen kann, müssen einige Voraussetzungen geschaffen werden. Dazu zählen unter anderem, je nachdem welche Passport Methode verwendet werden soll und welche Umgebung vorhanden ist:

Abbildung 1: Anforderungen für Microsoft Passport,
Quelle: https://technet.microsoft.com/library/mt589441(v=vs.85).aspx

Passport nutzt zur Authentifizierung eine 2-Faktor Authentifizierung. Eine PKI muss dafür jedoch nicht notwendigerweise vorhanden sein, wie Abbildung 1 zeigt. Egal welche Variante man nun nutzen will, ist ein Teil des Schlüssels direkt dem Computer oder der entsprechenden Hardware zugeordnet. Dies kann entweder ein Schlüssel oder ein Zertifikat sein. Dieser „Hardware-Schlüssel“ kann entweder direkt im eingebauten TPM-Chip gespeichert werden oder in Azure Active Directory (AAD) oder als weitere Alternative in Windows Server 2016 Active Directory. Der andere Teil für Passport ist ein benutzerspezifischer Teil, der entweder aus einer PIN oder einem biometrischen Merkmal besteht. Wird anstelle der Schlüssel basierten Authentifizierung eine optional vorhandene PKI verwendet, muss das Active Directory nicht angepasst werden, damit Passport unterstützt wird. Ebenfalls ist es möglich, Passport auch ohne einen verbauten TPM-Chip zu nutzen. Siehe dazu auch den entsprechenden Blogpost unter dem folgenden Link:
https://www.sepago.de/blog/2016/02/23/windows-10-enterprise-serie-passport.
Die Verwendung eines biometrischen Merkmals bietet gegenüber der rein Schlüssel basierten Variante einen Vorteil. Nutzer können nicht überall dasselbe Passwort benutzen. Dies erscheint erstmal als Nachteil; der Vorteil dieser Methode findet sich im weiteren Verlauf dieses Abschnitts. Weiterhin wird der entsprechende biometrische Schlüssel bzw. das biometrische Merkmal direkt auf dem entsprechenden Gerät gespeichert. Er kann also nicht mehr durch einen Angriff auf einen Server gehackt werden. Dies ist ein Vorteil. Weiterhin kann man nicht mit einem gehackten Passwort eines Nutzers auf weitere Geräte desselben Nutzers zugreifen bzw. sich damit im Unternehmen anmelden.

Feature „Device Guard”

Dieses Feature dient dazu, dass nur vertrauenswürdige Anwendungen auf den Computern verwendet werden können. Dazu werden die Anwendungen signiert. Besitzt das Unternehmen bereits ein digitales Zertifikat oder eine PKI, so können sie ihre klassischen Windows Anwendungen selbst signieren, indem sie sich selbst zur Liste der vertrauenswürdigen Unterzeichner hinzufügen.
Darüber hinaus gibt es noch andere Möglichkeiten, wie Anwendungen signiert werden können. Diese benutzen jedoch keine PKI. Weitere Informationen zu den anderen Möglichkeiten sind unter dem folgenden Link im Abschnitt „Signing your apps“ zu finden: https://technet.microsoft.com/en-us/library/dn986865(v=vs.85).aspx (zuletzt abgerufen 17.02.16).

Windows 10 Mobile

Zu den Funktionen von Windows 10 Mobile zählt unter anderem das Management von Benutzer basierten Zertifikaten über eine PKI.
Die Anmeldeinformationen bestehen entweder aus einem von Windows erstellten kryptographischen Schlüsselpaar oder einem Zertifikat, das von einer PKI erzeugt wurde. Das Active Directory ermöglicht das Management der Credentials. Da beide Varianten unterstützt werden, besitzen Unternehmen eine gewisse Flexibilität bei der Anwendung. Da die Unternehmensstruktur nicht immer einheitlich ist, ist dies essentiell und umfasst so die Mehrheit der Anforderungen in heterogenen Unternehmensstrukturen.

Microsoft Intune

Microsoft Intune, früher bekannt unter dem Namen Windows Intune, ist eine Cloud-basierte Lösung, die im Jahr 2011 vorgestellt wurde. Damit ist eine Verwaltung von PCs und mobilen Endgeräten über das Internet möglich. Die Netzwerkgröße liegt bei maximal 20.000 Computern bei einem einzelnen Account (http://pfaqs.com/WindowsIntune.html, in Version v1). Pro Benutzer können maximal 5 Geräte registriert werden. Es werden alle Betriebssysteme bei mobilen Endgeräten unterstützt, d.h. Android-, Apple- und Windows Phone-Geräte. Die Kommunikation zwischen Endgerät und der verantwortlichen Stelle erfolgt verschlüsselt. Bei der Einrichtung müssen jedoch unterschiedliche Dinge beachtet werden, abhängig vom OS des Gerätes. Dafür werden auch Zertifikate benötigt. Weiterhin müssen bestimmte Komponenten in der Infrastruktur vorhanden sein. Dazu zählen eine CA, ein NDES-Server (Network Device Enrollment Service) und optional ein Web Application Proxy Server (WAP). Der WAP muss vorhanden sein, wenn Zertifikate über das Internet auf mobilen Geräten verteilt oder erneuert werden sollen.
Die Verwaltung der Geräte kann entweder über Microsoft Intune direkt oder hybrid über SCCM 2012 R2 und Intune erfolgen. Ein nachträglicher Wechsel ist nur mit Hilfe des Microsoft Supports möglich. Siehe dazu auch den folgenden Link vom 11. März 2015: http://www.greenconsultingonline.com/2015/03/switching-from-intune-standalone-to-sccm-integrated/. Dort sind die Schritte beschrieben, die vor dem Wechsel von Intune als Standalone Variante hin zur Verwaltung von Intune mit SCCM unternommen werden müssen. Nach Abschluss dieser Schritte muss dann der Microsoft Support kontaktiert werden, der den Wechsel vornimmt. Abhängig von der Auslastung des Supports kann dies jedoch etwas dauern. Deshalb sollte man sich vorab überlegen, welche Variante man wählt.
Im Fall das der SCCM verwendet wird, muss keine PKI speziell für Intune vorhanden sein. Einzig damit Intune mit Apple Geräten kommunizieren kann, muss im SCCM eine Zertifikatsignieranforderung erstellt werden. Mit dieser Zertifikatsignieranforderung können Sie bei der Zertifizierungsstelle von Apple ein Apple Push Notification Service-Zertifikat (APNs) beantragen; siehe auch Abbildung 2 weiter unten. Erst wenn dieses Zertifikat vorhanden ist, kann Intune über SCCM mit Apple Geräten kommunizieren. Die Gültigkeit dieses Zertifikates beträgt 12 Monate. Alle weiteren Zertifikate werden direkt von Microsoft Intune an die entsprechenden Geräte verteilt.

Abbildung 2: Anforderung eines APN Zertifikates

Dafür muss vorab auf dem NDES-Server noch der NDES-Connector installiert werden. Dieser empfängt alle eingehenden Anfragen und stellt im Prinzip so etwas wie eine Brücke zwischen den MDM-Komponenten und dem Cloud Service Microsoft Intune dar. Am besten erklärt Abbildung 3 das Verhalten und Vorgehen des NDES-Connectors als Vermittler zwischen den einzelnen Komponenten.

Nachdem der NDES-Server und – Connector entsprechend installiert und konfiguriert worden sind, muss man zunächst für jeden tenant Server und jede Mobile Device Plattform ein Trusted CA Zertifikat Profil erstellen. Dies ist eine weitere Voraussetzung dafür, dass später die entsprechenden Zertifikate an die Mobile Devices automatisch durch SCEP-Profile (Simple Certificate Enrollment Protokoll) ausgerollt werden können. Sind diese beiden Zertifikatsprofile erstellt und entsprechend verteilt worden, steht einer Nutzung von Microsoft Intune eigentlich nichts mehr im Weg.
Der genaue Ablauf, wie schlussendlich die Zertifikate an die einzelnen Endgeräte verteilt und diese authentifiziert werden, veranschaulicht Abbildung 4. Im Grunde ist dieser Ablauf vollkommen automatisiert, wenn zuvor alle Einstellungen korrekt gemacht worden sind und sämtliche Policies entsprechend hinzugefügt worden sind. Wichtig ist noch, dass wenn die SCEP Zertifikats Profil Richtlinien festgelegt werden, die Eigenschaften dieses Zertifikats mit den Eigenschaften der NDES Zertifikat Vorlage übereinstimmen müssen (Schlüsselnutzung, Gültigkeitsdauer, Hash-Algorithmus, etc.).

Die folgenden beiden Abbildungen zeigen, dass man sowohl für die Server als auch für die Clients keine speziellen Zertifikate in Verbindung mit SCCM und Intune extra anzufordern muss, da diese automatisch von Intune angefordert und in der SCCM Datenbank bzw. im Computerspeicher des Gerätes installiert werden, wenn man Microsoft Intune abonniert bzw. wenn authentifizierte Benutzer ihre mobilen Geräte mit Intune anmelden.

Abbildung 5: PKI-Zertifikatanforderungen für Server
Quelle: https://technet.microsoft.com/en-us/library/gg699362.aspxAbbildung 5: PKI-Zertifikatanforderungen für Server, Quelle: https://technet.microsoft.com/en-us/library/gg699362.aspx

Abbildung 6: PKI-Zertifikatanforderungen für Clients,
Quelle: https://technet.microsoft.com/en-us/library/gg699362.aspx

Jedoch gibt es abhängig vom OS des verwendeten Mobile Devices noch verschiedene Besonderheiten zu beachten. Speziell für Windows Phone 8 muss das Unternehmensportal und alle Applikationen mit einem Codesignaturzertifikat für mobile Geräte von Symantec signiert werden. Im Falle von Windows Phone 8.1 ist dies nur für die Applikationen notwendig. Existiert dieses Codesignaturzertifikat nicht, können diese Telefone nicht über Intune verwaltet werden; unabhängig davon ob Intune als Standalone-Variante oder über SCCM verwaltet wird. Für Windows 10 mobile ist das Verhalten das Gleiche wie bei Windows Phone 8.1. Auch hier ist das Codesignaturzertifikat allein für die Signierung der Applikationen notwendig (Quelle: http://henkhoogendoorn.blogspot.de/2015/09/my-experience-with-configmgr-2012-r2.html). Nicht jedoch für das Unternehmensportal.
Android Geräte mit der Android Version 4.0 oder höher, sowie Samsung KNOX Geräte, brauchen keinerlei Zertifikate. Weder für das Unternehmensportal noch die Applikationen. „Samsung KNOX ist die umfassende Unternehmenslösung für Mobilgeräte, die privat und am Arbeitsplatz genutzt werden. Im Businessbereich kommen immer mehr Smartphones zum Einsatz und diese Lösung deckt die mobilen Sicherheitsanforderungen der IT-Abteilungen auf Unternehmensebene ab, ohne die Privatsphäre der Mitarbeiter zu verletzen.“ (Quelle: http://www.samsung.com/de/business/solutions-services/mobile-solutions/security/samsung-knox/).

DirectAccess & Windows 10

Wird DirectAccess in einer Umgebung verwendet, in der nur Windows 10 und 8.x Clients vorhanden sind, so ist die Verwendung einer PKI optional. Für diese Clients wird das neue Windows Server Feature „Kerberos Proxy“ verwendet, um eine starke Authentifizierung und die zugehörigen Schlüssel für IPSec zu Verfügung zu stellen. Sollten sich jedoch noch Windows 7 Clients im Unternehmen befinden, so ist die Verwendung einer PKI zwingend vorgeschrieben. Diese brauchen zur Ausstellung von Zertifikaten für die Verwendung von IPSec eine PKI.
Sollen außerdem Features wie One-time Passwort (OTP), Microsoft Network Access Protection (NAP) Integration, Load Balancing (intern & extern), Force Tunneling oder Multisite Connection verwendet werden, so ist ebenfalls eine PKI erforderlich.
Für eine optimale Sicherheit und einer hohen Flexibilität beim Deployment, sollte man eine PKI zur Verwaltung aller DirectAccess Zertifikate verwenden; auch für die Deployments, die nur Windows 8.x und Windows 10 unterstützen. Ebenso für den Fall, dass die oben genannten Features genutzt werden sollen. Falls dies aktuell noch nicht der Fall ist, dann vielleicht in späteren Szenarien, die jetzt noch nicht in Betracht kommen oder an die man jetzt noch nicht denkt.

Abbildung 7: Übersicht Direct Access & Verwendungsmöglichkeiten einer PKI 
(Quelle: http://blogs.technet.com/b/ash/rss.aspx)

SHA-1 vs. SHA-2

Im Moment ist SHA-1 noch die meist benutzte kryptographische Hash Funktion zur Erstellung von Zertifikaten. Spätestens ab dem 1. Januar 2017 sollen für Zertifikate aber nur noch Funktionen der SHA-2 Familie verwendet werden. Daher sollten Zertifikate, die noch mit SHA-1 erstellt worden sind, keine längere Laufzeit als dieses Datum besitzen.
Der Wechsel erfolgt aufgrund der kryptographischen Schwachstellen, die SHA-1 besitzt. Jedoch gibt es ein Problem bei der Umstellung von SHA-1 auf SHA-2. Die meisten Geräte sind nicht in der Lage SHA-2 zu verstehen oder Zertifikate, die damit erstellt worden sind, zu akzeptieren. Dennoch beginnen die meisten Hersteller bereits jetzt damit ihre Anwendungen, in erster Linie Browser, auf Zertifikate der SHA-2 Familie umzustellen. D.h. falls ein Browser ein Zertifikat erhält, das mit SHA-1 erstellt wurde, gibt er eine Warnung aus. Ebenfalls werden die meisten öffentlichen Zertifizierungsstellen keine neuen SHA-1 Zertifikate mehr ausstellen, sondern nur noch SHA-2 Zertifikate.
Die Migration von SHA-1 zu SHA-2 ist in Server Szenarien meist eine one-way Migration, d.h. wenn man einmal das Server Zertifikat von SHA-1 zu SHA-2 gewechselt hat, kann man nicht einfach wieder zu einem SHA-1 Zertifikat zurückkehren. Deshalb sollte man die Migration im Vorfeld genau planen und prüfen, ob alle Geräte und Anwendungen in der Lage sind, SHA-2 Zertifikate und die entsprechenden Certification Revocation Lists (CRL) zu verarbeiten. Andernfalls kann es zu Fehlermeldungen kommen. Windows XP Clients und Windows Server 2003 sind nicht in der Lage, Zertifikate von einer CA (Certification Authority) zu erhalten bzw. zu verstehen, wenn diese CA Zertifikate verteilt, die mit SHA-2 256 oder höherer Verschlüsselung erstellt worden sind.
Sollte eine interne PKI vorhanden sein, so muss diese ebenfalls auf den Wechsel vorbereitet werden. Zunächst muss man sämtliche CA‘s updaten und danach entsprechend neue Zertifikate verteilen. Die einfachere Variante ist dabei, die PKI komplett neu aufzusetzen. Sollten in der alten PKI kleinere Fehler vorhanden sein oder Fehlplanungen welcher Art auch immer, so kann man diese in der neuen PKI nun vermeiden.
Der Wechsel von SHA-1 zu SHA-2 bedeutet je nach Größe des Unternehmens einen großen logistischen Aufwand, den man nicht unterschätzen sollte. Bereits jetzt gibt es die SHA-3 Familie, die 2012 vom NIST ausgewählt wurde und aktuell auf Schwachstellen untersucht wird. Wer jetzt aber denkt, er könne den Wechsel auf SHA-2 aussitzen und auf SHA-3 warten, der irrt. Bis die SHA-3 Familie allgemein verwendet werden wird, wird es noch mehrere Jahre dauern.
Das Vorgehen von Microsoft beim Wechsel wird unter folgendem Link genau beschrieben: http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx (zuletzt abgerufen 18.03.2016). Dort ist auch der genaue Zeitplan hinterlegt, ab welchem Zeitpunkt Windows bzw. Microsoft mit verschiedenen Signaturen und Zertifikaten umgehen wird und bis zu welchem Zeitpunkt sie gültig sein werden.

Empfehlungen („Best Practices“)

Generelle Empfehlungen bzw. Best Practices zu Windows 10 in Verbindung mit einer PKI kann man eigentlich nicht geben. Es hängt immer davon ab, was im jeweiligen Unternehmen als Infrastruktur bereits vorhanden ist oder welche Features man verwenden will.
Sollte bereits eine PKI vorhanden sein, so kann man diese weiter nutzen. Je nachdem welcher SHA-Algorithmus für die Erstellung der Zertifikate verwendet wird, dieser sollte vorher entsprechend geändert werden bzw. alternativ eine neue PKI aufgebaut werden. Wenn man dagegen die oben im Abschnitt „DirectAccess & Windows 10“ erwähnten Features nicht nutzen will oder braucht, so ist eine PKI eine optionale Möglichkeit, die nicht extra aufgebaut werden muss in Verbindung mit Windows 10; vorausgesetzt es sind keine Windows 7 Clients in der Umgebung vorhanden.