Ensuite il faut voir quels sont les SID en place dans le registre en allant
dans la branche HKEYLOCALMACHINESECURITYPolicyAccounts.
Je n'ai pas cette clé chez moi. J'ai seulement
HKEY_LOCAL_MACHINESecurity
qui ne contient comme valeur que
(par défaut) REG_SZ (valeur non définie)
et ne contient aucune sous-clé.
Le lien entre le nom de connexion, nom interne et le SID est défini de la
façon suivante : Dans la branche
HKEY-MACHINE-SAMSAMDomainsAccountsUsersNames on trouve autant de
sous-clefs qu'il y a de comptes et le nom de chaque sous-clefs étant le nom
de connexion.
Je n'ai pas ces clés non plus. J'ai seulement
HKEY_LOCAL_MACHINESAM
qui contient
(par défaut) REG_SZ (valeur non définie)
et HKEY_LOCAL_MACHINESAMSAM
qui contient
(par défaut) REG_SZ (valeur non définie)
Donc ma question subsidiaire sera : pourquoi as-tu ces clés chez toi ? Qui te
les a mises ? (mais ce n'est pas forcément la peine de répondre à ces
questions).
Ensuite il faut voir quels sont les SID en place dans le registre en allant
dans la branche HKEYLOCALMACHINESECURITYPolicyAccounts.
Je n'ai pas cette clé chez moi. J'ai seulement
HKEY_LOCAL_MACHINESecurity
qui ne contient comme valeur que
(par défaut) REG_SZ (valeur non définie)
et ne contient aucune sous-clé.
Le lien entre le nom de connexion, nom interne et le SID est défini de la
façon suivante : Dans la branche
HKEY-MACHINE-SAMSAMDomainsAccountsUsersNames on trouve autant de
sous-clefs qu'il y a de comptes et le nom de chaque sous-clefs étant le nom
de connexion.
Je n'ai pas ces clés non plus. J'ai seulement
HKEY_LOCAL_MACHINESAM
qui contient
(par défaut) REG_SZ (valeur non définie)
et HKEY_LOCAL_MACHINESAMSAM
qui contient
(par défaut) REG_SZ (valeur non définie)
Donc ma question subsidiaire sera : pourquoi as-tu ces clés chez toi ? Qui te
les a mises ? (mais ce n'est pas forcément la peine de répondre à ces
questions).
Ensuite il faut voir quels sont les SID en place dans le registre en allant
dans la branche HKEYLOCALMACHINESECURITYPolicyAccounts.
Je n'ai pas cette clé chez moi. J'ai seulement
HKEY_LOCAL_MACHINESecurity
qui ne contient comme valeur que
(par défaut) REG_SZ (valeur non définie)
et ne contient aucune sous-clé.
Le lien entre le nom de connexion, nom interne et le SID est défini de la
façon suivante : Dans la branche
HKEY-MACHINE-SAMSAMDomainsAccountsUsersNames on trouve autant de
sous-clefs qu'il y a de comptes et le nom de chaque sous-clefs étant le nom
de connexion.
Je n'ai pas ces clés non plus. J'ai seulement
HKEY_LOCAL_MACHINESAM
qui contient
(par défaut) REG_SZ (valeur non définie)
et HKEY_LOCAL_MACHINESAMSAM
qui contient
(par défaut) REG_SZ (valeur non définie)
Donc ma question subsidiaire sera : pourquoi as-tu ces clés chez toi ? Qui te
les a mises ? (mais ce n'est pas forcément la peine de répondre à ces
questions).
Bonjour Ypoons, et Salut Georges !
[...]Je n'ai pas cette clé chez moi. J'ai seulement
HKEY_LOCAL_MACHINESecurity
qui ne contient comme valeur que
(par défaut) REG_SZ (valeur non définie)
et ne contient aucune sous-clé.
Elle existe. Voici par exemple :
HKEY_LOCAL_MACHINESECURITYPolicyAccounts
Toute cette zone est accessible seulement en opérant en tant que SYSTEM.
[...]
Elles y sont les clés, elles y sont :
HKEY_LOCAL_MACHINESAMSAMDomainsAccountUsersNamesHelpAssistant
C'est en partie à cause du fait qu'elles soient ainsi masquées [...]
Je relirai tout ça dans la journée.
Bonjour Ypoons, et Salut Georges !
[...]
Je n'ai pas cette clé chez moi. J'ai seulement
HKEY_LOCAL_MACHINESecurity
qui ne contient comme valeur que
(par défaut) REG_SZ (valeur non définie)
et ne contient aucune sous-clé.
Elle existe. Voici par exemple :
HKEY_LOCAL_MACHINESECURITYPolicyAccounts
Toute cette zone est accessible seulement en opérant en tant que SYSTEM.
[...]
Elles y sont les clés, elles y sont :
HKEY_LOCAL_MACHINESAMSAMDomainsAccountUsersNamesHelpAssistant
C'est en partie à cause du fait qu'elles soient ainsi masquées [...]
Je relirai tout ça dans la journée.
Bonjour Ypoons, et Salut Georges !
[...]Je n'ai pas cette clé chez moi. J'ai seulement
HKEY_LOCAL_MACHINESecurity
qui ne contient comme valeur que
(par défaut) REG_SZ (valeur non définie)
et ne contient aucune sous-clé.
Elle existe. Voici par exemple :
HKEY_LOCAL_MACHINESECURITYPolicyAccounts
Toute cette zone est accessible seulement en opérant en tant que SYSTEM.
[...]
Elles y sont les clés, elles y sont :
HKEY_LOCAL_MACHINESAMSAMDomainsAccountUsersNamesHelpAssistant
C'est en partie à cause du fait qu'elles soient ainsi masquées [...]
Je relirai tout ça dans la journée.
Salut JFBonjour Ypoons, et Salut Georges !
[...]Je n'ai pas cette clé chez moi. J'ai seulement
HKEY_LOCAL_MACHINESecurity
qui ne contient comme valeur que
(par défaut) REG_SZ (valeur non définie)
et ne contient aucune sous-clé.
Elle existe. Voici par exemple :
HKEY_LOCAL_MACHINESECURITYPolicyAccounts
Toute cette zone est accessible seulement en opérant en tant que SYSTEM.
Heu... tu peux développer ? Moi pas connaître...[...]
Elles y sont les clés, elles y sont :
HKEY_LOCAL_MACHINESAMSAMDomainsAccountUsersNamesHelpAssistant
C'est en partie à cause du fait qu'elles soient ainsi masquées [...]
Même question ?Je relirai tout ça dans la journée.
Et moi je m'absente pour 48 heures... je verrai la suite samedi.
Amicalement,
Salut JF
Bonjour Ypoons, et Salut Georges !
[...]
Je n'ai pas cette clé chez moi. J'ai seulement
HKEY_LOCAL_MACHINESecurity
qui ne contient comme valeur que
(par défaut) REG_SZ (valeur non définie)
et ne contient aucune sous-clé.
Elle existe. Voici par exemple :
HKEY_LOCAL_MACHINESECURITYPolicyAccounts
Toute cette zone est accessible seulement en opérant en tant que SYSTEM.
Heu... tu peux développer ? Moi pas connaître...
[...]
Elles y sont les clés, elles y sont :
HKEY_LOCAL_MACHINESAMSAMDomainsAccountUsersNamesHelpAssistant
C'est en partie à cause du fait qu'elles soient ainsi masquées [...]
Même question ?
Je relirai tout ça dans la journée.
Et moi je m'absente pour 48 heures... je verrai la suite samedi.
Amicalement,
Salut JFBonjour Ypoons, et Salut Georges !
[...]Je n'ai pas cette clé chez moi. J'ai seulement
HKEY_LOCAL_MACHINESecurity
qui ne contient comme valeur que
(par défaut) REG_SZ (valeur non définie)
et ne contient aucune sous-clé.
Elle existe. Voici par exemple :
HKEY_LOCAL_MACHINESECURITYPolicyAccounts
Toute cette zone est accessible seulement en opérant en tant que SYSTEM.
Heu... tu peux développer ? Moi pas connaître...[...]
Elles y sont les clés, elles y sont :
HKEY_LOCAL_MACHINESAMSAMDomainsAccountUsersNamesHelpAssistant
C'est en partie à cause du fait qu'elles soient ainsi masquées [...]
Même question ?Je relirai tout ça dans la journée.
Et moi je m'absente pour 48 heures... je verrai la suite samedi.
Amicalement,
Jean-François et Ypoons je vais être long sans doute trop long,
mais cela vous remerciera de m'avoir aidé et soutenu.
Je pense avoir réussi, Microsoft m'a fait un mail et conseillé de suivre les
prescriptions de la KB 909444/fr
qui explique pourquoi il arrive que l'on perde ses DROITS D'ACCES à certains
dossiers et fichiers.
(n'oublier pas, si
vous êtes dans mon cas et que vous suiviez cette « story » depuis le début,
qu'il est nécessaire de prendre connaissance des instructions données dans
les KB que Jean-François m'indiquait le 12 juin dernier aux adresses
suivantes)
www.bellamyjc.org/fr/windowsxp2003.html#securitytab
www.bellamyjc.org/fr/windowsnt.html#pbaccesfichiers
En gros, cette note dit, que les systèmes ayant modifiés les autorisations
de la liste de contrôle d'accès par défaut, du répertoire
%windir%registration, peuvent rencontrer différents problèmes après
l'installation de bulletin de sécurité Microsoft telle que la mise à jour
critique décrite dans le bulletin de sécurité Microsoft MS05-051. Ceci peut
se produire lorsque l'on a effectué une installation de réparation de Windows
(NT, 2000, XP.) même si l'utilisateur fait partie du groupe des
administrateurs. Cela peut se manifester également en cas de transfert d'un
disque dur d'une machine vers une autre.
Les évènements suivants, enregistrées dans le journal système, sont concernés
par cette note:
ID des événements 512, 4609, 778, 4689, 10010. Pour chaque événement cité une
description satisfaisante du problème est présentée.
Dans mon cas, l'ID de l'évènement était le 4609 et il se rapportait à
l'erreur produite après la mise en place de la mise à jour de sécurité
902400. La fameuse 80070005.
Pour bien montrer que la Kb 909444/fr. est bien adaptée voilà ce qui est
précisé dans l'ID de l'événement 4609 : Type d'événement : Erreur ; Source de
l'événement : EventSystem ; ID de l'événement : 4609; Catégorie de
l'événement (50); Date ; Heure; Utilisateur N/A; Ordinateur
:serveur :
Description :
Le système d'événement de COM+ a détecté un code de renvoi
erroné lors de son traitement interne. Le HRESULT est 80070005 à partir de la
ligne xx de d:qxq_sipcomcom1xsrceventstier1eventsystemobj.cpp.
Dans les symptômes décrits dans la note KB 909444/fr. il est précisé que le
service windows Firewall peut ne pas démarrer, (c'était mon cas), Le service
Microsoft COM+ EventSystem ne démarre pas et le noeud ordinateur de
l'arborescence de la console MMC de Microsoft component Service ne se
développe pas. (contrôle WMI, gestion Windows impossible et gestion des
disques durs non accessible).
J'ai donc appliqué les instructions données pour résoudre ce problème
espérant ainsi retrouver les droits d'accès qui me faisaient défaut. Hélas
sans aucun succès, Tout semblait, en principe, satisfaisant et pourtant
l'installation de KB 902400 provoquait toujours les mêmes difficultés. Accès
limités ou refusés pour certains fichiers.
Je précise qu'il faut avoir accès au bouton « sécurité » qui apparaît dans
l'onglet« propriété » des dossiers ou fichiers sélectionnés, il est donc
nécessaire d'installer le fichier scesp4i.exe que l'on téléchargera à
htpp://download.microsoft.com/msdowunload/sp4/x86/en/scesp4i.exe
Il ne faut pas exécuter directement le fichier scesp4i.exe mais le
décompresser dans un dossier et cliquer droit sur le fichier SETUP.INF de
9ko et sélectionner « installer ». L'installation a lieu par copie de fichier
dans le répertoire system32 de windows.
En cliquant sur l'onglet propriété de tous les fichiers et dossiers de toutes
les partitions NTFS on fait apparaître l'onglet « sécurité » qui donne accès
à la rubrique « autorisations » de qui permet de modifier les droits
d'utilisateurs, Administrateurs, propriétaires, invités et system.
Pour plus de détail consulter WindowsXP/2003 de Microsoft, rubrique « onglet
de sécurité » paragraphe « (non) affichage sous XP Home ».
Dans cette note, la KB 909444/fr, il est dit que le system peut créer
ultérieurement des fichiers .clb supplémentaires dans le dossier
%windir%/registration et que l'on peut utiliser le fichier Cacls.exe pour
automatiser ces modifications d'autorisations sur la machine concernée.
Là, je suis un peu dépassé et c'est peut être ce qui me manque pour sortir de
cette impasse, je lance bien la commande « cacls » dans l'invite de commande
ainsi que les paramètres qui sont indiqués dans l'aide, mais sans obtenir de
réponse, ce qui fait que je ne sais, si j'ai réussi dans l'utilisation de
cette commande et si j'ai modifié mes autorisations.
Retour en arrière, je peux effacer ce chapitre car j'ai trouvé la solution,
je le laisse en place pour bien faire voir comment on peut passer à coté
d'une solution et que persévérer est payant : Entrer dans l'invite de
commande ceux qui seront autorisés, par exemple :
« cacls %windir%registration /G system :F invité :F administrateur :F
Propriétaire :F » et OK
Pour contrôler ce qui est existe réellement dans la liste de contrôle (ACL)
taper simplement « cacls c:windowsregistration » et OK . La liste des
autorisations apparaît, c'est donc facile à contrôler.
En recherchant toujours plus loin, j'ai trouvé quelques nouveaux éléments se
rapportant à ce problème de droit d'accès. Il en ressort qu'il faut
intervenir sur les SID (sécurity identifies) ce sont les numéros uniques de
chaque compte créé lors de l'installation de windows, je simplifie bien
entendu, n° qui a l'allure suivante : S-1-5-21-nnnnn...-...
Grâce à vous, Jean-François et Ypoons, je sais comment voir ces SID dans le
registre et de quelle manière il existe un lien entre le nom de connexion
(nom externe) et le SID. Je pense avoir trouvé où se situait mon problème et
comment le résoudre. Pour retrouver un SID il faut utiliser un petit
programme « Obj|Sid » que l'on trouve à l'URL :
htpp://www.petri.co.il/obj_sid.htm, c'est une archive ZIP nommée objsid.exe,
on décompresse et on clic sur objsid.exe. Une fenêtre s'ouvre où l'on peut
trouver le SID en entrant le nom de connexion dans « Enter object » ou le nom
de connexion en entrant le SID dans « Inter SID » et en cliquant sur le
bouton « Check ».
En cherchant mes SID avec ce logiciel, j'ai entré Propriétaire,
Administrateur, Invité, nom de l'ordinateur, mon nom, etc., si le nom entré
n'existe pas il est annoncé que : Le mappage entre les noms de compte et les
ID de sécurité n'a pas été effectué, ce qui élimine tout intrus.
J'ai trouvé un SID pour Administrateur, Propriétaire, Georges Remion, et
Invité. Tous les SID autres que ceux de la forme S-1-5-21-...-...-...ne sont
pas à prendre en considération dans le cas présent, par exemple les SID de
valeur constante tels : créateur, utilisateurs, SYSTEM, invitéS, etc.
Ensuite il faut voir quels sont les SID en place dans le registre en allant
dans la branche HKEYLOCALMACHINESECURITYPolicyAccounts.
En ouvrant
Accounts tous les SID s'affichent du S-1-1-0 au S-1-5-32-547 en passant par
les SID qui nous intéressent les S-1-5-21-..-.. Là, j'ai relevé une
différence le SID « georges remion » n'apparaissait pas, seuls 3 SID
apparaissaient un SID « support », un SID « Propriétaire » et un SID « invité
», le SID georges remion n'était pas dans la liste, le SID support ne
m'appartenait pas et le SID invité ne pouvait être actif puisque désactivé du
compte utilisateurs.
Ces SID venaient d'une précédente installation qui se trouvait inactivé du
fait de mon installation de réparation. Réparation entraînant la perte de mes
droits lorsque dossiers et fichiers étaient sous contrôle de « georges remion
Administrateur », et acceptés lorsque ceux-ci étaient sous contrôle de «
georges remion Propriétaire ».
Le lien entre le nom de connexion, nom interne et le SID est défini de la
façon suivante : Dans la branche
HKEY-MACHINE-SAMSAMDomainsAccountsUsersNames
on trouve autant de
sous-clefs qu'il y a de comptes et le nom de chaque sous-clefs étant le nom
de connexion.
Ainsi les sous-clefs de Names représentent les utilisateurs de l'ordinateur,
dans mon cas on trouvait : Administrateur, georges remion, Help assistant,
invité, Propriétaire et Support.
En sélectionnant le nom d'un utilisateur on remarque que la clef ne contient
qu'une valeur par défaut, de données binaires de longueur nulle, mais
caractérisée par un type particulier que je n'avais jamais rencontré, et
représenté par une valeur hexadécimale. Par exemple pour mon nom
d'utilisateur « georges remion j'obtenais :
Nom Type Données
« (par défaut) 0x3f2 (valeur binaire de longueur zéro)
cette valeur 0x3f2 est égale à 1010 en décimale et ce nombre doit se
retrouver à la fin du SID « remion georges » (SID inexistant dans
HKLMSecurityPoliceAccount comme indiqué précédemment )
En cliquant « user » on développe les sous clefs aux valeurs hexadécimales et
en ouvrant la sous clef 0x3f2
on trouvera à droite une entrée binaire de nom « V »
qui contient toutes les informations sur le compte et en particulier le
SID correspondant. Cliquer V, Modifier pour faire apparaître la fenêtre «
Modification de la valeur » dans laquelle la valeur décimale indique le nom
de l'utilisateur.
La note que j'utilise ici confirme que lorsque l'on réinstalle windows ou que
l'on transporte un disque même si on crée un compte ayant le même nom que
précédemment, le SID associé sera différent. C'est mon cas et bien que
georges remion soit le nom du compte dans les deux cas il n'est pas reconnu
dans cette nouvelle configuration. Le SID « Administrateur » de la version 2
est différent du SID « Administrateur » de la version 1 et tous les dossiers,
fichiers accessibles à « Administrateur »(V1) sera refusé à « Administrateur
» (V2).
Par chance, mon SID « Propriétaire » étant reconnu dans les deux versions, je
conservais le droit de modifier les « Permissions » donc les droits de «
l'Administrateur »
l'inverse est également vrai, si j'ai tout compris, ce
n'est pas si simple pour un amateur.
J'ai donc supprimé le SID
« remion georges [nom de l'ordinateur] remion georges »
et confirmé le SID
« remion georges [nom de l'ordinateur] administrateur »
Depuis tout est OK la mise à jour, KB902400, objet de cette longue recherche,
s'installe sans plus créer de problème de droits d'accès.
Pour terminer, je dirais que je ne suis pas absolument certain qu'il faille
modifier les SID pour modifier les droits
et que la mise à jour de l'ACL (liste de contrôle d'accès des fichiers)
ne soit pas seule suffisante pour cette réalisation
mais obtenir l'onglet « SECURITE » lorsque l'on clique sur
« Propriété » est absolument nécessaire.
A tous bonsoir, à vous lire,
Salutations amicales.
Jean-François et Ypoons je vais être long sans doute trop long,
mais cela vous remerciera de m'avoir aidé et soutenu.
Je pense avoir réussi, Microsoft m'a fait un mail et conseillé de suivre les
prescriptions de la KB 909444/fr
qui explique pourquoi il arrive que l'on perde ses DROITS D'ACCES à certains
dossiers et fichiers.
(n'oublier pas, si
vous êtes dans mon cas et que vous suiviez cette « story » depuis le début,
qu'il est nécessaire de prendre connaissance des instructions données dans
les KB que Jean-François m'indiquait le 12 juin dernier aux adresses
suivantes)
www.bellamyjc.org/fr/windowsxp2003.html#securitytab
www.bellamyjc.org/fr/windowsnt.html#pbaccesfichiers
En gros, cette note dit, que les systèmes ayant modifiés les autorisations
de la liste de contrôle d'accès par défaut, du répertoire
%windir%registration, peuvent rencontrer différents problèmes après
l'installation de bulletin de sécurité Microsoft telle que la mise à jour
critique décrite dans le bulletin de sécurité Microsoft MS05-051. Ceci peut
se produire lorsque l'on a effectué une installation de réparation de Windows
(NT, 2000, XP.) même si l'utilisateur fait partie du groupe des
administrateurs. Cela peut se manifester également en cas de transfert d'un
disque dur d'une machine vers une autre.
Les évènements suivants, enregistrées dans le journal système, sont concernés
par cette note:
ID des événements 512, 4609, 778, 4689, 10010. Pour chaque événement cité une
description satisfaisante du problème est présentée.
Dans mon cas, l'ID de l'évènement était le 4609 et il se rapportait à
l'erreur produite après la mise en place de la mise à jour de sécurité
902400. La fameuse 80070005.
Pour bien montrer que la Kb 909444/fr. est bien adaptée voilà ce qui est
précisé dans l'ID de l'événement 4609 : Type d'événement : Erreur ; Source de
l'événement : EventSystem ; ID de l'événement : 4609; Catégorie de
l'événement (50); Date ; Heure; Utilisateur N/A; Ordinateur
:serveur :
Description :
Le système d'événement de COM+ a détecté un code de renvoi
erroné lors de son traitement interne. Le HRESULT est 80070005 à partir de la
ligne xx de d:qxq_sipcomcom1xsrceventstier1eventsystemobj.cpp.
Dans les symptômes décrits dans la note KB 909444/fr. il est précisé que le
service windows Firewall peut ne pas démarrer, (c'était mon cas), Le service
Microsoft COM+ EventSystem ne démarre pas et le noeud ordinateur de
l'arborescence de la console MMC de Microsoft component Service ne se
développe pas. (contrôle WMI, gestion Windows impossible et gestion des
disques durs non accessible).
J'ai donc appliqué les instructions données pour résoudre ce problème
espérant ainsi retrouver les droits d'accès qui me faisaient défaut. Hélas
sans aucun succès, Tout semblait, en principe, satisfaisant et pourtant
l'installation de KB 902400 provoquait toujours les mêmes difficultés. Accès
limités ou refusés pour certains fichiers.
Je précise qu'il faut avoir accès au bouton « sécurité » qui apparaît dans
l'onglet« propriété » des dossiers ou fichiers sélectionnés, il est donc
nécessaire d'installer le fichier scesp4i.exe que l'on téléchargera à
htpp://download.microsoft.com/msdowunload/sp4/x86/en/scesp4i.exe
Il ne faut pas exécuter directement le fichier scesp4i.exe mais le
décompresser dans un dossier et cliquer droit sur le fichier SETUP.INF de
9ko et sélectionner « installer ». L'installation a lieu par copie de fichier
dans le répertoire system32 de windows.
En cliquant sur l'onglet propriété de tous les fichiers et dossiers de toutes
les partitions NTFS on fait apparaître l'onglet « sécurité » qui donne accès
à la rubrique « autorisations » de qui permet de modifier les droits
d'utilisateurs, Administrateurs, propriétaires, invités et system.
Pour plus de détail consulter WindowsXP/2003 de Microsoft, rubrique « onglet
de sécurité » paragraphe « (non) affichage sous XP Home ».
Dans cette note, la KB 909444/fr, il est dit que le system peut créer
ultérieurement des fichiers .clb supplémentaires dans le dossier
%windir%/registration et que l'on peut utiliser le fichier Cacls.exe pour
automatiser ces modifications d'autorisations sur la machine concernée.
Là, je suis un peu dépassé et c'est peut être ce qui me manque pour sortir de
cette impasse, je lance bien la commande « cacls » dans l'invite de commande
ainsi que les paramètres qui sont indiqués dans l'aide, mais sans obtenir de
réponse, ce qui fait que je ne sais, si j'ai réussi dans l'utilisation de
cette commande et si j'ai modifié mes autorisations.
Retour en arrière, je peux effacer ce chapitre car j'ai trouvé la solution,
je le laisse en place pour bien faire voir comment on peut passer à coté
d'une solution et que persévérer est payant : Entrer dans l'invite de
commande ceux qui seront autorisés, par exemple :
« cacls %windir%registration /G system :F invité :F administrateur :F
Propriétaire :F » et OK
Pour contrôler ce qui est existe réellement dans la liste de contrôle (ACL)
taper simplement « cacls c:windowsregistration » et OK . La liste des
autorisations apparaît, c'est donc facile à contrôler.
En recherchant toujours plus loin, j'ai trouvé quelques nouveaux éléments se
rapportant à ce problème de droit d'accès. Il en ressort qu'il faut
intervenir sur les SID (sécurity identifies) ce sont les numéros uniques de
chaque compte créé lors de l'installation de windows, je simplifie bien
entendu, n° qui a l'allure suivante : S-1-5-21-nnnnn...-...
Grâce à vous, Jean-François et Ypoons, je sais comment voir ces SID dans le
registre et de quelle manière il existe un lien entre le nom de connexion
(nom externe) et le SID. Je pense avoir trouvé où se situait mon problème et
comment le résoudre. Pour retrouver un SID il faut utiliser un petit
programme « Obj|Sid » que l'on trouve à l'URL :
htpp://www.petri.co.il/obj_sid.htm, c'est une archive ZIP nommée objsid.exe,
on décompresse et on clic sur objsid.exe. Une fenêtre s'ouvre où l'on peut
trouver le SID en entrant le nom de connexion dans « Enter object » ou le nom
de connexion en entrant le SID dans « Inter SID » et en cliquant sur le
bouton « Check ».
En cherchant mes SID avec ce logiciel, j'ai entré Propriétaire,
Administrateur, Invité, nom de l'ordinateur, mon nom, etc., si le nom entré
n'existe pas il est annoncé que : Le mappage entre les noms de compte et les
ID de sécurité n'a pas été effectué, ce qui élimine tout intrus.
J'ai trouvé un SID pour Administrateur, Propriétaire, Georges Remion, et
Invité. Tous les SID autres que ceux de la forme S-1-5-21-...-...-...ne sont
pas à prendre en considération dans le cas présent, par exemple les SID de
valeur constante tels : créateur, utilisateurs, SYSTEM, invitéS, etc.
Ensuite il faut voir quels sont les SID en place dans le registre en allant
dans la branche HKEYLOCALMACHINESECURITYPolicyAccounts.
En ouvrant
Accounts tous les SID s'affichent du S-1-1-0 au S-1-5-32-547 en passant par
les SID qui nous intéressent les S-1-5-21-..-.. Là, j'ai relevé une
différence le SID « georges remion » n'apparaissait pas, seuls 3 SID
apparaissaient un SID « support », un SID « Propriétaire » et un SID « invité
», le SID georges remion n'était pas dans la liste, le SID support ne
m'appartenait pas et le SID invité ne pouvait être actif puisque désactivé du
compte utilisateurs.
Ces SID venaient d'une précédente installation qui se trouvait inactivé du
fait de mon installation de réparation. Réparation entraînant la perte de mes
droits lorsque dossiers et fichiers étaient sous contrôle de « georges remion
Administrateur », et acceptés lorsque ceux-ci étaient sous contrôle de «
georges remion Propriétaire ».
Le lien entre le nom de connexion, nom interne et le SID est défini de la
façon suivante : Dans la branche
HKEY-MACHINE-SAMSAMDomainsAccountsUsersNames
on trouve autant de
sous-clefs qu'il y a de comptes et le nom de chaque sous-clefs étant le nom
de connexion.
Ainsi les sous-clefs de Names représentent les utilisateurs de l'ordinateur,
dans mon cas on trouvait : Administrateur, georges remion, Help assistant,
invité, Propriétaire et Support.
En sélectionnant le nom d'un utilisateur on remarque que la clef ne contient
qu'une valeur par défaut, de données binaires de longueur nulle, mais
caractérisée par un type particulier que je n'avais jamais rencontré, et
représenté par une valeur hexadécimale. Par exemple pour mon nom
d'utilisateur « georges remion j'obtenais :
Nom Type Données
« (par défaut) 0x3f2 (valeur binaire de longueur zéro)
cette valeur 0x3f2 est égale à 1010 en décimale et ce nombre doit se
retrouver à la fin du SID « remion georges » (SID inexistant dans
HKLMSecurityPoliceAccount comme indiqué précédemment )
En cliquant « user » on développe les sous clefs aux valeurs hexadécimales et
en ouvrant la sous clef 0x3f2
on trouvera à droite une entrée binaire de nom « V »
qui contient toutes les informations sur le compte et en particulier le
SID correspondant. Cliquer V, Modifier pour faire apparaître la fenêtre «
Modification de la valeur » dans laquelle la valeur décimale indique le nom
de l'utilisateur.
La note que j'utilise ici confirme que lorsque l'on réinstalle windows ou que
l'on transporte un disque même si on crée un compte ayant le même nom que
précédemment, le SID associé sera différent. C'est mon cas et bien que
georges remion soit le nom du compte dans les deux cas il n'est pas reconnu
dans cette nouvelle configuration. Le SID « Administrateur » de la version 2
est différent du SID « Administrateur » de la version 1 et tous les dossiers,
fichiers accessibles à « Administrateur »(V1) sera refusé à « Administrateur
» (V2).
Par chance, mon SID « Propriétaire » étant reconnu dans les deux versions, je
conservais le droit de modifier les « Permissions » donc les droits de «
l'Administrateur »
l'inverse est également vrai, si j'ai tout compris, ce
n'est pas si simple pour un amateur.
J'ai donc supprimé le SID
« remion georges [nom de l'ordinateur] remion georges »
et confirmé le SID
« remion georges [nom de l'ordinateur] administrateur »
Depuis tout est OK la mise à jour, KB902400, objet de cette longue recherche,
s'installe sans plus créer de problème de droits d'accès.
Pour terminer, je dirais que je ne suis pas absolument certain qu'il faille
modifier les SID pour modifier les droits
et que la mise à jour de l'ACL (liste de contrôle d'accès des fichiers)
ne soit pas seule suffisante pour cette réalisation
mais obtenir l'onglet « SECURITE » lorsque l'on clique sur
« Propriété » est absolument nécessaire.
A tous bonsoir, à vous lire,
Salutations amicales.
Jean-François et Ypoons je vais être long sans doute trop long,
mais cela vous remerciera de m'avoir aidé et soutenu.
Je pense avoir réussi, Microsoft m'a fait un mail et conseillé de suivre les
prescriptions de la KB 909444/fr
qui explique pourquoi il arrive que l'on perde ses DROITS D'ACCES à certains
dossiers et fichiers.
(n'oublier pas, si
vous êtes dans mon cas et que vous suiviez cette « story » depuis le début,
qu'il est nécessaire de prendre connaissance des instructions données dans
les KB que Jean-François m'indiquait le 12 juin dernier aux adresses
suivantes)
www.bellamyjc.org/fr/windowsxp2003.html#securitytab
www.bellamyjc.org/fr/windowsnt.html#pbaccesfichiers
En gros, cette note dit, que les systèmes ayant modifiés les autorisations
de la liste de contrôle d'accès par défaut, du répertoire
%windir%registration, peuvent rencontrer différents problèmes après
l'installation de bulletin de sécurité Microsoft telle que la mise à jour
critique décrite dans le bulletin de sécurité Microsoft MS05-051. Ceci peut
se produire lorsque l'on a effectué une installation de réparation de Windows
(NT, 2000, XP.) même si l'utilisateur fait partie du groupe des
administrateurs. Cela peut se manifester également en cas de transfert d'un
disque dur d'une machine vers une autre.
Les évènements suivants, enregistrées dans le journal système, sont concernés
par cette note:
ID des événements 512, 4609, 778, 4689, 10010. Pour chaque événement cité une
description satisfaisante du problème est présentée.
Dans mon cas, l'ID de l'évènement était le 4609 et il se rapportait à
l'erreur produite après la mise en place de la mise à jour de sécurité
902400. La fameuse 80070005.
Pour bien montrer que la Kb 909444/fr. est bien adaptée voilà ce qui est
précisé dans l'ID de l'événement 4609 : Type d'événement : Erreur ; Source de
l'événement : EventSystem ; ID de l'événement : 4609; Catégorie de
l'événement (50); Date ; Heure; Utilisateur N/A; Ordinateur
:serveur :
Description :
Le système d'événement de COM+ a détecté un code de renvoi
erroné lors de son traitement interne. Le HRESULT est 80070005 à partir de la
ligne xx de d:qxq_sipcomcom1xsrceventstier1eventsystemobj.cpp.
Dans les symptômes décrits dans la note KB 909444/fr. il est précisé que le
service windows Firewall peut ne pas démarrer, (c'était mon cas), Le service
Microsoft COM+ EventSystem ne démarre pas et le noeud ordinateur de
l'arborescence de la console MMC de Microsoft component Service ne se
développe pas. (contrôle WMI, gestion Windows impossible et gestion des
disques durs non accessible).
J'ai donc appliqué les instructions données pour résoudre ce problème
espérant ainsi retrouver les droits d'accès qui me faisaient défaut. Hélas
sans aucun succès, Tout semblait, en principe, satisfaisant et pourtant
l'installation de KB 902400 provoquait toujours les mêmes difficultés. Accès
limités ou refusés pour certains fichiers.
Je précise qu'il faut avoir accès au bouton « sécurité » qui apparaît dans
l'onglet« propriété » des dossiers ou fichiers sélectionnés, il est donc
nécessaire d'installer le fichier scesp4i.exe que l'on téléchargera à
htpp://download.microsoft.com/msdowunload/sp4/x86/en/scesp4i.exe
Il ne faut pas exécuter directement le fichier scesp4i.exe mais le
décompresser dans un dossier et cliquer droit sur le fichier SETUP.INF de
9ko et sélectionner « installer ». L'installation a lieu par copie de fichier
dans le répertoire system32 de windows.
En cliquant sur l'onglet propriété de tous les fichiers et dossiers de toutes
les partitions NTFS on fait apparaître l'onglet « sécurité » qui donne accès
à la rubrique « autorisations » de qui permet de modifier les droits
d'utilisateurs, Administrateurs, propriétaires, invités et system.
Pour plus de détail consulter WindowsXP/2003 de Microsoft, rubrique « onglet
de sécurité » paragraphe « (non) affichage sous XP Home ».
Dans cette note, la KB 909444/fr, il est dit que le system peut créer
ultérieurement des fichiers .clb supplémentaires dans le dossier
%windir%/registration et que l'on peut utiliser le fichier Cacls.exe pour
automatiser ces modifications d'autorisations sur la machine concernée.
Là, je suis un peu dépassé et c'est peut être ce qui me manque pour sortir de
cette impasse, je lance bien la commande « cacls » dans l'invite de commande
ainsi que les paramètres qui sont indiqués dans l'aide, mais sans obtenir de
réponse, ce qui fait que je ne sais, si j'ai réussi dans l'utilisation de
cette commande et si j'ai modifié mes autorisations.
Retour en arrière, je peux effacer ce chapitre car j'ai trouvé la solution,
je le laisse en place pour bien faire voir comment on peut passer à coté
d'une solution et que persévérer est payant : Entrer dans l'invite de
commande ceux qui seront autorisés, par exemple :
« cacls %windir%registration /G system :F invité :F administrateur :F
Propriétaire :F » et OK
Pour contrôler ce qui est existe réellement dans la liste de contrôle (ACL)
taper simplement « cacls c:windowsregistration » et OK . La liste des
autorisations apparaît, c'est donc facile à contrôler.
En recherchant toujours plus loin, j'ai trouvé quelques nouveaux éléments se
rapportant à ce problème de droit d'accès. Il en ressort qu'il faut
intervenir sur les SID (sécurity identifies) ce sont les numéros uniques de
chaque compte créé lors de l'installation de windows, je simplifie bien
entendu, n° qui a l'allure suivante : S-1-5-21-nnnnn...-...
Grâce à vous, Jean-François et Ypoons, je sais comment voir ces SID dans le
registre et de quelle manière il existe un lien entre le nom de connexion
(nom externe) et le SID. Je pense avoir trouvé où se situait mon problème et
comment le résoudre. Pour retrouver un SID il faut utiliser un petit
programme « Obj|Sid » que l'on trouve à l'URL :
htpp://www.petri.co.il/obj_sid.htm, c'est une archive ZIP nommée objsid.exe,
on décompresse et on clic sur objsid.exe. Une fenêtre s'ouvre où l'on peut
trouver le SID en entrant le nom de connexion dans « Enter object » ou le nom
de connexion en entrant le SID dans « Inter SID » et en cliquant sur le
bouton « Check ».
En cherchant mes SID avec ce logiciel, j'ai entré Propriétaire,
Administrateur, Invité, nom de l'ordinateur, mon nom, etc., si le nom entré
n'existe pas il est annoncé que : Le mappage entre les noms de compte et les
ID de sécurité n'a pas été effectué, ce qui élimine tout intrus.
J'ai trouvé un SID pour Administrateur, Propriétaire, Georges Remion, et
Invité. Tous les SID autres que ceux de la forme S-1-5-21-...-...-...ne sont
pas à prendre en considération dans le cas présent, par exemple les SID de
valeur constante tels : créateur, utilisateurs, SYSTEM, invitéS, etc.
Ensuite il faut voir quels sont les SID en place dans le registre en allant
dans la branche HKEYLOCALMACHINESECURITYPolicyAccounts.
En ouvrant
Accounts tous les SID s'affichent du S-1-1-0 au S-1-5-32-547 en passant par
les SID qui nous intéressent les S-1-5-21-..-.. Là, j'ai relevé une
différence le SID « georges remion » n'apparaissait pas, seuls 3 SID
apparaissaient un SID « support », un SID « Propriétaire » et un SID « invité
», le SID georges remion n'était pas dans la liste, le SID support ne
m'appartenait pas et le SID invité ne pouvait être actif puisque désactivé du
compte utilisateurs.
Ces SID venaient d'une précédente installation qui se trouvait inactivé du
fait de mon installation de réparation. Réparation entraînant la perte de mes
droits lorsque dossiers et fichiers étaient sous contrôle de « georges remion
Administrateur », et acceptés lorsque ceux-ci étaient sous contrôle de «
georges remion Propriétaire ».
Le lien entre le nom de connexion, nom interne et le SID est défini de la
façon suivante : Dans la branche
HKEY-MACHINE-SAMSAMDomainsAccountsUsersNames
on trouve autant de
sous-clefs qu'il y a de comptes et le nom de chaque sous-clefs étant le nom
de connexion.
Ainsi les sous-clefs de Names représentent les utilisateurs de l'ordinateur,
dans mon cas on trouvait : Administrateur, georges remion, Help assistant,
invité, Propriétaire et Support.
En sélectionnant le nom d'un utilisateur on remarque que la clef ne contient
qu'une valeur par défaut, de données binaires de longueur nulle, mais
caractérisée par un type particulier que je n'avais jamais rencontré, et
représenté par une valeur hexadécimale. Par exemple pour mon nom
d'utilisateur « georges remion j'obtenais :
Nom Type Données
« (par défaut) 0x3f2 (valeur binaire de longueur zéro)
cette valeur 0x3f2 est égale à 1010 en décimale et ce nombre doit se
retrouver à la fin du SID « remion georges » (SID inexistant dans
HKLMSecurityPoliceAccount comme indiqué précédemment )
En cliquant « user » on développe les sous clefs aux valeurs hexadécimales et
en ouvrant la sous clef 0x3f2
on trouvera à droite une entrée binaire de nom « V »
qui contient toutes les informations sur le compte et en particulier le
SID correspondant. Cliquer V, Modifier pour faire apparaître la fenêtre «
Modification de la valeur » dans laquelle la valeur décimale indique le nom
de l'utilisateur.
La note que j'utilise ici confirme que lorsque l'on réinstalle windows ou que
l'on transporte un disque même si on crée un compte ayant le même nom que
précédemment, le SID associé sera différent. C'est mon cas et bien que
georges remion soit le nom du compte dans les deux cas il n'est pas reconnu
dans cette nouvelle configuration. Le SID « Administrateur » de la version 2
est différent du SID « Administrateur » de la version 1 et tous les dossiers,
fichiers accessibles à « Administrateur »(V1) sera refusé à « Administrateur
» (V2).
Par chance, mon SID « Propriétaire » étant reconnu dans les deux versions, je
conservais le droit de modifier les « Permissions » donc les droits de «
l'Administrateur »
l'inverse est également vrai, si j'ai tout compris, ce
n'est pas si simple pour un amateur.
J'ai donc supprimé le SID
« remion georges [nom de l'ordinateur] remion georges »
et confirmé le SID
« remion georges [nom de l'ordinateur] administrateur »
Depuis tout est OK la mise à jour, KB902400, objet de cette longue recherche,
s'installe sans plus créer de problème de droits d'accès.
Pour terminer, je dirais que je ne suis pas absolument certain qu'il faille
modifier les SID pour modifier les droits
et que la mise à jour de l'ACL (liste de contrôle d'accès des fichiers)
ne soit pas seule suffisante pour cette réalisation
mais obtenir l'onglet « SECURITE » lorsque l'on clique sur
« Propriété » est absolument nécessaire.
A tous bonsoir, à vous lire,
Salutations amicales.
*Bonjour Ypoons* !
[...]
PSEXEC
www.microsoft.com/france/technet/sysinternals/default.mspx
www.microsoft.com/france/technet/sysinternals/processesandthreads/psexec.mspx
Paragraphe ==> Exemples :
...
Exécutez Regedit de manière interactive dans le compte System pour
afficher le contenu des touches SAM et SECURITY :
psexec -i -d -s c:windowsregedit.exe
À samedi.
*Bonjour Ypoons* !
[...]
PSEXEC
www.microsoft.com/france/technet/sysinternals/default.mspx
www.microsoft.com/france/technet/sysinternals/processesandthreads/psexec.mspx
Paragraphe ==> Exemples :
...
Exécutez Regedit de manière interactive dans le compte System pour
afficher le contenu des touches SAM et SECURITY :
psexec -i -d -s c:windowsregedit.exe
À samedi.
*Bonjour Ypoons* !
[...]
PSEXEC
www.microsoft.com/france/technet/sysinternals/default.mspx
www.microsoft.com/france/technet/sysinternals/processesandthreads/psexec.mspx
Paragraphe ==> Exemples :
...
Exécutez Regedit de manière interactive dans le compte System pour
afficher le contenu des touches SAM et SECURITY :
psexec -i -d -s c:windowsregedit.exe
À samedi.
Jean_François , Ypoons bonjour,
Une copie d'écran de mon registre en ce qui concerne les sousclefs de
HKLMSAMSAM.
J'ai bien contrôlé que cette image soit pure et j'espère ne pas commettre
une erreur en vous adressant une PJ.
En ce qui concerne la manière utilisée pour voir ces clefs je ne peux pas
dire grand chose, ou alors aux innocents ...vous connaissez la suite!
Ce que je peux préciser c'est que j'ai, à un moment donné, été dans
l'obligation de reconstruire mon registre, enfin une partie du registre qui
étant corrompue empêchait le bureau de s'installer, et quelque soit la
configuration, avec la console de récupération comme en mode sans échec.
J'ai pour faire cela utiliser le bouquin de Jean-Noël Anderruthy nommé "Le
registre de Windows XP" paru chez MICRO Application. Il est certain que je
suis allé plus loin que ce que je connaissait de Windows XP car en
retrouvant mon registre et, de ce fait, l'affichage j'ai observé que
j'accédais à des fichiers que je ne connaissais pas mais, cela ne veut pas
dire que c'est exact car je n'avais jamais fouillé bien profondément le
registre et WindowsXP avant mon problème de droits d'accès.
Ce qui est certain, c'est que votre aide et vos directives (je veux bien
dire les directions vers lesquelles je devais aller selon vos indications)
m'ont fait progresser dans la compréhension de Windows mieux que l'ensemble
de ma bibliothèque.
Respects à vous deux.
Jean_François , Ypoons bonjour,
Une copie d'écran de mon registre en ce qui concerne les sousclefs de
HKLMSAMSAM.
J'ai bien contrôlé que cette image soit pure et j'espère ne pas commettre
une erreur en vous adressant une PJ.
En ce qui concerne la manière utilisée pour voir ces clefs je ne peux pas
dire grand chose, ou alors aux innocents ...vous connaissez la suite!
Ce que je peux préciser c'est que j'ai, à un moment donné, été dans
l'obligation de reconstruire mon registre, enfin une partie du registre qui
étant corrompue empêchait le bureau de s'installer, et quelque soit la
configuration, avec la console de récupération comme en mode sans échec.
J'ai pour faire cela utiliser le bouquin de Jean-Noël Anderruthy nommé "Le
registre de Windows XP" paru chez MICRO Application. Il est certain que je
suis allé plus loin que ce que je connaissait de Windows XP car en
retrouvant mon registre et, de ce fait, l'affichage j'ai observé que
j'accédais à des fichiers que je ne connaissais pas mais, cela ne veut pas
dire que c'est exact car je n'avais jamais fouillé bien profondément le
registre et WindowsXP avant mon problème de droits d'accès.
Ce qui est certain, c'est que votre aide et vos directives (je veux bien
dire les directions vers lesquelles je devais aller selon vos indications)
m'ont fait progresser dans la compréhension de Windows mieux que l'ensemble
de ma bibliothèque.
Respects à vous deux.
Jean_François , Ypoons bonjour,
Une copie d'écran de mon registre en ce qui concerne les sousclefs de
HKLMSAMSAM.
J'ai bien contrôlé que cette image soit pure et j'espère ne pas commettre
une erreur en vous adressant une PJ.
En ce qui concerne la manière utilisée pour voir ces clefs je ne peux pas
dire grand chose, ou alors aux innocents ...vous connaissez la suite!
Ce que je peux préciser c'est que j'ai, à un moment donné, été dans
l'obligation de reconstruire mon registre, enfin une partie du registre qui
étant corrompue empêchait le bureau de s'installer, et quelque soit la
configuration, avec la console de récupération comme en mode sans échec.
J'ai pour faire cela utiliser le bouquin de Jean-Noël Anderruthy nommé "Le
registre de Windows XP" paru chez MICRO Application. Il est certain que je
suis allé plus loin que ce que je connaissait de Windows XP car en
retrouvant mon registre et, de ce fait, l'affichage j'ai observé que
j'accédais à des fichiers que je ne connaissais pas mais, cela ne veut pas
dire que c'est exact car je n'avais jamais fouillé bien profondément le
registre et WindowsXP avant mon problème de droits d'accès.
Ce qui est certain, c'est que votre aide et vos directives (je veux bien
dire les directions vers lesquelles je devais aller selon vos indications)
m'ont fait progresser dans la compréhension de Windows mieux que l'ensemble
de ma bibliothèque.
Respects à vous deux.
En ce qui concerne les pièces jointes sur ce forum, elles ne sont pas
acceptées si elles dépassent 100 Ko (en fait un peu moins, il faut inclure
le "poids du message", mais je n'ai jamais fait de tests pour savoir la
limite exacte).
Quand on veut joindre une copie d'écran, on a le choix entre :
- faire un fichier de petite taille : JF sur son site explique comment
faire une capture d'écran, l'enregistrer sous Paint et l'enregistrer sous
un format "peu lourd" comme le format .png
Mais même ce format peut dépasser les capacités d'accueil des serveurs MS.
- "déposer" son image (ou n'importe quel fichier) sur un site qui servira
de "serveur temporaire". Il existe pas mal de sites qui permettent à un
particulier de faire ceci sans débourser le moindre sou. Chaque site a ses
limites propres (en particulier la durée de conservation du fichier sur le
site et la taille maxi des fichiers "déposés", mais ça peut aller jusqu'à
1 Go chez certains). Une fois le fichier transmis de ta machine vers le
site d'accueil, un lien est généré et affiché à l'écran (et parfois même
en plus copié dans ton presse-papiers). Il te suffit alors de coller le
lien dans un message, et l'internaute qui lit ton message pourra accéder à
la pièce jointe d'un simple clic.
http://fspsa.free.fr/copiecran.htm
Amicalement,
--
Ypoons [MVP]
Ne vous approchez jamais d'un ordinateur en disant ou même seulement
pensant "Je vais faire ça très vite !"
Pour m'écrire : http://www.cerbe rmail.com/?EEcGHSD8yU (enlever l'espace)
Ne me mettez pas dans votre carnet d'adresse ! Je suis spammé !
En ce qui concerne les pièces jointes sur ce forum, elles ne sont pas
acceptées si elles dépassent 100 Ko (en fait un peu moins, il faut inclure
le "poids du message", mais je n'ai jamais fait de tests pour savoir la
limite exacte).
Quand on veut joindre une copie d'écran, on a le choix entre :
- faire un fichier de petite taille : JF sur son site explique comment
faire une capture d'écran, l'enregistrer sous Paint et l'enregistrer sous
un format "peu lourd" comme le format .png
Mais même ce format peut dépasser les capacités d'accueil des serveurs MS.
- "déposer" son image (ou n'importe quel fichier) sur un site qui servira
de "serveur temporaire". Il existe pas mal de sites qui permettent à un
particulier de faire ceci sans débourser le moindre sou. Chaque site a ses
limites propres (en particulier la durée de conservation du fichier sur le
site et la taille maxi des fichiers "déposés", mais ça peut aller jusqu'à
1 Go chez certains). Une fois le fichier transmis de ta machine vers le
site d'accueil, un lien est généré et affiché à l'écran (et parfois même
en plus copié dans ton presse-papiers). Il te suffit alors de coller le
lien dans un message, et l'internaute qui lit ton message pourra accéder à
la pièce jointe d'un simple clic.
http://fspsa.free.fr/copiecran.htm
Amicalement,
--
Ypoons [MVP]
Ne vous approchez jamais d'un ordinateur en disant ou même seulement
pensant "Je vais faire ça très vite !"
Pour m'écrire : http://www.cerbe rmail.com/?EEcGHSD8yU (enlever l'espace)
Ne me mettez pas dans votre carnet d'adresse ! Je suis spammé !
En ce qui concerne les pièces jointes sur ce forum, elles ne sont pas
acceptées si elles dépassent 100 Ko (en fait un peu moins, il faut inclure
le "poids du message", mais je n'ai jamais fait de tests pour savoir la
limite exacte).
Quand on veut joindre une copie d'écran, on a le choix entre :
- faire un fichier de petite taille : JF sur son site explique comment
faire une capture d'écran, l'enregistrer sous Paint et l'enregistrer sous
un format "peu lourd" comme le format .png
Mais même ce format peut dépasser les capacités d'accueil des serveurs MS.
- "déposer" son image (ou n'importe quel fichier) sur un site qui servira
de "serveur temporaire". Il existe pas mal de sites qui permettent à un
particulier de faire ceci sans débourser le moindre sou. Chaque site a ses
limites propres (en particulier la durée de conservation du fichier sur le
site et la taille maxi des fichiers "déposés", mais ça peut aller jusqu'à
1 Go chez certains). Une fois le fichier transmis de ta machine vers le
site d'accueil, un lien est généré et affiché à l'écran (et parfois même
en plus copié dans ton presse-papiers). Il te suffit alors de coller le
lien dans un message, et l'internaute qui lit ton message pourra accéder à
la pièce jointe d'un simple clic.
http://fspsa.free.fr/copiecran.htm
Amicalement,
--
Ypoons [MVP]
Ne vous approchez jamais d'un ordinateur en disant ou même seulement
pensant "Je vais faire ça très vite !"
Pour m'écrire : http://www.cerbe rmail.com/?EEcGHSD8yU (enlever l'espace)
Ne me mettez pas dans votre carnet d'adresse ! Je suis spammé !
*Bonjour Ypoons* !
[...]
PSEXEC
www.microsoft.com/france/technet/sysinternals/default.mspx
www.microsoft.com/france/technet/sysinternals/processesandthreads/psexec.mspx
Paragraphe ==> Exemples :
...
Exécutez Regedit de manière interactive dans le compte System pour afficher
le contenu des touches SAM et SECURITY :
psexec -i -d -s c:windowsregedit.exe
À samedi.
Salut JF
Merci pour cette très intéressante information.
Mais de prime abord, comment as-tu su qu'il existait des clés "cachées" (à
part les infos données par JCB), et comment as-tu su quel outil permettait de
les voir ?
Je suppose que l'utilisateur lambda ne trouve pas l'information facilement ?
(et d'un certain côté, tant mieux !)
Et je suis comme toi : je me demande comment Georges a fait pour aller si
loin dans ses "trouvailles"...
Autre sujet que tu évoques dans ta réponse à Georges du 05/07 à 18:43, et
pour lequel il me *semble* qu'une coquille s'est glissée : en faisant une
"installation/réparation" de Windows telle que présentée dans la fiche
http://support.microsoft.com/?id15341 , les SID ne sont pas changés. En
tous cas, quand j'ai fait (pour test) cette opération sur ma machine, je n'ai
*rien* eu à récupérer au niveau des droits : l'ensemble de ma machine était
toujours accessible.
Il me *semble* toujours que les SID ne sont modifiés que si on fait une
nouvelle installation de Windows par-dessus lui-même (en écrasant l'ancienne,
comme on le faisait avec Win9x, mais il n'y avait aucun problème de droits à
l'époque car FAT32).
*Bonjour Ypoons* !
[...]
PSEXEC
www.microsoft.com/france/technet/sysinternals/default.mspx
www.microsoft.com/france/technet/sysinternals/processesandthreads/psexec.mspx
Paragraphe ==> Exemples :
...
Exécutez Regedit de manière interactive dans le compte System pour afficher
le contenu des touches SAM et SECURITY :
psexec -i -d -s c:windowsregedit.exe
À samedi.
Salut JF
Merci pour cette très intéressante information.
Mais de prime abord, comment as-tu su qu'il existait des clés "cachées" (à
part les infos données par JCB), et comment as-tu su quel outil permettait de
les voir ?
Je suppose que l'utilisateur lambda ne trouve pas l'information facilement ?
(et d'un certain côté, tant mieux !)
Et je suis comme toi : je me demande comment Georges a fait pour aller si
loin dans ses "trouvailles"...
Autre sujet que tu évoques dans ta réponse à Georges du 05/07 à 18:43, et
pour lequel il me *semble* qu'une coquille s'est glissée : en faisant une
"installation/réparation" de Windows telle que présentée dans la fiche
http://support.microsoft.com/?id15341 , les SID ne sont pas changés. En
tous cas, quand j'ai fait (pour test) cette opération sur ma machine, je n'ai
*rien* eu à récupérer au niveau des droits : l'ensemble de ma machine était
toujours accessible.
Il me *semble* toujours que les SID ne sont modifiés que si on fait une
nouvelle installation de Windows par-dessus lui-même (en écrasant l'ancienne,
comme on le faisait avec Win9x, mais il n'y avait aucun problème de droits à
l'époque car FAT32).
*Bonjour Ypoons* !
[...]
PSEXEC
www.microsoft.com/france/technet/sysinternals/default.mspx
www.microsoft.com/france/technet/sysinternals/processesandthreads/psexec.mspx
Paragraphe ==> Exemples :
...
Exécutez Regedit de manière interactive dans le compte System pour afficher
le contenu des touches SAM et SECURITY :
psexec -i -d -s c:windowsregedit.exe
À samedi.
Salut JF
Merci pour cette très intéressante information.
Mais de prime abord, comment as-tu su qu'il existait des clés "cachées" (à
part les infos données par JCB), et comment as-tu su quel outil permettait de
les voir ?
Je suppose que l'utilisateur lambda ne trouve pas l'information facilement ?
(et d'un certain côté, tant mieux !)
Et je suis comme toi : je me demande comment Georges a fait pour aller si
loin dans ses "trouvailles"...
Autre sujet que tu évoques dans ta réponse à Georges du 05/07 à 18:43, et
pour lequel il me *semble* qu'une coquille s'est glissée : en faisant une
"installation/réparation" de Windows telle que présentée dans la fiche
http://support.microsoft.com/?id15341 , les SID ne sont pas changés. En
tous cas, quand j'ai fait (pour test) cette opération sur ma machine, je n'ai
*rien* eu à récupérer au niveau des droits : l'ensemble de ma machine était
toujours accessible.
Il me *semble* toujours que les SID ne sont modifiés que si on fait une
nouvelle installation de Windows par-dessus lui-même (en écrasant l'ancienne,
comme on le faisait avec Win9x, mais il n'y avait aucun problème de droits à
l'époque car FAT32).
*Bonjour Ypoons, bonjour Georges* !
[...]
Ce que j'ai écrit est un copié-collé de la page de PSEXEC, et JCB a déjà
effectivement parlé de ces clés. À une époque j'avais une clé
inaccessible dans le Registre. J'avais pu y accéder avec la disquette
Nordhal. Suite à cette expérience je ne pouvais que m'intéresser à un
programme qui permettait de se faire passer pour SYSTEM.
Par ailleurs je fais avec Sysinternals comme avec Gratilog : je guette
les nouveautés et les mises à jour. De même pour le blog de Mark
Russinovich, par ex :
PsExec, User Account Control and Security Boundaries
http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx
[...]Autre sujet que tu évoques dans ta réponse à Georges du 05/07 à 18:43,
et pour lequel il me *semble* qu'une coquille s'est glissée : en
faisant une "installation/réparation" de Windows telle que présentée
dans la fiche http://support.microsoft.com/?id15341 , les SID ne
sont pas changés. En tous cas, quand j'ai fait (pour test) cette
opération sur ma machine, je n'ai *rien* eu à récupérer au niveau des
droits : l'ensemble de ma machine était toujours accessible.
Il me *semble* toujours que les SID ne sont modifiés que si on fait
une nouvelle installation de Windows par-dessus lui-même (en écrasant
l'ancienne, comme on le faisait avec Win9x, mais il n'y avait aucun
problème de droits à l'époque car FAT32).
Tu dois avoir raison mais il peut se passer tellement de choses
http://support.microsoft.com/kb/312369/fr
*Bonjour Ypoons, bonjour Georges* !
[...]
Ce que j'ai écrit est un copié-collé de la page de PSEXEC, et JCB a déjà
effectivement parlé de ces clés. À une époque j'avais une clé
inaccessible dans le Registre. J'avais pu y accéder avec la disquette
Nordhal. Suite à cette expérience je ne pouvais que m'intéresser à un
programme qui permettait de se faire passer pour SYSTEM.
Par ailleurs je fais avec Sysinternals comme avec Gratilog : je guette
les nouveautés et les mises à jour. De même pour le blog de Mark
Russinovich, par ex :
PsExec, User Account Control and Security Boundaries
http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx
[...]
Autre sujet que tu évoques dans ta réponse à Georges du 05/07 à 18:43,
et pour lequel il me *semble* qu'une coquille s'est glissée : en
faisant une "installation/réparation" de Windows telle que présentée
dans la fiche http://support.microsoft.com/?id15341 , les SID ne
sont pas changés. En tous cas, quand j'ai fait (pour test) cette
opération sur ma machine, je n'ai *rien* eu à récupérer au niveau des
droits : l'ensemble de ma machine était toujours accessible.
Il me *semble* toujours que les SID ne sont modifiés que si on fait
une nouvelle installation de Windows par-dessus lui-même (en écrasant
l'ancienne, comme on le faisait avec Win9x, mais il n'y avait aucun
problème de droits à l'époque car FAT32).
Tu dois avoir raison mais il peut se passer tellement de choses
http://support.microsoft.com/kb/312369/fr
*Bonjour Ypoons, bonjour Georges* !
[...]
Ce que j'ai écrit est un copié-collé de la page de PSEXEC, et JCB a déjà
effectivement parlé de ces clés. À une époque j'avais une clé
inaccessible dans le Registre. J'avais pu y accéder avec la disquette
Nordhal. Suite à cette expérience je ne pouvais que m'intéresser à un
programme qui permettait de se faire passer pour SYSTEM.
Par ailleurs je fais avec Sysinternals comme avec Gratilog : je guette
les nouveautés et les mises à jour. De même pour le blog de Mark
Russinovich, par ex :
PsExec, User Account Control and Security Boundaries
http://blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx
[...]Autre sujet que tu évoques dans ta réponse à Georges du 05/07 à 18:43,
et pour lequel il me *semble* qu'une coquille s'est glissée : en
faisant une "installation/réparation" de Windows telle que présentée
dans la fiche http://support.microsoft.com/?id15341 , les SID ne
sont pas changés. En tous cas, quand j'ai fait (pour test) cette
opération sur ma machine, je n'ai *rien* eu à récupérer au niveau des
droits : l'ensemble de ma machine était toujours accessible.
Il me *semble* toujours que les SID ne sont modifiés que si on fait
une nouvelle installation de Windows par-dessus lui-même (en écrasant
l'ancienne, comme on le faisait avec Win9x, mais il n'y avait aucun
problème de droits à l'époque car FAT32).
Tu dois avoir raison mais il peut se passer tellement de choses
http://support.microsoft.com/kb/312369/fr