Hello for Business ohne Cloud nutzen

 In Allgemein, Security, Windows 10, Windows Server

Mit Windows 10 und Hello for Business (ehemals Passport) will Microsoft die Kehrtwende weg vom klassischen Passwort einleiten. Warum ist das überhaupt nötig? Passwörter sind zum einen mit vielen verschiedenen Systemen kompatibel und lassen sich einfach verwalten. Außerdem hat man seine Anmeldedaten (wenn man sie auswendig kennt) immer mit dabei.

Das Problem mit Passwörtern

All diese Punkte treffen zu. Doch besonders bei Letztgenanntem zeigt sich die große Schwachstelle von Passwörtern. Entweder sind sie leicht zu merken (und damit unter Umständen nicht sicher genug, was jedoch nicht immer zutreffen muss) oder zu komplex, was viele Benutzer dann zur Ablage auf z. B. einem Notizzettel zwingt. Außerdem wird so das mehrfache Verwenden für verschiedene Dienste wahrscheinlicher. Selbst wenn alle Benutzer vorbildlich mit der Ablage und Komplexität ihrer Passwörter umgehen, können diese spätestens über Phising oder Angriffsmethoden wie Pass-the-Hash ebenfalls ungewollt in fremde Hand gelangen.

Was tun?

Schon seit einiger Zeit heißt die Lösung im Prinzip: MFA – Multi-factor Authentication. Mit jedem weiteren Faktor, den ich für eine Authentifizierung verwenden muss, sinkt auch die Wahrscheinlichkeit, dass ein Angreifer dieser habhaft wird. Im Active Directory Umfeld kennen wir dieses System in Form von Smartcards schon länger. Doch die sind in Implementierung und Handhabung komplex. Viele aktuelle Business-Geräte sind zudem nicht mehr mit Smartcard-Lesern ausgestattet.

Hello for Business

Hello for Business setzt genau hier an. Bei der Einrichtung werden die zusätzliche Anmeldedaten des Benutzers (ein asymmetrisches Schlüsselpaar) fest mit dem jeweiligen Gerät verknüpft und sicher im TPM-Chip abgelegt. Alternativ können auch selbst ausgestellte Zertifikate verwendet werden. Um bei der Authentifizierung die sicher abgelegten Schlüssel wieder freizugeben, muss der Benutzer diese dann noch per Eingabe einer PIN (die immer als Fallback dient) oder mit Hilfe eines biometrischen Faktors (Gesichtsscan, Fingerabdruck, Handvenenscanner, etc.) freigeben.

Sowohl PIN als auch Biometriedaten verlassen dabei nie das Gerät, sie werden lediglich verwendet um einen sogenannten „Protector Key“ freizugeben, der wiederum den „Authentication key“ und weiter darunter liegende Schlüssel freigibt. In der Standardeinstellung reicht bereits ein Faktor zum Entsperren. Per Policy kann aber auch eine Abfolge von z.B. Biometrie und PIN erzwungen werden. Somit handelt es sich im Endeffekt um eine Drei-Faktor Authentifizierung (Gerät + Biometrie + PIN). Bei der Zwei-Faktor Authentifizierung bleibt es aber in jedem Fall (Gerät + Biometrie oder PIN).

Die Geräte, auf denen Hello for Business verwendet soll, müssen dabei noch zusätzlich registriert werden. Ein Domain Join alleine reicht nicht. Diese Registrierung erfolgt in hybriden Active Directory/Azure Active Directory Umgebungen im Azure AD. Was man noch wissen bzw. beachten sollte: Hello for Business gilt immer nur für das Gerät, auf dem es eingerichtet wurde. Ansonsten könnte man das Gerät nicht als echten zweiten Faktor für die Authentifizierung ansehen. Ein Benutzer kann jedoch Hello for Business auf beliebig vielen Systemem separat einrichten (und die gleiche PIN verwenden).

Azure AD? Wo bleibt denn die versprochene Variante ohne Cloud?

Die kommt jetzt. Obwohl Microsoft sich auf dem unaufhaltbaren Weg in die Cloud befindet, existiert für Hello for Business auch eine Variante für klassiche on-premises Infrastrukturen. Eins muss jedoch beachtet werden: sollte zu Testzwecken bereits ein Azure AD Connect eingerichtet worden sein, muss dieser für die on-premises Variante von Hello for Business entfernt werden. Sobald man also (teilweise) Objekte mit dem Azure AD synchronisiert, ist diese Variante nur noch über manuelle Anpassungen möglich.

Wie bei der hybriden Implementierung muss man sich für das automatisch erstellte Schlüsselpaar oder eigene Zertifikate entscheiden. Laut Microsoft ist das Sicherheitslevel für beide Varianten identisch. Der Unterschied bei der on-premises Implementierung liegt nur darin, dass man mit Zertifikaten nicht zwingend Server 2016 Domain Controller benötigt (2016er Schema und DCs ab 2008 R2 reichen dann).

Für die Verwendung des sogenannten „Key trust“ Deployments gelten folgende Voraussetzungen:

  • Clients: Windows 10, Version 1703 oder neuer
  • AD Schema: Windows Server 2016
  • Domain und Forest Functional Level: 2008 R2 oder neuer
  • „Mehrere“ Server 2016 Domain Controller (genug um Hello for Business Authentifizierungen bearbeiten zu können)
  • Certificate Authority: Server 2012 oder neuer
  • AD FS 2016 + KB4088889
  • MFA Provider

Bis auf den MFA Provider kann alles über Windows Bordmittel abgedeckt werden. Diese Funktion kann zum Beispiel über Azure MFA implementiert werden. Azure? Das ist ja wieder Cloud. Das stimmt, jedoch landet kein Gerät oder Benutzer hier in der Cloud. Für Funktionalitäten wie Telefonanruf oder SMS Code benötigt man aber Zugriff auf einen Dienst, der dies anbietet. Zwangsläufig geht dieser über das Internet um auf das Telefonnetz zugreifen zu können.Man kann allerdings auch beliebige Drittherstellerlösung verwenden, solange sich diese in AD FS integrieren lässt, denn dort wird die Geräteregistrierung und damit auch das MFA Verfahren während der Einrichtung angestoßen, welches nicht deaktiviert werden kann. Benutzer benötigen daher eine gepflegte Telefonnummer im Active Directory.

Kann mir infoWAN helfen?

infoWAN hat sowohl die hybride, als auch die on-premises Variante von Hello for Business umgesetzt. Kommen Sie gerne auf uns zu, wenn Sie Unterstützung benötigen.

Recommended Posts
Kontaktformular

Wir werden Sie so schnell wie möglich kontaktieren.

Start typing and press Enter to search