User ID > User Name

Gilles LAURENT

25/08/2006 à 19:13

"Bouby6Killer" a écrit dans le
message de news:
| Bonjour,

Bonjour,

| Je souhaiterais pouvoir traduire les clés SID de la base de
| registre sous la branche HKEY_USERS afin d'obtenir les noms
| d'utilisateurs correspondants. De plus, il faudrait que la sortie
| soit récupérée dans un fichier texte afin de pouvoir être exploitée
| par mon application en Pascal. Si quelqu'un a une idée, je l'en
| remercie d'avance ;)

-- Coupez ici : Lookup.vbs --

Option Explicit

' déclaration des variables
Dim objWMI, objReg, objAccnt
Dim dicSID, colItems, arrSubKeys
Dim item, subkey

' initialisation
Set dicSID = CreateObject ("Scripting.Dictionary")
Set objWMI = GetObject ("winmgmts:rootcimv2")
Set objReg = GetObject ("winmgmts:rootdefault:StdRegProv")

' lecture de tous les sid et constitution d'un dictionnaire
Set colItems = _
objWMI.ExecQuery ("select * from Win32_AccountSID",,48)
For Each item in colItems
Set objAccnt = GetObject ("winmgmts:" & item.Element)
If Not dicSID.Exists (objAccnt.SID) Then _
dicSID.Add objAccnt.SID, objAccnt.Name
Next

' énumération des sous-clés HKEY_USERS
' et conversion des SID en Nom en s'appuyant sur le dictionnaire
objReg.EnumKey &H80000003, "", arrSubKeys
For Each subkey In arrSubKeys
If IsNumeric (Right (subkey,1)) Then
WScript.Echo subkey & "," & dicSID.Item (subkey)
End If
Next

-- Coupez ici : Lookup.vbs --

Pour exécuter le script :
>cscript //nologo Lookup.vbs > Lookup.sid

Le format de sortie sera le suivant :
sid1,compte_utilisateur
sid2,compte_utilisateur

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

Jacques Barathon [MS]

26/08/2006 à 00:37

J'avais fait une traduction du script ci-dessous en PowerShell (voir plus
bas) mais en faisant mes tests j'ai constaté que le script (VBS ou PS) ne
marche pas lorsque je suis connecté au domaine de mon entreprise.
Apparemment c'est l'énumération des instances de la classe Win32_AccountSID
qui bloque sur les SID du domaine. Si je suis déconnecté le script se
termine correctement au bout de 30 secondes à 1 minute, mais dans ce cas il
ne résoud pas les SID correspondant à des comptes du domaine.

Une technique alternative consiste à utiliser l'utilitaire sid2name. Cet
utilitaire est trouvable sur de nombreux sites (avec son compère name2sid),
par exemple ici:
http://www.derkeiler.com/Newsgroups/microsoft.public.win2000.security/2003-10/2879.html

En PowerShell ça donne ça:

# créer un lecteur HKU qui pointe sur HKEY_USERS:
new-psdrive hku registry HKEY_USERS >$null

# énumérer les clés de HKU et les résoudre avec sid2name
dir hku: | where {$_.name[-1] -match "d"} | foreach {sid2name
$_.name.split("")[1]}

Ca marche bien et vite, que le poste soit connecté ou pas. Je creuserai plus
tard les raisons pour lesquelles les scripts plantent lorsqu'ils sont
connectés.

Pour le fun quand même, une traduction (approximative) du script de Gilles:

--- couper ici ---
# création d'un dictionnaire des SID
$dicsid=@{}
get-wmiobject Win32_Account | foreach {
$dicsid += @{$_.SID=$_.name}
}

# création d'un lecteur HKU: pointant sur HKEY_USERS
new-psdrive hku registry HKEY_USERS > $null

# parcours de HKU:,
# traduction des SID grâce au dictionnaire
dir hku: | foreach {
$_.name.split("")[1]} | where {
$_[-1] -match "d"
} | foreach {
"$_, $($dicsid.$_)"
}
--- couper ici ---

Pour un éventuel concours de la syntaxe la plus ramassée, le même script
peut s'écrire en trois lignes (numérotées pour que vous puissiez les
reconstituer après l'insertion sauvage de retours chariot au passage):

