Discussion :

[islogged]

Bonjour,

Je suis sur Windows 8.1, mais le problème que j'expose existerai aussi sur les version 7 ou Vista !

Le compte par défaut est un compte administrateur mais c'est un faux compte administrateur, car il ne donne pas tous les droits
Le vrai Compte administrateur est caché, il s'appel Administrator (sur ma version) et celui-çi à vraiment tous les droits Administrateur.

[Je suppose que jusque là je n'ai rien appris à personne] ^^

Si j'utilise mon Faux compte administrateur, je ne peux pas faire un : copy *.adm %SystemRoot%\system32\GroupPolicy\Adm car j'obtient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Access is denied.
        0 file(s) copied.

Si je passe en Vrai compte administrateur ou que je 'level up" le cmd courant en [Run as administrator] et que je fais mon : copy *.adm %SystemRoot%\system32\GroupPolicy\Adm évidement cela fonctionne, sauf que mes *.adm sont copier uniquement (et en tout logique) sur la vue de mon Vraie Administrator

Et évidement si sur le Vraie Compte Administrator je fait un : runas /env /user:myUSER "batch.cmd" ou batch.cmd fait un copy *.adm %SystemRoot%\system32\GroupPolicy\Adm j'obtient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Access is denied.
        0 file(s) copied.

Bref, du coup impossible de copier mes *.adm [via la command line (ce que je veux faire)] dans %SystemRoot%\system32\GroupPolicy\Adm du mon compte courant !

Car soit je suis en Vraie Administrateur et les fichiers sont copier > dans la vue < de l'Administrator
Soit je suis en Faux Administrateur, et je n'ai pas l'accès !

Alors effectivement je peux le faire via l'explorateur Windows, via le Faux Administrateur, j'obtient alors : "You'll need to provide administrator permission to copy to this folder" and Continue.

A ce moment là, et uniquement à ce moment là mes fichiers *.adm sont bien copier dans la vue du %SystemRoot%\system32\GroupPolicy\Adm de l'utilisateur courant !

Difficile à expliquer, mais je pense que les plus chevronner sur Windows comprendront le sens de mon message, ainsi que mon problème.

Donc comment en [batch/shell] windows copier mes *.adm dans la vue de %SystemRoot%\system32\GroupPolicy\Adm de mon utilisateur courant ???

Car pour l'instant cela semble impossible et c'est un gros problème je trouve du coup sur Windows !

Merci

[sevyc64]

Tu execute ton Batch en [Run as administrator]

Depuis Vista, la sécurité a été renforcée et tous les comptes même Administrateurs n'ont plus que des droits de simples utilisateurs en temps normal. Les comptes Administrateurs ont simplement le privilège d'obtenir à la demande et ponctuellement les droits d'administration (ce que l'on appelle une élévation de privilège)


Quant au compte "vrai" administrateur, il est (par défaut) caché, et n'a pas plus de droit que ton "faux" administrateur. C'est juste que, étant caché, il faut une manip particulière pour pouvoir ouvrir une session avec ce compte, manip qui exécute la session dans un contexte particulier lancé avec l'option [Run as administrator].

Mais si tu rends ce compte visible pour pouvoir se logger normalement il se comportera comme ton "faux" administrateur.

