YubiKey Smart Card HowTo: Meine Konfigurationen und Erfahrungen

Nachdem ich in den vergangenen Wochen mit YubiKeys als Lösung für Smart Card Anmeldung und passwortlose Anmeldung gespielt habe, möchte ich euch kurz meine Konfiguration und die Erfahrungen dazu etwas näher bringen.

Worauf beziehen sich die Einstellungen und meine Erfahrungen damit? Für welche Zwecke nutze ich die YubiKeys?
Aktuell nutze ich 2 Modelle:

  • YubiKey 5 NFC
    Den YubiKey 5 NFC nutze ich bei meinem Arbeitgeber als Smart Card für die Anmeldung meines Standard Domain Accounts an meinen Windows Endgeräten. Darüber hinaus wird der YubiKey 5 NFC genutzt für die Anmeldung meines Admin Domain Accounts an Windows Server Systemen, sowie an Systemen, die Smart Card Authentication unterstützen und konfiguriert haben.
  • YubiKey 5C
    Den YubiKey 5C nutze ich für meine privaten Systeme. Hier jedoch ausschließlich für die Anmeldung meines Admin Domain Accounts an meinen Windows Server Systemen. Zusätzlich nutze ich den YubiKey 5C zur passwortlosen Anmeldung via FIDO2, was aber nicht Bestandteil dieses Beitrags ist.

Die Konfiguration für die Nutzung beider YubiKeys ist ähnlich, die des privaten YubiKeys ist nur etwas vereinfacht wegen der ausschließlichen Nutzung für meinen Admin Domain Account.

Software / Middleware

Ein konfigurierter YubiKey funktioniert prinzipiell ohne weitere Software mit dem Windows Standard-Treiber als Software. Es empfiehlt sich jedoch die Nutzung des YubiKey Smart Card Minidriver als Middleware zwischen dem physikalischen Gerät und dem Betriebssystem. Der Treiber ermöglicht es, das native Windows Interface für das Enrollment von Zertifikaten zu verwenden, die Smart Card PIN/PUK zu verwalten und die Anmeldung mit der Smart Card an Windows Systemen durchzuführen. Der Treiber muss auf allen Systemen installiert sein, an denen eine Anmeldung mit dem YubiKey erfolgen soll, lokal und remote. Eine Besonderheit gibt es bei der Installation des Minidrivers auf Systemen, auf die man sich per RDP verbinden möchte. Dazu weiter unten mehr Infos.

Über den folgenden Befehl wird die MSI-Variante des Treibers installiert:

msiexec /i YubiKey-Minidriver-<Version>-x64.msi [/passive] | [/quiet]

Möchte man verifizieren, dass der Treiber erfolgreich vorhanden ist, lässt sich dies mit folgendem PowerShell Befehl erledigen:

Get-WindowsDriver -Online | where {($_.ProviderName -like "Yubico") -and ($_.ClassName -like "SmartCard") -and ($_.Version -like "*")} | select ProviderName,ClassName,Version

Ist der Treiber nicht (korrekt) installiert, gibt der Befehl nichts aus. Ist der Treiber korrekt installiert, gibt der Befehl beispielhaft folgende Werte aus:

ProviderName ClassName Version
------------ --------- -------
Yubico       SmartCard 4.1.1.210

Unterschied im Device Manager zwischen YubiKey mit und ohne Minidriver

Ohne Minidriver wird der YubiKey als Identity Device (NIST SP 800-73 [PIV]) angezeigt.
Mit Minidriver wird der YubiKey als YubiKey Smart Card Minidriver angezeigt

Vorbereitung des YubiKeys

Um den YubiKey vorzubereiten, benutzt man am Besten eine separate Workstation mit installierter YubiKey Manager Software. Neben der dann vorhandenen GUI, über die die folgenden Tasks umgesetzt werden können, wird auch das CLI Tool ykman.exe mit installiert, um verschiedene Tasks automatisierter durchführen zu können.

Initialisierung

Vor der Nutzung des YubiKeys als Smart Card muss die Card Holder Unique ID erstellt werden.

%ProgramFiles%\Yubico\YubiKey Manager\ykman.exe piv objects generate chuid

Änderung des Management Keys