1: gwmi
win32_accountsid|%{$acc=[WMI]$_.element;$local:dicsid+=@{$acc.SID=$acc.name}}
2: new-psdrive hku registry HKEY_USERS >$null
3: dir hku:|%{$_.name.split("")[1]}|?{$_[-1] -match
"d"}|%{"$_,$($local:dicsid.$_)"}

Je note que VBScript a une fonction IsNumeric() pour laquelle je n'ai pas
trouvé d'équivalent en PowerShell. Il m'a fallu ruser en faisant une
comparaison avec une expression régulière "d" qui correspond à tout
caractère numérique.

Voilà. Comme écrit tout en haut, mes tests montrent de sérieuses limites à
l'exercice sur mon poste, à vous de voir si ça marche bien dans votre
environnement. Quoi qu'il en soit, je trouvais l'exercice intéressant et
j'espère qu'il sera utile à ceux qui veulent se lancer dans PowerShell.

Jacques

"Gilles LAURENT" a écrit dans le message de news:

"Bouby6Killer" a écrit dans le
message de news:
| Bonjour,

Bonjour,

| Je souhaiterais pouvoir traduire les clés SID de la base de
| registre sous la branche HKEY_USERS afin d'obtenir les noms
| d'utilisateurs correspondants. De plus, il faudrait que la sortie
| soit récupérée dans un fichier texte afin de pouvoir être exploitée
| par mon application en Pascal. Si quelqu'un a une idée, je l'en
| remercie d'avance ;)

-- Coupez ici : Lookup.vbs --

Option Explicit

' déclaration des variables
Dim objWMI, objReg, objAccnt
Dim dicSID, colItems, arrSubKeys
Dim item, subkey

' initialisation
Set dicSID = CreateObject ("Scripting.Dictionary")
Set objWMI = GetObject ("winmgmts:rootcimv2")
Set objReg = GetObject ("winmgmts:rootdefault:StdRegProv")

' lecture de tous les sid et constitution d'un dictionnaire
Set colItems = _
objWMI.ExecQuery ("select * from Win32_AccountSID",,48)
For Each item in colItems
Set objAccnt = GetObject ("winmgmts:" & item.Element)
If Not dicSID.Exists (objAccnt.SID) Then _
dicSID.Add objAccnt.SID, objAccnt.Name
Next

' énumération des sous-clés HKEY_USERS
' et conversion des SID en Nom en s'appuyant sur le dictionnaire
objReg.EnumKey &H80000003, "", arrSubKeys
For Each subkey In arrSubKeys
If IsNumeric (Right (subkey,1)) Then
WScript.Echo subkey & "," & dicSID.Item (subkey)
End If
Next

-- Coupez ici : Lookup.vbs --

Pour exécuter le script :
>cscript //nologo Lookup.vbs > Lookup.sid

Le format de sortie sera le suivant :
sid1,compte_utilisateur
sid2,compte_utilisateur

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

J'avais fait une traduction du script ci-dessous en PowerShell (voir plus
bas) mais en faisant mes tests j'ai constaté que le script (VBS ou PS) ne
marche pas lorsque je suis connecté au domaine de mon entreprise.
Apparemment c'est l'énumération des instances de la classe Win32_AccountSID
qui bloque sur les SID du domaine. Si je suis déconnecté le script se
termine correctement au bout de 30 secondes à 1 minute, mais dans ce cas il
ne résoud pas les SID correspondant à des comptes du domaine.

Une technique alternative consiste à utiliser l'utilitaire sid2name. Cet
utilitaire est trouvable sur de nombreux sites (avec son compère name2sid),
par exemple ici:
http://www.derkeiler.com/Newsgroups/microsoft.public.win2000.security/2003-10/2879.html

En PowerShell ça donne ça:

# créer un lecteur HKU qui pointe sur HKEY_USERS:
new-psdrive hku registry HKEY_USERS >$null

# énumérer les clés de HKU et les résoudre avec sid2name
dir hku: | where {$_.name[-1] -match "d"} | foreach {sid2name
$_.name.split("")[1]}

Ca marche bien et vite, que le poste soit connecté ou pas. Je creuserai plus
tard les raisons pour lesquelles les scripts plantent lorsqu'ils sont
connectés.

Pour le fun quand même, une traduction (approximative) du script de Gilles:

--- couper ici ---
# création d'un dictionnaire des SID
$dicsid=@{}
get-wmiobject Win32_Account | foreach {
$dicsid += @{$_.SID=$_.name}
}

