Comment verrouiller les utilisateurs normaux (non administrateurs) lors des installations de logiciels?

Nous avons beaucoup de clients légers exécutant Windows Embedded Standard 7 et un serveur SCCM 2012 R2 pour les gérer. Les clients légers ont leurs filtres d'écriture activés (FBWF) afin que les changements de machine ne soient pas persistants. À de rares occasions, nous devons mettre à jour quelque chose sur eux, nous le déployons simplement via SCCM et il se charge automatiquement de désactiver et de réactiver les filtres d'écriture pour valider les modifications.

Voici ce qui devrait arriver: le
client SCCM donne un avis à l'utilisateur et un compte à rebours de 30 minutes pour enregistrer son travail et quitter le système. Le client léger redémarre ensuite et désactive le filtre d'écriture. L'écran de connexion affiche un cadenas et remarque que l'unité est en cours de maintenance, et ne permettra pas aux utilisateurs normaux (non administrateurs) de se connecter pendant que SCCM fait son travail. Lorsque SCCM est terminé, il réactive le filtre d'écriture, redémarre, puis les utilisateurs peuvent se reconnecter.

Le problème que j'ai, c'est que nous utilisons des lecteurs de cartes de proximité pour nous connecter au système. Les employés ne tapent pas de mots de passe. Ils tapent juste leur badge. Ce système est agréable, mais le logiciel qui l'exécute rompt l'automatisation du filtre d'écriture avec Windows Embedded.

Voici ce qui se passe réellement : le
client SCCM donne le préavis habituel de 15 minutes avant de redémarrer avec le filtre d'écriture désactivé. Lorsqu'il redémarre, l' écran de connexion normal s'affiche. Les utilisateurs peuvent se connecter au système et l'utiliser pendant que SCCM installe le logiciel. Et comme une session utilisateur est active, elle donne à nouveau un préavis de 30 minutes avant de redémarrer avec le filtre d'écriture activé.

Dans ce scénario, non seulement cela ajoute 30 minutes supplémentaires au temps de déploiement, mais cela donne également aux utilisateurs ordinaires 30 à 60 minutes de temps non protégé sur les clients légers, quels que soient les changements qu'ils effectuent, ils sont définitivement intégrés dans l'image lorsque le le filtre d'écriture est réactivé.

Le problème provient du fait que Windows Embedded 7 utilise un fournisseur d'informations d'identification (aka GINA) différent de celui de Windows 7 normal, mais le produit SSO doit remplacer le fournisseur d'informations d'identification Windows pour fonctionner. J'ai contacté le fournisseur à ce sujet, mais ils disent simplement que c'est un problème connu et qu'il n'y a pas de solution ni de solution.

Voici donc ma question:
comment puis-je simuler le comportement souhaité d'une autre manière? Je sais qu'il existe un paramètre de stratégie de groupe dans lequel vous pouvez refuser l'ouverture de session locale à des groupes d'utilisateurs spécifiques. Je pensais pouvoir retourner le paramètre de registre correspondant avant et après l'installation, mais je suis ouvert à d'autres idées.

Je ne suis pas au-dessus des installations de script si je le dois. Je parle couramment les scripts, PowerShell, VBScript, etc. Je me demande simplement si quelqu'un a des idées brillantes sur la façon de résoudre ce problème.

Mise à jour:
J'ai négligé de mentionner que ces appareils sont utilisés dans un environnement hospitalier pour que le personnel puisse consulter leurs patients. Ils doivent être disponibles 24h / 24, nous ne pouvons donc pas limiter les heures d'ouverture de session ni configurer les fenêtres de maintenance. Nous gérons les temps d'arrêt en donnant un préavis aux superviseurs de quart, mais tout ce qui prend plus d'une heure devient un problème de conformité juridique et nécessite la mise en vigueur de procédures officielles d'arrêt.

Avant de commencer, je veux faire une remarque pédante, plus au profit du lectorat général que vous.

nous poussons simplement via SCCM

SCCM est une technologie basée sur l'extraction. Je sais ce que vous vouliez dire, mais je trouve qu'avec mes gars de niveau 1, chaque occasion que j'ai de souligner que SCCM n'est pas une technologie basée sur la poussée les aide à le comprendre plus rapidement.

J'ai contacté le vendeur à ce sujet, mais ils disent simplement que c'est un problème connu et qu'il n'y a pas de solution ou de solution pour le résoudre