Danach ändere ich den werkseitigen Management Key. Dieser lautet 010203040506070801020304050607080102030405060708 und ist mit dem TDES Algorithmus verschlüsselt.
Die folgende Befehlszeilen sind exemplarisch.
In ersten Fall möchte ich einen zufälligen Management Key generieren. Da man bei diesem Vorgehen den Key gar nicht kennt, erfolgt der Zugriff auf Management-Key-geschützte Funktionen mit der PIN des YubiKeys. Verschlüsselt wird mit TDES (Standard).
Im zweiten Fall gebe ich den Management Key vor und nutze keine PIN Protection. Als Verschlüsselungsalgorithmus verwende ich AES statt TDES; hierfür ist Firmware ab Version 5.4.3 erforderlich.

%ProgramFiles%\Yubico\YubiKey Manager\ykman.exe piv access change-management-key --management-key 010203040506070801020304050607080102030405060708 --generate --protect

%ProgramFiles%\Yubico\YubiKey Manager\ykman.exe piv access change-management-key --management-key 010203040506070801020304050607080102030405060708 --new-management-key <neuer-Management-Key*)> --algorithm AES256

*) 48 Zeichen (24 Bytes) bei Nutzung von TDES Verschlüsselung, 32 Zeichen (16 Bytes) bei AES128, 48 Zeichen (24 Bytes) bei AES192, 64 Zeichen (32 Bytes) bei AES256

Hinweis:
Wird wie oben konfiguriert eine PIN zur Eingabe als Management Key verwendet, wird die PUK Funktion gesperrt. Ein PIN Unblock ist dann nicht mehr möglich.

Änderung des PUKs

Neben dem Management Key ändere ich nun noch den werksseitigen PIN Unlock Key (PUK) 12345678.

%ProgramFiles%\Yubico\YubiKey Manager\ykman.exe piv access change-puk --puk 12345678 --new-puk <neuer-PUK>

Änderung der PIN

Optional kann nun noch die Standard PIN geändert werden. Eigentlich ist das natürlich Aufgabe des Users, aber wenn man sicherstellen möchte, dass zumindest nicht die werksseitige PIN 123456 genutzt wird, kann man dem User hier vorgreifen.

%ProgramFiles%\Yubico\YubiKey Manager\ykman.exe piv access change-pin --pin 123456 --new-pin <neuer-PIN-Code>
Zertifikat Templates

Smart Card Anmeldung basiert bekanntermaßen auf Zertifikaten. Dementsprechend benötigt man ein PKI und Templates für die Ausstellung der Zertifikate.

Hinweis:
In meinem Beispiel verwende ich RSA als Cryptographic Provider. Bei Verwendung von ECDH muss die Kompatibilität im AD erst per GPO aktiviert werden (siehe weiter unten).

YubiKey Smart Card User Authentication Zertifikat (User-Self-Enrollment)

Für meine Standard User habe ich eingestellt, dass deren Zertifikat selbständig erstellt und ausgerollt wird. Für das User Template wähle ich daher die folgende Konfiguration.

  • General
    • Template display name: YubiKey Smart Card Authentication User Enrollment
    • Template name: YubiKeySmartCardAuthenticationUserEnrollment
    • Validity period: 2 years
    • Renewal period: 3 months
    • Publish certificate in Active Directory: [X]
      • Do not automatically reenroll if a duplicate certificate exists in Active Directory: [X]
  • Compatibility
    • Certification Authority: <OS-Version der CA>
    • Certificate recipient: <OS-Version des ältesten Systems in der Domain>
  • Request Handling
    • Purpose: Signature and encryption
    • Include symmetric algorithms allowed by the subject: [X]
    • Allow private key to be exported: [X]
    • Renew with the same key: [ ]
    • For automatic renewal of smart card certificates, use the existing key if a new key cannot be created: [X]
    • Prompt the user during enrollment: [X]
  • Cryptography
    • Provider category: Key Storage Provider
    • Algorithm name: RSA
    • Minimum key size: 2048
    • Choose which cryptographic providers can be used for requests
      • Requests must use one of the following providers: Microsoft Software Key Storage Provider
    • Request hash: SHA256
  • Security
    • Permissions (Groups/Users)
      • <Group of Self-Enrollment Users>: Read, Enroll, Autoenroll

Abschließend habe ich das Template per PowerShell veröffentlicht:

Add-CATemplate -Name YubiKeySmartCardAuthenticationUserEnrollment

YubiKey Smart Card Admin Authentication Zertifikat (Enroll on Behalf of; mit Approval)

Anders als bei Standard Usern habe ich für Admins ein Template, welches erfordert, dass a) ein CA Manager die Ausstellung des Zertifikats freigeben muss und b) das Zertifikat nicht durch den Admin selbst, sondern einen weiteren User (Enrollment Agent) für den Admin ausgerollt wird. Für das Admin Template wähle ich daher die folgende Konfiguration.

  • General
    • Template display name: YubiKey Smart Card Authentication Admin Enrollment
    • Template name: YubiKeySmartCardAuthenticationAdminEnrollment
    • Validity period: 2 years
    • Renewal period: 3 months
    • Publish certificate in Active Directory: [X]
      • Do not automatically reenroll if a duplicate certificate exists in Active Directory: [X]
  • Compatibility
    • Certification Authority: <OS-Version der CA>
    • Certificate recipient: <OS-Version des ältesten Systems in der Domain>
  • Request Handling
    • Purpose: Signature and encryption
    • Include symmetric algorithms allowed by the subject: [X]
    • Allow private key to be exported: [X]
    • Renew with the same key: [ ]
    • For automatic renewal of smart card certificates, use the existing key if a new key cannot be created: [X]
    • Prompt the user during enrollment: [X]
  • Cryptography
    • Provider category: Key Storage Provider
    • Algorithm name: RSA
    • Minimum key size: 2048
    • Choose which cryptographic providers can be used for requests
      • Requests must use one of the following providers: Microsoft Software Key Storage Provider
    • Request hash: SHA256
  • Security
    • Permissions (Groups/Users)
      • Authenticated Users: Read
      • <Group of On-Behalf-of Users>: Read, Enroll
  • Issuance Requirements
    • CA certificate manager approval: [X]
    • This number of authorized signatures: 1
    • Policy type required in signature: Application policy
    • Application policy: Certificate Request Agent
    • Require the following for reenrollment: Same criteria as for enrollment

Auch dieses Template habe ich zum Abschluss per PowerShell veröffentlicht:

Add-CATemplate -Name YubiKeySmartCardAuthenticationAdminEnrollment
Group Policy Settings für Smart Card Authentifizierung

Um die YubiKeys für die Authentifizierung per Smart Card in Active Directory Domains sicher und sinnvoll nutzen zu können, habe ich mehrere Anpassungen per GPO vorgenommen.

Verhalten der Workstation beim Entfernen der Smart Card

Meldet sich ein Domain User per Smart Card an, kann danach standardmäßig die Smart Card entfernt werden und der User bleibt trotzdem angemeldet und die Workstation entsperrt. Aus Sicherheitsgründen empfiehlt es sich, dieses Verhalten zu ändern und die Workstation zumindest zu sperren (in hochsicheren Umgebungen oder auf Servern kann hier auch ein Logoff erzwungen werden). In der folgenden Policy sperre ich die Workstation beim Entfernen des YubiKeys.

Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Local Policies \ Security Options
-> Interactive logon: Smart card removal behavior => Define this policy setting: Lock Workstation

Smart Card Removal Policy Service

Eine Besonderheit ergibt sich nun aus dem konfigurierten Verhalten beim Entfernen des YubiKeys.

  1. Falls die Policy auf den Wert Lock Workstation gesetzt ist, sich die Workstation jedoch nicht sperrt beim Entfernen des YubiKeys, deutet dies i.d.R. darauf hin, dass der Smart Card Removal Policy Service (auf Deutsch: Richtlinie zum Entfernen der Smartcard) deaktiviert und nicht gestartet ist.
  2. Werden neben der Smart Card Funktion noch weitere Features des YubiKeys wie U2F genutzt, verhält sich der YubiKey unter Umständen so, als ob er entfernt wird. Mit obiger Einstellung bewirkt dies ein Sperren der Workstation, was in diesem Fall nicht gewünscht ist.

In diesen Fällen muss der Smart Card Removal Policy Service so konfiguriert werden, dass der Startup Type auf Automatic (Delayed Start) gesetzt wird:

Computer Configuration \ Preferences \ Windows Settings \ Registry \ New Registry Item
-> Action: Update
-> Hive: HKEY_LOCAL_MACHINE
-> Key Path: SYSTEM\CurrentControlSet\Services\SCPolicySvc
-> Value name: DelayedAutoStart
-> Value type: REG_DWORD
-> Value data: 1

Alternativ kann der Service über folgenden PowerShell Befehl z.B. per Startup Script konfiguriert werden:

Set-Service -Name ScPolicySvc -StartupType AutomaticDelayedStart

Danach sollte die Workstation beim Entfernen der Smart Card gesperrt werden.

PIN Unlock Key (PUK)

Wird ein YubiKey das erste Mal auf einem System mit dem Minidriver verwendet, prüft dieser den Management Key und die PUK des YubiKeys daraufhin, ob noch die Standardwerte verwendet werden. Im obigen Abschnitt Vorbereitung des YubiKeys habe ich beides ja schon geändert, sodass die folgende Konfiguration nicht mehr zwingend erforderlich ist. Hat man das aber versehentlich vergessen und verwendet für Management Key und PUK die Standardwerte, aktualisiert der Minidriver den Management Key und blockt den PUK. Dies führt dazu, dass die PUK Funktion inaktiv ist und man eine gesperrte PIN nicht freischalten kann. Um dieses ungewollte Block-Verhalten bei der automatischen Aktualisierung des Management Keys zu ändern, muss vor der Nutzung des YubiKeys ein Registry Key auf den entsprechenden Systemen gesetzt werden:

Computer Configuration \ Preferences \ Windows Settings \ Registry \ New Registry Item
-> Action: Update
-> Hive: HKEY_LOCAL_MACHINE
-> Key Path: Software\Yubico\ykmd
-> Value name: BlockPUKOnMGMUpgrade
-> Value type: REG_DWORD
-> Value data: 0

Um nun die PUK Funktion vor/während der Anmeldung nutzen zu können, um eine gesperrte PIN wieder freizugeben, muss folgende Policy konfiguriert werden:

Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Smart Card
-> Allow Integrated Unblock screen to be displayed at the time of logon => Enabled

Im Ergebnis wird durch die Policy neben der Option zur PIN Änderung auch die Option zum Entsperren per PUK eingeblendet.

ECDH statt RSA: Support für Elliptic Curve Cryptography (ECC) Certificate Login

Wurde im Template des Zertifikats statt RSA die ebenfalls unterstützten (aber älteren und weniger sicheren) (<= sorry, die Aussage ist Quatsch!) Algorithmen ECDH_P256 oder höher als Cryptography Algorithm ausgewählt, muss im Active Directory ECC unterstützt werden. Standardmäßig können ECC Zertifikate im Active Directory nicht zum Domain Login verwendet werden. Um ECC Zertifikate zu erlauben, muss die entsprechende Policy auf allen Systemen aktiviert werden, an denen mit ECC Zertifikaten authentifiziert werden soll.

Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Smart Card
-> Allow ECC certificates to be used for logon and authentication => Enabled
Smart Card RDP Authentication

Voraussetzungen:

  • Wird der YubiKey Smart Card Minidriver als Middleware verwendet, muss er sowohl auf dem lokalen RDP Client, als auch auf dem remote RDP Server installiert sein.
  • Wird der native Microsoft Smart Card Treiber verwendet, sind keine Installationen lokal und remote erforderlich.

Prinzipiell funktioniert die RDP Anmeldung analog zur lokalen Anmeldung. Bei der Verbindung zum RDP Server wird statt die Credentials einzugeben das entsprechende Smart Card Zertifikat ausgewählt.
Lediglich ein Microsoft Patch scheint in der Vergangenheit hier Probleme bereitet zu haben, aber das war noch bevor ich YubiKeys verwendet habe.

Smart Card RDP Logon Fehler bei Nutzung des Minidrivers: Requested Key Container is not available on the smart card

Der Fehler tritt auf, wenn der YubiKey Smart Card Minidriver verwendet wird, aber nur am Endgerät geladen wurde, jedoch nicht auf dem Zielsystem, zu dem man sich per RDP verbinden möchte. Ursache dafür ist, dass der Treiber normalerweise nur geladen wird, wenn der YubiKey daran physikalisch eingesteckt wird. Das ist bei RDP aber nicht der Fall.