# création d'un lecteur HKU: pointant sur HKEY_USERS
new-psdrive hku registry HKEY_USERS > $null

# parcours de HKU:,
# traduction des SID grâce au dictionnaire
dir hku: | foreach {
$_.name.split("")[1]} | where {
$_[-1] -match "d"
} | foreach {
"$_, $($dicsid.$_)"
}
--- couper ici ---

Pour un éventuel concours de la syntaxe la plus ramassée, le même script
peut s'écrire en trois lignes (numérotées pour que vous puissiez les
reconstituer après l'insertion sauvage de retours chariot au passage):

1: gwmi
win32_accountsid|%{$acc=[WMI]$_.element;$local:dicsid+=@{$acc.SID=$acc.name}}
2: new-psdrive hku registry HKEY_USERS >$null
3: dir hku:|%{$_.name.split("")[1]}|?{$_[-1] -match
"d"}|%{"$_,$($local:dicsid.$_)"}

Je note que VBScript a une fonction IsNumeric() pour laquelle je n'ai pas
trouvé d'équivalent en PowerShell. Il m'a fallu ruser en faisant une
comparaison avec une expression régulière "d" qui correspond à tout
caractère numérique.

Voilà. Comme écrit tout en haut, mes tests montrent de sérieuses limites à
l'exercice sur mon poste, à vous de voir si ça marche bien dans votre
environnement. Quoi qu'il en soit, je trouvais l'exercice intéressant et
j'espère qu'il sera utile à ceux qui veulent se lancer dans PowerShell.

Jacques

"Gilles LAURENT" <glsft@free.fr> a écrit dans le message de news:
etn2mnGyGHA.2208@TK2MSFTNGP03.phx.gbl...

"Bouby6Killer" <Bouby6Killer@discussions.microsoft.com> a écrit dans le
message de news:7C1E6642-7089-4E80-9EBD-04DD7D0E099B@microsoft.com
| Bonjour,

Bonjour,

| Je souhaiterais pouvoir traduire les clés SID de la base de
| registre sous la branche HKEY_USERS afin d'obtenir les noms
| d'utilisateurs correspondants. De plus, il faudrait que la sortie
| soit récupérée dans un fichier texte afin de pouvoir être exploitée
| par mon application en Pascal. Si quelqu'un a une idée, je l'en
| remercie d'avance ;)

-- Coupez ici : Lookup.vbs --

Option Explicit

' déclaration des variables
Dim objWMI, objReg, objAccnt
Dim dicSID, colItems, arrSubKeys
Dim item, subkey

' initialisation
Set dicSID = CreateObject ("Scripting.Dictionary")
Set objWMI = GetObject ("winmgmts:rootcimv2")
Set objReg = GetObject ("winmgmts:rootdefault:StdRegProv")

' lecture de tous les sid et constitution d'un dictionnaire
Set colItems = _
objWMI.ExecQuery ("select * from Win32_AccountSID",,48)
For Each item in colItems
Set objAccnt = GetObject ("winmgmts:" & item.Element)
If Not dicSID.Exists (objAccnt.SID) Then _
dicSID.Add objAccnt.SID, objAccnt.Name
Next

' énumération des sous-clés HKEY_USERS
' et conversion des SID en Nom en s'appuyant sur le dictionnaire
objReg.EnumKey &H80000003, "", arrSubKeys
For Each subkey In arrSubKeys
If IsNumeric (Right (subkey,1)) Then
WScript.Echo subkey & "," & dicSID.Item (subkey)
End If
Next

-- Coupez ici : Lookup.vbs --

Pour exécuter le script :
>cscript //nologo Lookup.vbs > Lookup.sid

Le format de sortie sera le suivant :
sid1,compte_utilisateur
sid2,compte_utilisateur

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

Vous avez filtré cet utilisateur ! Consultez son message

J'avais fait une traduction du script ci-dessous en PowerShell (voir plus
bas) mais en faisant mes tests j'ai constaté que le script (VBS ou PS) ne
marche pas lorsque je suis connecté au domaine de mon entreprise.
Apparemment c'est l'énumération des instances de la classe Win32_AccountSID
qui bloque sur les SID du domaine. Si je suis déconnecté le script se
termine correctement au bout de 30 secondes à 1 minute, mais dans ce cas il
ne résoud pas les SID correspondant à des comptes du domaine.

