Okta FastPass ist die Phishing-resistente Authentifizierungslösung von Okta für iOS-, macOS-, Windows- und Android-Geräte. Vor einigen Jahren berichteten Kunden, dass FastPass in bestimmten virtuellen Windows-Umgebungen nicht ordnungsgemäß funktionierte. Also machten wir uns daran, den Problemen auf den Grund zu gehen und sie zu beheben. Dies erwies sich als interessante Herausforderung.
In diesem Blog-Beitrag befassen wir uns mit Okta Verify und FastPass für Windows. Wir erläutern, warum unser Authentifikator in bestimmten virtuellen Umgebungen nicht funktionierte und wie es den Entwicklern von Okta mit kreativen Ansätzen gelungen ist, die technischen Herausforderungen zu meistern.
Weitere Informationen zu FastPass finden Sie in unseren detaillierten Informationen zu FastPass sowie in unserem technischen Whitepaper zu FastPass.
Warum gab es mit FastPass in virtuellen Umgebungen Probleme?
Es gibt zwei Hauptgründe, warum FastPass in virtuellen Umgebungen nicht zuverlässig funktionierte. Der erste hatte mit Abhängigkeiten vom Gerät zu tun, der zweite mit der Benutzerverifizierung mit Windows Hello. Wir werden beide Probleme im Detail untersuchen. Vorher wollen wir uns jedoch die Typen virtueller Umgebungen genauer ansehen und aufzeigen, worin sie sich unterscheiden.
Was sind VDIs?
VDI steht für Virtual Desktop Infrastructure („virtuelle Desktop-Infrastruktur“). Der Begriff umfasst Virtualisierungsinfrastrukturen, die darauf ausgelegt sind, Benutzern Zugriff auf eine virtuelle Maschine in Desktop-Form zu verschaffen. VDI kann sich sowohl auf die Infrastruktur als auch auf den Desktop beziehen, auf dem sich ein Benutzer verbindet.
VDI-Typen
Es gibt drei Haupttypen von VDIs:
- Persistente VDIs
- Nicht-persistente VDIs
- Mehrschichtige VDIs
Persistente VDIs
Bei einer persistenten VDI bleiben der Status der VDI sowie sämtliche Daten des Benutzers zwischen den Sessions erhalten. Wenn ein Benutzer beispielsweise eine virtuelle Maschine auf seinem Laptop erstellt, funktioniert diese wie eine persistente VDI. Jedes Mal, wenn sich der Benutzer verbindet, werden sein Desktop-Status und alle seine Daten gespeichert.
In einer Umgebung mit mehreren Benutzern und mehreren virtuellen Maschinen ist der Benutzer in der Regel statisch der Maschine zugewiesen. Das bedeutet, dass sich ein Benutzer bei jeder Anmeldung mit derselben virtuellen Maschine verbindet. Aus diesem Grund werden persistente VDIs manchmal auch als statische VDIs bezeichnet.
Nicht-persistente VDIs
Bei einer nicht-persistenten VDI bleiben der Status der virtuellen Maschine und die Benutzerdaten nicht zwischen den Sessions erhalten. Die virtuelle Maschine wird zwischen den Sessions gelöscht oder aus einem bereinigten Master-Image wiederhergestellt. In den meisten Umgebungen existiert ein Pool mit neuen virtuellen Maschinen, aus denen die Maschine des Benutzers zufällig ausgewählt wird. Bei einer nicht-persistenten VDI-Umgebung können der Benutzer mitunter bei jeder Anmeldung mit einer anderen virtuellen Maschine verbinden.
Mehrschichtige VDIs
Einige Infrastrukturanbieter stellen einen dritten VDI-Typ bereit, der eine Mischung aus einer persistenten und einer nicht-persistenten VDI darstellt. Diese Umgebungen sind üblicherweise in unterschiedliche Ebenen (Schichten) unterteilt. Es gibt also eine Benutzerebene, eine Anwendungsebene, eine Maschinenebene usw., weshalb diese Umgebungen als mehrschichtige VDIs bezeichnet werden. In einer mehrschichtigen VDI-Umgebung verbindet sich der Benutzer mit einer nicht-persistenten virtuellen Maschine, wobei allerdings ein User Profile-Dienst die Daten des Benutzers synchronisiert, sodass sie zwischen den Sessions erhalten bleiben. Wie in einer nicht-persistenten VDI-Umgebung verbindet sich der Benutzer mitunter bei jeder Anmeldung mit einer anderen virtuellen Maschine. Doch wie bei einer persistenten VDI, bleiben die Daten zwischen den Sessions erhalten.
Mehrschichtige VDI-Umgebungen sind der Umgebungstyp, der sich am schwierigsten unterstützen lässt, da der Benutzer letztendlich zwischen virtuellen Maschinen wechselt. Wir befassen uns zunächst mit den technischen Herausforderungen bei der Unterstützung mehrschichtiger VDIs und gehen anschließend kurz darauf ein, welche Herausforderungen und Lösungen ebenfalls herangezogen wurden, um statische VDIs zu unterstützen.
Unterstützung mehrschichtiger VDIs
Zum Unterstützen mehrschichtiger VDI-Umgebungen mussten vier Komponenten von Okta Verify und FastPass berücksichtigt werden:
- der Service-Account, der zum Schützen des kryptografischen Proof-of-Possession (PoP)-Schlüsselpaares verwendet wird
- die TPM-geschützten kryptografischen Schlüssel
- die lokal gespeicherten Anmeldedaten von Okta Verify
- die an das Okta-Backend gemeldeten Informationen zur Geräteidentifizierung
Sehen wir uns die einzelnen Komponenten im Detail an.
Der Okta Verify-Service-Account
Eines der kryptografischen Schlüsselpaare, die Okta Verify für die Authentifizierung verwendet, ist das Proof-of-Possession (PoP)-Schlüsselpaar. Der PoP-Schlüssel kann für eine Ein-Faktor-Authentifizierung im Hintergrund ohne Benutzerinteraktion verwendet werden. Daher muss er geschützt werden, um sicherzustellen, dass kein anderer Prozess auf dem Rechner ohne Wissen des Benutzers darauf zugreifen und ihn verwenden kann. In der Vergangenheit erstellte Okta Verify einen lokalen Windows-Account für den Schutz des (PoP-)Schlüssels. Diesen Account bezeichnen wir als Okta Verify-Service-Account oder als Sandbox-Account. Während der PoP-Schlüsseloperationen imitiert Okta Verify den Service-Account. Da es sich bei dem Account um einen lokalen User Account handelt, kann er in einer mehrschichtigen VDI-Umgebung nicht mit dem Benutzer zwischen virtuellen Maschinen verschoben werden.
Unsere Lösung: Wir schützen den PoP-Schlüssel in virtuellen Umgebungen mit einem Passcode. Bei Anwendungsstart generiert Okta Verify einen Passcode zum Schutz des Schlüssels. Wenn Okta Verify einen PoP-Schlüssel mit Win32-APIs erstellt, verwenden wir die NCryptSetProperty-Funktion mit dem NCRYPT_PIN_PROPERTY-Identifikator, um die PIN-Eigenschaft für den Schlüssel-Handle festzulegen, und wir geben unseren Passcode zum Schutz des Schlüssels an. Das Festlegen dieser Eigenschaft weist das Betriebssystem an, einen Schlüssel zu erstellen, der durch unseren Passcode zum Schutz des Schlüssels geschützt ist. Nach der Erstellung muss beim Verwenden des Schlüssels der korrekte Passcode angegeben werden. Da andere Prozesse auf dem Rechner nicht über den Passcode zum Schutz des Schlüssels verfügen, wird verhindert, dass sie den PoP-Schlüssel laden und verwenden können.
die TPM-geschützten kryptografischen Schlüssel
Okta Verify schützt die erstellten kryptografischen Schlüssel mit dem Trusted Platform Module (TPM) des Rechners, sofern verfügbar. Dies gilt auch bei vielen virtuellen Umgebungen, da diese häufig über virtuelle TPMs verfügen. In einer mehrschichtigen VDI-Umgebung kann Okta Verify das TPM jedoch nicht für den Schutz des Schlüssels verwenden. Denn wenn Okta Verify die Schlüssel via TPM schützt, sind diese Schlüssel kryptografisch an dieses TPM gebunden. Wenn Okta Verify nun auf einen anderen Rechner mit einem anderen TPM verschoben wird, wie dies in einer mehrschichtigen VDI-Umgebung der Fall ist, kann Okta Verify nicht auf die erstellten Schlüssel zugreifen und den Benutzer deshalb nicht authentifizieren.
Unsere Lösung: In mehrschichtigen VDI-Umgebungen speichert Okta Verify die kryptografischen Schlüssel in einem nicht exportierbaren Format über einen Software-basierten Schlüsselspeicheranbieter. Der Software-basierte Schlüsselspeicheranbieter wird vom Windows-Betriebssystem bereitgestellt und implementiert und die Schlüssel werden als Datei im Benutzer-Directory gespeichert. Wenn der User Profile-Synchronisierungsdienst der mehrschichtigen VDI das Benutzer-Directory synchronisiert, werden alle im Software-basierten Schlüsselspeicheranbieter gespeicherten Schlüssel des Benutzers synchronisiert. Weitere Informationen finden Sie in der Microsoft-Dokumentation zum Thema Schlüsselspeicherung.
Okta Verify-Anmeldedaten
Okta Verify speichert Anmeldedaten für Anwendungen im Windows Credential Manager, der zum Schutz von Anwendungsressourcen verwendet wird. Bislang setzte Okta Verify die Persist-Eigenschaft der Anmeldedaten auf CRED_PERSIST_LOCAL_MACHINE, wodurch die Anmeldedaten auf dem lokalen Rechner gespeichert wurden. Lokal gespeicherte Anmeldedaten können jedoch auf einer anderen virtuellen Maschine nicht von Okta Verify aufgerufen werden.
Unsere Lösung: Damit die Anmeldedaten in einer mehrschichtigen VDI-Umgebung zusammen mit dem User Profile zwischen virtuellen Maschinen verschoben werden können, setzen wir die Persist-Eigenschaft auf CRED_PERSIST_ENTERPRISE.
Geräteinformationen
Okta Verify erfasst zwei identifizierende Geräteinformationen, die an das Okta-Backend gemeldet werden:
- den Gerätenamen
- die Sicherheitskennung (SID) des Geräts
In mehrschichtigen VDI-Umgebungen können sich beide Gerätekennungen zwischen den Sessions ändern, was zu unerwartetem Verhalten, darunter das Fehlschlagen der Authentifizierung, führen kann.
Unsere Lösung: Damit in mehrschichtigen VDI-Umgebungen konsistente Gerätekennungen gemeldet werden, verwenden wir die SID des Benutzers als Basiskennung, da diese zwischen den Sessions erhalten bleibt. Daraus leiten wir einen Gerätenamen ab und melden diesen direkt als SID des Geräts.
Nachdem wir eine Lösung für jeden dieser Punkte gefunden hatten, war Okta Verify auch in virtuellen Umgebungen funktionsfähig. Doch bei FastPass war es noch nicht so weit. Die Benutzer konnten nach wie vor keine Benutzerverifizierung durchführen, also hatten wir noch zu tun.
Benutzerverifizierung in virtuellen Umgebungen
Die Benutzerverifizierung ist der Prozess, bei dem ein Authentifizierungsfaktor (z. B. Okta FastPass) überprüft, dass der Benutzer a) anwesend ist und b) die Person ist, die er zu sein vorgibt.
FastPass verwendet zur Benutzerverifizierung Windows Hello, wodurch der Benutzer seine Identität entweder mit einer PIN oder einer biometrischen Verifizierung bestätigen kann. Die meisten virtuellen Maschinen verfügen jedoch nicht über Windows Hello. Um Benutzern die Möglichkeit zu geben, die Zwei-Faktor-Authentifizierung mit Benutzerverifizierung in virtuellen Umgebungen durchzuführen, haben wir das Feature Okta Verify Passcode eingeführt.
FastPass-Registrierung
Während der FastPass-Registrierung wird der Benutzer aufgefordert, einen achtstelligen Passcode in Okta Verify zu erstellen.
Wenn Okta Verify das kryptografische Schlüsselpaar für die Benutzerverifizierung erstellt, verwenden wir dieselben Win32-APIs, um die NCRYPT_PIN_PROPERTY auf dem Schlüssel-Handle festzulegen und den Passcode des Benutzers als Wert zu übergeben. Das bedeutet, dass auf den Schlüssel für die Benutzerverifizierung nur dann zugegriffen werden kann, wenn der Passcode des Benutzers angegeben wird. Okta Verify speichert den Passcode des Benutzers nicht, sondern übergibt ihn lediglich über die Win32-APIs an das Betriebssystem.
FastPass-Authentifizierung
Während der Authentifizierung fordert Okta Verify den Benutzer auf, seinen Passcode einzugeben, um die Benutzerverifizierung durchzuführen.
Wenn Okta Verify den Schlüssel für die Benutzerverifizierung lädt, um die JWT-Sicherheitsabfrage der Authentifizierung zu signieren, legen wir die NCRYPT_PIN_PROPERTY erneut auf dem Schlüssel-Handle fest und übergeben den vom Benutzer angegebenen Passcode. Das Betriebssystem übernimmt die Verifizierung und stellt sicher, dass der Benutzer den korrekten Passcode angegeben hat.
Falscher Passcode
Wenn der Benutzer einen falschen Passcode eingibt, hat er maximal zwei weitere Versuche, bevor die Authentifizierungsanfrage fehlschlägt.
Da Okta Verify den Passcode des Benutzers nicht speichert, kann Okta Verify einen falschen Passcode nicht direkt erkennen. Stattdessen zieht Okta Verify die Fehler vom Schlüsselspeicheranbieter heran, um festzustellen, dass der vom Benutzer eingegebene Passcode falsch ist, und zeigt dem Benutzer dann den Fehler „Falscher Passcode“ an. Das Problem besteht darin, dass der zurückgegebene Fehler je nach Schlüsselspeicheranbieter variiert.
Wenn der Schlüssel im Softwareanbieter gespeichert ist, wird der Fehlercode NTE_INCORRECT_PASSWORD (0x80090033) zurückgegeben, wenn wir den Schlüssel öffnen und die NCRYPT_PIN_PROPERTY auf dem Schlüssel-Handle auf einen falschen Wert setzen. Dadurch lässt sich leicht feststellen, ob der Benutzer einen falschen Passcode eingegeben hat.
Beim TPM verhält es sich jedoch anders. Erstens wird kein Fehlercode zurückgegeben, wenn der Schlüssel geöffnet und die NCRYPT_PIN_PROPERTY auf dem Schlüssel-Handle auf einen falschen Wert gesetzt wird. Stattdessen wird später ein Fehlercode zurückgegeben, wenn der Schlüssel-Handle verwendet wird (z. B. beim Hashen von Daten). Zweitens ist der zurückgegebene Fehlercode nicht NTE_INCORRECT_PASSWORD, sondern NTE_PERM (d. h. Zugriff verweigert, 0x80090010).
Da der Fehler „Zugriff verweigert“ ein generischer Fehler ist, der in einer Vielzahl anderer Kontexte auftreten kann, können wir nicht einfach alle Fehler vom Typ „Zugriff verweigert“ als falsche Passcode-Eingaben des Benutzers verarbeiten. Vielmehr müssen wir Zugriffsfehler im Kontext der Operation behandeln. Wenn wir den Fehler „Zugriff verweigert“ erhalten, wenn wir versuchen, einen Schlüssel für die Benutzerverifizierung zu verwenden, von dem wir wissen, dass er durch einen vom Benutzer bereitgestellten Passcode geschützt ist, behandeln wir den Fehler als Fehler vom Typ „Falscher Passcode“ und erlauben dem Benutzer, seinen Passcode erneut einzugeben.
Unterstützung statischer VDIs
Statische VDIs ließen sich wesentlich einfacher unterstützen, da sie im Prinzip wie physische Maschinen funktionieren. Nachdem wir bereits die Herausforderungen bei der Unterstützung mehrschichtiger VDIs gelöst hatten, konnten wir einige der Lösungen wiederverwenden, um statische VDIs zu unterstützen. Die größte Herausforderung bei der Unterstützung einer statischen VDI ist die Benutzerverifizierung. Um diese zu überwinden, verwenden wir Okta Verify Passcode zur Benutzerverifizierung für statische VDIs.
Hinweis zur Unterstützung nicht-persistenter VDIs
Okta Verify wird für nicht-persistente VDIs nicht unterstützt, da keine Benutzerdaten zwischen den Sessions gespeichert werden, also auch nicht die Okta Verify-Daten des Benutzers. Wenn ein Benutzer versuchen würde, sich auf einem nicht-persistenten VDI bei FastPass zu registrieren, würde seine Registrierung nach dem Abmelden und erneuten Anmelden am VDI verloren gehen.
Konfigurieren von Okta Verify für virtuelle Umgebungen
Um Administratoren die Konfiguration von Okta Verify für virtuelle Umgebungen zu ermöglichen, haben wir ein neues Konfigurations-Flag mit der Bezeichnung AuthenticatorOperationMode hinzugefügt. Es besitzt drei Werte:
- Normal
- VirtualDesktopStatic
- VirtualDesktopLayered
Weitere Informationen zum Konfigurieren von Okta Verify für virtuelle Umgebungen finden Sie in unserer Dokumentation.
Um Administratoren die Konfiguration von Okta Verify für die Verwendung von Okta Verify Passcode zur Benutzerverifizierung zu ermöglichen, haben wir das neue Installations-Flag UserVerificationType hinzugefügt. Es besitzt zwei Werte:
- WindowsHello
- OktaVerifyPasscode
Damit es der Administrator leichter hat, passen wir den Standardwert des UserVerificationType-Flags basierend auf dem für das AuthenticatorOperationMode-Flag angegebenen Wert an.
- Im Normal-Modus ist der UserVerificationType standardmäßig WindowsHello.
- Im Modus VirtualDesktopStatic oder VirtualDesktopLayered lautet der UserVerificationType standardmäßig OktaVerifyPasscode.
Zum Konfigurieren von Okta Verify für die Ausführung in einer virtuellen Umgebung und die Verwendung von Okta Verify Passcodes zur Benutzerverifizierung muss der Administrator lediglich den AuthenticatorOperationMode richtig festlegen. Der UserVerificationType wird automatisch auf Okta Verify Passcode gesetzt.
Weitere Informationen zum Konfigurieren des Benutzerverifizierungstyps in Okta Verify finden Sie in unserer Dokumentation.
Hinweis zu den neuen Installations-Flags
Da die Installations-Flags AuthenticatorOperationMode und UserVerificationType die Kernfunktionalität von Okta Verify verändern, werden ihre Werte einmalig bei der Installation festgelegt. Nach der Installation durchgeführte Änderungen sind nicht wirksam. Dies ist notwendig, um die ordnungsgemäße Funktionsweise von Okta Verify sicherzustellen. Einige Kunden haben kürzlich Interesse daran bekundet, ihre Benutzer nach der Installation von einem Benutzerverifizierungstyp zu einem anderen zu migrieren.
Okta Verify Passcode anstelle von Windows Hello auf physischen Maschinen
In einigen Fällen möchten Administratoren nicht, dass ihre Benutzer Windows Hello verwenden, manchmal können Benutzer Windows Hello nicht verwenden, auch nicht auf physischen Computern. Daher haben wir die Okta Verify Passcode-Funktion so konzipiert, dass sie auch auf physischen Computern funktioniert. Der UserVerificationType kann unabhängig vom AuthenticatorOperationMode konfiguriert werden, um die Benutzerverifizierung mit Okta Verify Passcode auf physischen Geräten zu aktivieren.
Weitere Informationen finden Sie in unserer Dokumentation.
Probieren Sie es aus
Interessiert? Probieren Sie es aus. Um die neueste Version von Windows Okta Verify zu installieren, laden Sie sie vom Admin-Dashboard herunter. Befolgen Sie unbedingt unsere Anweisungen zum Konfigurieren von Okta Verify für virtuelle Umgebungen und zum Konfigurieren des Benutzerverifizierungstyps.
Haben Sie Fragen zu diesem Blog-Beitrag? Kontaktieren Sie uns unter eng_blogs@okta.com.
Entdecken Sie weitere aufschlussreiche Blogs der Entwickler von Okta, um Ihr Wissen zu erweitern.
Sie möchten Teil unseres fantastischen Technikerteams werden? Dann besuchen Sie unsere Karriere-Seite.
Nutzen Sie das Potenzial von modernem und fortschrittlichem Identity-Management für Ihr Unternehmen. Kontaktieren Sie unseren Vertrieb für weitere Informationen.
