7
Kombinieren von Credentialprovidern - Fallstricke
Moin allerseits!
Folgende Info kann interessant sein für Admins, die anfangen mit Credentialprovidern zu arbeiten.
Es gibt nämlich hierbei aus meiner Sicht einen sicherheitskritischen Effekt, der (für mich) nicht intuitiv ist.
Konkret: installiert man zum Beispiel auf einem Windows-PC den Yubico-Logon (2FA), so macht dieser folgendes:
Er verbietet für jene Konten, auf denen er aktiviert ist, das Anmelden mit Passwort, wenn der Yubikey nicht gesteckt ist.
Das bedeutet: er installiert einen eigenen Credentialprovider, an der Anmeldemaske erkennbar am Yubicosymbol, der zwar aussieht, wie der herkömmliche Passwortprovider (2-zeilig mit Nutzername und Kennwort), aber dennoch seinen eigenen Prüfmechanismus fährt ("steckt der Yubikey und enthält er das Secret, welches dem Nutzer in der Anmeldezeile zugeordnet ist?"). Sprich: der eigentliche Kennwortprovider ist weg, er wird technisch mittels eines Credentialproviderfiltereintrags ausgeblendet.
Soweit, so gut. In meinen Tests installierte ich weitere Credentialprovider parallel, hier betrachtet: Rohos Logon Key.
Dieser erlaubt, dass man sich alternativ mit Kennwort oder per Einstecken eines präparierten USB-Sticks anmeldet.
Nun zum interessanten Teil: Das aus meiner Sicht erwartete Verhalten in dieser Kombination wäre, dass die Restriktion "Verbiete Kennwortlogon es sei denn der richtige Yubikey steckt" weiterhin gilt. Tut Sie aber nicht!
Klickt man den Rohos-Button am Anmeldescreen an, kann man wieder mit Kennwort alleine rein.
Sprich: das OS wertet jeden Provider für sich aus und wendet keine Restriktionen des einen Providers auch global an.
Folgende Info kann interessant sein für Admins, die anfangen mit Credentialprovidern zu arbeiten.
Es gibt nämlich hierbei aus meiner Sicht einen sicherheitskritischen Effekt, der (für mich) nicht intuitiv ist.
Konkret: installiert man zum Beispiel auf einem Windows-PC den Yubico-Logon (2FA), so macht dieser folgendes:
Er verbietet für jene Konten, auf denen er aktiviert ist, das Anmelden mit Passwort, wenn der Yubikey nicht gesteckt ist.
Das bedeutet: er installiert einen eigenen Credentialprovider, an der Anmeldemaske erkennbar am Yubicosymbol, der zwar aussieht, wie der herkömmliche Passwortprovider (2-zeilig mit Nutzername und Kennwort), aber dennoch seinen eigenen Prüfmechanismus fährt ("steckt der Yubikey und enthält er das Secret, welches dem Nutzer in der Anmeldezeile zugeordnet ist?"). Sprich: der eigentliche Kennwortprovider ist weg, er wird technisch mittels eines Credentialproviderfiltereintrags ausgeblendet.
Soweit, so gut. In meinen Tests installierte ich weitere Credentialprovider parallel, hier betrachtet: Rohos Logon Key.
Dieser erlaubt, dass man sich alternativ mit Kennwort oder per Einstecken eines präparierten USB-Sticks anmeldet.
Nun zum interessanten Teil: Das aus meiner Sicht erwartete Verhalten in dieser Kombination wäre, dass die Restriktion "Verbiete Kennwortlogon es sei denn der richtige Yubikey steckt" weiterhin gilt. Tut Sie aber nicht!
Klickt man den Rohos-Button am Anmeldescreen an, kann man wieder mit Kennwort alleine rein.
Sprich: das OS wertet jeden Provider für sich aus und wendet keine Restriktionen des einen Providers auch global an.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 63366624204
Url: https://administrator.de/contentid/63366624204
Printed on: April 27, 2024 at 12:04 o'clock
7 Comments
Latest comment
Wenn ich ganz ehrlich bin, überrascht mich Deine Feststellung nicht, und ich halte sie sogar für naheliegend, wenn nicht sogar für zwingend.
Zunächst einmal folgendes bildhafte Gleichnis: Eine ummauerte Stadt hat mehrere Stadttore. Die eine Tormannschaft ist äußerst streng (= Yubico-Logon), während eine andere (= Rohos Logon Key) deutlich nachsichtiger ist. Wenn es also bei dem einen Stadttor nicht klappt, dann versuche ich es eben bei dem anderen, wo es leichter fällt ...
Wie bei diesem Gleichnis die "Stadttore" stehen die Credentialprovider doch jeder für sich. Jeder dieser Provider hat sein eigenes Regime. Etwas anderes könnte doch nur gelten, wenn die Anmeldevorgänge der verschiedenen Provider von ihren Zulässigkeitsregeln her UND-verknüpft wären. Nur dann würde sich immer der strengste Provider durchsetzen - die anderen wären quasi obsolet. Doch das ist nicht das Anliegen der autonom agierenden Provider. Mithin verbleibt es bei einer ODER-Verknüpfung und das niedrigste Schutzniveau bestimmt das Sicherheitsniveau.
Du hast natürlich völlig Recht, diese objektive Gegebenheit muss man sich verdeutlichen!
Viele Grüße
HansDampf06
Zunächst einmal folgendes bildhafte Gleichnis: Eine ummauerte Stadt hat mehrere Stadttore. Die eine Tormannschaft ist äußerst streng (= Yubico-Logon), während eine andere (= Rohos Logon Key) deutlich nachsichtiger ist. Wenn es also bei dem einen Stadttor nicht klappt, dann versuche ich es eben bei dem anderen, wo es leichter fällt ...
Wie bei diesem Gleichnis die "Stadttore" stehen die Credentialprovider doch jeder für sich. Jeder dieser Provider hat sein eigenes Regime. Etwas anderes könnte doch nur gelten, wenn die Anmeldevorgänge der verschiedenen Provider von ihren Zulässigkeitsregeln her UND-verknüpft wären. Nur dann würde sich immer der strengste Provider durchsetzen - die anderen wären quasi obsolet. Doch das ist nicht das Anliegen der autonom agierenden Provider. Mithin verbleibt es bei einer ODER-Verknüpfung und das niedrigste Schutzniveau bestimmt das Sicherheitsniveau.
Du hast natürlich völlig Recht, diese objektive Gegebenheit muss man sich verdeutlichen!
Viele Grüße
HansDampf06
1
Ja, das stimmt. Nur sagt einem niemand vorher, dass dieses Modell stimmt.
Irgendwo im Technet versteckt mag man das finden, aber klar herausgestellt ist es nicht.
Irgendwo im Technet versteckt mag man das finden, aber klar herausgestellt ist es nicht.
Zitat von @DerWoWusste:
Ja, das stimmt. Nur sagt einem niemand vorher, dass dieses Modell stimmt.
Irgendwo im Technet versteckt mag man das finden, aber klar herausgestellt ist es nicht.
Das ist, glaube ich, insgesamt das Problem der immer komplexer werdenden Technologie(n): Es ist für den einzelnen schon fast nicht mehr greifbar, um damit angemessen umgehen zu können. Und das Spiegelbild für uns Anwender ist das weite Feld der unzulänglichen Software. Denn auch die Entwickler sind ebenfalls in einem Bereich angekommen, wo die menschliche Fassbarkeit mittlerweile überdehnt wird ...Ja, das stimmt. Nur sagt einem niemand vorher, dass dieses Modell stimmt.
Irgendwo im Technet versteckt mag man das finden, aber klar herausgestellt ist es nicht.
Viele Grüße
HansDampf06
Stimme voll zu. "Keep it simple" wäre toll, aber wir entfernen uns weiter und weiter davon.
Hallo,
Du kannst die "schwächeren" Credential Provider per GPO deaktivieren, somit werden diese nicht mehr genutzt!
"Sinnvoll" liegt immer im Auge des Betrachters. Es kann durchaus sinnvoll sein mehrere Credential Provider parallel anzubieten. Liegt immer am geforderten Einsatzzweck!
Du kannst die "schwächeren" Credential Provider per GPO deaktivieren, somit werden diese nicht mehr genutzt!
"Sinnvoll" liegt immer im Auge des Betrachters. Es kann durchaus sinnvoll sein mehrere Credential Provider parallel anzubieten. Liegt immer am geforderten Einsatzzweck!
Moin @Toeffel
Du kannst die "schwächeren" Credential Provider per GPO deaktivieren, somit werden diese nicht mehr genutzt!
Ja, ist bekannt.
Moin,
wie HansDampf06 schon meinte ist dies Verhalten korrekt, aber es enthält einen groben Fehler seitens Microsoft.
Die Verfahren müssen unabhängig sein.
Verfahren A kann nicht beurteilen ob Verfahren B sicherer oder unsicherer ist.
Aber jedes Verfahren sollte global bestimmte Anmeldetypen deaktivieren können.
Der Yubikey macht sein Dinge und sagt dem OS "Niemand darf sich mit Kennwort anmelden". Das kann Verfahren B, auch wenn es schlampig programiert ist, nicht aushebeln dürfen/können.
Aber wenn Rohos sich anmelden möchte mit seinem Verfahren, darf Yubikey das nicht verhindern. Er weiß ja gar nicht warum und wieso. Wenn Rohos also eine eigene Kennwortmaske programmiert funktioniert die trotzdem. Aber nicht die Standard-Systemmaske.
Das klingt alles nach der alten Hackingmethode von Windows Server 2000 wo man über die Hilfe bei der Anmeldung ein Admin-CMD-Fenster öffnen konnte.
Stefan
wie HansDampf06 schon meinte ist dies Verhalten korrekt, aber es enthält einen groben Fehler seitens Microsoft.
Die Verfahren müssen unabhängig sein.
Verfahren A kann nicht beurteilen ob Verfahren B sicherer oder unsicherer ist.
Aber jedes Verfahren sollte global bestimmte Anmeldetypen deaktivieren können.
Der Yubikey macht sein Dinge und sagt dem OS "Niemand darf sich mit Kennwort anmelden". Das kann Verfahren B, auch wenn es schlampig programiert ist, nicht aushebeln dürfen/können.
Aber wenn Rohos sich anmelden möchte mit seinem Verfahren, darf Yubikey das nicht verhindern. Er weiß ja gar nicht warum und wieso. Wenn Rohos also eine eigene Kennwortmaske programmiert funktioniert die trotzdem. Aber nicht die Standard-Systemmaske.
Das klingt alles nach der alten Hackingmethode von Windows Server 2000 wo man über die Hilfe bei der Anmeldung ein Admin-CMD-Fenster öffnen konnte.
Stefan