Script de connexion avec SetPassword ...

Le
moi
Bonjour,


Pour changer automatiquement le mot de passe de "admin-local" sur
toutes les stations XP-pro d'un domaine W2003,
je me propose de faire un script de connexion qui
1. vérifie que la machine est XP-pro ( car on a aussi de vieux 98)
2. Si Xp : lance avec un privilège suffisant ( admin du domaine)
le script Change.vbs ci-dessous

Le but est de forcer le mot de passe
et de ne pas le refaire si c'est déjà fait.

Des fichiers nom-de-station.txt sont rangés dans un répertoire nommé
"Machines" situé à côté du script .
Chaque fichier contient
' - soit une première ligne avec le nouveau mot de passe
' puis (seconde ligne) une phrase confirmant la réussite
' - soit l'annonce de l'échec avec des infos sur l'erreur
' (infos sur 4 lignes)

Le "truc" des petits fichiers ( un par machine) m'est venu en songeant
qu'un unique fichier avec une liste serait source de pb ( connexion
"simultanées", plantus ??? )

La trace laissée dans le répertoire "Machines" me permet de passer à
un autre mot de passe en changeant celui cité au début du script et
sans toucher aux fichiers nom-de-station.txt

Ma question est donc multiple :

- La "stratégie" vous semble-t-elle bonne ?
- comment réaliser les point 1 et 2 ci-dessus ?

- Le script Change.vbs ci-dessous est-il bon ?
( compte tenu du résultat attendu )

Merci d'avance aux experts compatissants
et en particulier à JCB
dont j'ai sagement étudié et pillé les scripts
pour faire celui-ci


Cordialement,

HB
=
= Change.vbs ==
=
Dim FSO, NET, O_User, Fichier
'
KISSA = "admin_local"
'
MotDePasse = "BaraLatataBaliba"
'

Set FSO = WScript.CreateObject("Scripting.FileSystemObject")
Set NET = WScript.CreateObject("Wscript.Network")

BECANE = NET.ComputerName
Chemin = WScript.ScriptFullName

'
'

CheminBecane = Left(Chemin, InStrRev(Chemin, "")) & "Machines" &
BECANE & ".txt"

Flag = True

If FSO.FileExists(CheminBecane) then
Set Fichier = FSO.OpenTextFile(CheminBecane, 1, False)
Resultat = Fichier.ReadLine
Fichier.close
Set Fichier = Nothing
If Résultat = MotDePasse then
Flag = False
end if

end if

If Flag = True
Set Fichier = FSO.OpenTextFile(CheminBecane, 2, True)
on error resume next
Set O_User = GetObject("WinNT://" & BECANE & "/" & KISSA &
",User")

If Err.Number<>0 Then
Erreur "GetObject"
else
O_User.SetPassword MotDePasse
If Err.Number<>0 Then
Erreur "SetPassword"
else
Fichier.Writeline MotDePasse
Fichier.Writeline "est le nouveau mot de passe de " &
BECANE & "."
end if

End If
End if

Fichier.Close

Wscript.quit

'
'

Sub Erreur(Ap)
H = Hex(Err.Number)
D = Err.Description
Texte = "Echec de la définition du mot de passe de " & KISSA & "
sur " & BECANE & VBCRLF
Texte = Texte & "Appel : " & Ap & VBCRLF & "Code : " & H & VBCRLF
Texte = Texte & "Description : " & D
Fichier.WriteLine Texte
End Sub
'
'
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Gilles LAURENT
Le #631444
"moi" news:45881757$0$27369$
| Bonjour,

Bonjour,

| Pour changer automatiquement le mot de passe de "admin-local" sur
| toutes les stations XP-pro d'un domaine W2003,
| je me propose de faire un script de connexion qui
| 1. vérifie que la machine est XP-pro ( car on a aussi de vieux 98)
| 2. Si Xp : lance avec un privilège suffisant ( admin du domaine)
| le script Change.vbs ci-dessous
[...]

Pourquoi ne pas tout simplement vous appuyer sur les fonctionnalités de
votre domaine Windows 2003 à savoir les stratégies de groupe (scripts de
démarrage) et les filtres WMI ? Dans ce cas, pour changer le mot de
passe de l'administrateur local des postes de travail (Fr) via un script
de démarrage :
net user administrateur <password>

