Pour mieux comprendre le contexte, je vais le décrire ci-dessous:
Une application industrielle "SCW", développée en langages Java et C++
est mise à disposition du client, sur un PC Windows XP SP2, via un
émulateur Unix propriétaire (MKS-SCO). Cet émulateur est installé sous
Windows XP SP2.
L'émulateur "NUCR" nécessite de démarrer avec un compte
d'authentification de service "Local System". Cet émulateur, une fois
lancé, lance une autre application "GhostD" (qui n'est rien d'autre
qu'un processus), donc il y a dépendance. Ce "GhostD" démarre lui
aussi avec un compte d'authentification de service "Local System".
Une fois ce "GhostD" lancé, il autorise un autre processus chargé
d'initialiser une application Java RMI (Remote Method Invocation),
contrôleé par l'émulateur.
La demande du client: remplacer les comptes "Local System" par des
comptes de services créés spécialement avec les droits strictement
nécessaires pour démarrer les applications et les processus.
1) - Comme ce compte se trouve dans la base SAM locale de
l'ordinateur, existe-t-il un moyen d'empêcher une ouverture de session
locale avec ce compte, sans enrayer le fonctionnnement de l'ouverture
de session en tant que service ?
--------------------------------------------------------------------------------------------------------------
En phase manuelle, cette application, à priori, nécessite d'utiliser
un compte de service authentifié avec le compte "Local System". Or
pour des raisons de sécurité imposées, il faut que l'application
démarre avec un compte de service non "Local System".
Si je le configure avec un compte enrichi de droits "Ouvrir une
session en tant que service", cela ne fonctionne pas. Si je rajoute ce
compte de service dans le groupe "Administrateurs" local de
l'ordinateur, alors l'application démarre. Conclusion: les droits
"Ouvrir une session en tant que service" ne sont pas suffisants et
l'ajout des droits "Administrateurs" provoquent le démarrage.
Constatations:
Tous les processus de ces applications démarrant avec le compte de
service "Local System" fonctionnent correctement et ils sont tous
visibles dans l'onglet "Processus" du "Gestionnaire de Tâches",
marqués comme "Démarré /Automatique" dans les services et accessible
via une console "Xterm" de l'émulateur par un "ps -aex | grep nomdu
processus"
Si l'on modifie le démarrage de l'application "NUCR" avec un compte de
service (qui a reçu les droits "Ouvrir une session en tant que
service"), l'application démarre, mais l'application dépendante
"GhostD" ne démarre pas (bien qu'il soit avec le compte "Local
System". Les autres applications, basculées avec ce même compte, sont
démarrées, apparaissent comme "Démarré / Automatique" au niveau des
services, mais invisibles dans le "Gestionnaire des tâches" et pas
plus dans la "XTerm".
Si je change le compte de service "Local System" de "GhostD" par le
nouveau compte de service. Ce dernier ne démarre pas, n'apparait pas
dans le "Gestionnaire de Tâches", ni dans le "Xterm". Le RMI ne
démarre pas non plus. Ce qui signifie que le nouveau compte de
service créé avec les droits "Ouvrir une session en tant que service"
n'a pas suffisamment de "droits".
2) - Question: quel est le détail de "Ouvrir une session en tant que
service" et est-il possible de connaitre de quoi sont constitués les
droits "Administrateurs" et ceux de "Local System" afin de, par
tatonnement, de ne mettre que ce qui est nécessaire pour faire
démarrer ce service ?
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
Denis Levesque
Salut Yael
As-tu essayer la commande run as?
-- Ne pas faire de reply a ce message merci!
Denis Levesque http://www.dltsi.ca cliquer ici pour me contacter par email http://www.cervermail.com/?HrKKPcJ8ZN
"Yael Cheenne" wrote in message news:
Bonjour à toutes et à tous,
Pour mieux comprendre le contexte, je vais le décrire ci-dessous:
Une application industrielle "SCW", développée en langages Java et C++ est mise à disposition du client, sur un PC Windows XP SP2, via un émulateur Unix propriétaire (MKS-SCO). Cet émulateur est installé sous Windows XP SP2.
L'émulateur "NUCR" nécessite de démarrer avec un compte d'authentification de service "Local System". Cet émulateur, une fois lancé, lance une autre application "GhostD" (qui n'est rien d'autre qu'un processus), donc il y a dépendance. Ce "GhostD" démarre lui aussi avec un compte d'authentification de service "Local System".
Une fois ce "GhostD" lancé, il autorise un autre processus chargé d'initialiser une application Java RMI (Remote Method Invocation), contrôleé par l'émulateur.
La demande du client: remplacer les comptes "Local System" par des comptes de services créés spécialement avec les droits strictement nécessaires pour démarrer les applications et les processus.
1) - Comme ce compte se trouve dans la base SAM locale de l'ordinateur, existe-t-il un moyen d'empêcher une ouverture de session locale avec ce compte, sans enrayer le fonctionnnement de l'ouverture de session en tant que service ?
-------------------------------------------------------------------------------------------------------------- En phase manuelle, cette application, à priori, nécessite d'utiliser un compte de service authentifié avec le compte "Local System". Or pour des raisons de sécurité imposées, il faut que l'application démarre avec un compte de service non "Local System".
Si je le configure avec un compte enrichi de droits "Ouvrir une session en tant que service", cela ne fonctionne pas. Si je rajoute ce compte de service dans le groupe "Administrateurs" local de l'ordinateur, alors l'application démarre. Conclusion: les droits "Ouvrir une session en tant que service" ne sont pas suffisants et l'ajout des droits "Administrateurs" provoquent le démarrage.
Constatations:
Tous les processus de ces applications démarrant avec le compte de service "Local System" fonctionnent correctement et ils sont tous visibles dans l'onglet "Processus" du "Gestionnaire de Tâches", marqués comme "Démarré /Automatique" dans les services et accessible via une console "Xterm" de l'émulateur par un "ps -aex | grep nomdu processus"
Si l'on modifie le démarrage de l'application "NUCR" avec un compte de service (qui a reçu les droits "Ouvrir une session en tant que service"), l'application démarre, mais l'application dépendante "GhostD" ne démarre pas (bien qu'il soit avec le compte "Local System". Les autres applications, basculées avec ce même compte, sont démarrées, apparaissent comme "Démarré / Automatique" au niveau des services, mais invisibles dans le "Gestionnaire des tâches" et pas plus dans la "XTerm".
Si je change le compte de service "Local System" de "GhostD" par le nouveau compte de service. Ce dernier ne démarre pas, n'apparait pas dans le "Gestionnaire de Tâches", ni dans le "Xterm". Le RMI ne démarre pas non plus. Ce qui signifie que le nouveau compte de service créé avec les droits "Ouvrir une session en tant que service" n'a pas suffisamment de "droits".
2) - Question: quel est le détail de "Ouvrir une session en tant que service" et est-il possible de connaitre de quoi sont constitués les droits "Administrateurs" et ceux de "Local System" afin de, par tatonnement, de ne mettre que ce qui est nécessaire pour faire démarrer ce service ?
Merci pour votre aide. Cordialement, Houdini
Salut Yael
As-tu essayer la commande run as?
--
Ne pas faire de reply a ce message
merci!
Denis Levesque
http://www.dltsi.ca
cliquer ici pour me contacter par email
http://www.cervermail.com/?HrKKPcJ8ZN
"Yael Cheenne" <yael.cheenne@wanadoo.fr> wrote in message
news:1abad2tvchkkannj5soledin8f0hj8ek4n@4ax.com...
Bonjour à toutes et à tous,
Pour mieux comprendre le contexte, je vais le décrire ci-dessous:
Une application industrielle "SCW", développée en langages Java et C++
est mise à disposition du client, sur un PC Windows XP SP2, via un
émulateur Unix propriétaire (MKS-SCO). Cet émulateur est installé sous
Windows XP SP2.
L'émulateur "NUCR" nécessite de démarrer avec un compte
d'authentification de service "Local System". Cet émulateur, une fois
lancé, lance une autre application "GhostD" (qui n'est rien d'autre
qu'un processus), donc il y a dépendance. Ce "GhostD" démarre lui
aussi avec un compte d'authentification de service "Local System".
Une fois ce "GhostD" lancé, il autorise un autre processus chargé
d'initialiser une application Java RMI (Remote Method Invocation),
contrôleé par l'émulateur.
La demande du client: remplacer les comptes "Local System" par des
comptes de services créés spécialement avec les droits strictement
nécessaires pour démarrer les applications et les processus.
1) - Comme ce compte se trouve dans la base SAM locale de
l'ordinateur, existe-t-il un moyen d'empêcher une ouverture de session
locale avec ce compte, sans enrayer le fonctionnnement de l'ouverture
de session en tant que service ?
--------------------------------------------------------------------------------------------------------------
En phase manuelle, cette application, à priori, nécessite d'utiliser
un compte de service authentifié avec le compte "Local System". Or
pour des raisons de sécurité imposées, il faut que l'application
démarre avec un compte de service non "Local System".
Si je le configure avec un compte enrichi de droits "Ouvrir une
session en tant que service", cela ne fonctionne pas. Si je rajoute ce
compte de service dans le groupe "Administrateurs" local de
l'ordinateur, alors l'application démarre. Conclusion: les droits
"Ouvrir une session en tant que service" ne sont pas suffisants et
l'ajout des droits "Administrateurs" provoquent le démarrage.
Constatations:
Tous les processus de ces applications démarrant avec le compte de
service "Local System" fonctionnent correctement et ils sont tous
visibles dans l'onglet "Processus" du "Gestionnaire de Tâches",
marqués comme "Démarré /Automatique" dans les services et accessible
via une console "Xterm" de l'émulateur par un "ps -aex | grep nomdu
processus"
Si l'on modifie le démarrage de l'application "NUCR" avec un compte de
service (qui a reçu les droits "Ouvrir une session en tant que
service"), l'application démarre, mais l'application dépendante
"GhostD" ne démarre pas (bien qu'il soit avec le compte "Local
System". Les autres applications, basculées avec ce même compte, sont
démarrées, apparaissent comme "Démarré / Automatique" au niveau des
services, mais invisibles dans le "Gestionnaire des tâches" et pas
plus dans la "XTerm".
Si je change le compte de service "Local System" de "GhostD" par le
nouveau compte de service. Ce dernier ne démarre pas, n'apparait pas
dans le "Gestionnaire de Tâches", ni dans le "Xterm". Le RMI ne
démarre pas non plus. Ce qui signifie que le nouveau compte de
service créé avec les droits "Ouvrir une session en tant que service"
n'a pas suffisamment de "droits".
2) - Question: quel est le détail de "Ouvrir une session en tant que
service" et est-il possible de connaitre de quoi sont constitués les
droits "Administrateurs" et ceux de "Local System" afin de, par
tatonnement, de ne mettre que ce qui est nécessaire pour faire
démarrer ce service ?
Denis Levesque http://www.dltsi.ca cliquer ici pour me contacter par email http://www.cervermail.com/?HrKKPcJ8ZN
"Yael Cheenne" wrote in message news:
Bonjour à toutes et à tous,
Pour mieux comprendre le contexte, je vais le décrire ci-dessous:
Une application industrielle "SCW", développée en langages Java et C++ est mise à disposition du client, sur un PC Windows XP SP2, via un émulateur Unix propriétaire (MKS-SCO). Cet émulateur est installé sous Windows XP SP2.
L'émulateur "NUCR" nécessite de démarrer avec un compte d'authentification de service "Local System". Cet émulateur, une fois lancé, lance une autre application "GhostD" (qui n'est rien d'autre qu'un processus), donc il y a dépendance. Ce "GhostD" démarre lui aussi avec un compte d'authentification de service "Local System".
Une fois ce "GhostD" lancé, il autorise un autre processus chargé d'initialiser une application Java RMI (Remote Method Invocation), contrôleé par l'émulateur.
La demande du client: remplacer les comptes "Local System" par des comptes de services créés spécialement avec les droits strictement nécessaires pour démarrer les applications et les processus.
1) - Comme ce compte se trouve dans la base SAM locale de l'ordinateur, existe-t-il un moyen d'empêcher une ouverture de session locale avec ce compte, sans enrayer le fonctionnnement de l'ouverture de session en tant que service ?
-------------------------------------------------------------------------------------------------------------- En phase manuelle, cette application, à priori, nécessite d'utiliser un compte de service authentifié avec le compte "Local System". Or pour des raisons de sécurité imposées, il faut que l'application démarre avec un compte de service non "Local System".
Si je le configure avec un compte enrichi de droits "Ouvrir une session en tant que service", cela ne fonctionne pas. Si je rajoute ce compte de service dans le groupe "Administrateurs" local de l'ordinateur, alors l'application démarre. Conclusion: les droits "Ouvrir une session en tant que service" ne sont pas suffisants et l'ajout des droits "Administrateurs" provoquent le démarrage.
Constatations:
Tous les processus de ces applications démarrant avec le compte de service "Local System" fonctionnent correctement et ils sont tous visibles dans l'onglet "Processus" du "Gestionnaire de Tâches", marqués comme "Démarré /Automatique" dans les services et accessible via une console "Xterm" de l'émulateur par un "ps -aex | grep nomdu processus"
Si l'on modifie le démarrage de l'application "NUCR" avec un compte de service (qui a reçu les droits "Ouvrir une session en tant que service"), l'application démarre, mais l'application dépendante "GhostD" ne démarre pas (bien qu'il soit avec le compte "Local System". Les autres applications, basculées avec ce même compte, sont démarrées, apparaissent comme "Démarré / Automatique" au niveau des services, mais invisibles dans le "Gestionnaire des tâches" et pas plus dans la "XTerm".
Si je change le compte de service "Local System" de "GhostD" par le nouveau compte de service. Ce dernier ne démarre pas, n'apparait pas dans le "Gestionnaire de Tâches", ni dans le "Xterm". Le RMI ne démarre pas non plus. Ce qui signifie que le nouveau compte de service créé avec les droits "Ouvrir une session en tant que service" n'a pas suffisamment de "droits".
2) - Question: quel est le détail de "Ouvrir une session en tant que service" et est-il possible de connaitre de quoi sont constitués les droits "Administrateurs" et ceux de "Local System" afin de, par tatonnement, de ne mettre que ce qui est nécessaire pour faire démarrer ce service ?
