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