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

12

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.

windows scripting login sccm embedded Wes Sayeed
la source
Grande question. J'aimerais avoir une meilleure réponse.
bonne question - j'espère que votre histoire de malheur décourage les autres d'acheter des clients légers - Je déteste tous les bagages que ces appareils «à faible entretien» apportent
Jim B

Réponses:

4

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 .

la source
Merci pour la réponse. J'ai mis à jour ma question pour refléter l'environnement. C'est une opération 24x7 donc l'option 1 n'est pas viable. L'option 2 était ce que je pensais, mais je ne sais pas comment attribuer / annuler l'attribution d'un GPO à la demande. Cela laisse les options 3 et 4 que j'examinerai. J'ai pensé que je devrais probablement écrire mon chemin pour en sortir. Oh et j'ai corrigé la terminologie :-)
Wes Sayeed
@WesSayeed En théorie, vous devriez être en mesure de créer des modèles de stratégie de groupe locale avec SecPol.msc, de les enregistrer en tant que modèles et de les appliquer / désappliquer secedit.exevia un script. Je ne parle pas d'utiliser la stratégie de groupe Active Directory car le temps d'interrogation aléatoire ne fonctionnera pas pour votre fenêtre de maintenance serrée.
+1, j'aime cette réponse et je n'étais pas au courant de PSCX.
MDMoore313
4

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.

MDMoore313
la source
1
+1 Je me suis toujours demandé s'il existait des utilisations réelles des séquences de tâches non OSD.
alx9r
@BigHomie; J'ai juste essayé de faire un déploiement en utilisant une séquence de tâches plutôt qu'une application normale et cela n'a pas empêché la connexion des utilisateurs. La première étape de la séquence de tâches consiste à redémarrer l'ordinateur. Une fois que l'ordinateur est de retour, il présente un écran de connexion normal. La séquence de tâches ne reprend pas avant environ une minute plus tard (car le service est défini sur démarrage différé). Je peux configurer le service pour qu'il démarre immédiatement avec la stratégie de groupe afin que l'utilisateur voit une barre de progression, mais cela ne ferait que décourager les ouvertures de session, pas les empêcher. Suis-je en train de manquer quelque chose?
Wes Sayeed
@WesSayeed !! Ce TS est-il annoncé à l'utilisateur ou à l'ordinateur?
MDMoore313
@BigHomie; AFAIK, les séquences de tâches ne peuvent être publiées que dans des collections d'ordinateurs.
Wes Sayeed
C'est vrai, j'ai oublié ça. Malheureusement, j'ai pris un nouvel emploi l'année dernière et je suis hors du jeu sccm depuis un bon moment. Je vais continuer à chercher la réponse, mais je pensais que le même mécanisme qui permettait au logiciel de s'installer pendant un OSD avant que l'écran de connexion n'apparaisse puisse être utilisé en dehors de l'OSD également. Je suppose que votre déploiement ne peut pas être fait si la machine démarre sur WinPE, n'est-ce pas?
MDMoore313
2

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.

Nathan C
la source
Le logiciel SSO utilise AD. Tout ce qu'il fait, c'est faire correspondre une étiquette RFID à un compte AD et transmettre les informations d'identification à Windows pour effectuer la connexion. J'ai mis à jour ma réponse pour expliquer pourquoi je ne peux pas utiliser les heures d'ouverture de session (j'ai négligé de mentionner l'environnement), mais je vais jeter un œil au script auquel vous avez fait référence. Je pourrais peut-être faire quelque chose comme ça localement.
Wes Sayeed
-1

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

Greg Askew
la source
Je dois -1 cela, cela fonctionnerait, mais si le script est tué au milieu, d'une erreur aléatoire ou de la loi de Murphy, alors l'utilisateur ne peut pas se connecter et ils sont morts dans l'eau jusqu'à ce que le service informatique puisse répondre.
MDMoore313