Zum 23.08.2023 ist die NWC Services GmbH zur CANCOM GmbH geworden. Besuchen Sie uns gerne auf www.cancom.de
Toggle Bar

BLOG

BLOGGING CONSULTANTS

NWC Services Blog

Blogs von Consultants der NWC Services GmbH

Sperren der lokalen Anmeldung

Ein in der Enteo/DSM-Welt immer wieder kontrovers disktuiertes Thema ist, ob im Anschluss an eine Betriebssystem-Installation über OSD ein sogenannter "AutoAdminLogon" durchgeführt werden soll oder nicht.

Unter NetInstall 5.x und OSD 3.x wurde standardmäßig ein solche automatische Anmeldung vorgenommen und über einen RunOnce-Eintrag sowohl der NetInstall-Client installiert als auch der NetInstall Agent und damit implizit der AutoInstaller gestartet.

Wird Enteo v6 bzw. DSM 7 und damit auch OSD in der entsprechenden Version eingesetzt, so findet standardmäßig keine automatische Anmeldung mehr statt. Stattdessen steht nach der Betriebssystem-Installation der zu installierende Rechner im Login-Bildschirm während im Hintergrund zunächst über ein Post OS Action Package der NetInstall-Client installiert wird und anschließend der Service-Installer die Applikationspakete installiert (aus diesem Grund ist auch die Standard-Ausführungseinstellung für Pakete auf "Egal, ob ein Benutzer angemeldet ist, oder nicht" gesetzt).

Beide Verfahren haben ihre Vor- und Nachteile, die kurz dargestellt werden sollen (die Liste erhebt keinen Anspruch auf Vollständigkeit).
Für die Verwendung eines AutoAdminLogon spricht:

  • der Installationsfortschritt und -status ist im AutoInstaller-Fenster jederzeit sichtbar. Dies ist insbesondere von Vorteil, wenn die Installation am Arbeitsplatz des Anwenders erfolgt und dieser auf die Fertigstellung wartet
  • findet die (Re-)Installation am Arbeitsplatz des Andwenders statt und steht der Rechner während der Paketausführungsphase im Login-Screen, meldet sich eventuell ein – auf die Fertigstellung der Installation wartender  – Benutzer "zu früh" an und findet einen unfertigen Rechner vor. Dies führt zu Anfragen am Helpdesk und zur Verwirrung der Benutzer
  • wird – über das Deaktivieren von Maus und Tastatur – verhindert, dass sich ein Benutzer anmeldet, hat dieser keinerlei Informationation über den Fortschritt der Installation
  • Installationspakete, die einen lokalen Desktop benötigen, können erfolgreich ausgeführt werden
  • lokales Troubleshooting ist einfacher durchführbar, da direkter Zugang zu Dateisystem, Registry, der Computerverwaltung etc. besteht


Allerdings gibt es auch Gründe, die dagegen sprechen:

  • ist ein administratives Konto angemeldet, so kann ein am Rechner sitzender Benutzer kann jederzeit mit weitreichenden Berechtigungen Aktionen ausführen und sich beispielsweise "für später" einen eigenen lokalen Admin-Account anlegen
  • das Kennwort des lokalen Admin-Kontos ist im Klartext in der Registry hinterlegt, was eine Sicherheitslücke darstellt
  • das Sperren von Maus und Tastatur kann zu Problemen führen, wenn eine Paketausführung fehlschlägt und der Installationsprozess daher nicht erfolgreich zu Ende geführt wird


Die optimale Lösung besteht meiner Meinung nach darin, aus Sicherheitsaspekten den AutoAdminLogon nicht zu verwenden, jedoch die oben angesprochenen Vorteile soweit als möglich trotzdem zu implementieren. Das heißt, es soll einerseits die Möglichkeit des "zu frühen" Anmeldens unterbunden werden. Außerdem soll ein eventuell auf Fertigstellung wartender Anwender über den Fortschritt des Installationsvorgangs informiert und auf dem Laufenden gehalten werden.

Für die Umsetzung dieser Anforderungen stellt die NWC-Services das Freeware-Tool "BlockLogin" bereit, das Sie im Downloadbereich unserer Website herunterladen können. Dieses Tool ist als sogenannter "Credential Provider" umgesetzt und integriert sich in den Anmeldebildschirm von Windows. Credential Provider sind die Nachfolger der von früheren Windows-Versionen verwendeten "GINA" ("Graphical Identification and Authentication") und können daher nur unter Windows Vista, Windows 7 und Windows Server 2008 (inkl. R2) verwendet werden (für Windows XP, Windows Server 2003 und früher ist das Tool also NICHT anwendbar!).