Autre solution, que personnellement je déconseille (parce qu'on en revient à la passoire XP) est de désactiver l'UAC.

[JML19]

Bonsoir

Son problème que je crois insoluble est qu'il utilise cette variable %SystemRoot% qui fait qu'il copie dans l'utilisateur qui est utilisé sur le poste en question sans le connaitre.

S'il se met en grand administrateur cela copie dans le compte administrateur s'il se met en utilisateur cela ne copie pas.

Ce qu'il voudrait c'est se mettre administrateur est copier dans l'utilisateur avec cette variable %SystemRoot% sans avoir besoin de marquer le nom exact de l'utilisateur.

Car s'il marquait la ligne de copie en clair avec le nom complet, il n'aurait aucun problème, mais je suppose qu'il a besoin de cette variable car il ne le connait pas toujours suivant les postes où s'exécutent son batch.

[sevyc64]

%SystemRoot% indique le dossier racine d'installation du système. Par défaut c'est C:\Windows dans une installation standard, et ce, quelque soit l'utilisateur.

Mais effectivement ce dossier, les sous-dossiers, ainsi que la racine du disque système (C: par défaut), ainsi que le dossier des programmes (c:\Program Files, ainsi que C:\Program Files (x86) pour un système 64 bits) et les sous-dossiers sont, en temps normal, en lecture seule. Il faut une élévation de privilèges pour pouvoir y écrire.

[islogged]

Merci de m'avoir répondu ^^

Pour vraiment comprendre le problème que j'expose, je vous propose de créer un fichier lambda.txt puis via le shell faire un : copy lambda.txt %SystemRoot%\system32\GroupPolicy\Adm (%SystemRoot% équivalent à c:\Windows)

Alors 2 solutions possible :
- Avec une console [sans élévation de privilège], vous obtiendrai un : Access is denied.
- Avec une console [avec élévation de privilège], lambda.txt sera bien copier mais dans la vue de l'administrateur, pour vous en convaincre explorer (sans changer de compte) jusqu'a C:\Windows\System32\GroupPolicy\Adm et votre fichier pourtant bien copier ne s'y trouvera pas !!!

Pourquoi, parce qu'il a été copier dans la vue de l'administrateur (vu qu'élévation) mais pas dans la vue de votre utilisateur courant !!!

Du coup IMPOSSIBLE en ligne de commande de copier un file dans C:\Windows\System32\GroupPolicy\Adm de votre utilisateur courant, ce que je cherche à faire ! (et ce avec élévation de privilège ou non !)

Alors comment faire ? - That is the question !!!

Merci

[foetus]

Déactiver l'UAC <- Solution a pas chère qui peut ne pas fonctionner

[islogged]

Déactiver l'UAC <- Solution a pas chère qui peut ne pas fonctionner

Arf l'idée c'est que cela fonctionne dans un environnement NORMAL
Je trouve dingue tout de même qu'un admin ne puisse pas écrire dans l'emplacement spécifique d'un user !!!

[chrtophe]

Tu n'écris pas dans une zone spécifique à un user mais dans une zone spécifique au système.

[islogged]

Tu n'écris pas dans une zone spécifique à un user mais dans une zone spécifique au système.

C'est discutable puisque le C:\Windows\System32\GroupPolicy\Adm de mon current user n'est pas le même que le C:\Windows\System32\GroupPolicy\Adm d'un autre user tel que celui de l'Administrator par exemple !

Il suffit de faire le test exposé plus haut (avec plusieurs users) pour s'en rendre compte !

[JML19]

Peut être que tu ne vois pas la même chose simplement, car les droits sur les fichiers ne sont pas les mêmes, mais je pense qu'il y a la même chose quand même.

Peux tu modifier l'Explorateur Windows pour tout voir comme en grand administrateur ?

[islogged]

Merci pour votre aide !

J'ai résolu le problème, il y a eu un imbroglio (oui encore ^^) entre le logiciel que j'utilise pour gérer les fichiers qui est : Total Commander et qui semble mal géré le système de fichier à ce niveau là ! (je vais d'ailleurs aller faire un rapport de bug de ce coté là)

J'avais pourtant tester me semble t'il avec l'explorateur Windows et cela me faisait des choses bisard !
J'ai tout simplement réinstallé Windows et pas utilisé Total Commander !

Tout semble alors être maintenant rentré dans l'ordre, donc ce que j'avais énoncé ici :

- Avec une console [avec élévation de privilège], lambda.txt sera bien copier mais dans la vue de l'administrateur, pour vous en convaincre explorer (sans changer de compte) jusqu'a C:\Windows\System32\GroupPolicy\Adm et votre fichier pourtant bien copier ne s'y trouvera pas !!!

est tout simplement FAUX !
Windows fonctionne tout à fait normalement à ce niveau là ! (dsl)

Pardon Windows, et pardon de vous avoir embéter avec ce problème là ^^

-----------

Par contre avant de fermer le sujet j'aimerai clarifier certaines choses qui ne sont toujours pas très clair au niveau de la gestion des users dans Windows !

Depuis Vista, la sécurité a été renforcée et tous les comptes même Administrateurs n'ont plus que des droits de simples utilisateurs en temps normal. Les comptes Administrateurs ont simplement le privilège d'obtenir à la demande et ponctuellement les droits d'administration (ce que l'on appelle une élévation de privilège)

Ok !

Quant au compte "vrai" administrateur, il est (par défaut) caché, et n'a pas plus de droit que ton "faux" administrateur. C'est juste que, étant caché, il faut une manip particulière pour pouvoir ouvrir une session avec ce compte, manip qui exécute la session dans un contexte particulier lancé avec l'option [Run as administrator].

Je pense par contre qu'à ce niveau ce que tu dis est Faux, car pour avoir tourner sur ce vrai compte [Administrator] caché il y a quelques années (sur Vista ou Seven me souvient plus), il ne se comporte pas comme un compte Administrateur de base puisque de mémo la demande ponctuel d'élévation des privilèges n'a jamais lieu, car avec ce compte l'on les droits auxquels on peux s'attendre d'un vraie compte Administrateur.

Il y a encore d'autres choses qui m'interpelles, je suppose que c'est encore pour des raisons de sécurité mais pourquoi un compte sans mot de passe n'est une nouvelle fois pas un vraie compte sans mot de passe, il suffit de faire un runas /user:Name "application.exe" pour s'en rendre compte.

Q1 - Donc comment sur Windows créer un vraie compte sans mot de passe ?

Q2 - Si "la sécurité a été renforcée et tous les comptes même Administrateurs n'ont plus que des droits de simples utilisateurs en temps normal" quelle est la différence entre un compte Administrator (de base), un compte User et un compte "Power User" ?

Q3 - (et qui boucle Q2) N'y aurait'il pas une infographie (tel que c'elle çi : http://images.pcastuces.com/faq_windows8_05.png) qui résumerai les différences exacte entre les différents types de compte sur Windows ? (car il y en à une chié en plus même de ceux que j'ai cité et au final ont y comprend vraiment plus rien)

Merci

[JML19]

Bonjour

Je pense que lorsqu'on parle d'administrateur Microsoft fait la différence entre administration réseau et administration système.

Je pense simplement que l'administration système a été séparée de l'administration réseau.

[sevyc64]

Je pense par contre qu'à ce niveau ce que tu dis est Faux, car pour avoir tourner sur ce vrai compte [Administrator] caché il y a quelques années (sur Vista ou Seven me souvient plus), il ne se comporte pas comme un compte Administrateur de base puisque de mémo la demande ponctuel d'élévation des privilèges n'a jamais lieu, car avec ce compte l'on les droits auxquels on peux s'attendre d'un vraie compte Administrateur.

Tu n'as donc pas lu ce que j'ai écrit :

C'est juste que, étant caché, il faut une manip particulière pour pouvoir ouvrir une session avec ce compte, manip qui exécute la session dans un contexte particulier lancé avec l'option [Run as administrator].

Le compte étant caché, il n'est pas accessible directement mais via une manip particulière, manip qui fait que le contexte d'ouverture de cette session subit lui-même une élévation de droits. Le compte n'a donc, par la suite, pas besoin d'avoir une élévation puisque s'executant dans un contexte ayant déjà tous les droits.
Mais le même compte, sans rien en changer, tu le rends accessible depuis l'écran de login standard et il ouvrira, depuis cet écran, une session à l'identique de tes autres comptes administrateur.

Il y a encore d'autres choses qui m'interpelles, je suppose que c'est encore pour des raisons de sécurité mais pourquoi un compte sans mot de passe n'est une nouvelle fois pas un vraie compte sans mot de passe, il suffit de faire un runas /user:Name "application.exe" pour s'en rendre compte.

Un compte sans mot de passe est un compte sans mot de passe. C'est juste que runas, prévu pour exécuter les contextes de sécurité associés au compte passé en paramètre, ne sait pas gérer les comptes sans mot de passe, un compte sans mot de passe n'étant pas considéré comme ayant la moindre notion de sécurité.

Q2 - Si "la sécurité a été renforcée et tous les comptes même Administrateurs n'ont plus que des droits de simples utilisateurs en temps normal" quelle est la différence entre un compte Administrator (de base), un compte User et un compte "Power User" ?

La différence d'un compte administrateur est essentiellement qu'il peut obtenir relativement facilement les droits d'administration et ponctuelle (au lieu de en permanence avant Vista).
Un compte Utilisateur avec pouvoir est, pour faire très très simple, un compte utilisateur qui a plus qu'un compte utilisateur standard. Il a pu, notamment obtenir certains droits par GPO par rapport aux droits standard d'un utilisateur standard.

Q3 - (et qui boucle Q2) N'y aurait'il pas une infographie (tel que c'elle çi : http://images.pcastuces.com/faq_windows8_05.png) qui résumerai les différences exacte entre les différents types de compte sur Windows ? (car il y en à une chié en plus même de ceux que j'ai cité et au final ont y comprend vraiment plus rien)

C'est possible, mais je n'en connais pas.

[islogged]

Tu n'as donc pas lu ce que j'ai écrit :

Si, mais j'avais plus lu "Quant au compte "vrai" administrateur, il est (par défaut) caché, et n'a pas plus de droit que ton "faux" administrateur. " que "exécute la session dans un contexte particulier lancé avec l'option [Run as administrator]." ^^

Après pour la manip c'est pas dur il suffit de décoché "account disabled"

runas ... ne sait pas gérer les comptes sans mot de passe

Ah ok !, lol quand même ^^

Pour le reste, tout est OK ;P
Thanx !

[sevyc64]

Après pour la manip c'est pas dur il suffit de décoché "account disabled"

Dans ce cas, si je ne me trompe pas, il est rajouté à l'écran de login. Il sera donc ouvert comme les autres comptes administrateur.

Perso, je parlais d'une autre manip, dont je me souviens plus d'ailleurs, pour lancer ponctuellement une session avec ce compte, même resté désactivé. Je ne sais même pas s'il fallait pas le faire depuis un cd d'install.