Discussion :

[M0nk-]

Bonjour,

En dernier recours, je me permets de vous solliciter afin d’essayer de débloquer ma situation.
Mon objectif est le suivant : mettre en place un tableau de bord permettant de restituer les informations d’espaces disques de mes serveurs.
Le tableau de bord est une application web développée en C# .NET Framework 4.6.
Pour interroger mes serveurs, j’utilise WMI.
Mes serveurs sont tous sur des OS Windows Server 2012.
Appelons mes serveurs : Serveur1, Serveur2 et Serveur3.
Pour le WMI, j’instancie un nouvel objet ManagementScope(NameSpace, ConnectionOptions) ou je précise les options de connexion (un utilisateur qui a tous les droits).
J’exécute mon application en local depuis Visual Studio 2015, j’accède à mon tableau de bord, je récupère toutes les informations souhaitées via ma connexion WMI et la restitution de la page est immédiate.
Notons que le programme s’exécute sur un poste utilisateur qui n’est pas concerné par l’interrogation WMI.



Je déploie mon application sur mon serveur IIS, le fameux Serveur3.
J’accède à mon tableau de bord et j’obtiens un joli message d’erreur : Les références utilisateur ne peuvent pas être utilisées pour des connexions locales.
Lorsque je supprime l’interrogation du serveur Serveur3 (où l’application est déployée), pas de message d’erreur je récupère bien les informations des deux autres serveurs.

Quelqu’un aurait-il une idée ?
Je reste disponible pour fournir plus d'informations.
Merci à vous.

[ericlm128]

Et bien le message me parait clair. Lorsque que tu interroge utilise une connexion local (programme sur serveur 3 qui interroge serveur 3) tu ne peux pas utiliser le couple identifiants/mot de passe.

Tu peux les définir à null pour réussir la connexion local ou créer un deuxième ConnectionOptions

Voici une proposition pas très jolie (je sais pas ) mais qui me parait simple et logique

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
ManagementScope scope = new ManagementScope();
ConnectionOptions ConnectionOptions1 = new ConnectionOptions();
ConnectionOptions1.Username = "domaine\\ip";
ConnectionOptions1.Password = "pass";
string pc = "mon-pc";
 
try
{
    try
    {
        scope = new ManagementScope("\\\\" + pc + "\\root\\cimv2", ConnectionOptions1);
        scope.Connect();
    }
    catch (ManagementException ex) when (ex.ErrorCode == ManagementStatus.LocalCredentials)
    {
        // Exception : Les références utilisateur ne peuvent pas être utilisées pour des connexions locales. Permet de conserver les autres paramètres
 
        // Clone les options de connection et enlève les identifiants
        ConnectionOptions ConnectionOptions2 = (ConnectionOptions)ConnectionOptions1.Clone();
        ConnectionOptions2.Username = null;
        ConnectionOptions2.Password = null;
 
        // Connection en local
        scope = new ManagementScope("\\\\.\\root\\cimv2", ConnectionOptions2);
        scope.Connect();
    }
}
catch (Exception ex)
{
    // Exception lors de la connection au WMI
}

[M0nk-]

Bonjour ericlm128,

Tout d’abord merci de l'intérêt porté à ma problématique.
Je n'ai pas fournis tous les éléments dans mon premier post car je trouvais le message déjà suffisamment long.
J'ai déjà testé la solution que tu me proposes et d'ailleurs c'est celle que j'ai conservé le temps de trouver mieux.

1. Je trouve ça dommage de devoir gérer dans mon code une exception de ce type (dynamiquement je dois récupérer le nom du serveur sur lequel est hébergé l'application et positionner une condition si on essaye d’interroger ce serveur).
   
2. Cela fonctionne, mais je récupère uniquement la partition C:. Je pense que l'utilisateur utilisé par défaut n'a pas les autorisations sur les autres lecteurs.
   Cela me pose deux problèmes :
   
   • a. Je ne suis pas administrateur des serveurs et de l'AD dans mon entreprise donc je ne peux pas modifier les droits comme je le souhaiterais.
   • b. Je ne parviens pas à identifier l'utilisateur par défaut qui est utilisé lorsqu'on laisse à null les options de connexion.

Y a-t-il une autre méthode que cette double connexion ?

Merci beaucoup.

[DotNetMatt]

Je trouve ça dommage de devoir gérer dans mon code une exception de ce type (dynamiquement je dois récupérer le nom du serveur sur lequel est hébergé l'application et positionner une condition si on essaye d’interroger ce serveur).

Il n'y a pas de mal a utiliser les exceptions pour ce genre de scenario farfelu. C'est utilise a bon escient et comme ton application ne requiert pas de performance particuliere (les exceptions sont couteuses), ca fait le job.

Cela fonctionne, mais je récupère uniquement la partition C:. Je pense que l'utilisateur utilisé par défaut n'a pas les autorisations sur les autres lecteurs.
Cela me pose deux problèmes :

• a. Je ne suis pas administrateur des serveurs et de l'AD dans mon entreprise donc je ne peux pas modifier les droits comme je le souhaiterais.
• b. Je ne parviens pas à identifier l'utilisateur par défaut qui est utilisé lorsqu'on laisse à null les options de connexion.

Tu devrais utiliser un compte de service qui aurait plus de permissions qu'un utilisateur lambda.

Y a-t-il une autre méthode que cette double connexion ?

Tu peux heberger ton code au sein d'un Web Service, qui serait heberge sur un autre serveur (serveur 4 ?). Ce Web Service serait interroge par tes clients depuis les Serveurs 1 / 2 / 3.

Voila tu as deja 2 solutions a envisager : le compte de service et le web service.

[M0nk-]

Bonsoir DotNetMatt,

Tout d'abord merci du temps accordé à mon sujet.
En effet, tu m'as convaincu, c'est une exception acceptable.
J'ai décidé de maintenir cette solution.

D'autre part, l'équipe d'admin des serveurs m'a fournit un compte de service qui possède des droits étendus.
Dans IIS, j'ai configuré mon application pour qu'elle utilise ce compte utilisateur.
Cela fonctionne très bien, il accède à toutes les partitions de mon serveur.

Pour finir, si quelqu'un à une explication à cette question, je suis preneur : pourquoi ne pouvons-nous pas utiliser une référence utilisateur pour une connexion locale WMI ?

Un grand merci à tous les deux.
C'est l'équipe de prod qui va être contente, elle aura un nouvel outil de travail