Voici donc le scoop:
J'ai écrit une infime C # tandis que le dos qui affiche le nom d'hôte, l'adresse IP, la date d'imagerie, l'état de la dégel (nous utilisons DeepFreeze), le domaine actuel et la date / heure actuelle, à afficher sur l'écran de bienvenue de nos fenêtres 7 machines de laboratoire. Il s'agissait de remplacer notre bloc d'informations précédent, qui a été défini de manière statique au démarrage et en réalité embarqué du texte en arrière-plan, avec quelque chose d'un peu plus dynamique et fonctionnel. L'application utilise une minuterie pour mettre à jour l'adresse IP, le statut de SpeepFree et l'horloge chaque seconde et vérifie si un utilisateur s'est connecté et se tue s'il détecte une telle condition.
Si nous venons de l'exécuter, via notre script de démarrage (défini via la stratégie de groupe), il contient le script ouvert et la machine ne le rend jamais à l'invite de connexion. Si nous utilisons quelque chose comme les commandes de démarrage ou de cmd pour la démarrer sous une coque / un processus séparé, il s'exécute jusqu'à la fin du script de démarrage, à laquelle les fenêtres de points semblent nettoyer tous les processus enfants du script. Nous sommes actuellement capables de contourner que l'utilisation de Nous avons expérimenté l'utilisation d'une autre application C # pour démarrer le processus, via la classe de processus, à l'aide d'appels WMI (Win32_Process et Win32_ProcessStartup) avec divers drapeaux de démarrage, etc., mais toutes les personnes finales de la finition du script et de l'information Processus de bloc à tuer. J'ai bricé de réécrire l'application en tant que service, mais les services n'ont jamais été conçus pour interagir avec le bureau, sans parler de la fenêtre de connexion et faire fonctionner les choses dans le bon contexte ne semblait jamais vraiment fonctionner.
Donc pour la question: Quelqu'un a-t-il un bon moyen d'accomplir cela? Lancez une tâche afin qu'elle soit indépendante du script de démarrage et exécutée en haut de l'écran de bienvenue? pSexec -s -d -x -x pour le déclencher, ce qui le permet de persister une fois le script de démarrage terminé, mais peut être incroyablement lent, ajoutant n'importe où entre 5 secondes et plus d'une minute à notre heure de démarrage.
4 Réponses :
Je pense que vous pouvez le faire, mais c'est assez impliqué. Les applications interactives ne sont normalement pas autorisées à exécuter sur l'écran de bienvenue. À un niveau élevé, vous devrez:
WTSGetactiveconsolesolesSolesSolesIsIude OpenInputDesktop )
J'ai écrit une application qui peut interagir quelque peu avec l'écran de connexion, mais cela ne montre aucune interface utilisateur. Cela peut probablement être fait, mais cela peut être encore plus impliqué.
Remarque: j'ai constaté que je n'ai pas pu obtenir les résultats de OpenInputDesktop à partir de mon service Windows. Je devais plutôt faire appel à l'appel dans l'autre processus et informer le service de redémarrer le processus sur le bon bureau.
J'espère que cela peut au moins vous aider à démarrer. Bonne chance!
Que Psexec peut le faire me dire qu'il est possible, c'est juste une question d'imitation de la façon dont il le lance je suppose. Je vais regarder dans ce que vous avez suggéré et voyez où cela me mène.
C'est l'une de ces "vous vraiment besoin d'une bonne raison de faire cela" questions. Microsoft essaie très difficile de bloquer les applications exécutées à l'écran de démarrage - chaque bit de code dans Windows qui interagit avec l'écran de connexion est très soigné le code examiné car les conséquences de sécurité d'un bogue dans le code exécuté à l'écran de connexion sont désire. Même légèrement, vous permettrez aux logiciels malveillants d'obtenir sur l'ordinateur.
Pourquoi voulez-vous exécuter votre programme à l'écran de connexion? Peut-être qu'il y a une façon documentée de le faire ce n'est pas aussi risqué.
Je comprends la paranoïa de Microsoft, mais c'est l'une de ces choses qui me fait détester les fenêtres beaucoup plus. Nous avons besoin d'informations sur l'écran pour diverses raisons, dont la plupart sont les nôtres. Le programme en question ne prend aucune entrée utilisateur, affiche simplement des informations. Les chances d'une application de 14k C # étant un risque de sécurité ne nous sont pas un problème, en particulier lorsque nous avons 50 000 utilisateurs potentiels par machine.
Les informations que vous souhaitez afficher peuvent-elles afficher dans une zone de message? Windows a un mécanisme pour afficher une chaîne de texte dans une boîte de message au moment de la connexion qui pourrait faire ce que vous voulez.
Retour à mon message d'origine, il s'agit de données sur la machine pour le personnel de support et des opérations, de sorte qu'ils ne doivent pas se connecter à une machine pour le regarder. Il est important que ce soit au-à-jour, toujours des informations disponibles. OSX fournit des informations similaires dans la fenêtre de connexion, qui nous sauve de devoir faire quelque chose de même compliqué là-bas.
Quel type d'informations ont-ils besoin que cela ne puisse être récupéré à distance via WMI? Windows a une quantité stupéfiante d'informations de gestion pouvant être lues à l'aide des API de l'OMM destinées au personnel de soutien et d'opérations. Y a-t-il des informations dont ils ont besoin qui n'est disponible que sur la console physique?
Vous savez, si vous n'allez pas m'aider à résoudre le problème, je vous ai demandé, je ne discute tout aussi vite pas sur la création de nouveaux problèmes.
D'où je suis assis, je am essaye de vous aider à résoudre le problème. Il n'y a pas de moyen fiable de faire ce que vous voulez sans introduire des menaces de sécurité potentielles pour le système. J'essaie donc de proposer un mécanisme alternatif qui vous permet de récupérer les informations dont vous avez besoin sans piratage autour des fonctionnalités de sécurité du système. A propos de chaque fois tous les 3 mois, une personne de Inside MSFT pose une question similaire sur notre alias interne "Windows Windows" et la réponse est toujours la même que celle que je donne - trouve une autre façon de faire ce que vous voulez parce que c'est plus sûr pour < Je> tous nos clients.
Et avant de répondre "Si vous continuez à obtenir ce type de demande, cela ne vous montre-t-il pas que vous devez faire cela sécurisé?", Il n'ya aucun moyen de résoudre ce problème - le code courant sur le bureau de connexion est vulnérable aux attaques de brison ( en.wikipedia.org/wiki/sharter_attack ), à moins que vous ne assuriez soigneusement que votre logique UI est à l'abri d'eux (ce qui signifie de longues critiques de code impliquées de tous les indicateurs d'interface utilisateur, y compris la base de code WPF que vous utilisez), il n'y a aucun moyen de vous assurer que votre application est totalement sûre. C'est invariablement préférable de trouver une autre manière.
Eh bien, encore une fois, j'apprécie la préoccupation, mais nous le faisons déjà, via Psexec, alors ne serait-ce pas assez évident que nous sommes tous deux au courant et que nous pouvions en faire moins de problèmes de sécurité? Et quelle partie de «50 000 utilisateurs» n'était pas claire? Ce ne sont pas des postes de travail NSA, ce sont des machines de laboratoire informatique sur un très grand campus universitaire. Votre problème de boîte de message Je suis au courant, cela nécessiterait chaque élève de vous connecter pour confirmer la case - qui est inacceptable. Notre personnel de soutien et de soutien entrent dans des chambres avec 20, 30, voire 100 machines, dont elle est importante sur l'écran de connexion.
Je suis très conscient des capacités de WMI et de son pouvoir à distance, mais cela ne nous fait aucun bien lorsque nous essayons de vérifier ou de corriger les problèmes avec une station physique. Si la SP était capable de certains prévoyait, ils auraient pu construire une certaine extensibilité à authui.dll, que ce soit en lui permettant de lire un fichier XML de configuration, similaire à celui interne à celui-ci, ou pire, via des clés de registre. Aucune aucune solution ne serait idéale pour notre état de gèle profond, votre adresse IP ou notre horloge, car toute info doit être rafraîchie régulièrement.
Voici le risque que vous exécutez: vous obtenez votre interface utilisateur sur le bureau et que certains étudiants intelligents déterminent comment exploiter votre UI. Ils sont maintenant 0wn votre bureau. Ils répètent pour chaque machine dans le laboratoire, ils sont maintenant 0wn votre laboratoire. Maintenant, un administrateur de domaine se connecte à la machine dans le laboratoire. Maintenant, votre intelligent étudiant 0wns votre domaine. Et une fois que l'étudiant intelligent 0wns votre domaine, c'est le jeu terminé. Il y a des solutions à cela: par exemple, je connais des universités (et des entreprises) qui réinitialisent chaque ordinateur de laboratoire tous les soirs. Mais ces remèdes ont tendance à être plutôt draconiennes.
Avoir simplement avoir des machines Windows sur le campus est un risque, comme vous le définissez. Il y a beaucoup plus de trous dans le système qu'ils peuvent exploiter, surtout si elles peuvent apparemment éventuellement exhausser à partir d'un processus en fonction d'un utilisateur local à quelque chose avec le domaine Privs. Mon point est que ce sont nos machines, c'est notre appel à faire. Nous effectuons des échanges de sécurité tous les jours pour garder nos machines fonctionnelles pour nous et nos utilisateurs finaux.
Et juste pour vous peindre une image pareeuse, les utilisateurs s'assoient sur nos machines, réinitialisent le boîtier, réinitialisent le BIOS, qui efface le mot de passe, ils peuvent alors démarrer de tout ce qu'ils veulent de modifier nos entraînements et de laisser Les machines bottent, contournant toute notre "sécurité". Ils installent un Keylogger et commencent à saisir des mots de passe. Nos scénarios de cauchemar ne tournent pas autour d'un étudiant en ennuyeux en essayant d'exploiter une petite fenêtre peu transparente stupide sur l'écran de connexion composé de rien que des étiquettes.
Lorsque les utilisateurs ont un accès physique aux machines, votre sécurité est déjà compromise. Cette application ne présente pas une menace de réseau significative pour nous, et c'est tout ce que nous nous soucions vraiment. Si ce que vous dites est en fait vrai, alors le fait qu'il n'existe aucun moyen de lancer un processus comme celui-ci, de manière sûre, parle vraiment des volumes sur les «améliorations» à la sécurité de Windows. Au lieu de le rendre meilleur, laissez simplement restreindre ce que les gens peuvent faire. Voici une idée de rendre les machines encore plus sécurisées: nous allons simplement les débrancher du réseau et emporter les claviers et les souris.
Ceci peut être fait à travers beaucoup d'appels d'API Win32. J'ai réussi à obtenir un programme avec une interface graphique sur le bureau Winlogon (avant que quiconque ne le demande, ce n'est pas une interactivité interactive). Fondamentalement, vous devez exécuter un processus de chargeur comme système, qui augmentera ensuite le nouveau processus. Étant donné que vous voulez probablement que ce processus fonctionne au démarrage, vous pouvez utiliser le planificateur de tâche pour exécuter le chargeur comme système ou utiliser un service pour faire la même chose. J'utilise actuellement un service, mais j'ai essayé d'utiliser le planificateur de tâches et il fonctionnait bien.
Résumé court:
code de code:
@Ffluxer Le processus de connexion de Windows XP est extrêmement différent de celui de Vista et supérieur. XP a utilisé Gina, mais de Vista vers le haut, Microsoft a réécrivé la section de connexion pour utiliser CredentialProviders. J'espère que cela t'aides.
Je reçois une erreur 1314 lorsque vous essayez d'exécuter CreateProcessasUser. Aucune suggestion? string lpappname = @ "D: \ smu \ \ ubiquitous informatique 7390 \ Projet final \ Locker \ Locker \ Bin \ Debug \ Locker.exe"; Si (! CreateProcessasuser (NewToken, LPAppname, NULL, REF TOKENATTRIBUTES, REF TRUITATTRIBUTS, VRAI, (UINT) CRISEPROCESSFLAGS.CREATTE_NEW_CONSOLE | (UINT) CreateProcessflags.inherit_caller_Priority, IntPtr.zero, Null, Réf Si, Out PI)))
J'ai traduit le code ci-dessus en C ++, si quelqu'un d'autre en a besoin ... Notez qu'il y a des références à des parties de mon code, mais cela peut aider quand même:
static bool StartProcess(LPCTSTR lpApplicationPath)
{
CAutoGeneralHandle hWinlogonProcess = FindWinlogonProcess();
if (hWinlogonProcess == INVALID_HANDLE_VALUE)
{
DU_OutputDebugStringff(L"ERROR: Can't find the 'winlogon' process");
return false;
}
CAutoGeneralHandle hUserToken;
if (!OpenProcessToken(hWinlogonProcess, TOKEN_QUERY|TOKEN_IMPERSONATE|TOKEN_DUPLICATE, &hUserToken))
{
DU_OutputDebugStringff(L"ERROR: OpenProcessToken returned false (error %u)", GetLastError());
return false;
}
// Create a new token
SECURITY_ATTRIBUTES tokenAttributes = {0};
tokenAttributes.nLength = sizeof tokenAttributes;
SECURITY_ATTRIBUTES threadAttributes = {0};
threadAttributes.nLength = sizeof threadAttributes;
// Duplicate the winlogon token to the new token
CAutoGeneralHandle hNewToken;
if (!DuplicateTokenEx(hUserToken, 0x10000000, &tokenAttributes,
SECURITY_IMPERSONATION_LEVEL::SecurityImpersonation,
TOKEN_TYPE::TokenImpersonation, &hNewToken))
{
DU_OutputDebugStringff(L"ERROR: DuplicateTokenEx returned false (error %u)", GetLastError());
return false;
}
TOKEN_PRIVILEGES tokPrivs = {0};
tokPrivs.PrivilegeCount = 1;
LUID seDebugNameValue = {0};
if (!LookupPrivilegeValue(nullptr, SE_DEBUG_NAME, &seDebugNameValue))
{
DU_OutputDebugStringff(L"ERROR: LookupPrivilegeValue returned false (error %u)", GetLastError());
return false;
}
tokPrivs.Privileges[0].Luid = seDebugNameValue;
tokPrivs.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
// Escalate the new token's privileges
if (!AdjustTokenPrivileges(hNewToken, false, &tokPrivs, 0, nullptr, nullptr))
{
DU_OutputDebugStringff(L"ERROR: AdjustTokenPrivileges returned false (error %u)", GetLastError());
return false;
}
PROCESS_INFORMATION pi = {0};
STARTUPINFO si = {0};
si.cb = sizeof si;
si.lpDesktop = L"Winsta0\\Winlogon";
// Start the process using the new token
if (!CreateProcessAsUser(hNewToken, lpApplicationPath, nullptr, &tokenAttributes, &threadAttributes,
true, CREATE_NEW_CONSOLE|INHERIT_CALLER_PRIORITY, nullptr, nullptr, &si, &pi))
{
DU_OutputDebugStringff(L"ERROR: CreateProcessAsUser returned false (error %u)", GetLastError());
return false;
}
return true;
}