Une technique alternative consiste à utiliser l'utilitaire sid2name. Cet
utilitaire est trouvable sur de nombreux sites (avec son compère name2sid),
par exemple ici:
http://www.derkeiler.com/Newsgroups/microsoft.public.win2000.security/2003-10/2879.html

En PowerShell ça donne ça:

# créer un lecteur HKU qui pointe sur HKEY_USERS:
new-psdrive hku registry HKEY_USERS >$null

# énumérer les clés de HKU et les résoudre avec sid2name
dir hku: | where {$_.name[-1] -match "d"} | foreach {sid2name
$_.name.split("")[1]}

Ca marche bien et vite, que le poste soit connecté ou pas. Je creuserai plus
tard les raisons pour lesquelles les scripts plantent lorsqu'ils sont
connectés.

Pour le fun quand même, une traduction (approximative) du script de Gilles:

--- couper ici ---
# création d'un dictionnaire des SID
$dicsid=@{}
get-wmiobject Win32_Account | foreach {
$dicsid += @{$_.SID=$_.name}
}

# création d'un lecteur HKU: pointant sur HKEY_USERS
new-psdrive hku registry HKEY_USERS > $null

# parcours de HKU:,
# traduction des SID grâce au dictionnaire
dir hku: | foreach {
$_.name.split("")[1]} | where {
$_[-1] -match "d"
} | foreach {
"$_, $($dicsid.$_)"
}
--- couper ici ---

Pour un éventuel concours de la syntaxe la plus ramassée, le même script
peut s'écrire en trois lignes (numérotées pour que vous puissiez les
reconstituer après l'insertion sauvage de retours chariot au passage):

1: gwmi
win32_accountsid|%{$acc=[WMI]$_.element;$local:dicsid+=@{$acc.SID=$acc.name}}
2: new-psdrive hku registry HKEY_USERS >$null
3: dir hku:|%{$_.name.split("")[1]}|?{$_[-1] -match
"d"}|%{"$_,$($local:dicsid.$_)"}

Je note que VBScript a une fonction IsNumeric() pour laquelle je n'ai pas
trouvé d'équivalent en PowerShell. Il m'a fallu ruser en faisant une
comparaison avec une expression régulière "d" qui correspond à tout
caractère numérique.

Voilà. Comme écrit tout en haut, mes tests montrent de sérieuses limites à
l'exercice sur mon poste, à vous de voir si ça marche bien dans votre
environnement. Quoi qu'il en soit, je trouvais l'exercice intéressant et
j'espère qu'il sera utile à ceux qui veulent se lancer dans PowerShell.

Jacques

"Gilles LAURENT" a écrit dans le message de news:

"Bouby6Killer" a écrit dans le
message de news:
| Bonjour,

Bonjour,

| Je souhaiterais pouvoir traduire les clés SID de la base de
| registre sous la branche HKEY_USERS afin d'obtenir les noms
| d'utilisateurs correspondants. De plus, il faudrait que la sortie
| soit récupérée dans un fichier texte afin de pouvoir être exploitée
| par mon application en Pascal. Si quelqu'un a une idée, je l'en
| remercie d'avance ;)

-- Coupez ici : Lookup.vbs --

Option Explicit

' déclaration des variables
Dim objWMI, objReg, objAccnt
Dim dicSID, colItems, arrSubKeys
Dim item, subkey

' initialisation
Set dicSID = CreateObject ("Scripting.Dictionary")
Set objWMI = GetObject ("winmgmts:rootcimv2")
Set objReg = GetObject ("winmgmts:rootdefault:StdRegProv")

' lecture de tous les sid et constitution d'un dictionnaire
Set colItems = _
objWMI.ExecQuery ("select * from Win32_AccountSID",,48)
For Each item in colItems
Set objAccnt = GetObject ("winmgmts:" & item.Element)
If Not dicSID.Exists (objAccnt.SID) Then _
dicSID.Add objAccnt.SID, objAccnt.Name
Next

' énumération des sous-clés HKEY_USERS
' et conversion des SID en Nom en s'appuyant sur le dictionnaire
objReg.EnumKey &H80000003, "", arrSubKeys
For Each subkey In arrSubKeys
If IsNumeric (Right (subkey,1)) Then
WScript.Echo subkey & "," & dicSID.Item (subkey)
End If
Next

-- Coupez ici : Lookup.vbs --

Pour exécuter le script :
>cscript //nologo Lookup.vbs > Lookup.sid

