Windows Hello - Optionen ausgegraut
Moin.
Kennt jemand das Verhalten, dass auch ohne konfigurierte GPOs sämtliche Windows-Hello-Optionen ausgegraut sind?
Es geht um eine Domänencomputer (Win10 20H2), dem früher Hello über GPOs verboten war - jetzt werden jedoch keine GPOs mehr angewendet, weder auf den Nutzer, noch auf den Computer.
Edit: Verallgemeinerung des Problems, siehe Beitrag weiter unten!
Auch in der Registry ist sicherheitshalber alles bereinigt worden unter HKCU\software\policies und HKLM\software\policies - dennoch alles grau und der rote Hinweis kommt ohne ersichtlichen Grund.
(dass die ersten 3 Optionen ausgegraut sind, ist ok - es geht hier um die Einrichtung eines Security Keys).
Kennt jemand das Verhalten, dass auch ohne konfigurierte GPOs sämtliche Windows-Hello-Optionen ausgegraut sind?
Es geht um eine Domänencomputer (Win10 20H2), dem früher Hello über GPOs verboten war - jetzt werden jedoch keine GPOs mehr angewendet, weder auf den Nutzer, noch auf den Computer.
Edit: Verallgemeinerung des Problems, siehe Beitrag weiter unten!
Auch in der Registry ist sicherheitshalber alles bereinigt worden unter HKCU\software\policies und HKLM\software\policies - dennoch alles grau und der rote Hinweis kommt ohne ersichtlichen Grund.
(dass die ersten 3 Optionen ausgegraut sind, ist ok - es geht hier um die Einrichtung eines Security Keys).
Please also mark the comments that contributed to the solution of the article
Content-ID: 623881
Url: https://administrator.de/forum/windows-hello-optionen-ausgegraut-623881.html
Printed on: January 26, 2025 at 06:01 o'clock
28 Comments
Latest comment
Hi DWW,
AFAIK musst du Windows Hello for Business aktivieren und einrichten.
Lokale Bereitstellung mit schlüsselbasiertem Vertrauensmodell
AFAIK musst du Windows Hello for Business aktivieren und einrichten.
Lokale Bereitstellung mit schlüsselbasiertem Vertrauensmodell
Und das brauch es eben doch!
Das löschen einer GPO setzt die Einstellung nicht automatisch zurück.
Ich muß mich da aber @tikayevent und @tech-flare anschließen, das sind auch meine Erfahrungen, kann funktionieren, muß aber nicht. Was MS gerne möchte und was dann funktioniert, sind ja bekanntlich zwei paar Schuhe. In meiner alten Firma hatten wir extra einen Domänencontroller, der keine GPO´s hatte um eben die Rechner definitiv auf ohne GPO´s zurückzusetzen. War etwas Aufwand, aber hielt sich noch in Grenzen, im Prinzip mußten nur zwei Netzwerkkabel getauscht werden und der entsprechende Rechner in die "non GPO Domäne" aufgenommen werden. Wenn man ihn dann wieder aus der Domäne genommen hat, war alles gut. Das war aber auch schon bei Win7 so.
🖖
🖖
Zitat von @DerWoWusste:
Bevor hier noch jemand einstimmt in diesen Mythos, bitte beachtet, dass ich etwas verlinkt habe. Schaut es euch an, testet es aus und ihr werdet sehen. Da es Policies gibt (wie gesagt, 1,x Prozent von allen sind noch NT4-style), die sich wie von Euch beschrieben verhalten, sollte schnell klar wrden, woher Eure Erfahrungen stammen.
Bevor hier noch jemand einstimmt in diesen Mythos, bitte beachtet, dass ich etwas verlinkt habe. Schaut es euch an, testet es aus und ihr werdet sehen. Da es Policies gibt (wie gesagt, 1,x Prozent von allen sind noch NT4-style), die sich wie von Euch beschrieben verhalten, sollte schnell klar wrden, woher Eure Erfahrungen stammen.
Das mag in bestimmten Fällen funktionieren, aber wenn entweder der DC oder der Rechner nichts davon weiß, das da noch was zurückgerollt werden muss, dann wirds auch nicht funktionieren, sprich wenn es für einen gewissen Zeitraum an der Konnektivität hapert. Das ist nicht NT4 Style, das passiert auf jeden Fall bis 2012 R2, aufgrund von realen Erfahrungen, bei 2016 kann ich es noch nicht sagen, das haben wir noch nicht so lang.
Meine Erfahrung sagt, wenn man will das eine Einstellung einen bestimmten Wert hat, sollte man sie konfigurieren.
Also hab ich in unserem Netzwerk die Hello Settings eben so gesetzt das sie bei allen aktiv sind.
Zitat von @DerWoWusste:
Bevor hier noch jemand einstimmt in diesen Mythos, bitte beachtet, dass ich etwas verlinkt habe. Schaut es euch an, testet es aus und ihr werdet sehen. Da es Policies gibt (wie gesagt, 1,x Prozent von allen sind noch NT4-style), die sich wie von Euch beschrieben verhalten, sollte schnell klar wrden, woher Eure Erfahrungen stammen.
Bevor hier noch jemand einstimmt in diesen Mythos, bitte beachtet, dass ich etwas verlinkt habe. Schaut es euch an, testet es aus und ihr werdet sehen. Da es Policies gibt (wie gesagt, 1,x Prozent von allen sind noch NT4-style), die sich wie von Euch beschrieben verhalten, sollte schnell klar wrden, woher Eure Erfahrungen stammen.
In dem von Dir verlinkten Artikel steht aber auch: "Registry values that are controlled by Group Policy but do not fall under one of these 4 keys are called Preferences(this is not the same as “GroupPolicy Preferences”, which came later and don’t necessarily relate to this). Preferences don’t benefit from the “no-tattooing zone” and thus if you set a preference within a GPO, and then remove that GPO, the preferences are not removed, just as in NT 4"
Will sagen, es kann zu "Rückständen" kommen, muß aber nicht. Und es hat auch nichts mit den Policies zu tun. Wir sind ganz gut damit gefahren, die Rechner aus der "Produktivdomäne" zu nehmen und dann in die "Resetdomäne" aufzunehmen. Hat zumindest das gemacht, was es sollte.
🖖
So jetzt muss ich mich da auch mal einmischen
ich bin bislang auch davon ausgegangen, dass GPOs nie automatisch zurückgestellt werden, aber auch ich habe mich neulich (letzte Woche) eines besseren belehren lassen. Folgendes Szenario habe ich getestet:
Eine Gruppenrichtlinie sperrt CD-Rom Laufwerke und USB-Drives. Schiebe ich einen Rechner aus dieser GPO heraus, so wird die Änderung Rückgängig gemacht und die Laufwerke funktionieren wieder.
Anders seiht es hingegen aus, bei einer Richtlinie, die im Userprofil das verschieben der Taskleiste verbietet. Wenn ich einen User aus der GPO nehme, dann kann die Taskleiste weiterhin nicht verschoben werden, auf neuen Rechnern allerdings schon. Hier ist dann eindeutig eine "Gegen-GPO" notwendig. Laut https://gpsearch.azurewebsites.net befindet sich "Lock Taskbar" unter HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer, fällt damit unter HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies. Damit sollte eigentlich keine Gegen-GPO erforderlich sein. Hat aber ohne gegen GPO (Stand Montag 16.11.2020) nicht funktioniert.
ich bin bislang auch davon ausgegangen, dass GPOs nie automatisch zurückgestellt werden, aber auch ich habe mich neulich (letzte Woche) eines besseren belehren lassen. Folgendes Szenario habe ich getestet:
Eine Gruppenrichtlinie sperrt CD-Rom Laufwerke und USB-Drives. Schiebe ich einen Rechner aus dieser GPO heraus, so wird die Änderung Rückgängig gemacht und die Laufwerke funktionieren wieder.
Anders seiht es hingegen aus, bei einer Richtlinie, die im Userprofil das verschieben der Taskleiste verbietet. Wenn ich einen User aus der GPO nehme, dann kann die Taskleiste weiterhin nicht verschoben werden, auf neuen Rechnern allerdings schon. Hier ist dann eindeutig eine "Gegen-GPO" notwendig. Laut https://gpsearch.azurewebsites.net befindet sich "Lock Taskbar" unter HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer, fällt damit unter HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies. Damit sollte eigentlich keine Gegen-GPO erforderlich sein. Hat aber ohne gegen GPO (Stand Montag 16.11.2020) nicht funktioniert.
Zitat von @DerWoWusste:
@Dr.Bit
Ich schrieb doch selbst haargenau das: es gibt Policies, die sich so Verhalten, wir Ihr beschreibt, ja, aber das sind nicht die modernen. Die, welche z.B. tech-flare nennt, fallen definitiv in diese 4 Registrybereiche und werden somit automatisch entfernt, wenn nicht länger angewendet.
@Dr.Bit
Ich schrieb doch selbst haargenau das: es gibt Policies, die sich so Verhalten, wir Ihr beschreibt, ja, aber das sind nicht die modernen. Die, welche z.B. tech-flare nennt, fallen definitiv in diese 4 Registrybereiche und werden somit automatisch entfernt, wenn nicht länger angewendet.
Das wollte ich auch gar nicht bestreiten. Ich sage nur, das durch die GPO auch Einträge ausgerollt werden, die man nur durch eine GegenGPO wieder entfernen kann. Die Prefences eben. Diese werden auch unter Server 2019 immer noch mit ausgerollt.
Wenn keine Prefences vorhanden sind, reicht es natürlich den Rechner einfach aus der Domäne zu nehmen. (Sollte es zumindest)
🖖
Zitat von @DerWoWusste:
Bitte lies doch mal, was ich schreibe.
"Normalerweise setzen wir bei Regkeys, die wir per group policy preferences verteilen, dass diese entfernt werden, wenn die Policy nicht länger Anwendung findet, aber in diesem Fall fehlte der Haken dafür..."
Es ist ohne Weiteres möglich, auch bei group policy preferences. Wenn man den vergisst, den Haken zu setzen, ist man selbst Schuld.
Bitte lies doch mal, was ich schreibe.
"Normalerweise setzen wir bei Regkeys, die wir per group policy preferences verteilen, dass diese entfernt werden, wenn die Policy nicht länger Anwendung findet, aber in diesem Fall fehlte der Haken dafür..."
Es ist ohne Weiteres möglich, auch bei group policy preferences. Wenn man den vergisst, den Haken zu setzen, ist man selbst Schuld.
Das habe ich schon verstanden. Ich beziehe mich aber auf die Prefences und NICHT die group policy prefences. Da gibt´s einen Unterschied. Es werden aber beide über die GPO verteilt. Die "normalen" Prefences werden dann aber eben nicht wieder zurückgesetzt, wenn man den Rechner aus der Domäne nimmt. Das geht dann eben am Einfachsten über eine GegenGPO oder sehr umständlich und langwierig von Hand.
🖖
Es gibt Prefences (NT4 Relikt), aber immer noch vorhanden und nicht zu den 4 Schlüsseln zugehörig, und group policy prefences, Diese gehören dann zu den 4 Schlüsseln. Die group policy prefences werden entfernt, wenn man den Rechner aus der Domäne nimmt, die prefences nicht.
Nun frag mich aber nicht, was alles zu wem gehört.
🖖
Nun frag mich aber nicht, was alles zu wem gehört.
🖖
Um Rauszufinden was nicht zu den 4 Schlüsseln gehört gibt es ja https://gpsearch.azurewebsites.net/