VBScript: Verwenden von WScript.Shell zum Ausführen eines Befehlszeilenprogramms, das auf Active Directory zugreift

Ich versuche, ein .NET (3.5)-Befehlszeilenprogramm aus einer VBScript-Datei auszuführen, die zwei Hauptdinge ausführt:

  • Stellt eine Verbindung mit einem Active Directory her, das sich in derselben Domäne wie der Server befindet, auf dem das Skript gehostet wird, um einen Attributwert abzurufen. Ich suche AD mit dem ersten Befehlszeilenargument, das ein Benutzername ist.
  • Erstellt einen DTO mit diesem Attributwert und dem zweiten Befehlszeilenargument, das dann in einem WCF-Dienstaufruf verwendet wird.

Wenn ich die Anwendung explizit ausführe, funktioniert alles. Auf Active Directory wird zugegriffen, das Attribut abgerufen und der WCF-Dienst wird mit dem richtigen Ergebnis aufgerufen (wie durch Betrachten der Datenbank überprüft).

(Bearbeiten: Ich entschuldige mich, ich habe vergessen, das eigentliche Problem zu setzen.)

Wenn ich das Skript ausführe, scheint es, als ob ich in meinem .NET-Code (der MyProgram-App) nicht auf Active Directory zugreifen kann.

Der VBScript-Code:

Dim objResult

Set objShell = WScript.CreateObject("WScript.Shell")    
objResult = objShell.Run("MyProgram " & strUsername & " 0", 1, True) 

Benötigt das WScript.Shell-Objekt spezielle Berechtigungen für die Datei? Ich habe sie überprüft und die Execute-Berechtigung ist vorhanden. Typischerweise das zweite Argument, das ich an die übergehe. Run()-Methode wäre 6, ich wollte, dass es 1 für das Debuggen ist.

Gibt es eine andere Möglichkeit für mich, ein Programm in VBScript auszuführen?

Antwort auf "VBScript: Verwenden von WScript.Shell zum Ausführen eines Befehlszeilenprogramms, das auf Active Directory zugreift " 4 von antworten

Wenn Sie WScript.Shell ausführen, wird es unter dem lokalen Systemkonto ausgeführt, dieses Konto verfügt über vollständige Rechte auf dem Computer, aber keine Rechte in Active Directory.

http://support.microsoft.com/kb/278319

Shiraz' Idee mitnehmen und damit laufen...

Definieren Sie in Ihrer Anwendung explizit ein Domänenbenutzerkonto und Kennwort für den Zugriff auf AD?

Wenn Sie die Anwendung explizit ausführen, kann es sein, dass sie inhärent Ihre Anmeldeinformationen (Ihr derzeit eingeloggtes Domänenkonto) verwendet, um AD abzufragen. Wenn Sie die Anwendung jedoch über das Skript aufrufen, bin ich mir jedoch nicht sicher, ob sich die Anwendung im Systemkontext befindet.

Ein VBScript-Beispiel wäre wie folgt:

  Dim objConnection As ADODB.Connection
    Set objConnection = CreateObject("ADODB.Connection")
    objConnection.Provider = "ADsDSOObject"
    objConnection.Properties("User ID") = "MyDomain\MyAccount"
    objConnection.Properties("Password") = "MyPassword"
    objConnection.Open "Active Directory Provider"

Wenn dies funktioniert, wäre es natürlich eine bewährte Methode, ein Dienstkonto speziell für diese Aufgabe zu erstellen und zu verwenden und die interaktive Anmeldung für dieses Konto zu verweigern.

Dies ist keine Antwort (ich kann keine Kommentare posten), nur wenige zufällige Ideen könnten hilfreich sein. Leider habe ich mich nie mit Citrix beschäftigt, sondern nur mit normalen Windows-Servern.

_0. Stellen Sie sicher, dass Sie kein Opfer der Windows-Firewall oder einer anderen persönlichen Firewall sind, die Prozesse selektiv blockiert.

Fügen Sie der ersten Zeile Ihrer .NET-App 10 Minuten Sleep() hinzu, führen Sie dann sowohl die VBScript-Datei als auch Ihre eigenständige Anwendung aus, führen Sie den sysinternals-Prozess-Explorer aus und vergleichen Sie 2 Prozesse.

_1. Gleiche Registerkarte, "Befehlszeile" und "aktuelles Verzeichnis". Stellen Sie sicher, dass sie identisch sind.

_2. Registerkarte "Umgebung". Stellen Sie sicher, dass sie identisch sind. Normalerweise erben untergeordnete Prozesse die Umgebung, aber dieses Verhalten kann leicht geändert werden.

Die folgende Prüfung ist erforderlich, wenn Sie mit "mein Skript ausführen" etwas anderes meinen, dann doppelklicken Sie auf die . VBS-Datei:

_3. Bild-Registerkarte, "Benutzer". Wenn sie sich unterscheiden - es kann bedeuten, dass der Benutzer keinen Zugriff auf das Netzwerk hat (z. B. localsystem), oder benutzertoken auf die Delegierung beschränkt und daher nur auf lokale Ressourcen zugreifen kann (wie im Fall von IIS NTLM auth), oder benutzer hat keinen Zugriff auf einige lokale Dateien, die er möchte.

Das Problem stellte sich als zertifikatsbezogen heraus. Der von der Konsolen-App aufgerufene WCF-Dienst verwendet ein X509-Zertifikat für die Authentifizierung, das auf den Servern installiert ist, von denen dieses Skript gehostet und ausgeführt wird.

Auf anderen Servern, auf denen dieselben Dienste verbraucht werden, wurden die Zertifikate wie folgt konfiguriert:

winhttpcertcfg.exe -g -c LOCAL_MACHINE\My -s "certificate-name" -a "NETWORK SERVICE"

Wie sie im Kontext von IIS ausgeführt wurden. Wenn das Skript jedoch wie in der Produktion ausgeführt wird, liegt es im Kontext des Benutzers selbst. Also musste das Skript wie folgt geändert werden:

winhttpcertcfg.exe -g -c LOCAL_MACHINE\My -s "certificate-name" -a "USERS"

Sobald diese Änderung vorgenommen wurde, war alles in Ordnung. Vielen Dank an alle, die Hilfe angeboten haben.