L'onglet Sécurité bien connu des utilisateurs de xppro est absent sur xphome. Il est cependant disponible en mode sans échec pour tous les utilisateurs admin, et pas seulement pour le compte Administrateur intégré.
Comme il est normalement assez rare de devoir modifier la sécurité d'accès aux fichiers, le mode sans échec suffira dans la plupart des cas. Cependant l'absence de cet onglet est une gêne pour les habitués. Heureusement il est possible de forcer son affichage et ne plus avoir à redémarrer en mode sans échec pour pouvoir l'utiliser.
Si vous êtes débutant et que vous êtes amené à intervenir sur les propriétés NTFS de fichiers, vous vous contenterez sans doute de redémarrer en mode sans échec. Si, plus tard, l'onglet sécurité vous devient plus nécessaire, vous aurez la possibilité d'utiliser les informations ci-après pour travailler plus facilement.
Cette méthode permet, sur un ordinateur utilisant xphome, d'utiliser momentanément l'onglet Sécurité sans avoir à redémarrer en mode sans échec .
Registre :
Mode normal : pas de clé OPTION sous
SafeBoot :
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot
Mode sans échec : on constate la
présence d'une sous-clé OPTION. Elle contient une valeur OptionValue.
Cette
clé OPTION est supprimée en quittant le mode sans échec
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\OPTION\OptionValue=1
Pour ceux qui savent utiliser regedit.exe (WIN+R, regedit) il ne faudra que quelques secondes pour ajouter manuellement la clé Option et la valeur dword OptionValue pour obtenir l'onglet sécurité. Un batch à télécharger est proposé plus bas pour créer la clé et rendre disponible l'onglet de sécurité, puis de supprimer la clé, étape qu'il ne faut pas manquer.
Mode sans échec et OptionValue
La clé qui gère le mode sans échec (safe boot) est
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot
Lorsqu'on démarre en mode sans
échec une sous-clé "Option" est ajoutée. Cette sous-clé abrite alors une valeur
OptionValue=1
Cette valeur est testée par rshx32.dll lorqu'on affiche les
propriétés d'un fichier. Si Optionvalue=1 alors l'onglet Sécurité est affiché.
Comme la clé Option est supprimée en quittant le mode sans échec, le mode
normal de xphome ne peut afficher l'onglet de sécurité.
OptionValue et mode normal
La clé Option n'existe pas en mode
normal.
Si on crée \Option\OptionValue=1 en mode normal et qu'on affiche les
propriétés d'un fichier, le test effectué par rshx32.dll est positif et l'onglet
sécurité est disponible.
Mode normal : la clé OPTION n'existe pas :
Mode sans échec : OptionValue est activé, l'onglet sécurité est disponible :
- La casse est
sans importance
- OptionValue=0 suffit à revenir au mode normal mais il est
préférable de supprimer la clé OPTION pour éviter un effet de bord (voir
ci-dessous)
|
Le batch
onglet-securite.cmd crée la clef Option avec son contenu
OptionValue=1 Aperçu des commandes utilisées : Pour revenir au mode normal, il faut supprimer la clé OPTION.
@set key=HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option Plus d'infos sur la commande reg et ses paramètres en tapant reg /? dans une console de commandes (WIN+R, cmd) Après utilisation de l'onglet de sécurité, ne pas oublier de normaliser en supprimant la clé OPTION, sinon le compte intégré "Administrateur" sera affiché dans le panneau d'accueil même en mode normal. D'autres inconvénients seraient à venir du fait que le système se croirait alors en mode sans échec. Par exemple le service Spouler sera inutilisable et on ne pourra plus imprimer. Pour éviter cela, simplement poursuivre le batch onglet-securite.cmd jusqu'au bout. |
Cette méthode, exposée à fin de compréhension, donne un accès permanent à l'onglet de sécurité.
RSHX32.DLL est situé dans system32, il est responsable du non-affichage de
l'onglet.
La version de ce fichier est la même dans
xphome que dans xppro.
Le fichier est inscrit par défaut dans ces clés :
[HKEY_CLASSES_ROOT\CLSID\{1F2E5C40-9550-11CE-99D2-00AA006E086C}\InProcServer32]
@="rshx32.dll"
[HKEY_CLASSES_ROOT\CLSID\{F37C5810-4D3F-11d0-B4BF-00AA00BBB723}\InProcServer32]
@="rshx32.dll"
Quand on affiche les Propriétés d'un lecteur, d'un dossier, ou d'un fichier,
le système vérifie la valeur de
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option\OptionValue
Si OptionValue est absent ou différent de 1 alors l'onglet sécurité n'est pas
affiché.
En résumé la méthode consiste à faire en sorte que
la dll utilisée pointe OptionValue à un endroit différent de l'endroit officiel
(lequel ferait, comme on a vu, passer en pseudo mode sans échec). La dll pointera sur
cet emplacement, sans autre effet pour le système
:
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\OptionValue <=
valeur ignorée par le système à cet emplacement
HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Option\OptionValue
<= emplacement officiel de la valeur (pour rappel)
L'astuce consiste à créer une copie de la dll et la déclarer dans le registre pour qu'elle soit utilisée à la place de la dll officielle. On modifie cette nouvelle dll pour que OptionValue=1 soit trouvé à un autre endroit du registre, où cette valeur n'aura pas de signification pour le système. Le résultat sera que, OptionValue=1 étant trouvé, l'onglet sera affiché même en dehors du mode sans échec.
Pour modifier le fichier on utilise au choix un éditeur hexadécimal ou la
commande debug.
Voici un excellent éditeur hexadécimal gratuit :
hxd
Copier le fichier rshx32.dll et nommer la copie rshx32p.dll (j'ai choisi
d'ajouter la lettre p, comme plus).
Éditer rshx32p.dll avec
hxd et rechercher la suite d'octets
74 00
5C
00 4F
En ASCII, 74 est le code
hexadécimal pour la lettre t minuscule, et 4F est le code pour la lettre O
majuscule.
Le code 5C est celui du
signe \
dans la chaine S.a.f.e.B.o.o.t.\.O.p.t.i.o.n
Remplacer 5C par 00, ce qui raccourcira le chemin de la clé contenant la valeur
OptionValue.
La sous-clé Option étant ainsi isolée, la clé devient HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot
Vue de la recherche de la suite 74 00 5C 00 4F dans l'éditeur hexadécimal hxd :
Remplacement du code 5C par 00 :
On peut préférer procéder en lignes de commandes avec debug.
ATTENTION : quand on cherche la suite avec la commande S, le résultat peut-être
différent que ce qui est indiqué ici.
Remplacer 0B00 par le résultat observé chez vous :
C:\Documents and Settings\Propriétaire>cd\
C:\>cd windows\system32C:\WINDOWS\system32>copy rshx32.dll rshx32p.dll
1 fichier(s) copié(s).
C:\WINDOWS\system32>debug rshx32p.dll
-s 100 8000 74 00 5c 00 4F
0CA3:0B00
-e 0B00 74 00 00 00 4F
-w
Ecriture de 0A000 octets
-qC:\WINDOWS\system32>
Plus d'infos sur la commande debug en entrant : debug /?
Créer une valeur OptionValue=1 sous la clé SafeBoot. À cet endroit cette valeur ne signifie rien pour le système, il ne sera donc pas passé en mode sans échec. Par contre rshx32p.dll y trouvera bien Optionvalue=1 et l'affichage de l'onglet sécurité sera autorisé. Le batch présenté à la section suivante crée cet OptionValue en même temps que l'inscription dans le registre de rshx32p.dll
Il reste à inscrire le nouveau fichier c:\Windows\System32\rshx32p.dll dans
le registre, manuellement ou avec un fichier reg à fusionner.
Le batch
rshx32p-inscription.cmd crée la valeur OptionValue=1 sous la clé SafeBoot puis modifie
les deux clés concernées avec rshx32p.dll au lieu de rshx32.dll ==>
Normalement vous êtes content d'avoir l'onglet sécurité (ouéééé !). Mais après être intervenu sur une machine
qui ne vous appartient pas, il peut être demandé de revenir à l'état normal de
xphome, tout le monde n'est pas encore à l'aise avec ces notions, ou on peut
avoir envie que les enfants ne jouent pas avec ce nouvel outil. Pour masquer à nouveau l'onglet on pourrait se contenter de faire OptionValue=0,
mais cela masquerait aussi
l'onglet en mode sans échec !
Il faut revenir au standard en rétablissant
la rshx32.dll d'origine ==>
Revenir au système normal
En effet puisque c'est la dll modifiée qui est inscrite dans le registre, c'est
elle qui est utilisée et l'onglet ne serait plus affiché en mode sans échec.
Bien sûr il suffirait de remettre OptionValue=1 dans ce mode. Mais on risque de
ne pas s'en souvenir ce jour-là, ou bien l'utilisateur de la machine sur
laquelle on est intervenu ne sera pas au courant. Il est prudent de revenir à la
configuration standard en réinscrivant la dll originale avec la commande regsvr32 rshx32.dll
Avec cette commande, si OptionValue a été laissée à 1 il faut redémarrer la session. Le batch ci-après détaille les opérations et met en conformité les deux OptionValue. L'effet est ainsi immédiat, et pas besoin de relancer la session. Contenu du batch rshx32-officiel-reinscription.cmd :
On revient ainsi à une situation totalement clean.
Remarque : si on était en mode sans échec en appliquant ce batch il faut redémarrer.
rshx32p-inscription.cmd
vu précédemment permettra en un clic de faire revenir l'onglet.
Laisser rshx32p.dll dans system32 et ranger les deux batchs dans un dossier. La
prochaine fois que vous aurez à intervenir sur cette machine vous obtiendrez
l'onglet avec le batch pour utiliser rshx32p.dll, et vous rétablirez la
situation habituelle avec le batch pour rshx32.dll ou la commande regsvr32
rshx32.dll
Cette méthode popularisée par
Gilles Pion est très
répandue.
Elle consiste à ajouter un greffon prévu initialement pour Windows NT4 :
KB195227 : Windows NT Service Pack
4 Security Configuration Manager
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/tools/SCM/
Le
readme.1st explique que pour les plateformes X86 on télécharge
scesp4i.exe
==>
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/tools/SCM/scesp4i.exe
Exécuter scesp4i.exe permettra de décompresser les fichiers qu'il contient.
Le fichier d'installation setup.inf est une bonne source d'informations.
On trouvera dans mssce.cab le seul fichier qui nous intéresse vraiment :
rshx32_5.dll
Je l'indique pour montrer son mauvais fonctionnement.
Je conseille
l'installation manuelle ci-après, on comprend mieux ce qui se passe.
Habituellement on explique de faire l'installation de la façon suivante (en
images) :
Faire un clic droit sur setup.inf et choisir "Installation" dans le menu
contextuel.
Refuser le remplacement de esent.dll
lorsqu'il est proposé.
De toute façon la protection des fichiers systèmes de XP
protége contre ces remplacements
Essayez, pour voir, de renommer une dll
dans system32 ! Ça étonne quand on ne connnait pas ... le fichier est recréé
après quelques secondes.
Le refus du système de se voir remplacer ses dll est
inscrit dans l'observateur d'événements.
L'observateur d'événements révèle une installation bancale, deux fichiers sont trop anciens et ont été refusés :
Source de l'événement : Windows File Protection
Tentative de remplacement du fichier système protégé c:\windows\system32\esentprf.dll. Ce fichier a été restauré en utilisant sa version initiale pour maintenir la stabilité du système. La version du fichier incorrect est 5.5.1960.8, la version du fichier système actuel est 5.1.2600.0.
Tentative de remplacement du fichier système protégé c:\windows\system32\esentutl.exe. Ce fichier a été restauré en utilisant sa version initiale pour maintenir la stabilité du système. La version du fichier incorrect est 5.5.1960.8, la version du fichier système actuel est 5.1.2600.0.
Le résultat des courses est, pour ce qui est des fichiers, la simple addition du fichier rshx32_5.dll dans system32, puisque la protection des fichiers systèmes répare automatiquement toute remplacement non-autorisé, les deux dll qui accompagnaient rshx32_5.dll ont été supprimées (remplacées par les dll standards de XP). Pour ce qui est du registre, le fichier est inscrit de la façon qu'on a vue plus haut :
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{1F2E5C40-9550-11CE-99D2-00AA006E086C}\InProcServer32]
@="rshx32_5.dll"
[HKEY_CLASSES_ROOT\CLSID\{F37C5810-4D3F-11d0-B4BF-00AA00BBB723}\InProcServer32]
@="rshx32_5.dll"
Noter qu'à cet instant c'est cette dll qui sera utilisée aussi en mode sans échec. Si elle est foireuse, et c'est le cas, le mode sans échec n'est d'aucun secours, il faudra réinscrire la dll standard. Je dis ça parce que je vois souvent les gens penser que le mode sans échec est plus fort, qu'il a quelque chose de plus. Et ils expliquent que même l'administrateur intégré du mode sans échec n'arrive pas à leur redonner l'accès à un volume ...
Copier rshx32_5.dll depuis mssce.cab dans system32, puis inscrire le fichier dans le registre comme on vient de le voir. Il n'est même pas nécessaire de connaître ces clés, il suffit de faire une recherche (CTL+F) du mot rshx. L'avantage du procédé est qu'on comprend comment revenir à la normale en remplaçant rshx32_5.dll par rshx32.dll dans le registre. Cette possibilité n'avait jamais été indiquée, la KB195509 expliquant une façon peu élégante de procéder en manipulant les deux fichiers dans system32 au lieu de jouer sur l'enregistrement dans le registre.
Super, on a installé rshx32_5.dll qui ne vérifie pas OptionValue, on a donc
l'onglet sécurité en mode normal.
On devrait se méfier :
En général les utilisateurs de xphome ignorent tout de cet onglet, et du fait qu'il existe en mode sans échec. Suite à un petit problème d'accès NTFS une recherche dans les FAQ invite l'utilisateur à installer ce greffon. Une fois le problème réglé on constate alors que rien n'est prévu pour masquer ce nouvel onglet dans les propriétés des fichiers. La plupart des utilisateurs ne seront pas gênés pour si peu s'ils sont seuls utilisateurs de leur machine, d'autant plus qu'ils ignorent la présence du bug. Mais d'autres souhaiteront masquer cet onglet inhabituel sur xphome. Si vous intervenez chez un tiers des explications doivent être fournies sur le bug reproduit ci-dessous.
Il est absolument anormal qu'un module additionnel ne soit pas livré avec un moyen de désinstallation. Si vous intervenez sur une machine qui ne vous appartient pas, il n'est pas sain de laisser derrière soi une telle modification (sauf demande expresse, bien entendu). Elle est buguée, et elle corrompt l'onglet sécurité du mode sans échec qui utilise la même dll. À l'origine il était prévu de désinstaller la chose, voir la KB195509.
Si vous êtes sérieux, c'est ce que vous ferez pour retrouver l'onglet Sécurité d'origine (rshx32.dll de xp) du mode sans échec qui n'a pas les problèmes de propagation de ce greffon écrit pour NT4, bug reproduit ci-après :
Dans certains cas, l'utilisateur peut se retrouver avec un volume interdit d'accès et ne sait pas comment faire pour se récupérer. Tous ses efforts se soldent par "Accès refusé" et "Impossible d'enregistrer les modifications d'autorisation". Ceci n'est pas normal et n'est pas constaté avec le fichier rshx32.dll d'origine XP. Voici comment reproduire à volonté le bug :
Illustration du problème : soit un volume NTFS nommé TEST. Sa lettre est E.
L'onglet sécurité installé par le greffon NT4 indique :
Les Paramètres avancés indiquent le groupe Administrateurs comme Propriétaire
du lecteur ; tout va bien pour l'instant. Ça ne va pas durer.
Des utilisateurs ayant comme idée de limiter l'accès aux autres utilisateurs,
ont commencé par supprimer le groupe Administrateurs.
Vérification que les administrateurs n'ont plus accès :
Ça marche, il n'y a plus qu'à s'ajouter comme seul utilisateur de ce volume.
Mais la suite est catastrophique : impossible de s'ajouter comme utilisateur,
impossible de se rendre propriétaire (Paramètres avancés) :
Redémarrer en mode sans échec ne sert à rien, puisque c'est le rshx32_5.dll buggé qui continu à être utilisé depuis son enregistrement dans le registre.
L'utilisateur se sent fautif, il se dit qu'il ne fallait pas supprimer ainsi l'accès aux administrateurs. Or les administrateurs ont par définition tous les droits ! Sur XPPRO comme sur les autres systèmes cette manip n'a pas ces conséquences. Encore faut-il le savoir...
Les utilisateurs ont souvent dans l'idée que le mode sans échec peut réparer ce genre de situation, ils pensent qu'il y a un "super-administrateur". C'est faux. Cet Administrateur intégré est aussi touché par la modif du greffon NT4, et son onglet sécurité a les mêmes symptômes puisqu'il utilise à présent cette rsh32_5.dll qui a été enregistrée dans le registre à la place de la dll normale. Le piège est refermé.
Solution
Voir à la section Comment
désinstaller le greffon rshx32_5.dll de NT4 pour réinscrire le module normal
rshx32.dll de XP.
Le système étant réparé, l'onglet sécurité du mode sans
échec fonctionne à nouveau correctement et permet de rétablir la situation.
Astuce : pour éviter de redémarrer simuler le mode sans échec comme il a été vu
plus haut :
Créer la clé Safeboot\Option et y ajouter la valeur OptionValue,
en lui donnant momentanément la valeur 1 pour faire croire au système
qu'il est en mode sans échec.
C'est alors le véritable onglet sécurité XP qui est affiché, lequel fonctionne
parfaitement. On a de nouveau accès pour donner les droits au groupe SYSTEM et à
l'Utilisateur :
Ne pas oublier de supprimer la clé Option pour sortir de ce pseudo mode-sans-échec.
Il existe donc bien un bug avec ce greffon. Il s'exprime rarement, car il faut se mettre dans cette situation assez particulière. Mais ce n'est pas une raison pour l'ignorer, ce n'est pas la peine que des utilisateurs soient amenés à cette pénible situation.
Il est amusant de réfléchir à l'historique cet imbroglio. Microsoft a pensé qu'il fallait que les utilisateurs de xphome n'aient l'onglet sécurité qu'en mode sans échec. Cette décision, qui étonne les vieux routiers de Windows NT, vient sans doute du fait que les gens normaux avaient une expérience de Windows 98 et donc ignoraient tout de ces notions de permission (Note1). Il est probable que les essais ont montré que cette nouveauté provoquait des problèmes. On a donc limité son accès. Bon. Les utilisateurs chevronnés ont vite contourné cette restriction en installant cette rshx32_5.dll laissée par Microsoft à disposition sur ses serveurs. Grave erreur, avec la fausse bonne conscience que ce contournement est officiel puisque fourni par Microsoft. Lequel n'a certainement pas voulu cette utilisation détournée de cette dll prévue à l'origine pour NT, et dont l'installateur, comme on l'a vu, ne connait rien du système de protection des fichiers de XP, lequel s'oppose à la modification de deux fichiers prévus par le greffon NT4 lors de son installation.
Note1 : les mauvaises habitudes ont la vie dure quand on voit que sur une machine neuve le propriétaire se retrouve systématiquement installé en tant qu'administrateur.
Exemples
On trouve quelques
exemples sur le web, parfois résolus avec
takeown.exe qui
semble avoir été conçu pour. Certains comprennent que leurs difficultés sont
apparues depuis l'installation du greffon. Si c'est assez récent un retour à un
point de restauration est efficace. Si cela n'est pas possible, ils cherchent à
désinstaller le truc. Mais comme rien n'a été prévu...
Comment désinstaller le programme scesp4i.exe ? Car je ne peux plus aller sur le disque C:
J'ai niqué les permissions administrateur de toute une partition ...
Pour info ce cas s'est résolu encore une fois avec
takeown.exe
qui répare de façon transparente ce genre d'anicroche. Le problème c'est que
l'utilisation de cet outil masque la cause qui est le bug du greffon NT4.
L'idée se répand donc que "cela arrive" et qu'il existe un outil pour
réparer. Or c'est une idée fausse, cela n'arrive pas avec le mode sans échec
d'un XPHOME normal, non modifié avec ce greffon.
Si l'opération est récente, revenir à un point de restauration permet de réparer. Une sauvegarde du registre sera mise en place, et la modification consistant à inscrire la mauvaise dll sera supprimée.
Si l'opération n'est pas récente, il suffit de réinscrire rshx32.dll à la place de rshx32_5.dll dans le registre avec la commande :
regsvr32 rshx32.dll
Autre façon de procéder : fusionner au registre le fichier
rshx32_5.dll-desinstall.reg :
Pour fusionner le fichier au registre, double-cliquer le fichier téléchargé, et accepter l'opération, ou faire un clic droit, et Fusionner.
On peut aussi utiliser le batch http://fspsa.free.fr/rshx32-officiel-reinscription.cmd vu à la section "Revenir au mode normal et masquer l'onglet de sécurité".
Puisqu'il ne sera plus utilisé, on peut supprimer le fichier \windows\system32\rshx32_5.dll
Voici à présent quelques cas fréquents d'utilisation de l'onglet sécurité.
System Volume information (SVI) est un dossier
système et caché situé sur la racine des volumes.
Son rôle est, entre autres, le stockage des points de restauration, c'est pour
cela qu'il est protégé.
Seul le compte SYSTEM est déclaré, il n'est donc pas accessible même aux
administrateurs. Sauf modification.
Il faut donc pour y accéder donner une
autorisation d'accès à l'utilisateur ou au groupe auquel il appartient.
Restorwin et System Restore Manager
La seule raison pour
laquelle on aurait besoin de se balader dans le SVI, outre une légitime
curiosité, serait une nécessité de récupérer les ruches du registre. Ou alors
c'est qu'on est tellement en manque de place qu'on en est réduit à manager
manuellement quelques points de restauration. Les points de restauration ne sont pas indépendants, il est donc délicat d'en
supprimer un, on risque de rendre les autres inactifs. Ce problème de la gestion
fine des points de restauration est résolu sur XP avec
Restorwin,
et sur Vista et W7 avec
System Restore Manager de
www.thewindowsclub.com. Pour télécharger SRM.zip chercher "System
Restore Manager has been developed by".
Erunt
Concernant la sauvegarde des ruches du registre indépendamment
du système des points de restauration, on ne peut qu'encourager l'utilisation de
Erunt. Il fait double emploi avec
ce système mais il est une bien meilleure aide quand ça ne démarre plus à cause
du registre.
Maintenant qu'on sait activer l'onglet sécurité, il est facile d'accéder à ce dossier en s'ajoutant dans la liste des utilisateurs autorisés.
CACLS
Pour les amateurs de la ligne de commande, un simple petit coup de CACLS permet de régler les
permissions. Si on doit l'utiliser souvent faire au choix des raccourcis ou des
batchs avec les commandes suivantes (ici pour le disque C). La première ajoute
le groupe Administrateurs en lui attribuant toutes les permissions (F=Full), la
seconde retire le groupe Administrateurs pour revenir à la norme :
cacls "C:\System Volume Information" /E /G administrateurs:F
cacls "C:\System Volume Information" /E /R administrateurs
PSEXEC
Les aficionados sauront utiliser le très pratique
psexec (exemple) qui permet de
se faire passer pour le compte SYSTEM. Je l'utilise principalement en liaison
avec regedit ou
regshot pour observer
les contenus des clés SAM et SECURITY du Registre, lesquelles, à l'instar du
dossier SVI, ne sont pas accessibles même aux admins. L'avantage est qu'on ne modifie rien sur la machine.
Q-DIR
Cet excellent explorateur de fichiers, portable, a plusieurs cordes à son arc.
Pour ce qui nous intéresse ici, il permet d'explorer le SVI malgré la limitation
à SYSTEM. Si nécessaire, clic droit sur Q-DIR.exe et "Exécuter
en tant qu'administrateur". (exemple)
Le coup du partage à la xphome
Sur xphome, l'onglet sécurité étant normalement absent, partage réseau et
sécurité ont été réunis. Quand on fait un partage réseau le groupe "Tout le
monde" est ajouté aux permissions NTFS. Ces notions sont
séparées sur xppro sur lequel, après le partage réseau, il faudra définir les
autorisations d'accès NTFS aux fichiers, voir
Différences entre partages et permissions
Ces spécificités de xphome
font donc que l'accès au SVI se
fait en deux clics : il suffit de le partager !
Le système ajoute alors le
groupe "Tout le monde" dans la liste et le dossier devient accessible.
Noter
qu'il y a dans un premier temps une information "Accès refusé" lors du partage.
Lors du retour à la normale on découvre que le partage n'est plus affiché dans
les Propriétés.
Simplement recocher le partage (sans alerte cette fois-ci), Appliquer, décocher et OK, le partage sera
annulé, et le groupe "Tout le monde" retiré. Voici l'opération en
images :
Lors du partage, sur xphome, le groupe "Tout le monde" est ajouté :
Après une réparation avec le CD d'installation de XPHOME d'un système installé sur une partition NTFS, on a la surprise de ne plus avoir accès à ses fichiers. Il faut s'en rendre à nouveau propriétaire.
Rappel : la très efficace réparation de Windows à l'aide du CD d'installation consiste à réinstaller Windows XP par-dessus lui-même, sans perte de données. On trouve de nombreux tutos sur le web :
Réparation de Windows XP avec conservation des données :
http://support.microsoft.com/kb/315341/fr
http://www.astucesinternet.com/modules/news/article.php?storyid=262s
http://www.bellamyjc.org/fr/windows2000.html#repair
http://www.vista-xp.fr/forum/topic211.html
Remarque : ne pas confondre avec les procédures de restauration de la configuration usine prévues pour les PC de marques livrés avec Windows pré-installé (sans vrai CD d'installation Microsoft).
Suite à cette réinstallation on constate le refus d'accès à ses dossiers.
En
effet la procédure a changé le
SID du système, il est nécessaire de se redéclarer comme Propriétaire des dossiers.
Voir ces
explications détaillées, et
comment afficher l'onglet de sécurité sur xppro. La procédure se résume
ensuite à s'approprier
un fichier ou un dossier. Voici l'opération en deux images :
KB313222 :
Restaurer les paramètres de sécurité par défaut.
- Fixit valide de xphome à Vista. Utilisation détaillée de secedit.
- Secedit ne fait pas partie de xphome mais le fixit corrige cette lacune.
- Résultats dans c:\windows\Security\Logs\Scesrv.log
Utilisation de NTFS
pour protéger facilement l'accès à un fichier ou un dossier
Différences entre partages et permissions
http://www.hotline-pc.org/permissionsntfs.htm
http://fr.wikipedia.org/wiki/Access_Control_List
http://setacl.sourceforge.net/
http://fspsa.free.fr/chkdsk-5phases.htm#takeown
How to Use CACLS.EXE in a
Batch File
subinacl
http://fspsa.free.fr/mises-a-jour.htm
Chercheur en sécurité informatique, le métier où règne l'insécurité
Merci d'avoir lu jusqu'ici !
Retour au début
Les restes du site
JF
(Jean-François)
Publié le 29/10/2009