Le format de sortie sera le suivant :
sid1,compte_utilisateur
sid2,compte_utilisateur

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

Gilles LAURENT

26/08/2006 à 18:45

"Jacques Barathon [MS]" a écrit dans le
message de news:

Bonjour,

| J'avais fait une traduction du script ci-dessous en PowerShell (voir
| plus bas) mais en faisant mes tests j'ai constaté que le script (VBS
| ou PS) ne marche pas lorsque je suis connecté au domaine de mon
| entreprise.

Je ne rencontre pas ce problème (client XP SP2 et domaine W2K3 SP1). Par
contre, c'est vrai que dans mon environnement maquette il n'y a qu'une
douzaine de comptes utilisateur.

| Apparemment c'est l'énumération des instances de la
| classe Win32_AccountSID qui bloque sur les SID du domaine. Si je suis
| déconnecté le script se termine correctement au bout de 30 secondes à
| 1 minute, mais dans ce cas il ne résoud pas les SID correspondant à
| des comptes du domaine.

En mode déconnecté, c'est exact, les SID de domaine ne sont pas résolus.
Pour ce qui est des performances, elles ne sont en effet pas au
rendez-vous ;-) La constitution du dictionnaire avec tous les SID
(domaine et locaux) était la seule solution pour écrire le script sans
utiliser d'outil externe.

| Une technique alternative consiste à utiliser l'utilitaire sid2name.
| Cet utilitaire est trouvable sur de nombreux sites (avec son compère
| name2sid), par exemple ici:
|
http://www.derkeiler.com/Newsgroups/microsoft.public.win2000.security/2003-10/2879.html

Cela change la donne ;-)

| En PowerShell ça donne ça:
|
| # créer un lecteur HKU qui pointe sur HKEY_USERS:
| new-psdrive hku registry HKEY_USERS >$null
|
| # énumérer les clés de HKU et les résoudre avec sid2name
| dir hku: | where {$_.name[-1] -match "d"} | foreach {sid2name
| $_.name.split("")[1]}

Et en batch en une seule ligne (testé sous XP SP1/SP2) :

-- Coupez ici : lookup.cmd --

@for /f "delims= tokens=2" %%i in ('reg query hku ^| find "S-1" ^| find
/v "Classes"') do @for /f "delims=," %%j in ('sid2name %%i') do @echo
%%i,%%j

-- Coupez ici : lookup.cmd --

| Ca marche bien et vite, que le poste soit connecté ou pas.

Il n'y a pas photo sur les performances ! En effet, cette fois, seuls
les SID nécessaires sont résolus en nom.

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> a écrit dans le
message de news:uKyORKQyGHA.3568@TK2MSFTNGP03.phx.gbl

Bonjour,

| J'avais fait une traduction du script ci-dessous en PowerShell (voir
| plus bas) mais en faisant mes tests j'ai constaté que le script (VBS
| ou PS) ne marche pas lorsque je suis connecté au domaine de mon
| entreprise.

Je ne rencontre pas ce problème (client XP SP2 et domaine W2K3 SP1). Par
contre, c'est vrai que dans mon environnement maquette il n'y a qu'une
douzaine de comptes utilisateur.

| Apparemment c'est l'énumération des instances de la
| classe Win32_AccountSID qui bloque sur les SID du domaine. Si je suis
| déconnecté le script se termine correctement au bout de 30 secondes à
| 1 minute, mais dans ce cas il ne résoud pas les SID correspondant à
| des comptes du domaine.

En mode déconnecté, c'est exact, les SID de domaine ne sont pas résolus.
Pour ce qui est des performances, elles ne sont en effet pas au
rendez-vous ;-) La constitution du dictionnaire avec tous les SID
(domaine et locaux) était la seule solution pour écrire le script sans
utiliser d'outil externe.

| Une technique alternative consiste à utiliser l'utilitaire sid2name.
| Cet utilitaire est trouvable sur de nombreux sites (avec son compère
| name2sid), par exemple ici:
|
http://www.derkeiler.com/Newsgroups/microsoft.public.win2000.security/2003-10/2879.html

Cela change la donne ;-)

| En PowerShell ça donne ça:
|
| # créer un lecteur HKU qui pointe sur HKEY_USERS:
| new-psdrive hku registry HKEY_USERS >$null
|
| # énumérer les clés de HKU et les résoudre avec sid2name
| dir hku: | where {$_.name[-1] -match "d"} | foreach {sid2name
| $_.name.split("")[1]}

