Nov 19, 2020, updated at 15:34:16 (UTC)

4993

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).

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

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.

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?

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.

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.

Zitat von @DerWoWusste:

Moin.

Gegen-GPO...LOL
Nee, sowas braucht es nicht mehr.

Und das brauch es eben doch!
Das löschen einer GPO setzt die Einstellung nicht automatisch zurück.

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:

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.

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...

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.

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.

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.

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.

@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.

@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.

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.

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.

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.

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.

🖖

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.

German solved Question Microsoft Windows 10