Pour appliquer la stratégie uniquement sur les postes XP et donc ignorer
les systèmes Windows 2000/2003, il suffirait d'appliquer le filtre
suivant sur la GPO :
select * from Win32_OperatingSystem where caption like '%xp%'

Note : Les systèmes Windows 98 ne seront de toute façon pas impactés car
non réceptifs aux GPO

Cette solution est robuste. Rien ne vous interdit ensuite de mettre en
place un système de log pour contrôler le résultats des opérations ...

--
Gilles LAURENT
http://glsft.free.fr
moi
Le #631183
Notre ami Gilles LAURENT tapota :


Pourquoi ne pas tout simplement vous appuyer sur les fonctionnalités
de votre domaine Windows 2003 à savoir les stratégies de groupe
(scripts de démarrage) et les filtres WMI ? Dans ce cas, pour
changer
le mot de passe de l'administrateur local des postes de travail (Fr)
via un script de démarrage :
net user administrateur <password>


Ah mais j'ignorais cette possibilité de "net" dans un script ...
Mon ignorance est sans borne... :o(

Ainsi, si j'ai bien compris , dans un truc.bat :

net user <nomlogin> <motdepasse>
force le mot de passe d'un utilisateur local.

Comment faire, alors pour récupérer une éventuelle erreur
( j'aimerais disposer d'un suivi de cette affaire )

Pour appliquer la stratégie uniquement sur les postes XP et donc
ignorer les systèmes Windows 2000/2003, il suffirait d'appliquer le
filtre suivant sur la GPO :
select * from Win32_OperatingSystem where caption like '%xp%'


en fait, ce ne sera pas nécessaire, y'a rien entre w98 et xp

Note : Les systèmes Windows 98 ne seront de toute façon pas impactés
car non réceptifs aux GPO

Cette solution est robuste.


et simple :o)

Rien ne vous interdit ensuite de mettre en
place un système de log pour contrôler le résultats des opérations
...


ça me serait bien utile, certaines machines ne fonctionnent pas chaque
jour et donc j'aimerais pouvoir trouver simplement la liste des
stations traitées ( et non traitées ).

Merci,

HB

Gilles LAURENT
Le #631178
"moi" news:4589871f$0$5076$

[...]
| Ainsi, si j'ai bien compris , dans un truc.bat :
|
| net user <nomlogin> <motdepasse>
| force le mot de passe d'un utilisateur local.

Oui

| Comment faire, alors pour récupérer une éventuelle erreur
| ( j'aimerais disposer d'un suivi de cette affaire )

Par exemple générer un évènement dans le journal Application du serveur
Windows 2003 en utilisant le code de sortie de la commande net user.
Vous serez ensuite en mesure d'extraire et d'analyser les évènements à
partir d'un point central.

net user administrateur <password>
eventcreate /s <server> /id %errorlevel% /t information /d
[%errorlevel%]

Pour extraire les informations de réussite de traitement :
=> sur une seule ligne :

>wmic ntevent
where "logfile='application'
and sourcename='eventcreate' and eventidentifier=0"
get computername,eventidentifier,timegenerated

Pour extraire les évènements d'échec de traitement :
=> sur une seule ligne :

>wmic ntevent
where "logfile='application'
and sourcename='eventcreate' and eventidentifier<>0"
get computername,eventidentifier,timegenerated

Note : Vous pouvez adapter la source, créer un journal spécifique, ...

--
Gilles LAURENT
http://glsft.free.fr
moi
Le #631176
Notre ami Gilles LAURENT tapota :


salut,