BlockLogin_small

Die Funktionsweise besteht darin, dass BlockLogin andere Credential Provider (wie z.B. den Standard Credential Provider, bei dem Benutzername und Kennwort angegeben werden müssen, aber bei Bedarf auch z.B. Credential Provider für Smart-Cards oder Fingerabdruck-Sensoren) sperrt, sodass diese im Login-Bildschirm nicht angezeigt werden. Werden alle Credential Provider – außer dem BlockLogin Provider selbst – gesperrt, ist eine Anmeldung nicht möglich.

Der BlockLogin Provider kann über Registry-Einstellungen individuell konfiguriert werden, sodass – ohne Neustart – die Möglichkeit besteht, eine Anmeldung doch zu erlauben, um beispielsweise bestimmte Troubleshooting-Aktionen zu ermöglichen. Dabei kann zusätzlich unterschieden werden, ob keinerlei Anmeldung, nur eine lokale Anmeldung, nur eine Remote-Anmeldung (über eine RDP-Sitzung) oder beides möglich sein soll. Details können Sie der Registry-Referenz von BlockLogin entnehmen, die sich mit im Download-Paket befindet.

Um einen Benutzer über den Fortschritt der Installation zu informieren, können mehrere Elemente des Anmeldebildschirms angepasst werden:

  1. Das Bild, das in der "Anmeldekachel" dargestellt wird, ist frei anpassbar. Dort können Sie beispielsweise auf Ihr Firmenlogo verweisen oder auch auf das Programmicon des aktuell installierten Pakets referenzieren
  2. Sowohl der "große" als auch der "kleine" Text im Anmeldebildschirm können frei gewählt werden. Hier können Sie beispielsweise den Namen des aktuell ausgeführten Installationspakets und die voraussichtliche Installationsdauer anzeigen lassen
  3. Sie können sich einen Link (mit beliebiger Beschriftung) zu einem ausführbaren Programm anzeigen lassen, das ausgeführt wird, wenn ein Benutzer auf den Link klickt

Um den BlockLogin Credential Provider zu verwenden, muss dieser "installiert" werden. Kopieren Sie dazu die "NwcCredentialProvider.dll" (aus dem Download-Archiv) in das System32-Verzeichnis des Zielsystems. Anschließend muss der Provider registriert werden: dies erfolgt über die Registry, indem die folgenden Werte gesetzt werden:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{6945E482-393E-4989-BBC3-012291FCDD4E}]
@="NwcCredentialProvider"

[HKEY_CLASSES_ROOT\CLSID\{6945E482-393E-4989-BBC3-012291FCDD4E}]
@="NwcCredentialProvider"

[HKEY_CLASSES_ROOT\CLSID\{6945E482-393E-4989-BBC3-012291FCDD4E}\InprocServer32]
@="NwcCredentialProvider.dll"
"ThreadingModel"="Apartment"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters\{46804D1F-5E54-4edf-A5E4-9C6863D73F37}]
@="NwcCredentialProvider"

[HKEY_CLASSES_ROOT\CLSID\{46804D1F-5E54-4edf-A5E4-9C6863D73F37}]
@="NwcCredentialProvider"

[HKEY_CLASSES_ROOT\CLSID\{46804D1F-5E54-4edf-A5E4-9C6863D73F37}\InprocServer32]
@="NwcCredentialProvider.dll"
"ThreadingModel"="Apartment"

Sämtliche Einstellungen des BlockLogin Credential Providers werden im Schlüssel [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{6945E482-393E-4989-BBC3-012291FCDD4E}\Settings] der Registry konfiguriert.

Zunächst muss der Credential Provider aktiviert werden. Dazu muss in diesem Schlüssel der DWORD-Value IsEnabled auf 1 gesetzt werden. Die Aktivierung benötigt einen Reboot, sodass es sinnvoll ist, diesen Wert direkt bei der Installation von BlockLogin zu setzen – im Optimalfall integrieren Sie die Installation und Grundkonfiguration schon direkt in Ihr OS Configuration Package.