Et en batch en une seule ligne (testé sous XP SP1/SP2) :

-- Coupez ici : lookup.cmd --

@for /f "delims= tokens=2" %%i in ('reg query hku ^| find "S-1" ^| find
/v "Classes"') do @for /f "delims=," %%j in ('sid2name %%i') do @echo
%%i,%%j

-- Coupez ici : lookup.cmd --

| Ca marche bien et vite, que le poste soit connecté ou pas.

Il n'y a pas photo sur les performances ! En effet, cette fois, seuls
les SID nécessaires sont résolus en nom.

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

Vous avez filtré cet utilisateur ! Consultez son message

"Jacques Barathon [MS]" a écrit dans le
message de news:

Bonjour,

| J'avais fait une traduction du script ci-dessous en PowerShell (voir
| plus bas) mais en faisant mes tests j'ai constaté que le script (VBS
| ou PS) ne marche pas lorsque je suis connecté au domaine de mon
| entreprise.

Je ne rencontre pas ce problème (client XP SP2 et domaine W2K3 SP1). Par
contre, c'est vrai que dans mon environnement maquette il n'y a qu'une
douzaine de comptes utilisateur.

| Apparemment c'est l'énumération des instances de la
| classe Win32_AccountSID qui bloque sur les SID du domaine. Si je suis
| déconnecté le script se termine correctement au bout de 30 secondes à
| 1 minute, mais dans ce cas il ne résoud pas les SID correspondant à
| des comptes du domaine.

En mode déconnecté, c'est exact, les SID de domaine ne sont pas résolus.
Pour ce qui est des performances, elles ne sont en effet pas au
rendez-vous ;-) La constitution du dictionnaire avec tous les SID
(domaine et locaux) était la seule solution pour écrire le script sans
utiliser d'outil externe.

| Une technique alternative consiste à utiliser l'utilitaire sid2name.
| Cet utilitaire est trouvable sur de nombreux sites (avec son compère
| name2sid), par exemple ici:
|
http://www.derkeiler.com/Newsgroups/microsoft.public.win2000.security/2003-10/2879.html

Cela change la donne ;-)

| En PowerShell ça donne ça:
|
| # créer un lecteur HKU qui pointe sur HKEY_USERS:
| new-psdrive hku registry HKEY_USERS >$null
|
| # énumérer les clés de HKU et les résoudre avec sid2name
| dir hku: | where {$_.name[-1] -match "d"} | foreach {sid2name
| $_.name.split("")[1]}

Et en batch en une seule ligne (testé sous XP SP1/SP2) :

-- Coupez ici : lookup.cmd --

@for /f "delims= tokens=2" %%i in ('reg query hku ^| find "S-1" ^| find
/v "Classes"') do @for /f "delims=," %%j in ('sid2name %%i') do @echo
%%i,%%j

-- Coupez ici : lookup.cmd --

| Ca marche bien et vite, que le poste soit connecté ou pas.

Il n'y a pas photo sur les performances ! En effet, cette fois, seuls
les SID nécessaires sont résolus en nom.

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

Jacques Barathon [MS]

26/08/2006 à 20:50

"Gilles LAURENT" a écrit dans le message de news:

<...>

| Apparemment c'est l'énumération des instances de la
| classe Win32_AccountSID qui bloque sur les SID du domaine. Si je suis
| déconnecté le script se termine correctement au bout de 30 secondes à
| 1 minute, mais dans ce cas il ne résoud pas les SID correspondant à
| des comptes du domaine.

En mode déconnecté, c'est exact, les SID de domaine ne sont pas résolus.
Pour ce qui est des performances, elles ne sont en effet pas au
rendez-vous ;-) La constitution du dictionnaire avec tous les SID
(domaine et locaux) était la seule solution pour écrire le script sans
utiliser d'outil externe.

Je n'ai pas vraiment isolé la cause de la lenteur avec certitude.
L'énumération des instances de Win32_Account (ou de Win32_AccountSID)
mettait beaucoup plus de temps hier lors de mes tests. Aujourd'hui c'est un
peu plus vif, peut-être un effet "cache"? Je referai des tests plus poussés
à l'occasion.

<...>

Et en batch en une seule ligne (testé sous XP SP1/SP2) :