C'est dommage car il semble que la cause de ce problème soit le programme d'authentification de la carte intégrée. Restez sur le fournisseur, peut-être qu'ils répareront leur logiciel.

Sur une vraie réponse - je vois quelques solutions possibles pour vous, aucune d'entre elles n'est particulièrement bonne.

• Configurez une fenêtre de maintenance pour ces clients afin que votre redémarrage initial pour supprimer les clients de leur filtre d'écriture, votre charge utile réelle et le redémarrage résultant se produisent en dehors des heures de bureau lorsque les employés ne sont pas présents sur les terminaux. Cela semble être l'option la moins douloureuse. Pas besoin de rendre SCCM plus compliqué qu'il ne l'est déjà.
• Créez un modèle de stratégie de groupe locale qui ajoute un groupe de sécurité au droit d'utilisateur Refuser la connexion, puis attribuez-le / annulez-le dans le cadre du déploiement de votre application.
• Utilisez PowerShell pour définir le droit d'utilisateur Refuser la connexion. Je crois que les extensions de communauté PowerShell (PSCX) ont les Set/Get-Privilegesapplets de commande qui vous permettront de manipuler les attributions de droits utilisateur
• Vous pouvez utiliser l'API si vous le souhaitez. Voici un exemple .

Il semble que personne n'ait abordé la possibilité d'utiliser une séquence de tâches pour gérer cela, alors permettez-moi d'énumérer les avantages (en supposant que vous ne les connaissez pas vraiment en général, mais veuillez lire même si vous l'êtes):

Si tout ce que vous installez et configurez est géré avec SCCM, vous devriez pouvoir utiliser une séquence de tâches pour y parvenir. Principalement pour OSD, l'utilisation d'un TS n'est pas seulement pour OSD et peut offrir les avantages suivants:

Pas de connexion au poste de travail

Un TS s'exécute avant l'exécution de winlogon.exe, il n'est donc pas possible qu'un utilisateur se connecte par inadvertance, car il n'y a pas de fenêtre de connexion. Ce qui m'amène à mon deuxième point:

Écran d'arrière-plan personnalisé

Vous pouvez fournir un écran de démarrage indiquant que la maintenance est en cours ou tout ce que vous voulez vraiment dire.

Un TS n'est vraiment qu'un script glorifié, mais il a beaucoup de fonctionnalités et est conçu de manière à réduire le temps de développement, et j'ai trouvé des cas d'utilisation au-delà de l'OSD.

Il semble que vous ayez déjà un script pour faire ce que vous devez faire, vous devriez donc être en mesure de le mettre dans un TS avec un débogage minimal et de commencer.

Vous n'avez pas spécifié si le logiciel SSO utilise les informations d'identification Active Directory, donc une solution serait d'utiliser la fonction "Heures d'ouverture de session" d'Active Directory. C'est au niveau de chaque utilisateur, mais peut facilement être scripté dans Powershell ( ceci étant un exemple). Fondamentalement, définissez les heures d'ouverture de session sur "refuser" l'ouverture de session dans votre fenêtre de mise à jour SCCM et les utilisateurs ne pourront pas se connecter aux clients pendant que SCCM fera son travail. Vous devrez avoir ce premier redémarrage forcé qui les déconnectera (la fonction des heures d'ouverture de session ne fonctionne pas sur les utilisateurs connectés), mais il serait autrement indolore à mettre en œuvre.

Peut vouloir tester cela et voir si cela fonctionne:

Un script au début de l'activité SCCM pour effectuer les opérations suivantes:

• Supprimer l'identité NT AUTHORITY \ Authenticated Users du groupe local d'utilisateurs
• Supprimer NT AUTHORITY \ Interactive identity du groupe local d'utilisateurs
• Supprimer le groupe d'utilisateurs de domaine du groupe d'utilisateurs local

À la fin:

Ajoutez les principaux de sécurité que vous avez supprimés dans le groupe d'utilisateurs local

Les groupes réels que vous ajoutez / supprimez peuvent dépendre de la configuration actuelle de vos ordinateurs.

Quelque chose d'un peu plus long, le début de l'activité SCCM pourrait copier un raccourci vers logoff.exe dans le dossier All Users Start Menu \ Startup (généralement C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Programs \ StartUp). Cela aurait pour effet de fermer une session dès qu'ils se connectent. Pour être sûr, vous voudrez peut-être avoir un script de démarrage / arrêt pour supprimer ce raccourci. (Je crois que les raccourcis de démarrage peuvent être contournés en maintenant la touche Maj enfoncée lors de la connexion).