Um festzulegen, welche anderen Credential Provider blockiert werden sollen, muss in oben genanntem Schlüssel ein REG_MULTI_SZ-Value namens BlockProviders angelegt werden. In diesem werden die GUIDs der zu blockierenden Credential Provider angegeben (eine GUID pro Zeile). Die GUIDs entsprechen den Schlüsselnamen unterhalb von [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers] und müssen inklusive der geschweiften Klammern eingetragen werden. Es wird empfohlen, hier alle auf einem Referenzsystem vorhandenen GUIDs – bis auf die des BlockLogin Credential Providers selbst – einzutragen.

Um den Anwender über den Fortschritt der Installation zu unterrichten, kann ein NetInstall-Script verwendet werden, das allen Clients als Job-Policy, die bei jedem Start eines Pakets ausgeführt wird, verwendet werden. In diesem Script werden dann die Registry-Werte LargeTextMessage und SmallTextMessage im Settings-Schlüssel gesetzt. Es bietet sich hier an, über den RegModify-Befehl etwas wie "Installation von %Project.Name%" als LargeTextMessage und "Dieser Vorgang kann einige Minuten dauern..." als SmallTextMessage einzutragen.

Über ein abschließendes Script am Ende des Installationsprozesses – vergleichbar dem aus OSD 3.x bekannten "EndInstallationProcess" – können Sie den BlockLogin Credential Provider deaktivieren. Dazu genügt es, den Wert IsEnabled auf 0 zu setzen und das System neu zu starten. Eine Deinstallation ist nicht erforderlich. Es kann sogar durchaus von Vorteil sein, wenn die Sperre der Anmeldung jederzeit wieder aktiviert werden kann, beispielsweise wenn Sie zukünftig ein großes Paket, wie z.B. ein Betriebssystem-Servicepack, verteilen möchten und für die Installationsdauer dieses Pakets die Anmeldung verhindern möchten. Dann genügt es, BlockLogin wieder zu aktivieren und einen Neustart durchzuführen. Nach der Installation (über den Service-Installer) kann dann BlockLogin einfach wieder deaktiviert werden und die Anwender können – nach dem erforderlichen Neustart – normal weiterarbeiten.

Noch ein abschließender Hinweis: bei der Verwendung des Credential Providers auf 64-Bit Betriebssystemen, müssen die (De-)Aktivierung und Konfiguration natürlich auch im 64-Bit Bereich der Registry vorgenommen werden. Werden die entsprechenden Werte also über NetInstall-Scripte gesetzt, muss unbedingt der Haken bei "64 Bit Zweig auf x64 Computer verwenden" aktiviert sein...

×
Stay Informed

When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.

Hotfix-Bundle 1 für DSM 7 verfügbar
Das neue Install-Verzeichnis in DSM 7
 

Kommentare 11

Andreas Bischof (webseite) am Donnerstag, 20. Februar 2014 16:11

Hallo Herr Scholer,

ich habe mich gerade hier angemeldet und Ihr Blocklogin getestet - ein wunderbares Tool, vielen Dank dafür!
Eine Frage: Funktioniert das auch unter Windows 8?

viele Grüße aus Bayern,
Andreas Bischof

Hallo Herr Scholer, ich habe mich gerade hier angemeldet und Ihr Blocklogin getestet - ein wunderbares Tool, vielen Dank dafür! Eine Frage: Funktioniert das auch unter Windows 8? viele Grüße aus Bayern, Andreas Bischof
Frank Scholer (webseite) am Donnerstag, 20. Februar 2014 16:17

Hallo Herr Bischof,

ja, BlockLogin funktioniert auch unter Windows 8.x. Lediglich die Werte, die im BlockProviders Reg-Value eingetragen werden müssen, unterscheiden sich von Windows 7...

Viel Spaß und Erfolg weiterhin damit und beste Grüße
Frank Scholer

Hallo Herr Bischof, ja, BlockLogin funktioniert auch unter Windows 8.x. Lediglich die Werte, die im BlockProviders Reg-Value eingetragen werden müssen, unterscheiden sich von Windows 7... Viel Spaß und Erfolg weiterhin damit und beste Grüße Frank Scholer
Edmund Fink (webseite) am Freitag, 02. Mai 2014 17:02

Hallo Herr Scholer,

ich habe laut Ihrer oben beschriebenen detailierten Anleitung die Umsetzung an einem Rechner mit Win 7 (32-Bit) gemacht, allerdings bekomme ich folgende Fehlermeldung, die ich nicht wegbekomme.

LogonUI.exe - Ungültiges Bild

c:\Windows\system32\NwcCredentialProvider.dll ist entweder nicht für die Ausführung unter Windows vorgesehen oder enthält einen Fehler. Installieren Sie .....


