28
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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 623881
Url: https://administrator.de/forum/windows-hello-optionen-ausgegraut-623881.html
Ausgedruckt am: 05.02.2025 um 18:02 Uhr
28 Kommentare
Neuester Kommentar
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
Hi.
Nee, das hat keinen Effekt.
Mir geht es um die rote Meldung. Die erscheint auch auf vielen anderen Seiten der modernen Systemsteuerung - ohne dass irgendwelche Policies Dinge einschränken.
---
Ich würde gerne meine Frage verallgemeinern, kann aber die Frage nicht mehr ändern. ohne einen Mod zu belämmern... sie soll so aussehen:
---
Kennt jemand das Verhalten, dass auch ohne konfigurierte GPOs sämtliche Systemsteuerungsoptionen 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.
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.
Nee, das hat keinen Effekt.
Mir geht es um die rote Meldung. Die erscheint auch auf vielen anderen Seiten der modernen Systemsteuerung - ohne dass irgendwelche Policies Dinge einschränken.
---
Ich würde gerne meine Frage verallgemeinern, kann aber die Frage nicht mehr ändern. ohne einen Mod zu belämmern... sie soll so aussehen:
---
Kennt jemand das Verhalten, dass auch ohne konfigurierte GPOs sämtliche Systemsteuerungsoptionen 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.
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.
Es waren also mal GPO vorhanden, die darauf gewirkt haben?
Hast du vorher auch eine entsprechende Gegen-GPO einwirken lassen, bevor du die GPO deaktiviert hast?
Hast du vorher auch eine entsprechende Gegen-GPO einwirken lassen, bevor du die GPO deaktiviert hast?
Moin.
Gegen-GPO...LOL
Nee, sowas braucht es nicht mehr. Lies mal nach, Was Registry-Tattooing ist und wann es wirkt. Das sind Relikte aus NT4-Zeiten.
Gegen-GPO...LOL
Nee, sowas braucht es nicht mehr. Lies mal nach, Was Registry-Tattooing ist und wann es wirkt. Das sind Relikte aus NT4-Zeiten.
Dieser PC wurde aus der Domäne genommen - Problem blieb bestehen.
Dieser PC wurde sodann mittels Inplace-Upgrade repariert - Problem verschwunden!
Da es hier alle PCs betrifft, ist dies keine brauchbare Lösung.
Dieser PC wurde sodann mittels Inplace-Upgrade repariert - Problem verschwunden!
Da es hier alle PCs betrifft, ist dies keine brauchbare Lösung.
Und das brauch es eben doch!
Das löschen einer GPO setzt die Einstellung nicht automatisch zurück.
1
Doch, wie ich schon geschrieben habe, das würde nur gelten für die ganz alten GPOs, die es schon unter NT4 gab.
https://sdmsoftware.com/wp-content/uploads/2020/02/Understanding-Group-P ...
besagt es:
https://sdmsoftware.com/wp-content/uploads/2020/02/Understanding-Group-P ...
besagt es:
Basically, how Group Policy prevents registry tattooing is fairly simple. Microsoft has allocated 4 registry keys–2 under HKEY_LOCAL_MACHINE and 2 under HKEY_CURRENT_USER which are considered “no-tattooing zones”. Any registry values placed under one of these 4 keys will be removed when the policy no longer applies. These 4 keys are:
HKEY_LOCAL_MACHINE\Software\Policies
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies
HKEY_CURRENT_USER\Software\Policies
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
Most of the Admin. Template policies that you get out-of-the-box in Windows fall under one of these 4 keys.
Und "Most" sind wirklich viele, nahezu 99% aller Policies, die Win10 kennt. Unsere fallen allesamt in diese Pfade.HKEY_LOCAL_MACHINE\Software\Policies
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies
HKEY_CURRENT_USER\Software\Policies
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
Most of the Admin. Template policies that you get out-of-the-box in Windows fall under one of these 4 keys.
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.
🖖
🖖
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.
Ok, Lösung gefunden.
Es war selbstgemachtes Registry-Tattooing:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\Settings\AllowSignInOptions
value (DWORD) war auf 1 gesetzt. 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 war selbstgemachtes Registry-Tattooing:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\Settings\AllowSignInOptions
value (DWORD) war auf 1 gesetzt. 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...
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.
Noch einer...
Also: wenn es "für einen gewissen Zeitraum an der Konnektivität hapert", dann kommt diese irgendwann wieder, oder? Und dann läuft der Gruppenrichtlinienclient und sieht, dass diese GPOs nicht mehr gelten und entfernt die Registrykeys.
Wenn Ihr meint, dass das nicht so ist, dann gebt bitte auch nur ein einziges nachvollziehbares Beispiel.
Also: wenn es "für einen gewissen Zeitraum an der Konnektivität hapert", dann kommt diese irgendwann wieder, oder? Und dann läuft der Gruppenrichtlinienclient und sieht, dass diese GPOs nicht mehr gelten und entfernt die Registrykeys.
Wenn Ihr meint, dass das nicht so ist, dann gebt bitte auch nur ein einziges nachvollziehbares Beispiel.
Wenn Ihr meint, dass das nicht so ist, dann gebt bitte auch nur ein einziges nachvollziehbares Beispiel.
Diese habe ich hin und wieder hier bei uns in der Firma 
Ja, dann nenn bitte eins.
u. a. Windows Hello und letztens erst mit Windows Updates automatisch Konfigurieren.
Gut, dann sag genau was du gesetzt hast.
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.
@Doskias: Das kannst Du doch selbst atomar nachprüfen. Geh in die Registry, schau, ob der Wert noch da ist. Ist er noch da, melde den User neu an - der Wert wird verschwinden.
@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.
@Doskias
Lock Taskbar verhält sich wie zu erwarten. Der Regkey wird bei der nächsten Anmeldung des Nutzers gelöscht, wenn man es wieder auf "nicht konfiguriert" setzt oder die Verlinkung der policy auf die OU des Testusers aufhebt.
Lock Taskbar verhält sich wie zu erwarten. Der Regkey wird bei der nächsten Anmeldung des Nutzers gelöscht, wenn man es wieder auf "nicht konfiguriert" setzt oder die Verlinkung der policy auf die OU des Testusers aufhebt.
Dann werde ich das nochmal testen. Habe wie gesagt am Montag den user aus der OU auf die die LOCK-TASKBAR wirkt geschoben, GPUPDATE /Force gemacht und anschließend den Rechner neu gestartet (und folglich neu angemeldet) und es war immer noch gesperrt.
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)
🖖
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.
"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.
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.
🖖
Was sind "normale" preferences?
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/
Hatte ich geschrieben. Es sind etwas weniger als 2% der ca. 4500 GPOs, die ein Registry-Tattooing durchführen, siehe Pfade im Reference Excelsheet https://www.microsoft.com/en-us/download/confirmation.aspx?id=102158
Ich möchte diese Diskussion nun verlassen.
Ich möchte diese Diskussion nun verlassen.
