PKI ? Token ? Gina.dll ? Quelle methode utiliser pour de l'authentification Physique ?
44 réponses
Imochon
Bonjour a tous,
Je me renseigne actuellement sur une methode d'authentification permettant
de rendre accessible un pc uniquement si un clé USB est connecté avec un
fichier dauthentification dessus.
Il y a des déjà des offres comme celle de Placoot par exemple qui correspond
parfaitement a ce que je souhaite :
http://fr.palcott.com/products/naturallogin/screenshots.php
par contre je me dis que l'on peut peut-etre créer soit mm une telle
solution avec des bases de de développement et un cle usb ;)
J'ai effectué qq recherches mais rien de bien top mis a part le fait que
tout part de la gina.dll pour l'ouverture de sessiosn. par apres je ne sais
comment faire ..
prévoyer simplement une machine multi-OS pour ne pas passer plus de temps à réinstaller un système bloqué qu'à developper.
Pas besoin. En cas de pb : reboot en mode sans echec sans reseau et suppression de la cle declarant la Gina dans la BDR.
ah ouais ? on peut démarrer en mode DOS aussi ???
on est en 2005 et je ne parlais pas de ton w98 - j'ai même indiqué que cet OS nécessitait une approche propriétaire car son boot est merdique (non sécurisé).
W2k, XP et 2003Svr utilisent winlogon qui utilisera la Gina déclarée, si elle est (trop) buggée le système est mort.
Sylvain.
Thierry wrote on 10/08/2005 17:13:
prévoyer simplement une machine multi-OS pour ne pas passer
plus de temps à réinstaller un système bloqué qu'à developper.
Pas besoin. En cas de pb : reboot en mode sans echec sans reseau et
suppression de la cle declarant la Gina dans la BDR.
ah ouais ? on peut démarrer en mode DOS aussi ???
on est en 2005 et je ne parlais pas de ton w98 - j'ai même indiqué que
cet OS nécessitait une approche propriétaire car son boot est merdique
(non sécurisé).
W2k, XP et 2003Svr utilisent winlogon qui utilisera la Gina déclarée, si
elle est (trop) buggée le système est mort.
prévoyer simplement une machine multi-OS pour ne pas passer plus de temps à réinstaller un système bloqué qu'à developper.
Pas besoin. En cas de pb : reboot en mode sans echec sans reseau et suppression de la cle declarant la Gina dans la BDR.
ah ouais ? on peut démarrer en mode DOS aussi ???
on est en 2005 et je ne parlais pas de ton w98 - j'ai même indiqué que cet OS nécessitait une approche propriétaire car son boot est merdique (non sécurisé).
W2k, XP et 2003Svr utilisent winlogon qui utilisera la Gina déclarée, si elle est (trop) buggée le système est mort.
Sylvain.
Thierry
Bonjour,
Sylvain a écrit :
ah ouais ? on peut démarrer en mode DOS aussi ???
on est en 2005 et je ne parlais pas de ton w98 - j'ai même indiqué que cet OS nécessitait une approche propriétaire car son boot est merdique (non sécurisé).
W2k, XP et 2003Svr utilisent winlogon qui utilisera la Gina déclarée, si elle est (trop) buggée le système est mort.
T'es gentil mais j'ai une certaine expérience en Gina buguée :-)
Et puis suffit de lire les docs, hein... "Another option is to jump into Safe mode to remove a misbehaving GINA." et probablement dans le MSDN. Je l'ai pas inventé.
-- « Le travail est probablement ce qu'il y a sur cette terre de plus bas et de plus ignoble. Il n'est pas possible de regarder un travailleur sans maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager, dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. » Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Bonjour,
Sylvain a écrit :
ah ouais ? on peut démarrer en mode DOS aussi ???
on est en 2005 et je ne parlais pas de ton w98 - j'ai même indiqué que
cet OS nécessitait une approche propriétaire car son boot est merdique
(non sécurisé).
W2k, XP et 2003Svr utilisent winlogon qui utilisera la Gina déclarée, si
elle est (trop) buggée le système est mort.
T'es gentil mais j'ai une certaine expérience en Gina buguée :-)
Et puis suffit de lire les docs, hein...
"Another option is to jump into Safe mode to remove a misbehaving GINA."
et probablement dans le MSDN. Je l'ai pas inventé.
--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
on est en 2005 et je ne parlais pas de ton w98 - j'ai même indiqué que cet OS nécessitait une approche propriétaire car son boot est merdique (non sécurisé).
W2k, XP et 2003Svr utilisent winlogon qui utilisera la Gina déclarée, si elle est (trop) buggée le système est mort.
T'es gentil mais j'ai une certaine expérience en Gina buguée :-)
Et puis suffit de lire les docs, hein... "Another option is to jump into Safe mode to remove a misbehaving GINA." et probablement dans le MSDN. Je l'ai pas inventé.
-- « Le travail est probablement ce qu'il y a sur cette terre de plus bas et de plus ignoble. Il n'est pas possible de regarder un travailleur sans maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager, dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. » Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Sylvain
Thierry wrote on 18/08/2005 18:00:
T'es gentil
(ce n'est pas le but cherché, ni son contraire d'ailleurs.)
mais j'ai une certaine expérience en Gina buguée :-)
dommage alors que la transmission de cette expérience se soit bornée à une solution non applicable.
Et puis suffit de lire les docs, hein... "Another option is to jump into Safe mode to remove a misbehaving GINA." et probablement dans le MSDN. Je l'ai pas inventé.
from Security Briefs Customizing GINA, Part 1 Keith Brown May 2005
l'auteur y écrit:
Once your GINA is built, you'll want to deploy it and test it out. I
strongly recommend that you don't deploy the GINA to your development box. Use a separate machine to host your GINA for testing. My own setup relies on Virtual PC with its undo disk feature. If something goes really wrong and I end up in an infinite reboot loop (yes, this will happen to you at some point), I just close down the Virtual PC and discard changes. *Another option is to jump into Safe mode to remove a misbehaving GINA* <<<
ce qui se traduit par _si vous utilisez Virtual PC_ (alternative au multi boot), vous pouvez soit restaurer l'image système (undo disk feature), soit booter le système _virtuel_ en mode safe.
suffit pas de lire ... la fin des phrases, il faut tout lire.
Sylvain.
Thierry wrote on 18/08/2005 18:00:
T'es gentil
(ce n'est pas le but cherché, ni son contraire d'ailleurs.)
mais j'ai une certaine expérience en Gina buguée :-)
dommage alors que la transmission de cette expérience se soit bornée à
une solution non applicable.
Et puis suffit de lire les docs, hein...
"Another option is to jump into Safe mode to remove a misbehaving GINA."
et probablement dans le MSDN. Je l'ai pas inventé.
from
Security Briefs
Customizing GINA, Part 1
Keith Brown
May 2005
l'auteur y écrit:
Once your GINA is built, you'll want to deploy it and test it out. I
strongly recommend that you don't deploy the GINA to your development
box. Use a separate machine to host your GINA for testing. My own setup
relies on Virtual PC with its undo disk feature. If something goes
really wrong and I end up in an infinite reboot loop (yes, this will
happen to you at some point), I just close down the Virtual PC and
discard changes. *Another option is to jump into Safe mode to remove a
misbehaving GINA*
<<<
ce qui se traduit par _si vous utilisez Virtual PC_ (alternative au
multi boot), vous pouvez soit restaurer l'image système (undo disk
feature), soit booter le système _virtuel_ en mode safe.
suffit pas de lire ... la fin des phrases, il faut tout lire.
(ce n'est pas le but cherché, ni son contraire d'ailleurs.)
mais j'ai une certaine expérience en Gina buguée :-)
dommage alors que la transmission de cette expérience se soit bornée à une solution non applicable.
Et puis suffit de lire les docs, hein... "Another option is to jump into Safe mode to remove a misbehaving GINA." et probablement dans le MSDN. Je l'ai pas inventé.
from Security Briefs Customizing GINA, Part 1 Keith Brown May 2005
l'auteur y écrit:
Once your GINA is built, you'll want to deploy it and test it out. I
strongly recommend that you don't deploy the GINA to your development box. Use a separate machine to host your GINA for testing. My own setup relies on Virtual PC with its undo disk feature. If something goes really wrong and I end up in an infinite reboot loop (yes, this will happen to you at some point), I just close down the Virtual PC and discard changes. *Another option is to jump into Safe mode to remove a misbehaving GINA* <<<
ce qui se traduit par _si vous utilisez Virtual PC_ (alternative au multi boot), vous pouvez soit restaurer l'image système (undo disk feature), soit booter le système _virtuel_ en mode safe.
suffit pas de lire ... la fin des phrases, il faut tout lire.
Sylvain.
YBM
ce qui se traduit par _si vous utilisez Virtual PC_ (alternative au multi boot), vous pouvez soit restaurer l'image système (undo disk feature), soit booter le système _virtuel_ en mode safe.
Ce n'est pas parce qu'un dévelopeur donné est incapable de tirer parti de la modularité (même si très limitée semble-t-il) d'un système, qu'il faut que tout le monde fasse comme lui.
Un bête serveur telnet avec une authentification locale c'est pas possible ? Ou mieux, personne n'a porté un bête getty+login sous Windows ?
ce qui se traduit par _si vous utilisez Virtual PC_ (alternative au
multi boot), vous pouvez soit restaurer l'image système (undo disk
feature), soit booter le système _virtuel_ en mode safe.
Ce n'est pas parce qu'un dévelopeur donné est incapable de tirer parti
de la modularité (même si très limitée semble-t-il) d'un système, qu'il
faut que tout le monde fasse comme lui.
Un bête serveur telnet avec une authentification locale c'est pas
possible ? Ou mieux, personne n'a porté un bête getty+login sous
Windows ?
ce qui se traduit par _si vous utilisez Virtual PC_ (alternative au multi boot), vous pouvez soit restaurer l'image système (undo disk feature), soit booter le système _virtuel_ en mode safe.
Ce n'est pas parce qu'un dévelopeur donné est incapable de tirer parti de la modularité (même si très limitée semble-t-il) d'un système, qu'il faut que tout le monde fasse comme lui.
Un bête serveur telnet avec une authentification locale c'est pas possible ? Ou mieux, personne n'a porté un bête getty+login sous Windows ?
Sylvain
YBM wrote on 18/08/2005 23:26:
Ce n'est pas parce qu'un dévelopeur donné est incapable de tirer parti de la modularité (même si très limitée semble-t-il) d'un système, qu'il faut que tout le monde fasse comme lui.
je n'ai que recadré un propos tronqué.
ce n'est pas en effet la seule option et il s'agit plus de comprendre et developper (dont sa propre stratégie) que de copier.
Un bête serveur telnet avec une authentification locale c'est pas possible ? Ou mieux, personne n'a porté un bête getty+login sous Windows ?
telnet et/ou un tout bête rlogin (vieux de 30 ans sous unix) n'existe quasiment pas sous wintel (en tout cas pas sous forme d'outil courant).
un getty n'est pas applicable car rien ne préexiste pour permettre son invocation (prompt texte ou autre).
(très schématiquement) sous unix, vous avez spontanément la main (N shell concurrentiels) et vous voulez vous loger N fois créant N process utilisateurs; sous windows, tout est fermé et vous devez passer par winlogon qui n'offre que l'interface Gina comme canal de communication (impossible de lui causer par la bande en socket ou push) et vous créez qu'un seul espace utilisateur (tous les process héritent du même context) - ce point est légèrement assoupli avec le dernier XP.
Sylvain.
YBM wrote on 18/08/2005 23:26:
Ce n'est pas parce qu'un dévelopeur donné est incapable de tirer parti
de la modularité (même si très limitée semble-t-il) d'un système, qu'il
faut que tout le monde fasse comme lui.
je n'ai que recadré un propos tronqué.
ce n'est pas en effet la seule option et il s'agit plus de comprendre et
developper (dont sa propre stratégie) que de copier.
Un bête serveur telnet avec une authentification locale c'est pas
possible ? Ou mieux, personne n'a porté un bête getty+login sous
Windows ?
telnet et/ou un tout bête rlogin (vieux de 30 ans sous unix) n'existe
quasiment pas sous wintel (en tout cas pas sous forme d'outil courant).
un getty n'est pas applicable car rien ne préexiste pour permettre son
invocation (prompt texte ou autre).
(très schématiquement) sous unix, vous avez spontanément la main (N
shell concurrentiels) et vous voulez vous loger N fois créant N process
utilisateurs; sous windows, tout est fermé et vous devez passer par
winlogon qui n'offre que l'interface Gina comme canal de communication
(impossible de lui causer par la bande en socket ou push) et vous créez
qu'un seul espace utilisateur (tous les process héritent du même
context) - ce point est légèrement assoupli avec le dernier XP.
Ce n'est pas parce qu'un dévelopeur donné est incapable de tirer parti de la modularité (même si très limitée semble-t-il) d'un système, qu'il faut que tout le monde fasse comme lui.
je n'ai que recadré un propos tronqué.
ce n'est pas en effet la seule option et il s'agit plus de comprendre et developper (dont sa propre stratégie) que de copier.
Un bête serveur telnet avec une authentification locale c'est pas possible ? Ou mieux, personne n'a porté un bête getty+login sous Windows ?
telnet et/ou un tout bête rlogin (vieux de 30 ans sous unix) n'existe quasiment pas sous wintel (en tout cas pas sous forme d'outil courant).
un getty n'est pas applicable car rien ne préexiste pour permettre son invocation (prompt texte ou autre).
(très schématiquement) sous unix, vous avez spontanément la main (N shell concurrentiels) et vous voulez vous loger N fois créant N process utilisateurs; sous windows, tout est fermé et vous devez passer par winlogon qui n'offre que l'interface Gina comme canal de communication (impossible de lui causer par la bande en socket ou push) et vous créez qu'un seul espace utilisateur (tous les process héritent du même context) - ce point est légèrement assoupli avec le dernier XP.
Sylvain.
YBM
(très schématiquement) sous unix, vous avez spontanément la main (N shell concurrentiels) et vous voulez vous loger N fois créant N process utilisateurs; sous windows, tout est fermé et vous devez passer par winlogon qui n'offre que l'interface Gina comme canal de communication (impossible de lui causer par la bande en socket ou push) et vous créez qu'un seul espace utilisateur (tous les process héritent du même context) - ce point est légèrement assoupli avec le dernier XP.
Ça m'étonne un peu quand même. Sous UNIX ce ne sont pas des shells qui sont en train de tourner en attente, mais des processus quelconque, ayant les droits administrateur, et qui, une fois la connexion acceptée sur un critère quelconque, lance un shell sous une identité x ou y.
Il n'y vraiment pas moyen d'avoir ça sous Windows ? Même pendant les phases de mise au point ?
(très schématiquement) sous unix, vous avez spontanément la main (N
shell concurrentiels) et vous voulez vous loger N fois créant N process
utilisateurs; sous windows, tout est fermé et vous devez passer par
winlogon qui n'offre que l'interface Gina comme canal de communication
(impossible de lui causer par la bande en socket ou push) et vous créez
qu'un seul espace utilisateur (tous les process héritent du même
context) - ce point est légèrement assoupli avec le dernier XP.
Ça m'étonne un peu quand même. Sous UNIX ce ne sont pas des shells
qui sont en train de tourner en attente, mais des processus quelconque,
ayant les droits administrateur, et qui, une fois la connexion acceptée
sur un critère quelconque, lance un shell sous une identité x ou y.
Il n'y vraiment pas moyen d'avoir ça sous Windows ? Même pendant les
phases de mise au point ?
(très schématiquement) sous unix, vous avez spontanément la main (N shell concurrentiels) et vous voulez vous loger N fois créant N process utilisateurs; sous windows, tout est fermé et vous devez passer par winlogon qui n'offre que l'interface Gina comme canal de communication (impossible de lui causer par la bande en socket ou push) et vous créez qu'un seul espace utilisateur (tous les process héritent du même context) - ce point est légèrement assoupli avec le dernier XP.
Ça m'étonne un peu quand même. Sous UNIX ce ne sont pas des shells qui sont en train de tourner en attente, mais des processus quelconque, ayant les droits administrateur, et qui, une fois la connexion acceptée sur un critère quelconque, lance un shell sous une identité x ou y.
Il n'y vraiment pas moyen d'avoir ça sous Windows ? Même pendant les phases de mise au point ?
Sylvain
YBM wrote on 19/08/2005 01:19:
(très schématiquement) sous unix, vous avez spontanément la main (N shell concurrentiels) et vous voulez vous loger N fois créant N process utilisateurs; sous windows, tout est fermé et vous devez passer par winlogon qui n'offre que l'interface Gina comme canal de communication (impossible de lui causer par la bande en socket ou push) et vous créez qu'un seul espace utilisateur (tous les process héritent du même context) - ce point est légèrement assoupli avec le dernier XP.
Ça m'étonne un peu quand même. Sous UNIX ce ne sont pas des shells qui sont en train de tourner en attente,
excusez moi de ne pas avoir developper de tels kernel pour utiliser le terme exact.
mais des processus quelconque,
je dirais plutôt un "kernel à l'écoute" - une fois démarré, le système a monté les disks, énuméré les périphériques et propose un interpréteur minimum qui permet de lancer d'autres processus ou de réclamer des droits (en se loguant).
ayant les droits administrateur,
non "il" (en fait personne, sinon le kernel) n'a pas de droits admin (ni superuser), il "voit" simplement toutes les ressources (dont disks, dont adapt. ethernet), pour autant des droits d'accès ou d'exécution existent.
et qui, une fois la connexion acceptée sur un critère quelconque, lance un shell sous une identité x ou y.
un shell particulier (dans la famille *sh) ou un environnement X11 n'est lancé que si cela correspond au profil de l'utilisateur identifié (dans ses .pref_a_lui); le shell n'est donc pas (systématiquement) lancé _sous_ une identité mais n'existe que via cette identité.
Il n'y vraiment pas moyen d'avoir ça sous Windows ?
à mon sens la notion de micro-kernel est absente (ça n'aide pas à isoler) et Billou ne semble pas avoir eu envie (ni de faire, ni d'ouvrir).
Même pendant les phases de mise au point ?
de l'OS ? avec un patch par semaine, ça veut dire tout le temps.
de services ou d'appli ? ils sont contraints par l'OS.
Sylvain.
(faire suivre sur fr.comp.os.je_sais_pas_quoi le cas échéant).
YBM wrote on 19/08/2005 01:19:
(très schématiquement) sous unix, vous avez spontanément la main (N
shell concurrentiels) et vous voulez vous loger N fois créant N
process utilisateurs; sous windows, tout est fermé et vous devez
passer par winlogon qui n'offre que l'interface Gina comme canal de
communication (impossible de lui causer par la bande en socket ou
push) et vous créez qu'un seul espace utilisateur (tous les process
héritent du même context) - ce point est légèrement assoupli avec le
dernier XP.
Ça m'étonne un peu quand même. Sous UNIX ce ne sont pas des shells
qui sont en train de tourner en attente,
excusez moi de ne pas avoir developper de tels kernel pour utiliser le
terme exact.
mais des processus quelconque,
je dirais plutôt un "kernel à l'écoute" - une fois démarré, le système a
monté les disks, énuméré les périphériques et propose un interpréteur
minimum qui permet de lancer d'autres processus ou de réclamer des
droits (en se loguant).
ayant les droits administrateur,
non "il" (en fait personne, sinon le kernel) n'a pas de droits admin (ni
superuser), il "voit" simplement toutes les ressources (dont disks, dont
adapt. ethernet), pour autant des droits d'accès ou d'exécution existent.
et qui, une fois la connexion acceptée sur un critère
quelconque, lance un shell sous une identité x ou y.
un shell particulier (dans la famille *sh) ou un environnement X11 n'est
lancé que si cela correspond au profil de l'utilisateur identifié (dans
ses .pref_a_lui); le shell n'est donc pas (systématiquement) lancé
_sous_ une identité mais n'existe que via cette identité.
Il n'y vraiment pas moyen d'avoir ça sous Windows ?
à mon sens la notion de micro-kernel est absente (ça n'aide pas à
isoler) et Billou ne semble pas avoir eu envie (ni de faire, ni d'ouvrir).
Même pendant les phases de mise au point ?
de l'OS ? avec un patch par semaine, ça veut dire tout le temps.
de services ou d'appli ? ils sont contraints par l'OS.
Sylvain.
(faire suivre sur fr.comp.os.je_sais_pas_quoi le cas échéant).
(très schématiquement) sous unix, vous avez spontanément la main (N shell concurrentiels) et vous voulez vous loger N fois créant N process utilisateurs; sous windows, tout est fermé et vous devez passer par winlogon qui n'offre que l'interface Gina comme canal de communication (impossible de lui causer par la bande en socket ou push) et vous créez qu'un seul espace utilisateur (tous les process héritent du même context) - ce point est légèrement assoupli avec le dernier XP.
Ça m'étonne un peu quand même. Sous UNIX ce ne sont pas des shells qui sont en train de tourner en attente,
excusez moi de ne pas avoir developper de tels kernel pour utiliser le terme exact.
mais des processus quelconque,
je dirais plutôt un "kernel à l'écoute" - une fois démarré, le système a monté les disks, énuméré les périphériques et propose un interpréteur minimum qui permet de lancer d'autres processus ou de réclamer des droits (en se loguant).
ayant les droits administrateur,
non "il" (en fait personne, sinon le kernel) n'a pas de droits admin (ni superuser), il "voit" simplement toutes les ressources (dont disks, dont adapt. ethernet), pour autant des droits d'accès ou d'exécution existent.
et qui, une fois la connexion acceptée sur un critère quelconque, lance un shell sous une identité x ou y.
un shell particulier (dans la famille *sh) ou un environnement X11 n'est lancé que si cela correspond au profil de l'utilisateur identifié (dans ses .pref_a_lui); le shell n'est donc pas (systématiquement) lancé _sous_ une identité mais n'existe que via cette identité.
Il n'y vraiment pas moyen d'avoir ça sous Windows ?
à mon sens la notion de micro-kernel est absente (ça n'aide pas à isoler) et Billou ne semble pas avoir eu envie (ni de faire, ni d'ouvrir).
Même pendant les phases de mise au point ?
de l'OS ? avec un patch par semaine, ça veut dire tout le temps.
de services ou d'appli ? ils sont contraints par l'OS.
Sylvain.
(faire suivre sur fr.comp.os.je_sais_pas_quoi le cas échéant).
Johann.D
"YBM" a écrit dans le message de news:430516f0$0$21668$
(très schématiquement) sous unix, vous avez spontanément la main (N shell concurrentiels) et vous voulez vous loger N fois créant N process utilisateurs; sous windows, tout est fermé et vous devez passer par winlogon qui n'offre que l'interface Gina comme canal de communication (impossible de lui causer par la bande en socket ou push) et vous créez qu'un seul espace utilisateur (tous les process héritent du même context) - ce point est légèrement assoupli avec le dernier XP.
Ça m'étonne un peu quand même. Sous UNIX ce ne sont pas des shells qui sont en train de tourner en attente, mais des processus quelconque, ayant les droits administrateur, et qui, une fois la connexion acceptée sur un critère quelconque, lance un shell sous une identité x ou y.
Il n'y vraiment pas moyen d'avoir ça sous Windows ? Même pendant les phases de mise au point ?
Il y a toujours la possibilité d'utiliser un accès console via le réseau (rclient.exe ou un truc équivalent), ou un accès distant à la base de registres, MAIS le point bloquant c'est que l'interface graphique est un élément obligatoire du système, pas une extension plus ou moins contournable. Sur un WinNT opérationnel, -pour résumer- on active les pilotes, puis les services (dont les services d'authentification et l'éventuel service de login distant), puis l'interface graphique (dont toute la circuiterie Winlogon+Gina qui attend le Ctrl+Alt+Suppr, ou un événement carte à puce, ou autre, pour tenter d'ouvrir une session). Si le login graphique *n'est pas opérationnel* il reste effectivement possible d'intervenir par le réseau. Si le login graphique *plante* (boucle infinie, reset, écran bleu...), l'accès via le réseau n'aura pas servi à grand chose car il ne sera resté "ouvert" qu'une fraction de secondes.
Mes 2 centimes.
-- Johann
"YBM" <ybmess@nooos.fr> a écrit dans le message de
news:430516f0$0$21668$626a14ce@news.free.fr...
(très schématiquement) sous unix, vous avez spontanément la main (N
shell concurrentiels) et vous voulez vous loger N fois créant N process
utilisateurs; sous windows, tout est fermé et vous devez passer par
winlogon qui n'offre que l'interface Gina comme canal de communication
(impossible de lui causer par la bande en socket ou push) et vous créez
qu'un seul espace utilisateur (tous les process héritent du même
context) - ce point est légèrement assoupli avec le dernier XP.
Ça m'étonne un peu quand même. Sous UNIX ce ne sont pas des shells
qui sont en train de tourner en attente, mais des processus quelconque,
ayant les droits administrateur, et qui, une fois la connexion acceptée
sur un critère quelconque, lance un shell sous une identité x ou y.
Il n'y vraiment pas moyen d'avoir ça sous Windows ? Même pendant les
phases de mise au point ?
Il y a toujours la possibilité d'utiliser un accès console via le réseau
(rclient.exe ou un truc équivalent), ou un accès distant à la base de
registres, MAIS le point bloquant c'est que l'interface graphique est un
élément obligatoire du système, pas une extension plus ou moins
contournable. Sur un WinNT opérationnel, -pour résumer- on active les
pilotes, puis les services (dont les services d'authentification et
l'éventuel service de login distant), puis l'interface graphique (dont toute
la circuiterie Winlogon+Gina qui attend le Ctrl+Alt+Suppr, ou un événement
carte à puce, ou autre, pour tenter d'ouvrir une session). Si le login
graphique *n'est pas opérationnel* il reste effectivement possible
d'intervenir par le réseau. Si le login graphique *plante* (boucle infinie,
reset, écran bleu...), l'accès via le réseau n'aura pas servi à grand chose
car il ne sera resté "ouvert" qu'une fraction de secondes.
"YBM" a écrit dans le message de news:430516f0$0$21668$
(très schématiquement) sous unix, vous avez spontanément la main (N shell concurrentiels) et vous voulez vous loger N fois créant N process utilisateurs; sous windows, tout est fermé et vous devez passer par winlogon qui n'offre que l'interface Gina comme canal de communication (impossible de lui causer par la bande en socket ou push) et vous créez qu'un seul espace utilisateur (tous les process héritent du même context) - ce point est légèrement assoupli avec le dernier XP.
Ça m'étonne un peu quand même. Sous UNIX ce ne sont pas des shells qui sont en train de tourner en attente, mais des processus quelconque, ayant les droits administrateur, et qui, une fois la connexion acceptée sur un critère quelconque, lance un shell sous une identité x ou y.
Il n'y vraiment pas moyen d'avoir ça sous Windows ? Même pendant les phases de mise au point ?
Il y a toujours la possibilité d'utiliser un accès console via le réseau (rclient.exe ou un truc équivalent), ou un accès distant à la base de registres, MAIS le point bloquant c'est que l'interface graphique est un élément obligatoire du système, pas une extension plus ou moins contournable. Sur un WinNT opérationnel, -pour résumer- on active les pilotes, puis les services (dont les services d'authentification et l'éventuel service de login distant), puis l'interface graphique (dont toute la circuiterie Winlogon+Gina qui attend le Ctrl+Alt+Suppr, ou un événement carte à puce, ou autre, pour tenter d'ouvrir une session). Si le login graphique *n'est pas opérationnel* il reste effectivement possible d'intervenir par le réseau. Si le login graphique *plante* (boucle infinie, reset, écran bleu...), l'accès via le réseau n'aura pas servi à grand chose car il ne sera resté "ouvert" qu'une fraction de secondes.
Mes 2 centimes.
-- Johann
Thierry
Bonjour,
Sylvain a écrit :
mais j'ai une certaine expérience en Gina buguée :-)
dommage alors que la transmission de cette expérience se soit bornée à une solution non applicable.
Et bien juste essaye avec la Gina livrée avec l'article.
ce qui se traduit par _si vous utilisez Virtual PC_ (alternative au multi boot), vous pouvez soit restaurer l'image système (undo disk feature), soit booter le système _virtuel_ en mode safe.
C'est pas une traduction c'est une interpretation. On va pas y passer l'été (surtout que ça n'a pas grand chose a voir avec le forum): fais la manip.
Cependant c'est clairement plus confortable d'avoir une machine de tests.
-- « Le travail est probablement ce qu'il y a sur cette terre de plus bas et de plus ignoble. Il n'est pas possible de regarder un travailleur sans maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager, dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. » Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
Bonjour,
Sylvain a écrit :
mais j'ai une certaine expérience en Gina buguée :-)
dommage alors que la transmission de cette expérience se soit bornée à
une solution non applicable.
Et bien juste essaye avec la Gina livrée avec l'article.
ce qui se traduit par _si vous utilisez Virtual PC_ (alternative au
multi boot), vous pouvez soit restaurer l'image système (undo disk
feature), soit booter le système _virtuel_ en mode safe.
C'est pas une traduction c'est une interpretation.
On va pas y passer l'été (surtout que ça n'a pas grand chose a voir avec le
forum): fais la manip.
Cependant c'est clairement plus confortable d'avoir une machine de tests.
--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
mais j'ai une certaine expérience en Gina buguée :-)
dommage alors que la transmission de cette expérience se soit bornée à une solution non applicable.
Et bien juste essaye avec la Gina livrée avec l'article.
ce qui se traduit par _si vous utilisez Virtual PC_ (alternative au multi boot), vous pouvez soit restaurer l'image système (undo disk feature), soit booter le système _virtuel_ en mode safe.
C'est pas une traduction c'est une interpretation. On va pas y passer l'été (surtout que ça n'a pas grand chose a voir avec le forum): fais la manip.
Cependant c'est clairement plus confortable d'avoir une machine de tests.
-- « Le travail est probablement ce qu'il y a sur cette terre de plus bas et de plus ignoble. Il n'est pas possible de regarder un travailleur sans maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager, dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. » Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<
pornin
According to YBM :
Il n'y vraiment pas moyen d'avoir ça sous Windows ?
Windows 2000, XP et suivants comportent un serveur telnet, qui est désactivé par défaut. Mais c'est facile à activer (c'est un banal service) ; je viens de le faire sur un XP Pro que j'ai sous la main. Évidemment, on n'obtient qu'une console texte, sans accès à un "bureau" (i.e., un environnement graphique), ce qui trouble la plupart des applications (le monde Windows n'a pas la "culture texte" unixienne). Mais pour simplement déplacer des fichiers, ça marche.
Évidemment, telnet, c'est un peu naze point de vue sécurité (surtout en authentification classique, où les mots de passe sont envoyés en clair sur la ligne), mais dans un réseau local contrôlé, ça ne pose pas de problème particulier.
--Thomas Pornin
According to YBM <ybmess@nooos.fr>:
Il n'y vraiment pas moyen d'avoir ça sous Windows ?
Windows 2000, XP et suivants comportent un serveur telnet, qui est
désactivé par défaut. Mais c'est facile à activer (c'est un banal
service) ; je viens de le faire sur un XP Pro que j'ai sous la main.
Évidemment, on n'obtient qu'une console texte, sans accès à un "bureau"
(i.e., un environnement graphique), ce qui trouble la plupart des
applications (le monde Windows n'a pas la "culture texte" unixienne).
Mais pour simplement déplacer des fichiers, ça marche.
Évidemment, telnet, c'est un peu naze point de vue sécurité (surtout
en authentification classique, où les mots de passe sont envoyés en
clair sur la ligne), mais dans un réseau local contrôlé, ça ne pose
pas de problème particulier.
Il n'y vraiment pas moyen d'avoir ça sous Windows ?
Windows 2000, XP et suivants comportent un serveur telnet, qui est désactivé par défaut. Mais c'est facile à activer (c'est un banal service) ; je viens de le faire sur un XP Pro que j'ai sous la main. Évidemment, on n'obtient qu'une console texte, sans accès à un "bureau" (i.e., un environnement graphique), ce qui trouble la plupart des applications (le monde Windows n'a pas la "culture texte" unixienne). Mais pour simplement déplacer des fichiers, ça marche.
Évidemment, telnet, c'est un peu naze point de vue sécurité (surtout en authentification classique, où les mots de passe sont envoyés en clair sur la ligne), mais dans un réseau local contrôlé, ça ne pose pas de problème particulier.