Das Fenster kann man wegklicken und bekommt die Standardanmeldung.

Die Einträge habe ich überprüft und sollten soweit stimmen. Kennen Sie den Fehler?

Viele Grüße aus Freiburg
Edmund Fink

Hallo Herr Scholer, ich habe laut Ihrer oben beschriebenen detailierten Anleitung die Umsetzung an einem Rechner mit Win 7 (32-Bit) gemacht, allerdings bekomme ich folgende Fehlermeldung, die ich nicht wegbekomme. LogonUI.exe - Ungültiges Bild [b] c:\Windows\system32\NwcCredentialProvider.dll ist entweder nicht für die Ausführung unter Windows vorgesehen oder enthält einen Fehler. Installieren Sie .....[/b] Das Fenster kann man wegklicken und bekommt die Standardanmeldung. Die Einträge habe ich überprüft und sollten soweit stimmen. Kennen Sie den Fehler? Viele Grüße aus Freiburg Edmund Fink
Frank Scholer (webseite) am Freitag, 02. Mai 2014 18:20

Hallo Herr Fink,

wie ich gesehen habe, haben Sie sich die 64-Bit Version des Credential Providers heruntergeladen - das kann dann nicht funktionieren. Mit der richtigen Version wird es sicher funktionieren...

Beste Grüße
Frank Scholer

Hallo Herr Fink, wie ich gesehen habe, haben Sie sich die 64-Bit Version des Credential Providers heruntergeladen - das kann dann nicht funktionieren. Mit der richtigen Version wird es sicher funktionieren... Beste Grüße Frank Scholer
Edmund Fink (webseite) am Montag, 05. Mai 2014 10:04

Hallo Herr Scholer,

danke, das war's.
Manchmal sind's die simplen Dinge, die einen bewegen.

Viele Grüße
Edmund Fink

Hallo Herr Scholer, danke, das war's. Manchmal sind's die simplen Dinge, die einen bewegen. Viele Grüße Edmund Fink
Manuel Walz (webseite) am Freitag, 30. Januar 2015 11:48

Hallo Herr Scholer,

gibt es denn eine Beschreibung, welche Werte unter Windows 8.x in der Registry eingetragen werden müssen?

Beste Grüße

Hallo Herr Scholer, gibt es denn eine Beschreibung, welche Werte unter Windows 8.x in der Registry eingetragen werden müssen? Beste Grüße
Frank Scholer (webseite) am Freitag, 30. Januar 2015 11:59

Hallo Herr Walz,

wie im Artikel beschrieben: die GUIDs unterhalb von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers (außer dem BlockLogin Credential Provider selbst).

Am einfachsten Sie legen den REG_MULTI_SZ Value "BlockProviders" manuell an und fügen dann die GUIDs von Hand (inkl. der geschweiften Klammern) hinzu, eine GUID pro Zeile. Den können Sie dann in eine Reg-Datei exportieren...

Ich hoffe, das hilft Ihnen weiter.

Hallo Herr Walz, wie im Artikel beschrieben: die GUIDs unterhalb von HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers (außer dem BlockLogin Credential Provider selbst). Am einfachsten Sie legen den REG_MULTI_SZ Value "BlockProviders" manuell an und fügen dann die GUIDs von Hand (inkl. der geschweiften Klammern) hinzu, eine GUID pro Zeile. Den können Sie dann in eine Reg-Datei exportieren... Ich hoffe, das hilft Ihnen weiter.
Rafael Bungert (webseite) am Montag, 08. Juni 2015 14:12

Hallo Herr Scholer,
gibt es auch eine Möglichkeit den Knopf zum herunterfahren des Systems durch den User auszublenden?

Viele Grüße!
Rafael Bungert

Hallo Herr Scholer, gibt es auch eine Möglichkeit den Knopf zum herunterfahren des Systems durch den User auszublenden? Viele Grüße! Rafael Bungert
Frank Scholer (webseite) am Montag, 08. Juni 2015 14:25

Hallo Herr Bungert,

ja, das müsste gehen - ist eine ganz normale Windows-Funktionalität. Googeln Sie mal nach "ShutdownWithoutLogon". Das ist ein Registry-Value, den Sie setzen können und über den wird festgelegt, ob im Anmeldebildschirm der Shutdown-Button angezeigt wird (wie er das z.B. bei den Serverversionen nicht wird).

Ich hoffe, das beantwortet Ihre Frage.
Viele Grüße, Frank Scholer