Merci beaucoup pour ces précisions. Je vais tenter d'être moins
ignorant :o(
j'avoue humblement que la récupération d'évenements dans le journal du
même nom ne m'avais pas éfleuré.
La commande
">wmic ntevent m'était jusqu'à ce jour inconnue ...
Je vais me renseigner.

J'ose donc une question peut-être sotte :
Peut-on, pour retrouver plus facilement les choses, créer une rublique
de plus dans le journal
car la rubrique "application" existe déjà et contient sans doute
"nativement" pas mal de choses, non ?
J'ai noté que certains prgm ajoutent une rubrique rien-que-pour-eux...
alors...
( comme mon anti-virus )

A+

HB


net user <nomlogin> <motdepasse>
force le mot de passe d'un utilisateur local.


Oui

Comment faire, alors pour récupérer une éventuelle erreur
( j'aimerais disposer d'un suivi de cette affaire )


Par exemple générer un évènement dans le journal Application du
serveur Windows 2003 en utilisant le code de sortie de la commande
net user. Vous serez ensuite en mesure d'extraire et d'analyser les
évènements à partir d'un point central.

net user administrateur <password>
eventcreate /s <server> /id %errorlevel% /t information /d
[%errorlevel%]

Pour extraire les informations de réussite de traitement :
=> sur une seule ligne :

>wmic ntevent
where "logfile='application'
and sourcename='eventcreate' and eventidentifier=0"
get computername,eventidentifier,timegenerated

Pour extraire les évènements d'échec de traitement :
=> sur une seule ligne :

>wmic ntevent
where "logfile='application'
and sourcename='eventcreate' and eventidentifier<>0"
get computername,eventidentifier,timegenerated

Note : Vous pouvez adapter la source, créer un journal spécifique,
...



Gilles LAURENT
Le #630921
"moi" news:458ac873$0$27399$
| salut,

Bonsoir,

[...]
| Peut-on, pour retrouver plus facilement les choses, créer une rublique
| de plus dans le journal
| car la rubrique "application" existe déjà et contient sans doute
| "nativement" pas mal de choses, non ?

Oui, il est possible de créer un journal spécifique et c'est même
recommandé. Pour cela, il suffit de créer une nouvelle clé de registre
sous HKLMSYSTEMCurrentControlSetServicesEventlog. Le nom de cette
nouvelle clé correspondra au nom du nouveau journal. Cette modification
sera prise en compte par l'observateur d'événements sans nécessiter de
rédémarrage (il sera toutefois nécessaire de relancer la console
eventvwr.msc si celle-ci était déjà démarrée). Ce nouveau journal
héritera des propriétés par défaut (taille, rétention, ...). Le fichier
journal (<journal>.evt) sera automatiquement créé dans le dossier
%systemroot%system32config<journal>.evt

Après ces modifications, il sera donc nécessaire de spécifier dans la
ligne de commandes 'wmic' le nom du journal spécifique via l'option '/L
<journal>'. L'opération d'extraction et d'analyse des logs se fera à
partir d'un poste d'administration Windows XP.

Note : Sur votre poste d'administration sera également installé Windows
PowerShell pour vous aider dans vos tâches d'administration courante. Je
vous invite à découvrir le nouveau shell Microsoft Windows PowerShell
consultable à cette adresse :
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx

Ainsi que le blog de Jacques Barathon [MS] sur Windows PowerShell :
http://janel.spaces.msn.com/blog

Bonne mise en oeuvre ;-)

--
Gilles LAURENT
http://glsft.free.fr
moi
Le #630920
Notre ami Gilles LAURENT tapota :

Merci beaucoup pour ces précieuses précisions.

Avec tout ça je devrais pouvoir m'en sortir
"comme un chef" :o)

bien amicalement,

HB

Bonsoir,

[...]
Peut-on, pour retrouver plus facilement les choses, créer une
rublique de plus dans le journal
car la rubrique "application" existe déjà et contient sans doute
"nativement" pas mal de choses, non ?


Oui, il est possible de créer un journal spécifique et c'est même
recommandé. Pour cela, il suffit de créer une nouvelle clé de
registre
sous HKLMSYSTEMCurrentControlSetServicesEventlog. Le nom de
cette
nouvelle clé correspondra au nom du nouveau journal. Cette
modification sera prise en compte par l'observateur d'événements
sans
nécessiter de rédémarrage (il sera toutefois nécessaire de relancer
la console eventvwr.msc si celle-ci était déjà démarrée). Ce nouveau
journal héritera des propriétés par défaut (taille, rétention, ...).
Le fichier journal (<journal>.evt) sera automatiquement créé dans le
dossier %systemroot%system32config<journal>.evt

Après ces modifications, il sera donc nécessaire de spécifier dans
la
ligne de commandes 'wmic' le nom du journal spécifique via l'option
'/L <journal>'. L'opération d'extraction et d'analyse des logs se
fera à partir d'un poste d'administration Windows XP.

Note : Sur votre poste d'administration sera également installé
Windows PowerShell pour vous aider dans vos tâches d'administration
courante. Je vous invite à découvrir le nouveau shell Microsoft
Windows PowerShell consultable à cette adresse :
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx

