Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows XP Discussions Générales multi-session et domaine Active Directory

multi-session et domaine Active Directory

10 réponses
Avatar
Eric Belhomme
Bonjour,

Une fonctionalité de XP que je trouve bien pratique : la possibilité
d'ouvrir simultanément 2 sessions avec des comptes utilisateurs différents
(ce qui permet par exemple d'ouvrir une session administrateur afin
d'installer un programme ou un périphérique sans avoir à se delogguer...)

Hélas, cette fonctionalité si pratique n'est plus disponible une fois que
l'ordinateur sous XP est rejoint un domaine Active Directory :(

Je voulais donc savoir si il est possible de garder cette fonction activée
avec un ordinateur membre d'un domaine Active Directory ?

mon système :
- controlleurs de domaine Windows 2000 Server SP4
- postes Windows XP Pro SP2
- postes Windows 2000 Pro SP4

Je suppose que ca doit pouvoir se faire via une GPO. Mais mes controlleurs
de domaine etant des Windows 2000, ils n'ont pas de GPO spécifiques à XP...
Faut-il installer quelques chose sur mes controlleurs ?

Merci

--
Rico
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Thierry DEMAN [MVP]
Bonjour,

eh non, cela n'est pas possible !
Cette possibilité disparaît dès que XP est intégré dans un domaine.

A bientôt,
--
Thierry DEMAN-BARCELÒ
MVP Exchange, SQL/Server
MCSE2003+M,MCSE+I,MCDBA,MCSA2003+S
http://webfamilial.dyndns.org
http://faqexchange.dyndns.org
http://ofniorcim.dyndns.org (une nouvelle FAQ en cours de création)

"Eric Belhomme" <{rico}+no/ a écrit dans le message de news:
Bonjour,

Une fonctionalité de XP que je trouve bien pratique : la possibilité
d'ouvrir simultanément 2 sessions avec des comptes utilisateurs différents
(ce qui permet par exemple d'ouvrir une session administrateur afin
d'installer un programme ou un périphérique sans avoir à se delogguer...)

Hélas, cette fonctionalité si pratique n'est plus disponible une fois que
l'ordinateur sous XP est rejoint un domaine Active Directory :(

Je voulais donc savoir si il est possible de garder cette fonction activée
avec un ordinateur membre d'un domaine Active Directory ?

mon système :
- controlleurs de domaine Windows 2000 Server SP4
- postes Windows XP Pro SP2
- postes Windows 2000 Pro SP4

Je suppose que ca doit pouvoir se faire via une GPO. Mais mes controlleurs
de domaine etant des Windows 2000, ils n'ont pas de GPO spécifiques à XP...
Faut-il installer quelques chose sur mes controlleurs ?

Merci

--
Rico


Avatar
Jean-Claude BELLAMY
Dans le message news: ,
Eric Belhomme <{rico}+no/ s'est ainsi exprimé:

Bonjour,

Une fonctionalité de XP que je trouve bien pratique : la possibilité
d'ouvrir simultanément 2 sessions avec des comptes utilisateurs
différents (ce qui permet par exemple d'ouvrir une session
administrateur afin d'installer un programme ou un périphérique sans
avoir à se delogguer...)

Hélas, cette fonctionalité si pratique n'est plus disponible une fois
que l'ordinateur sous XP est rejoint un domaine Active Directory :(


NORMAL !

Le fonctionnement en domaine désactive le mode de connexion "Playmobil" de
XP
(écran avec liste des comptes en gros)
Cela parce qu'en principe, dans un domaine, le nombre de comptes est très
important (au moins plusieurs dizaines)
Donc incompatible avec une liste prévue pour afficher environ 10 comptes au
max ...
De plus, cela risquerait de semer la pagaille au niveau des profils, ....
Et ce n'est pas dans la "philosophie" d'une architecture en domaine d'avoir
un utilisateur qui "zappe" temporairement avec un autre sur une même
station !

Je voulais donc savoir si il est possible de garder cette fonction
activée avec un ordinateur membre d'un domaine Active Directory ?


NON, catégorique !

A moins de réécrire totalement le processus WinLogon et la DLL MSGINA.DLL
...
(c'est possible, je l'ai fait, mais je te souhaite bien du plaisir, pour peu
d'intérêt en fin de compte)

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
*

Avatar
JacK [MVP]
Thierry DEMAN [MVP] a exprimé avec précision :
Bonjour,

eh non, cela n'est pas possible !
Cette possibilité disparaît dès que XP est intégré dans un domaine.

A bientôt,


'lut,

Mais ce sera possible sous VISTA ;)

--
http://www.optimix.be.tf MVP Windows Security
http://websecurite.org
http://www.msmvps.com/XPditif/
http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click to answer/cliquer pour répondre :
http://www.cerbermail.com/?z1GqGLYjhd

Avatar
Eric Belhomme
"Jean-Claude BELLAMY" wrote in
news::

Dans le message news: ,
Eric Belhomme <{rico}+no/ s'est ainsi exprimé:

Bonjour,

Une fonctionalité de XP que je trouve bien pratique : la possibilité
d'ouvrir simultanément 2 sessions avec des comptes utilisateurs
différents (ce qui permet par exemple d'ouvrir une session
administrateur afin d'installer un programme ou un périphérique sans
avoir à se delogguer...)

Hélas, cette fonctionalité si pratique n'est plus disponible une fois
que l'ordinateur sous XP est rejoint un domaine Active Directory :(


NORMAL !

Le fonctionnement en domaine désactive le mode de connexion
"Playmobil" de XP
(écran avec liste des comptes en gros)
Cela parce qu'en principe, dans un domaine, le nombre de comptes est
très important (au moins plusieurs dizaines)
Donc incompatible avec une liste prévue pour afficher environ 10
comptes au max ...


Il y a un quiproco là... La fonction qui me manque dès que la station a
rejoint un domaine, ce n'est pas la fenetre d'ouverture de session, mais
la fonctionalité permettant de basculer d'une session à une autre sans
avoir à fermer les sessions ! Bref un fonctionnement qui s'apparente à du
multi-utilisateurs, à la unix quoi !

De plus, cela risquerait de semer la pagaille au niveau des profils,
.... Et ce n'est pas dans la "philosophie" d'une architecture en
domaine d'avoir un utilisateur qui "zappe" temporairement avec un
autre sur une même station !

il y a tellement de mettre la pagaille au niveau des profils...


A moins de réécrire totalement le processus WinLogon et la DLL
MSGINA.DLL
...
(c'est possible, je l'ai fait, mais je te souhaite bien du plaisir,
pour peu d'intérêt en fin de compte)

tu piques ma curiosité là ! qu'as tu fais exactement ? Quant à l'interet

de la chose, chacun son point de vue... Moi je trouve ca extremement
interessant de pouvoir changer de contexte utilisateur sans avoir besoin
de fermer tout son travail à chaque fois qu'on veut rajouter une
imprimante, ou un DSN système, etc...

PS : merci pour ton site, une réference absolue pour ce qui concerne NT
et consors ;)

--
Rico


Avatar
Eric Belhomme
"JacK [MVP]" wrote in news:mn.6af17d596e1e28ab.34023
@wanadoo.fr:

Mais ce sera possible sous VISTA ;)

euh... au risque de passer pour une tanche, c'est quoi VISTA ???


--
Rico

Avatar
Thierry DEMAN [MVP]
Bonsoir,

la notion de contexte et de profils fonctionnent toujours très bien, et cela est indépendant de l'interface Ecran !

=> chaque service, chaque processus peut être lancé avec un compte, un profil et donc un environnement différent.
Il suffit d'utiliser le gestionnaire de tache pour voir les différents comptes utilisés...

Sans parler de l'instruction "Runas" qui permet de réaliser cela.

A+
--
Thierry DEMAN-BARCELÒ
MVP Exchange, SQL/Server
MCSE2003+M,MCSE+I,MCDBA,MCSA2003+S
http://webfamilial.dyndns.org
http://faqexchange.dyndns.org
http://ofniorcim.dyndns.org (une nouvelle FAQ en cours de création)

"Eric Belhomme" <{rico}+no/ a écrit dans le message de news:
"Jean-Claude BELLAMY" wrote in
news::

Dans le message news: ,
Eric Belhomme <{rico}+no/ s'est ainsi exprimé:

Bonjour,

Une fonctionalité de XP que je trouve bien pratique : la possibilité
d'ouvrir simultanément 2 sessions avec des comptes utilisateurs
différents (ce qui permet par exemple d'ouvrir une session
administrateur afin d'installer un programme ou un périphérique sans
avoir à se delogguer...)

Hélas, cette fonctionalité si pratique n'est plus disponible une fois
que l'ordinateur sous XP est rejoint un domaine Active Directory :(


NORMAL !

Le fonctionnement en domaine désactive le mode de connexion
"Playmobil" de XP
(écran avec liste des comptes en gros)
Cela parce qu'en principe, dans un domaine, le nombre de comptes est
très important (au moins plusieurs dizaines)
Donc incompatible avec une liste prévue pour afficher environ 10
comptes au max ...


Il y a un quiproco là... La fonction qui me manque dès que la station a
rejoint un domaine, ce n'est pas la fenetre d'ouverture de session, mais
la fonctionalité permettant de basculer d'une session à une autre sans
avoir à fermer les sessions ! Bref un fonctionnement qui s'apparente à du
multi-utilisateurs, à la unix quoi !

De plus, cela risquerait de semer la pagaille au niveau des profils,
.... Et ce n'est pas dans la "philosophie" d'une architecture en
domaine d'avoir un utilisateur qui "zappe" temporairement avec un
autre sur une même station !

il y a tellement de mettre la pagaille au niveau des profils...


A moins de réécrire totalement le processus WinLogon et la DLL
MSGINA.DLL
...
(c'est possible, je l'ai fait, mais je te souhaite bien du plaisir,
pour peu d'intérêt en fin de compte)

tu piques ma curiosité là ! qu'as tu fais exactement ? Quant à l'interet

de la chose, chacun son point de vue... Moi je trouve ca extremement
interessant de pouvoir changer de contexte utilisateur sans avoir besoin
de fermer tout son travail à chaque fois qu'on veut rajouter une
imprimante, ou un DSN système, etc...

PS : merci pour ton site, une réference absolue pour ce qui concerne NT
et consors ;)

--
Rico




Avatar
Jean-Claude BELLAMY
Dans le message news: ,
Eric Belhomme <{rico}+no/ s'est ainsi exprimé:

"Jean-Claude BELLAMY" wrote in
news::

Dans le message news:
, Eric Belhomme <{rico}+no/ s'est ainsi exprimé:

Bonjour,

Une fonctionalité de XP que je trouve bien pratique : la possibilité
d'ouvrir simultanément 2 sessions avec des comptes utilisateurs
différents (ce qui permet par exemple d'ouvrir une session
administrateur afin d'installer un programme ou un périphérique sans
avoir à se delogguer...)

Hélas, cette fonctionalité si pratique n'est plus disponible une
fois que l'ordinateur sous XP est rejoint un domaine Active
Directory :(


NORMAL !

Le fonctionnement en domaine désactive le mode de connexion
"Playmobil" de XP
(écran avec liste des comptes en gros)
Cela parce qu'en principe, dans un domaine, le nombre de comptes est
très important (au moins plusieurs dizaines)
Donc incompatible avec une liste prévue pour afficher environ 10
comptes au max ...


Il y a un quiproco là... La fonction qui me manque dès que la station
a rejoint un domaine, ce n'est pas la fenetre d'ouverture de session,
mais la fonctionalité permettant de basculer d'une session à une
autre sans avoir à fermer les sessions !


C'est lié !!!!

Le FUS (Fast User Switching) implique que l'écran d'accueil "Playmobil" soit
activé !
D'ailleurs, tu n'as qu'à faire l'expérience :
Sur un PC sous XP où le FUS et "playmobil" sont actifs, on a, dans le
panneau de config "Comptes d'utilisateurs" :
- case "Utiliser l'écran d'accueil" cochée
- case "Utiliser la bascule rapide utilisateur" cochée

Si on décoche la 1ère case ("...écran d'accueil") on constate que la 2ème
("...bascule rapide ") se décoche automatiquement.


Bref un fonctionnement qui
s'apparente à du multi-utilisateurs, à la unix quoi !
Le noyau de XP est multi-user, mais "bridé"


[...]
A moins de réécrire totalement le processus WinLogon et la DLL
MSGINA.DLL
...
(c'est possible, je l'ai fait, mais je te souhaite bien du plaisir,
pour peu d'intérêt en fin de compte)

tu piques ma curiosité là ! qu'as tu fais exactement ?



La réécriture de Gina (Graphical Identification aNd Authentication) n'est
pas très complexe, il "suffit" d'intercepter les fonctions :
WlxNegotiate
WlxInitialize
WlxDisplaySASNotice
WlxLoggedOutSAS
WlxActivateUserShell
WlxLoggedOnSAS
WlxDisplayLockedNotice
WlxWkstaLockedSAS
WlxIsLockOk
WlxIsLogoffOk
WlxShutdown
WlxNetworkProviderLoad
WlxDisplayStatusMessage
WlxGetStatusMessage
WlxRemoveStatusMessage
...
que l'on modifie et ensuite on repasse la main à la MSGINA.DLL d'origine de
Microsoft.
cf. http://www.microsoft.com/windows2000/docs/msgina.doc


La GINA que j'ai conçue a été écrite en Delphi.
Son rôle est de renforcer la sécurité en ouvrant une boite de dialogue
supplémentaire si le compte qui se connecte est du groupe administrateur.

Comme la réécriture complète de MSGINA serait beaucoup trop complexe, la
solution habituellement utilisée consiste à créer une bibliothèque "relais"
(dite "stub" - intraduisible! - en anglais).
Elle comporte toutes les fonctions nécessaires, chaque fonction se limitant
à appeler la fonction identique de la DLL d'origine (MSGINA.DLL), sauf pour
les fonctions que l'on veut personnaliser, dans lesquelles on introduira du
code supplémentaire.


Dans mon cas présent, j'intercepte l'appel à la fonction "WlxLoggedOutSAS".
C'est elle qui est appelée par Winlogon après une "Secure Attention
Sequence" (SAS), obtenue par action sur les touches CTRL-ALT-DEL, lorsque
aucune session n'est encore ouverte.

Cet appel survient immédiatement après envoi des informations de nom de
compte, mot de passe et domaine dans la boite de dialogue de connexion.

La fonction WlxLoggedOutSAS reçoit en particulier comme paramètre d'entrée
une structure WLX_MPR_NOTIFY_INFO laquelle se compose du nom de compte, mot
de passe et domaine.

A l'aide de ces informations, on peut alors déterminer les privilèges du
compte concerné, par appel de la fonction NetUserGetInfo de l'API NetAPI32 :

- Si le compte n'a pas le privilège administrateur,
on termine la fonction WlxLoggedOutSAS en retournant
le code WLX_SAS_ACTION_LOGON qui signifie
"Ouverture de session acceptée".
- Si le compte a le privilège administrateur, on ouvre alors
une boite de dialogue dans laquelle on va demander à
l'utilisateur d'effectuer certaines opérations (saisie d'un
autre mot de passe et/ou insertion d'une disquette clef).
On termine la fonction WlxLoggedOutSAS en retournant,
suivant les informations saisies le code :
- WLX_SAS_ACTION_LOGON
("Ouverture de session acceptée")
- WLX_SAS_ACTION_NONE
("Ouverture de session refusée")

Si tu veux , et si tu pratiques Delphi, je peux t'envoyer mon code, tu
pourras t'en inspirer, ou au minimum comprendre ce mécanisme de "stub" ..


Quant à
l'interet de la chose, chacun son point de vue... Moi je trouve ca
extremement interessant de pouvoir changer de contexte utilisateur
sans avoir besoin de fermer tout son travail à chaque fois qu'on veut
rajouter une imprimante, ou un DSN système, etc...


Mais pas besoin de changer de session pour cela !
Tu as RUNAS pour cela !
Ou encore mon outil "SuperExec", ou tout bêtement le menu contextuel
"Exécuter en tant que "


--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
*



Avatar
Gilles RONSIN
"Jean-Claude BELLAMY" , le mar. 13
sept. 2005 23:44:38, écrivait ceci:
Salut,

Mais pas besoin de changer de session pour cela !
Tu as RUNAS pour cela !


Je viens de m'apercevoir d'un truc avec RUNAS. Si on affecte un
raccourci à un utilisateur avec l'option /savecred (pour une
application anodine par exemple comme le monitorage des températures),
le mot de passe est conservé pour toute utilisation ultérieure de
RUNAS. En fait on donne les clés d'accès à tout abus. Il suffit de
faire RUNAS /user:admin sans en connaitre le mot de passe sur les
autres applications !!!

Ou encore mon outil "SuperExec", ou tout bêtement le menu
contextuel "Exécuter en tant que "


Il est très bien. Sauf que seule l'ancienne version fonctionne sur mon
PC :-( (celle d'avant la possibilité d'affecter par catégorie)

--
Embryon de site : http://gilles.ronsin.free.fr
Gérez vos messages non lus http://gilles.ronsin.free.fr/#nonlus V3.0
Il est impossible pour un optimiste d'être agréablement surpris.

Avatar
Eric Belhomme
"Jean-Claude BELLAMY" wrote in
news:#:

Si tu veux , et si tu pratiques Delphi, je peux t'envoyer mon code, tu
pourras t'en inspirer, ou au minimum comprendre ce mécanisme de "stub"
..
merci, mais je pratique le c et tes informations me sont suffisantes, c'est

tres clair, et tres interessant ;)

Mais pas besoin de changer de session pour cela !
Tu as RUNAS pour cela !


exemple : je veux modifier à la volée la configuration de mon interface
réseau. Si je ne suis pas administrateur, je ne peux pas le faire, et la
fonction "runas" ne m'est d'aucun secours...

--
Rico

Avatar
Jean-Claude BELLAMY
Dans le message news: ,
Eric Belhomme <{rico}+no/ s'est ainsi exprimé:

"Jean-Claude BELLAMY" wrote in
news:#:
[...]
Mais pas besoin de changer de session pour cela !
Tu as RUNAS pour cela !


exemple : je veux modifier à la volée la configuration de mon
interface réseau. Si je ne suis pas administrateur, je ne peux pas le
faire, et la fonction "runas" ne m'est d'aucun secours...


Bien sur que si !!!!!

Il suffit de lancer une autre instance de "explorer" via RUNAS !

Pour cela, il faut qu'au préalable (une fois pour toutes) "explorer" ait été
configuré sous le compte admin de cette façon :
Menu Outils / Options des dossiers/
Onglet Affichage
Cocher la case
"Ouvrir les fenêtres des dossiers dans un processus différent"



HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerAdvancedSeparatePr­ocess
Valeur 0x1 : processus séparés


On peut alors, sous un autre compte, lancer :
RUNAS /users:administrateur explorer.exe

On est alors dans explorer sous le compte admin ...
On a donc accès à à peu près TOUT !
En particulier aux dossiers système "Panneau de configuration" et
"Connexions réseau" !
DONC la configuration de l'interface réseau est parfaitement POSSIBLE !


Et tu peux aussi faire appel à NETSH, exécuté via RUNAS

Et toc ! ;-)

--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
*