Wer nutzt SmartCards für Windows-Login?
Moin Kollegen.
Ich bin damit beschäftigt, zu prüfen, ob unsere Domänenlogons in Zukunft mittels SmartCard ausführbar gemacht werden sollen und suche nach Erfahrungsaustausch.
Wichtig ist mir zunächst einmal zu wissen, ob es überhaupt gebräuchlich ist, also ob es z.B. in der Leserschaft hier viele (wenige?) gibt, die das benutzen.
Mit SmartCard-Login meine ich keinen VPN-Zugang, sondern normalen Windows-Domänenlogon unter Einsatz einer wie auch immer gearteten SmartCard, z.B. Yubikey oder auch virtuelle SmartCards.
Wer nutzt das?
Disclaimer: bitte nicht "ich nicht" schreiben, das interessiert hierbei nicht. Nur melden, wenn Ihr's nutzt
Ich bin damit beschäftigt, zu prüfen, ob unsere Domänenlogons in Zukunft mittels SmartCard ausführbar gemacht werden sollen und suche nach Erfahrungsaustausch.
Wichtig ist mir zunächst einmal zu wissen, ob es überhaupt gebräuchlich ist, also ob es z.B. in der Leserschaft hier viele (wenige?) gibt, die das benutzen.
Mit SmartCard-Login meine ich keinen VPN-Zugang, sondern normalen Windows-Domänenlogon unter Einsatz einer wie auch immer gearteten SmartCard, z.B. Yubikey oder auch virtuelle SmartCards.
Wer nutzt das?
Disclaimer: bitte nicht "ich nicht" schreiben, das interessiert hierbei nicht. Nur melden, wenn Ihr's nutzt
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 638576
Url: https://administrator.de/forum/wer-nutzt-smartcards-fuer-windows-login-638576.html
Ausgedruckt am: 25.04.2025 um 09:04 Uhr
40 Kommentare
Neuester Kommentar
Hallo,
und hier. In unserem Fall mit Yubikey als Smartcard==SmartcardReader.
Grüße
lcer
und hier. In unserem Fall mit Yubikey als Smartcard==SmartcardReader.
Grüße
lcer
Welche Technik hinter unserer Smartcard steckt k.A., wird einfach ins Lesegerät der mobilen Workstation gesteckt und voala.
Für Festrechner gibt's auch Kartenleser.
Probleme bei den Anderen sehe ich keine außer das es 2 Lager gibt.
Die die das sofort benutzt haben und die (wie ich) die Karte nicht nutzen.
Wie oben geschrieben, meine Finger vergessen sonst die vielen Kennwörter. *gg*
Soweit ich weiß werden die Karten bei uns nur für die Anmeldungen an den Maschinen benutzt, aber (noch) nicht für andere Anwendungen.
Die Einführung hat etwas gedauert, aber da wir hier die gesamte IT Landschaft umgekrempelt hatten, war das Thema Smartcard nur eines unter vielen und musste sich dort anstellen wo es im Plan dran war.
Den einzigen Charme den ich bei den Smartcards sehe ist, wenn die Karte gezogen wird ist die Maschine ad hoc gesperrt.
Für Festrechner gibt's auch Kartenleser.
Probleme bei den Anderen sehe ich keine außer das es 2 Lager gibt.
Die die das sofort benutzt haben und die (wie ich) die Karte nicht nutzen.
Wie oben geschrieben, meine Finger vergessen sonst die vielen Kennwörter. *gg*
Soweit ich weiß werden die Karten bei uns nur für die Anmeldungen an den Maschinen benutzt, aber (noch) nicht für andere Anwendungen.
Die Einführung hat etwas gedauert, aber da wir hier die gesamte IT Landschaft umgekrempelt hatten, war das Thema Smartcard nur eines unter vielen und musste sich dort anstellen wo es im Plan dran war.
Den einzigen Charme den ich bei den Smartcards sehe ist, wenn die Karte gezogen wird ist die Maschine ad hoc gesperrt.
Hi,
dachte, Du wärst schon voll dabei, nach deinen vorherigen Fragen. Ich hatte einige Smartcard-Projekte, zuletzt mit YubiKeys. Privat nutze ich es auch.
Domain-Logon ist eigentlich nie das Problem. Ich habe bei einer IT-affinen Nutzerbasis sogar die YubiKey Touch-Policy aktiv, und es wurde gut angenommen (obwohl es bei langsamen RDP-Logins via VPN nerven kann, zugegebenermaßen).
Gerade bin ich dabei, das wieder abzulösen. Denn es ist halt nicht unbedingt einfach oder "schnell", Mitarbeitern im z.B. im Ausland das konfigurierte Gerät zur Verfügung zu stellen. Wenn man per Auto-Enrollment provisioniert, ist das wieder etwas anders, aber das hat je nach Features der Smartcard andere Nachteile. Die Cloud-IAMs setzen auch nicht darauf. In der eigenen IT und mit Gebieten mit Cloud-Aversion würde ich immer zur Smartcard greifen.
Grüße
Richard
dachte, Du wärst schon voll dabei, nach deinen vorherigen Fragen. Ich hatte einige Smartcard-Projekte, zuletzt mit YubiKeys. Privat nutze ich es auch.
Domain-Logon ist eigentlich nie das Problem. Ich habe bei einer IT-affinen Nutzerbasis sogar die YubiKey Touch-Policy aktiv, und es wurde gut angenommen (obwohl es bei langsamen RDP-Logins via VPN nerven kann, zugegebenermaßen).
Gerade bin ich dabei, das wieder abzulösen. Denn es ist halt nicht unbedingt einfach oder "schnell", Mitarbeitern im z.B. im Ausland das konfigurierte Gerät zur Verfügung zu stellen. Wenn man per Auto-Enrollment provisioniert, ist das wieder etwas anders, aber das hat je nach Features der Smartcard andere Nachteile. Die Cloud-IAMs setzen auch nicht darauf. In der eigenen IT und mit Gebieten mit Cloud-Aversion würde ich immer zur Smartcard greifen.
Grüße
Richard
Moin,
Gruß,
Dani
Auf gut 300 Aufrufer nur 3 Leute? Ich habe es befürchtet... Gute Technik, aber geringe Verbreitung.
Ich habe mit weniger Aufrufer gerechnet. Was genau nutzt Ihr? (Icer hat's schon gesagt)
Klassisches Smartcard. Die Zertifikate stammen von unserem TrustCenter. Denn die Karte wird nicht nur für die Anmeldung am Rechner genutzt, sondern auch als Mitarbeiterausweis, Verschlüsselung, VPN, Zugangsberechtigungen für Standorte und deren Bereiche, Zeiterfassung, Kantine, etc... Welche Probleme gab/gibt es (Einführung/Handling/Komfort/Sicherheit)?
Das weiß ich leider nicht. Die Implementierung passierte vor meiner Anstellung. Aus Erzählungen weiß ich aber, dass es eine lebengroße Spielwiese gab, wo nach Plan nach und nach die Anwendungen bzw. die jeweiligen Teams ihre Workflow testen konnten. Um so Schulungen als auch die notwendigen Anpassungen für die Produktivumgebung dokumentieren zu können. Kennt Ihr SSO-Anwendungen, die damit Probleme haben?
Ja. Es sind primär Nischenprodukte oder Eigenentwicklungen die nicht so einfach angepasst werden können. Ich kann dir theoretisch eine Liste zur Verfügung stellen, aber ein direkten Nutzen für dich sehe ich nicht. Wo kein SSO (mehr) möglich ist/war, greifen wir auf Techniken wie SAML/oAuth in Kombination mit AD FS zurück.Gruß,
Dani
Den einzigen Charme den ich bei den Smartcards sehe ist, wenn die Karte gezogen wird ist die Maschine ad hoc gesperrt.
Ich sehe da noch weitere (positive) Punkte in der Fläche:- Keine Weitergabe der Zugangsdaten mehr möglich. Denn eine Karte ist erst einmal einzigartig.
- Sperren der Karte führt automatisch dazu, dass alle verbundenen IT-Systeme und Anwendungen nicht mehr genutzt werden können.
Gruß,
Dani
Hallo,
Die Normal-Benutzer-Anmeldung läuft meist über Kennworte. Hier muss man nämlich einen Weg gegen das „Steckenlassen“ und „Verbummeln“ finden. Bei den Yubikeys ist durch die Kombi aus Lesegerät und Smartcard die Anwendung an sich einfach. Aber das Ding ist ziemlich klein. Es gibt auch Smartcardreader mit Bluetooth, die als Mitarbeiterausweis an die Brust geheftet getragen werden. Das ist mit zu viel Technik (Bluetooth-Dongle am PC, Batterie im „Ausweis“).
Wo es möglich ist, haben wir andere Anmeldungen an das AD gebunden. Zum Teil mit Azure/SAML.
Grüße
lcer
Zitat von @H41mSh1C0R:
Wie oben geschrieben, meine Finger vergessen sonst die vielen Kennwörter. *gg*
Den einzigen Charme den ich bei den Smartcards sehe ist, wenn die Karte gezogen wird ist die Maschine ad hoc gesperrt.
Zwischengespeicherte Passwordhashes waren der Hauptgrund für die Einführung. Zunächst haben wir für die Admin-Konten die Smartcardanmeldung erzwungen.Wie oben geschrieben, meine Finger vergessen sonst die vielen Kennwörter. *gg*
Den einzigen Charme den ich bei den Smartcards sehe ist, wenn die Karte gezogen wird ist die Maschine ad hoc gesperrt.
Die Normal-Benutzer-Anmeldung läuft meist über Kennworte. Hier muss man nämlich einen Weg gegen das „Steckenlassen“ und „Verbummeln“ finden. Bei den Yubikeys ist durch die Kombi aus Lesegerät und Smartcard die Anwendung an sich einfach. Aber das Ding ist ziemlich klein. Es gibt auch Smartcardreader mit Bluetooth, die als Mitarbeiterausweis an die Brust geheftet getragen werden. Das ist mit zu viel Technik (Bluetooth-Dongle am PC, Batterie im „Ausweis“).
Wo es möglich ist, haben wir andere Anmeldungen an das AD gebunden. Zum Teil mit Azure/SAML.
Grüße
lcer
Hi
Wir verwenden zwar nicht den "Windows Standard" sondern eine SSO Lösung von Evidian
https://www.evidian.com/products/enterprise-sso/?s=316471&gclid=EAIa ...
Funktioniert sehr gut. Hat auch einen Kioskmodus zb für Scada Systeme (WinCC ist nicht mehrfach Startbar)
Anwender kann für bestimmte Tätigkeiten diesen selbst anlernen zb für Browser Passwörter.
Alle x Stunden und beim ersten anmelden am Tag muss zusätzlich ein PIN eingegeben werden.
Und vieles mehr. Bei Interesse gerne nachfragen.
Mit freundlichen Grüßen Nemesis
Wir verwenden zwar nicht den "Windows Standard" sondern eine SSO Lösung von Evidian
https://www.evidian.com/products/enterprise-sso/?s=316471&gclid=EAIa ...
Funktioniert sehr gut. Hat auch einen Kioskmodus zb für Scada Systeme (WinCC ist nicht mehrfach Startbar)
Anwender kann für bestimmte Tätigkeiten diesen selbst anlernen zb für Browser Passwörter.
Alle x Stunden und beim ersten anmelden am Tag muss zusätzlich ein PIN eingegeben werden.
Und vieles mehr. Bei Interesse gerne nachfragen.
Mit freundlichen Grüßen Nemesis
Hallo,
- Aber zumindest speichert er keine Passwordhashes, weil es ja kein Passwort gibt.
Jedenfalls haben wir für die Adminkonten im AD eingestellt, dass eine Smartcard zum Login erforderlich ist und das führt dazu, dass kein Password mehr da ist.
Es ist übrigends nett in Powershell zu beobachten was wann passiert, wenn man beim Yubikey den "Tastendruck" als Bestätigung aktiviert hat:
Die Pin wird vom Get-Credential abgefragt.
Der Tastendruck auf den Yubikey wird erst angefordert (erkennbar durch blinken, als Anzeigen von Kryptooperationen) wenn der Restart-Computer Befehl ausgeführt wird. Und beim 2. PC wird wieder ein Tastendruck angefordert.
Dass die Kombination aus Zertifikat, PIN und Tastendruck (3 Faktoren) schon deutlich sicherer als ein Passwort (ein Faktor) ist sicher unstrittig.
Grüße
lcer
PS:
PPS:
zum Testen muss man nicht Restart-Computer nehmen
Zitat von @DerWoWusste:
@lcer00
und Du meinst, nun werden keine Hashes mehr zwischengespeichert? Hast Du das mit Mimikatz nachgeprüft?
nee habe ich nicht - da müsste ich mir das runterladen von Mimikatz selbst genehmigen. @lcer00
und Du meinst, nun werden keine Hashes mehr zwischengespeichert? Hast Du das mit Mimikatz nachgeprüft?
Jedenfalls haben wir für die Adminkonten im AD eingestellt, dass eine Smartcard zum Login erforderlich ist und das führt dazu, dass kein Password mehr da ist.
Es ist übrigends nett in Powershell zu beobachten was wann passiert, wenn man beim Yubikey den "Tastendruck" als Bestätigung aktiviert hat:
$cred = Get-Credential
Restart-Computer -Credential $cred -Computername PC1
Restart-Computer -Credential $cred -Computername PC2
Die Pin wird vom Get-Credential abgefragt.
Der Tastendruck auf den Yubikey wird erst angefordert (erkennbar durch blinken, als Anzeigen von Kryptooperationen) wenn der Restart-Computer Befehl ausgeführt wird. Und beim 2. PC wird wieder ein Tastendruck angefordert.
Dass die Kombination aus Zertifikat, PIN und Tastendruck (3 Faktoren) schon deutlich sicherer als ein Passwort (ein Faktor) ist sicher unstrittig.
Grüße
lcer
PS:
Da man wohl bei allen SmartCards mit Mimikatz die PIN aus dem RAM auslesen kann ...
der Yubikey führt die erforderlichen Smartcard-Kryptooperationen ersrt durch, wenn man die Taste drückt. Zumindest, wenn man mittels GPO die Touch Policy setzt: https://developers.yubico.com/yubikey-piv-manager/Settings_and_Group_Pol ...PPS:
zum Testen muss man nicht Restart-Computer nehmen

Wir nutzen dies für AD, Admin Zugänge und auch die User in der VDI Umgebung.
Zitat von @DerWoWusste:
Zudem kommt, dass Cred.Guard Entrepriselizenzen voraussetzt, welche wir nicht überall einsetzen.
Mit aktiviertem CredGuard kommt kein Tool an die Hashes (des domain accounts) - also hast du weder passworteingabe die man abfangen kann, noch gespeicherte hashe auf der kiste - das ist doch das Ziel hier, oder?Löst die Themen nicht ein aktivierter Credential Guard?
Ja nun, was will ich denn lösen? Lokale Hashes willst Du ja manchmal sogar unverschlüsselt haben.Zudem kommt, dass Cred.Guard Entrepriselizenzen voraussetzt, welche wir nicht überall einsetzen.
Hallo
Na ja, die PIN muss ja in irgend einer Art und Weise im RAM liegen. Der springende Punkt ist, dass noch jeweils ein Tastendruck erforderlich ist. Damit genehmigt man jeden Einsatz (bzw, wenn entsprechend eingestellt jede Einsatzmöglichkeit für eine „kurze Zeitspanne“ ) separat. Das schränkt die Verwendung sehr ein.
Wenn man beispielsweise eine gesperrte RDPSitzung entsperren will, ist es erforderlich Yubikey, PIN und Tastendruck zu haben. Das Kapern der Sitzung ist ohne Benutzertastendruck nicht möglich (ob man das mit irgendwelchen expoilts umgehen kann? Da kann man sich nie sicher sein).
Grüße
lcer
Na ja, die PIN muss ja in irgend einer Art und Weise im RAM liegen. Der springende Punkt ist, dass noch jeweils ein Tastendruck erforderlich ist. Damit genehmigt man jeden Einsatz (bzw, wenn entsprechend eingestellt jede Einsatzmöglichkeit für eine „kurze Zeitspanne“ ) separat. Das schränkt die Verwendung sehr ein.
Wenn man beispielsweise eine gesperrte RDPSitzung entsperren will, ist es erforderlich Yubikey, PIN und Tastendruck zu haben. Das Kapern der Sitzung ist ohne Benutzertastendruck nicht möglich (ob man das mit irgendwelchen expoilts umgehen kann? Da kann man sich nie sicher sein).
Grüße
lcer
Das Berühren des YubiKeys ist eine Smartcard-seitige Voraussetzung zur Freigabe der Private-Key-Operation(en), und damit schon geeignet, menschliche Interaktion abzuschichten. Im Endeffekt aber nur, wenn die Smartcard entsprechend konfiguriert wurde, und nicht mit Treiber-Setting (ich weiß nicht mehr, ob der verlinkte Manager als Hintegrunddienst gedacht ist und damit nur gleichwertig zum Treiber wäre; ich habe das immer ohne Client-Software gemacht).
Die Überlegungen zu RAM-Content und Mimikatz sind etwas theoretisch, weil ja das viel grundlegendere "Problem" (oder einfach Design) ist, dass eine Smartcard aus Sicht des Client-Computers quasi als Remote-Computer zwar einen Vorgang authentifiziert, aber das Client-System und damit den Vorgang selbst nicht kontrolliert. Der YubiKey erlaubt nach PIN- und/oder Touch-Authentifizierung Private-Key-Operations einzeln oder zeitbasiert (in der Regel ist nur zeitbasiert praktikabel oder - bei vielen anderen Smartcards - unterstützt). Die Vornahme der Private-Key-Operationen in dieser Situation wird von Windows prozessbasiert kontrolliert, nicht von der Smartcard.
Die Überlegungen zu RAM-Content und Mimikatz sind etwas theoretisch, weil ja das viel grundlegendere "Problem" (oder einfach Design) ist, dass eine Smartcard aus Sicht des Client-Computers quasi als Remote-Computer zwar einen Vorgang authentifiziert, aber das Client-System und damit den Vorgang selbst nicht kontrolliert. Der YubiKey erlaubt nach PIN- und/oder Touch-Authentifizierung Private-Key-Operations einzeln oder zeitbasiert (in der Regel ist nur zeitbasiert praktikabel oder - bei vielen anderen Smartcards - unterstützt). Die Vornahme der Private-Key-Operationen in dieser Situation wird von Windows prozessbasiert kontrolliert, nicht von der Smartcard.

Wir haben es so gelöst:
User steckt Yubikey in sein Device und kann das OS (Linux oder MacOS ) auf dem Device starten, ohne Yubikey gar keine OS Nutzung
möglich. (Yubikey & PIN & 2FA Code aus der App)
In der VDI wird der Yubikey weitergereicht und der User kann sich dann mit dem Yubikey & PIN & 2FA Code aus der App (Wir nutzen dafür DUO Security von Cisco) an der VDI egal welches OS er nutzen will, anmelden.
Beim Admin Panel ist es auch Yubikey & PIN & 2FA Code aus der App anmelden.
Wir nutzen MacOS und Linux als Grund OS. Windows nur noch als virtuelles OS. Kein User hat ein lokales Windows auf seiner Hardware. Kein lokales Windows spart dem Admin massig aufwand und ärger. Non-Persistent VDI und jeden Tag hat der User eine Jungfräuliche VDI.
Ein Kopieren von Daten in oder aus der VDI ist ausgeschaltet. Für den Datentransfer intern, extern haben wir einen Nextcloud Cluster der mit Eset gescannt wird.
Probleme bei der Einführung = User mussten sich umgewöhnen.
SSO Probleme gabs nur mit dem SAP und was mit ein bisschen Aufwand gelöst werden konnte, das ServiceDesk Software gebastel, konnten wir dann Problemlos ablösen.
Sicherheit haben wir so von mittelsicherheit auf Sicher hochgeschraubt.
Was die User am meisten schätzen ist der Wegfall des ewigen Passwordwechsels.
User steckt Yubikey in sein Device und kann das OS (Linux oder MacOS ) auf dem Device starten, ohne Yubikey gar keine OS Nutzung
möglich. (Yubikey & PIN & 2FA Code aus der App)
In der VDI wird der Yubikey weitergereicht und der User kann sich dann mit dem Yubikey & PIN & 2FA Code aus der App (Wir nutzen dafür DUO Security von Cisco) an der VDI egal welches OS er nutzen will, anmelden.
Beim Admin Panel ist es auch Yubikey & PIN & 2FA Code aus der App anmelden.
Wir nutzen MacOS und Linux als Grund OS. Windows nur noch als virtuelles OS. Kein User hat ein lokales Windows auf seiner Hardware. Kein lokales Windows spart dem Admin massig aufwand und ärger. Non-Persistent VDI und jeden Tag hat der User eine Jungfräuliche VDI.
Ein Kopieren von Daten in oder aus der VDI ist ausgeschaltet. Für den Datentransfer intern, extern haben wir einen Nextcloud Cluster der mit Eset gescannt wird.
Probleme bei der Einführung = User mussten sich umgewöhnen.
SSO Probleme gabs nur mit dem SAP und was mit ein bisschen Aufwand gelöst werden konnte, das ServiceDesk Software gebastel, konnten wir dann Problemlos ablösen.
Sicherheit haben wir so von mittelsicherheit auf Sicher hochgeschraubt.
Was die User am meisten schätzen ist der Wegfall des ewigen Passwordwechsels.

Windof ist und bleibt Windof egal ob Hardware oder Virtuell die Funktionen sind die selben.
Zitat von @146211:
Wir nutzen MacOS und Linux als Grund OS. Windows nur noch als virtuelles OS. Kein User hat ein lokales Windows auf seiner Hardware. Kein lokales Windows spart dem Admin massig aufwand und ärger. Non-Persistent VDI und jeden Tag hat der User eine Jungfräuliche VDI.
Ein Kopieren von Daten in oder aus der VDI ist ausgeschaltet. Für den Datentransfer intern, extern haben wir einen Nextcloud Cluster der mit Eset gescannt wird.
Wir nutzen MacOS und Linux als Grund OS. Windows nur noch als virtuelles OS. Kein User hat ein lokales Windows auf seiner Hardware. Kein lokales Windows spart dem Admin massig aufwand und ärger. Non-Persistent VDI und jeden Tag hat der User eine Jungfräuliche VDI.
Ein Kopieren von Daten in oder aus der VDI ist ausgeschaltet. Für den Datentransfer intern, extern haben wir einen Nextcloud Cluster der mit Eset gescannt wird.
Mal so ein paar Fragen, müssen eure User in ihrer Arbeitszeit Geld verdienen oder ist das egal?
Mir kommt das alles wie ein massiver Time Sink vor, der produktives Arbeiten ziemlich einschränkt.
Müssen eure User zum Kunden und dort mit der Software umgehen oder ist alles zentral an einem Standort?
Wieviele IT-Ler habt ihr pro User um eine solche Monströsität zu verwalten?
Wie oft werden Rechner ausgetauscht und wie viel IT-Budget habt ihr um solche Späße zu finanzieren?
Ich mein nur, ich habe auch so einen Kunden, der ähnlich hohe Sicherheitsstandards umsetzt, die IT-ler finden sich es total super, aber alle die damit arbeiten müssen, sind nur noch am abkotzen.
Bleibt da der Servicegedanken nicht irgendwie auf der Strecke?
Mal so ein paar Fragen, müssen eure User in ihrer Arbeitszeit Geld verdienen oder ist das egal?
Ja. Die Einen mit direkten Kontakt zum Kunden mehr. Das Controlling eher weniger. Mir kommt das alles wie ein massiver Time Sink vor, der produktives Arbeiten ziemlich einschränkt.
Das kann ich nicht beurteilen. Denn das System gibt es hier schon seit ich angenfangen habe. Einen Einblick, zu wie viele Problemen/Störungen/etc... es im Jahr kommt, habe ich leider nicht. Müssen eure User zum Kunden und dort mit der Software umgehen oder ist alles zentral an einem Standort?
Sowohl als auch. Wieviele IT-Ler habt ihr pro User um eine solche Monströsität zu verwalten?
Das ist schwer zu sagen. Denn die notwendigen Infrastrukturen, Applikationen, werden ja nicht nur für den einen Zweck genutzt. Sondern es haben sich mit der Zeit auch Synergien für Produkte ergeben, mit den wir wieder Geld verdienen. Wie oft werden Rechner ausgetauscht und wie viel IT-Budget habt ihr um solche Späße zu finanzieren?
Alle 5 Jahre. Wobei 80% der IT-Arbeitsplätze als VDI betrieben werden. Hier erfolgt ein Tausch der Zero/Thinclients nur noch wenn es notwendig ist. Wobei das aus meiner Sicht erstmal unabhängig von der Smartcard Thematik ist. Bleibt da der Servicegedanken nicht irgendwie auf der Strecke?
In wie fern? Ob der Nutzer Benutzername und Passwort eintippt oder die Smartcard einsteckt und mit den PIN bestätigt, macht erst einmal keinen großen Unterschied.Gruß,
Dani
Zitat von @Dani:
Bleibt da der Servicegedanken nicht irgendwie auf der Strecke?
In wie fern? Ob der Nutzer Benutzername und Passwort eintippt oder die Smartcard einsteckt und mit den PIN bestätigt, macht erst einmal keinen großen Unterschied.Mir gings dabei wie von DerWoWusste bereits korrekt bemerkt um dieses komische Mac/Linux + Virtuelles Windows Konstrukt von ZeroTrust, welches meines Erachtens nur funktioniert wenn alles in einem Standort sitzt, und dann ist eigentlich die Sicherheit auch ohne dieses komische Konstrukt relativ easy umzusetzen, weshalb ich nicht verstehe warum man den Usern so eine Grausamkeit antut.
Das mit dem Stick und draufdappen interessiert mich aber schon auch brennend, gerade weil ich das mit dem kleineren blauen Yubikey nicht hinbekommen hab, und gern wissen würde was man tun muss, um es gewinnbringend einzusetzen. Dazu gehört aber auch der Business Case, denn mach mal einer Firma für Schweissdienstleistungen klar, warum sie sowas braucht, ich will das danach ja auch verkaufen.
Grad das Thema Business Case und Rentabilität wird hier und in anderen deutschen Foren gern unter den Tisch gekehrt, ist aber für die Rechtfertigung von bestimmten Vorgehensweisen essentiell.
Hallo
Ein wesentlicher Vorteil für den Endbenutzer ist, dass das Zwang für sichere Passwörter und deren regelmäßiges Ändern wegfällt.
Grüße
lcer
Ein wesentlicher Vorteil für den Endbenutzer ist, dass das Zwang für sichere Passwörter und deren regelmäßiges Ändern wegfällt.
Zitat von @DerWoWusste:
@rzlbrnft
Das entsprechende Stichwort heißt "PIV": https://developers.yubico.com/PIV/Guides/@rzlbrnft
...weil ich das mit dem kleineren blauen Yubikey nicht hinbekommen hab...
Der blaue Yubikey kann nicht für Zertifikatslogon benutzt werden. Brauchst einen teureren (45€, Yubikey 5 NfC), zum Beispiel.Grüße
lcer
Zitat von @DerWoWusste:
https://support.yubico.com/hc/en-us/articles/360013707820-YubiKey-Smart- ... sagt, dass es mit dem "Security key" nicht geht. https://support.yubico.com/hc/en-us/articles/360015654500-Setting-up-Win ... sagt, wie es geht.
Ich hatte das so gemeint: Man sollte sich vor der Anschaffung der Hardware über das Stichwort "PIV" informieren.https://support.yubico.com/hc/en-us/articles/360013707820-YubiKey-Smart- ... sagt, dass es mit dem "Security key" nicht geht. https://support.yubico.com/hc/en-us/articles/360015654500-Setting-up-Win ... sagt, wie es geht.
Grüße
lcer