Ainsi que le blog de Jacques Barathon [MS] sur Windows PowerShell :
http://janel.spaces.msn.com/blog

Bonne mise en oeuvre ;-)



moi
Le #630919
Notre ami Gilles LAURENT tapota :

[...]
Après ces modifications, il sera donc nécessaire de spécifier dans
la
ligne de commandes 'wmic' le nom du journal spécifique via l'option
'/L <journal>'.


Euh alors là je ne comprend plus ... :o(
C'est pas dans "eventcreate" qui devient
(( Sur Une Ligne)
eventcreate /s MonServeur /id %errorlevel%
/t information /d [%errorlevel%] /L MonJournal

[...]

L'opération d'extraction et d'analyse des logs se
fera à partir d'un poste d'administration Windows XP.


Ne puis-je l'automatiser en tâche planifiée sur le serveur
avec, pour les échecs un truc.bat contenant , par exemple :
( Sur Une Ligne)
_________________________________________
wmic ntevent
where "logfile='MonJournal'
and sourcename='eventcreate' and eventidentifier<>0"
get computername,eventidentifier,timegenerated
/format:htable >D:Outilsmonjournalechecs.htm
_________________________________________

et tant que j'y suis ... peut effcer des évènements avec une ligne qui
va bien
genre
( Sur Une Ligne)

wmic ntevent
where "logfile='MonJournal'
and sourcename='eventcreate' and eventidentifier<>0"
delete
[...]

bon ...
Promis, quand je serais grand, je passe à PowerShell :o)

HB

Gilles LAURENT
Le #630918
"moi" news:458b06c0$0$25954$

Bonjour,

| Ne puis-je l'automatiser en tâche planifiée sur le serveur
| avec, pour les échecs un truc.bat contenant , par exemple :
| ( Sur Une Ligne)
| wmic ntevent
| where "logfile='MonJournal'
| and sourcename='eventcreate' and eventidentifier<>0"
| get computername,eventidentifier,timegenerated
| /format:htable >D:Outilsmonjournalechecs.htm

Oui, bien sûr, libre cours à votre imagination ;-)

| et tant que j'y suis ... peut effcer des évènements avec une ligne qui
| va bien
| genre
| ( Sur Une Ligne)
| wmic ntevent
| where "logfile='MonJournal'
| and sourcename='eventcreate' and eventidentifier<>0"
| delete

Non, il n'est pas possible de supprimer de manière sélective des
événements. Par contre, vous pouvez vider le journal (i.e supprimer tous
les enregistrements) via la classe wmi Win32_NTEventlogFile (alias
nteventlog sous la console wmic). Cela donne donc :
>wmic nteventlog where logfilename='<journal>' call cleareventlog

| Promis, quand je serais grand, je passe à PowerShell :o)

LOL

--
Gilles LAURENT
http://glsft.free.fr
moi
Le #630917
Notre ami Gilles LAURENT tapota :

(...)
Oui, bien sûr, libre cours à votre imagination ;-)

et tant que j'y suis ... peut effcer des évènements avec une ligne
qui va bien
genre
( Sur Une Ligne)
wmic ntevent
where "logfile='MonJournal'
and sourcename='eventcreate' and eventidentifier<>0"
delete


Non, il n'est pas possible de supprimer de manière sélective des
événements. Par contre, vous pouvez vider le journal (i.e supprimer
tous les enregistrements) via la classe wmi Win32_NTEventlogFile
(alias nteventlog sous la console wmic). Cela donne donc :
>wmic nteventlog where logfilename='<journal>' call cleareventlog

nickel , cela devrait me suffire... en récupérant plutôt du *.txt pour

les réussites, je devrais pouvoir ajouter au fichier des réussites (
au lieu de > ) avant de vider le journal puisque le fichier des
échecs, lui, repart logiquement sur du neuf à chaque fois ...



Je passerais à la phase "expérimentation avant la mise en oeuvre
globale" en me limitant à une petite "sous-OU" contenant peu de postes
...

Merci encore pour ces lumineuses infos ...
je crois avoir compris l'essentiel .

C'est toujours un plaisir de se renseigner sur ce NG !

Bien amicalement,

HB


Poster une réponse
Anonyme