Prüfen lässt sich dies am Zielsystem in der CMD. Im Problemfall gibt hier der Befehl certutil -scinfo die Karte als Identity Device (NIST SP 800-73 [PIV]) aus, was das Standardgerät in Windows ist. Der korrekte Wert der Karte lautet hingegen YubiKey Smart Card.

Um das Problem zu beheben muss auf dem Zielsystem der Minidriver mit dem Parameter INSTALL_LEGACY_NODE=1 installiert werden:

msiexec /i YubiKey-Minidriver-<Version>-x64.msi INSTALL_LEGACY_NODE=1 [/passive] | [/quiet]

Ist der Minidriver bereits installiert, lässt sich das Problem nachträglich noch manuell beheben. Dazu ist über den Gerätemanager der Treiber der vorhandenen Smart Card zu ändern auf den Hersteller Yubico und das Model YubiKey Smart Card Minidriver.

Nutzung mehrerer Smart Card Credentials mit einem YubiKey

Ein PIV-enabled YubiKey verfügt über 4 Slots für X.509 Zertifikate und deren Private Keys. Jeder Slot hat eigentlich einen eigenen Zweck und teilweise unterschiedliche PIN Policies. Die genauen Unterschiede sind auf der Developer Website von Yubico zu finden, hier nur eine Kurzübersicht:

  • Slot 9a: PIV Authentication
    Zweck: Benutzer Authentifizierung via Smart Card
    PIN: PIN-Eingabe ist erforderlich um Private Key Operationen durchzuführen
  • Slot 9c: Digital Signature
    Zweck: Dokumentensignierung, Programmsignierung, Scriptsignierung, etc.
    PIN: PIN-Eingabe ist erforderlich um Private Key Operationen durchzuführen
  • Slot 9d: Key Management
    Zweck: Verschlüsselung von z.B. Emails, Dokumenten, etc.
    PIN: PIN-Eingabe ist erforderlich um Private Key Operationen durchzuführen
  • Slot 9e: Card Authentication
    Zweck: Physical Access Applications, z.B. Gebäudezugangssysteme
    PIN: PIN-Eingabe ist nicht erforderlich um Private Key Operationen durchzuführen

Trotz der Unterschiede sind die 4 Slots technisch ähnlich und können z.T. „zweckendfremded“ werden – u.a. eben auch, um Credentials von mehreren User-Accounts zu speichern. Lediglich Slot 9e ist auf Grund der fehlenden PIN Anforderung nicht geeignet.

Praktisch ist dies, wenn beispielsweise eine reale Person über mehrere Accounts wie einen User Account und einen Admin Account verfügt.

Bei meinem YubiKey habe ich nun das Smart Card Zertifikat meines normalen User Accounts in Slot 9a importiert, das meines Admin Accounts in Slot 9d. Dabei ist zu beachten, dass das Auto-Enrollment und das Auto-Renew des Zertifikats nur für den normalen User in Slot 9a funktioniert. Das zusätzliche Admin Zertifikat muss manuell ausgestellt/erneuert und importiert werden. Hier der ykman CLI Befehl dazu für den Import in Slot 9d:

%ProgramFiles%\Yubico\YubiKey Manager\ykman.exe piv certificates import --management-key <Management-Key> --password <pfx-Password> 9d <Path-to-Certificate\Certificate-Name>.pfx

Wie sieht es jedoch mit PIN und PUK aus?

Das ist relativ einfach zu beantworten. PIN/PUK- und Zertifikatsverwaltung sind unabhängig voneinander. PIN und PUK sind Geräte-spezifisch und nicht Zertifikat-spezifisch. Das heißt, es kann pro YubiKey nur eine PIN und eine PUK vergeben werden, die dann für alle Zertifikate auf dem Gerät gültig ist.

Hilfreiche Tools

Einige nützliche, bzw. benötigte Tools habe ich oben ja bereits genannt. Darüber hinaus empfehle ich die folgenden Tools zur besseren Nutzung und Administration der YubiKeys.

PowerShell Modul

Yubico bietet seit September 2021 ein .NET SDK für die YubiKeys an. Dazu wurde bereits ein erstes PowerShell Modul entwickelt, welches auf GitHub heruntergeladen werden kann.