Hallo Herr Bungert, ja, das müsste gehen - ist eine ganz normale Windows-Funktionalität. Googeln Sie mal nach "ShutdownWithoutLogon". Das ist ein Registry-Value, den Sie setzen können und über den wird festgelegt, ob im Anmeldebildschirm der Shutdown-Button angezeigt wird (wie er das z.B. bei den Serverversionen nicht wird). Ich hoffe, das beantwortet Ihre Frage. Viele Grüße, Frank Scholer
Gäste - Christian Windorfer am Mittwoch, 16. Oktober 2019 08:24

Hallo Herr Scholer,

das Sperren der Anmeldung funktioniert gemäß Ihrem Blog unter Windows 10 sehr gut. Im Moment haben wir die Installation in der unattend.xml im ConigurationPackage realisiert. Jedoch wird über diese Methode der CredentialManager dann immer installiert. Gibt es auch eine Möglichkeit die Installation über eine Art 'Schalter' zu steuern (an/aus). Sie schreiben ja "im Optimalfall integrieren Sie die Installation und Grundkonfiguration schon direkt in Ihr OS Configuration Package."

Für einen Tipp wäre ich sehr dankbar!

Viele Grüße
Christian Windorfer

Hallo Herr Scholer, das Sperren der Anmeldung funktioniert gemäß Ihrem Blog unter Windows 10 sehr gut. Im Moment haben wir die Installation in der unattend.xml im ConigurationPackage realisiert. Jedoch wird über diese Methode der CredentialManager dann immer installiert. Gibt es auch eine Möglichkeit die Installation über eine Art 'Schalter' zu steuern (an/aus). Sie schreiben ja "im Optimalfall integrieren Sie die Installation und Grundkonfiguration schon direkt in Ihr OS Configuration Package." Für einen Tipp wäre ich sehr dankbar! Viele Grüße Christian Windorfer
Frank Scholer am Mittwoch, 16. Oktober 2019 09:07

Hallo Herr Windorfer,

die einfachste Möglichkeit wäre, über einen Installationsparameter des OS Config Packages zu steuern, ob der Credential Provider aktiv ist (Reg-Value "IsEnabled" auf 0 oder 1). So wird er zwar in jedem Fall installiert, aber das "frisst ja kein Brot" und Sie haben Ihn auf den Systemen drauf, wenn Sie ihn brauchen. Solange das nicht der Fall ist, sollte sich das System komplett so verhalten, als wäre er gar nicht da...

Wenn Sie wirklich steuern wollen, ob der installiert wird oder nicht, können Sie das im Script des OS Config Packages machen, indem Sie wieder über einen Installationsparameter steuern, ob die Installation übersprungen wird (also die Logik hinter den Aufruf des Windows-Setups packen) oder eben nicht.

Schließlich würde mir noch einfallen, dass Sie die Installation des Credential Providers auch in ein Post OS Action Package auslagern könnten und dann entweder mit unterschiedlichen OS Sets arbeiten oder eben auch wieder über Installationsparameter im Post OS Action Package steuern, ob die Einrichtung erfolgt oder nicht.

Ich hoffe, diese Ideen helfen Ihnen weiter.

Grüße
Frank Scholer

Hallo Herr Windorfer, die einfachste Möglichkeit wäre, über einen Installationsparameter des OS Config Packages zu steuern, ob der Credential Provider aktiv ist (Reg-Value "IsEnabled" auf 0 oder 1). So wird er zwar in jedem Fall installiert, aber das "frisst ja kein Brot" und Sie haben Ihn auf den Systemen drauf, wenn Sie ihn brauchen. Solange das nicht der Fall ist, sollte sich das System komplett so verhalten, als wäre er gar nicht da... Wenn Sie wirklich steuern wollen, ob der installiert wird oder nicht, können Sie das im Script des OS Config Packages machen, indem Sie wieder über einen Installationsparameter steuern, ob die Installation übersprungen wird (also die Logik hinter den Aufruf des Windows-Setups packen) oder eben nicht. Schließlich würde mir noch einfallen, dass Sie die Installation des Credential Providers auch in ein Post OS Action Package auslagern könnten und dann entweder mit unterschiedlichen OS Sets arbeiten oder eben auch wieder über Installationsparameter im Post OS Action Package steuern, ob die Einrichtung erfolgt oder nicht. Ich hoffe, diese Ideen helfen Ihnen weiter. Grüße Frank Scholer
Bereits registriert? Hier einloggen
Freitag, 29. März 2024

Sicherheitscode (Captcha)