-- Coupez ici : lookup.cmd --

@for /f "delims= tokens=2" %%i in ('reg query hku ^| find "S-1" ^| find
/v "Classes"') do @for /f "delims=," %%j in ('sid2name %%i') do @echo
%%i,%%j

-- Coupez ici : lookup.cmd --

J'hésite toujours à utiliser des commandes externes car je dépend alors
fortement du format de leur affichage dans mon analyse des données. Mais
après tout, j'ai déjà changé la donne en introduisant sid2name.exe, et puis
reg.exe est une commande standard sous XP! Alors voici une adaptation de mes
deux lignes PowerShell en une seule grâce à reg et sid2name:

reg query hku | % {if ($_ -match "S-.+d$") {"{0},{1}" -f $matches[0],
(sid2name $matches[0]).split(",")[0]}}

Jacques

Jacques Barathon [MS]

27/08/2006 à 10:44

Pour info, j'ai posté un billet sur mon blog à ce sujet, où je propose
également une version PowerShell des outils sid2name et name2sid:

http://janel.spaces.live.com/blog/cns!9B5AA3F6FA0088C2!203.entry

Jacques

"Jacques Barathon [MS]" a écrit dans le
message de news:

"Gilles LAURENT" a écrit dans le message de news:

<...>
| Apparemment c'est l'énumération des instances de la
| classe Win32_AccountSID qui bloque sur les SID du domaine. Si je suis
| déconnecté le script se termine correctement au bout de 30 secondes à
| 1 minute, mais dans ce cas il ne résoud pas les SID correspondant à
| des comptes du domaine.

En mode déconnecté, c'est exact, les SID de domaine ne sont pas résolus.
Pour ce qui est des performances, elles ne sont en effet pas au
rendez-vous ;-) La constitution du dictionnaire avec tous les SID
(domaine et locaux) était la seule solution pour écrire le script sans
utiliser d'outil externe.

Je n'ai pas vraiment isolé la cause de la lenteur avec certitude.
L'énumération des instances de Win32_Account (ou de Win32_AccountSID)
mettait beaucoup plus de temps hier lors de mes tests. Aujourd'hui c'est
un peu plus vif, peut-être un effet "cache"? Je referai des tests plus
poussés à l'occasion.

<...>
Et en batch en une seule ligne (testé sous XP SP1/SP2) :

-- Coupez ici : lookup.cmd --

@for /f "delims= tokens=2" %%i in ('reg query hku ^| find "S-1" ^| find
/v "Classes"') do @for /f "delims=," %%j in ('sid2name %%i') do @echo
%%i,%%j

-- Coupez ici : lookup.cmd --

J'hésite toujours à utiliser des commandes externes car je dépend alors
fortement du format de leur affichage dans mon analyse des données. Mais
après tout, j'ai déjà changé la donne en introduisant sid2name.exe, et
puis reg.exe est une commande standard sous XP! Alors voici une adaptation
de mes deux lignes PowerShell en une seule grâce à reg et sid2name:

reg query hku | % {if ($_ -match "S-.+d$") {"{0},{1}" -f $matches[0],
(sid2name $matches[0]).split(",")[0]}}

Jacques

Pour info, j'ai posté un billet sur mon blog à ce sujet, où je propose
également une version PowerShell des outils sid2name et name2sid:

http://janel.spaces.live.com/blog/cns!9B5AA3F6FA0088C2!203.entry

Jacques

"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> a écrit dans le
message de news: OZDfQCUyGHA.284@TK2MSFTNGP02.phx.gbl...

"Gilles LAURENT" <glsft@free.fr> a écrit dans le message de news:
u3xGw8SyGHA.4044@TK2MSFTNGP04.phx.gbl...
<...>

| Apparemment c'est l'énumération des instances de la
| classe Win32_AccountSID qui bloque sur les SID du domaine. Si je suis
| déconnecté le script se termine correctement au bout de 30 secondes à
| 1 minute, mais dans ce cas il ne résoud pas les SID correspondant à
| des comptes du domaine.

En mode déconnecté, c'est exact, les SID de domaine ne sont pas résolus.
Pour ce qui est des performances, elles ne sont en effet pas au
rendez-vous ;-) La constitution du dictionnaire avec tous les SID
(domaine et locaux) était la seule solution pour écrire le script sans
utiliser d'outil externe.