Ein detailliertes HowTo findet man auf der GitHub Download Seite.

Troubleshooting / Probleme

Device Manager zeigt keine Smart Card an

Beim geschäftlichen YubiKey kämpfe ich mit dem Phänomen, dass trotz installiertem Minidriver dieser nicht verwendet wird, die certutil -scinfo Ausgabe sowohl lokal als auch über RDP zeigt nur das Windows Standardgerät an. Über den Device Manager kann ich den Treiber nicht tauschen, da hier überhaupt kein Smart Card Gerät angezeigt wird. Nur der Smart Card Reader. Die Anmeldung funktioniert, lokal und per RDP, aber eben nicht, wie es eigentlich sein soll.

Das Problem tritt nicht bei meinem privaten YubiKey nicht auf. Hier wird das Gerät korrekt im Device Manager als YubiKey Smart Card Minidriver in der Smartcard Geräteklasse angezeigt.

Momentan habe ich dafür noch keine Lösung.


Quellen:
YubiKey Smart Card Deployment Guide – Yubico
YubiKey Smart Card Troubleshooting – Yubico

15 Antworten

  1. Dominik sagt:

    Servus Andreas,
    vielen Dank für deine Zahl- und hilfreichen Blog Einträge. Ich habe mir das Yubikey Konstrukt nachgebaut, um meine PAWs damit abzusichern.
    Vielleicht hast du ein ähnliches Problem:
    Zertifkate, die im Slot2 (Dig.Signature) liegen, funktionieren nicht beim RDP Login. Das habe ich mehrfach mit meinen Yubikeys reprodozieren können. Wenn das Zertifikat im Slot1+3 liegt, funktioniert alles wunderbar. Ich nutze die Yubikeys u.a. auch für KeepassXC als 2ten Faktor über Challenge Response. Feine Sache das. Grüße vom Chiemsee, Dominik

  2. Patrick Schoeberl sagt:

    Ich hatte dasselbe Problem, dass der Treiber nicht richtig geladen wurde. Yubico hat mir dann empfohlen, folgende GPO auf Enabled zu setzen:
    Computer-Configuration\Policies\Administrative Templates\Windows Components\Smart Card\Turn on Smart Card Plug and Play service

    • Hallo Patrick
      Danke für den Hinweis. Ich hab’s probiert, bei mir hat sich das Problem dadurch nicht gelöst. Vielleicht liegt es aber auch einfach an meiner Windows 10 Version. Mein Firmen-PC hat noch Windows 10 1607 LTSB, während meine Firmen-Notebook und meine privaten Geräte eine aktuellere Version von Windows 10 haben.
      Gruß
      Andreas

  3. Pascal sagt:

    Moin Andreas,
    vielen Dank für den sehr guten Artikel! Eine Frage: du schreibst, dass die ECDH-Algorithmen unsicherer seien als RSA. Leider finde ich dazu online nichts. Bei div. Zertifikatsanbietern & Co. finde ich Aussagen, dass ECC und RSA sicherheitstechnisch gleich auf liegen, ECC aber besser performed.
    Hast du zufällig einen Link für mich, der den Vorteil von RSA gegenüber ECDH erklärt?

    Danke!
    Pascal

    • Hallo Pascal
      Du hast Recht, ECC ist nicht unsicherer als RSA und ja, performt besser, weil mit kleinerer Schlüssellänge als mit RSA gearbeitet werden kann um die gleiche Verschlüsselung zu erreichen. Ich glaub, ich hatte einen schlechten Tag, in dem Beitrag stimmt noch mehr nicht :-(, werde ich auf jeden Fall überarbeiten. Das Argument „unsicherer“ ist generell schlecht ausgedrückt. Es gab eine Zeit, da war ECC nicht von allen Browsern unterstützt und deshalb eigentlich unüblich. Inzwischen ist das auch nicht mehr so, alle modernen Browser und Betriebssysteme unterstützen ECC Zertifikate.

  4. Yannik sagt:

    Hi Andreas,

    super, danke für diesen ausführlichen Post!
    Eine Frage habe ich: Funktioniert die Smartcard Removal Policy bei Nutzung des YubiKey 5 NFC?

    LG Yannik

  5. David sagt:

    Hei Andreas,

    wie verhält sich das nach Ablauf von den 3 Monaten zur Erneuerung des Yubikey Zertifikates? Bekommt der Nutzer hier eine Aufforderung nochmal mit seinem PIN ein neues zu machen oder geht das im Hintergrund komplett automatisiert? Ich habe auch via GPO eine Nutzerbenachrichtung be 10% aktiviert.

    Gruß
    David

    • Hallo David
      Der 3-Monats-Parameter hat eine andere Bedeutung. Das heißt nicht, dass das Zertifikat nur 3 Monate läuft, sondern dass ab Restlaufzeit < 3 Monate versucht wird, das Zertifikat zu erneuern. Das geht i.d.R. im Hintergrund. Nur wenn innerhalb der letzten 3 Monate das Zertifikat nicht erneuert werden kann (z.B. weil der Client keine direkte Verbindung ins Firmennetzwerk hat), muss ein neues Zertifikat erstellt werden. Abgelaufene Zertifikate können nicht erneuert werden, das geht nur, solange es noch gültig ist. Grúß Andreas

      • David sagt:

        Hallo Andreas,

        Danke für die schnelle Antwort. Beginnt er dann damit ab den 10% von den 3 Monaten oder in welchem Zeitraum wird hier versucht. Wir haben bei uns viele Montageleute/Systemtechniker die oft über einige Wochen nicht vor Ort sind. Ich denke da geht das bestimmt auch ganz normal über eine aktive VPN Verbindung.

        Gruß

        • Hallo David
          Die 10% bezieht sich nicht auf die Renewal-Period, sondern auf die Gesamtlaufzeit des Zertifikats. D.h. bei z.B. 365 Tagen Laufzeit werden ab ca. 36 Tagen Restlaufzeit Ablauf-Events generiert. Das ist natürlich dann doof, wenn die Renewal Period kleiner als die Log/Notification Period ist. Dann werden Events generiert, obwohl sich das Zertifikat noch gar nicht versucht zu erneuern. Ein guter Wert ist daher z.B. bei einem Zertifikat mit 2 Jahren Laufzeit eine 3 Monate Renewal Period und 5% Log/Notification Period. Das ergibt (ca.) 730 Tage Laufzeit, 90 Tage Renewal und 36,5 Tage Log/Notification Period.
          Gruß
          Andreas

  6. Marco sagt:

    Hi Andreas,
    vielen Dank für deine sehr lehrreichen Artikel zum Thema Smart-Card Authentifizierung mit Yubikeys. Wir haben die Smart-Card Authentifizierung erfolgreich in unserem Unternehmen eingeführt (-> klappt problemlos zur lokalen Anmeldung an Windows 11 Laptops oder an Servern via RDP etc.). Wir bekommen aber an physischen Servern (Windows Server 2019) am Konsolenlogin keine Möglichkeit angeboten, sich per Smart-Card anzumelden. SCardSvr ist auf manuell oder automatisch gestartet, macht keinen Unterschied. Yubikey Treiber ist installiert.
    Hast du eine Idee?
    VG, Marco

    • Hallo Marco
      Ist auf euren Servern die Policy „Interactive logon: Don’t display last signed-in“ aktiv? Falls ja, probier’s mal ohne die Einstellung.
      Gruß
      Andreas

      • Marco sagt:

        Danke für den Tipp, ist aber nicht aktiviert. Achja, sind Server Core Installationen…

        • Hallo Marco
          Ja, die Info „Server Core“ ist grundsätzlich sehr wichtig. Eigentlich ist – nach Microsoft’s Vorstellung – eine lokale Anmeldung an einem Core-System nicht vorgesehen/gewünscht/etc., weswegen die interaktiven Anmelde-Features nicht vergleichbar sind mit „normalen“ Servern. Deswegen geht bei euch die Smartcard-Anmeldung per RDP (remote) aber eben nicht lokal (interaktiv). Hier gibt es ein ähnliches Problem wie bei euch, aber selbst die Antwort der Microsoft Mitarbeiterin ist „fragwürdig“. Ob ihre Lösung a) überhaupt funktioniert ist unklar und b) was auf jeden Fall mit der Lösung passiert ist, dass sich kein lokaler User mehr anmelden kann (soweit ich weiß).
          Gruß
          Andreas

Schreibe einen Kommentar zu Patrick Schoeberl Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.