Je n'ai pas vraiment isolé la cause de la lenteur avec certitude.
L'énumération des instances de Win32_Account (ou de Win32_AccountSID)
mettait beaucoup plus de temps hier lors de mes tests. Aujourd'hui c'est
un peu plus vif, peut-être un effet "cache"? Je referai des tests plus
poussés à l'occasion.

<...>

Et en batch en une seule ligne (testé sous XP SP1/SP2) :

-- Coupez ici : lookup.cmd --

@for /f "delims= tokens=2" %%i in ('reg query hku ^| find "S-1" ^| find
/v "Classes"') do @for /f "delims=," %%j in ('sid2name %%i') do @echo
%%i,%%j

-- Coupez ici : lookup.cmd --

J'hésite toujours à utiliser des commandes externes car je dépend alors
fortement du format de leur affichage dans mon analyse des données. Mais
après tout, j'ai déjà changé la donne en introduisant sid2name.exe, et
puis reg.exe est une commande standard sous XP! Alors voici une adaptation
de mes deux lignes PowerShell en une seule grâce à reg et sid2name:

reg query hku | % {if ($_ -match "S-.+d$") {"{0},{1}" -f $matches[0],
(sid2name $matches[0]).split(",")[0]}}

Jacques

Vous avez filtré cet utilisateur ! Consultez son message

Gilles LAURENT

27/08/2006 à 11:33

"Fred" a écrit dans le message de
news:%
| Bonjour,

Bonjour,

[...]

| Ensuite je fais 'appel à Win32_SID.SID pour récupérer le compte.

Bien vu Fred ;-)
Du coup les performances sont bien meilleurs !
Je viens de faire la modification et donc repost le script :

-- Coupez ici : Lookup2.vbs --

Option Explicit

' déclaration des variables
Dim objWMI, objReg, objAccnt
Dim arrSubKeys
Dim item, subkey

' initialisation
Set objWMI = GetObject ("winmgmts:rootcimv2")
Set objReg = GetObject ("winmgmts:rootdefault:StdRegProv")

' énumération des clés HKEY_USERS et conversion des SID en Nom
' la relation SID <-> Nom est stockée dans le dictionnaire
objReg.EnumKey &H80000003, "", arrSubKeys
For Each subkey In arrSubKeys
If IsNumeric (Right (subkey,1)) Then
Set objAccnt = objWMI.Get ("Win32_SID.SID='" & subKey & "'")
WScript.Echo subkey & "," & _
objAccnt.ReferencedDomainName & "" & objAccnt.AccountName
End If
Next

-- Coupez ici : Lookup2.vbs --

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

Gilles LAURENT

27/08/2006 à 11:49

"Jacques Barathon [MS]" a écrit dans le
message de news:%23$

Bonjour,

| Pour info, j'ai posté un billet sur mon blog à ce sujet, où je propose
| également une version PowerShell des outils sid2name et name2sid:
|
| http://janel.spaces.live.com/blog/cns!9B5AA3F6FA0088C2!203.entry
|
| Jacques

C'est parfait ! Cependant, Fred à mis en lumière l'objet WMI Win32_SID
Je compte sur vous pour adapter votre script Powershell ;-)

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

Gilles LAURENT

27/08/2006 à 11:53

"Gilles LAURENT" a écrit dans le message de
news:
| C'est parfait ! Cependant, Fred à mis en lumière l'objet WMI Win32_SID

Il faut bien entendu lire la classe (et non l'objet) WMI Win32_SID :-(

--
Gilles LAURENT
Me contacter : http://cerbermail.com/?zoTY7ZkLcD

Fred

27/08/2006 à 12:18

dans : news:OCJr%,
Gilles LAURENT écrivait :

"Fred" a écrit dans le message de
news:%
Bonjour,

Bonjour,

[...]

Ensuite je fais 'appel à Win32_SID.SID pour récupérer le compte.

Bien vu Fred ;-)
Du coup les performances sont bien meilleurs !

J'ai jeté un ½il à la page de Jacques et aux classes .NET qu'il utilise.
Cela sera probablement plus rapide car cela finit par faire appel à une
API Win32, sans passer par la couche WMI.
Mais je pense que le principe est très proche de ce que j'avais trouvé
(tout à fait fortuitement d'ailleurs).

--
Fred
http://www.cerbermail.com/?3kA6ftaCvT

User ID > User Name

9 réponses

Veuillez sélectionner un problème