none
Exchange Powershell Kommandos in fremde Domäne mit RUNAS RRS feed

  • Frage

  • Hallo Experten,

    ich habe eine etwas außergewöhnlich Frage:
    Ich möchte von einem Rechner, welcher in der produktiven AD Domäne hängt, Powershell Kommandos in eine Testdomäne absetzen. Es gibt keinen Trust zwischen produktiver Domäne und Test-Domäne.

    Ich habe auf dem Rechner die Exchange Management Tools installiert, ich kann jetzt auf dem produktiven AD Kommandos abschicken, wie etwa get-mailbox.

    Für das Test-Active-Directory und dem damit verbundenen Test-Exchange Server (2010) funktioniert das noch nicht. Wenn ich den Befehl: runas /netonly /user:testdomain.com/serviceuser "get-mailbox" aufrufe, erhalte ich zunächst den password prompt und dann die Fehlermeldung RUNAS ERROR: Unable to acquire user password

    Testdomäne und Produktivdomäne kennen sich nicht. Testdomain.com kann aber aufgelöst werden. Kann mir jemand einen Tipp geben, wie ich dieses Szenario zum Laufen bekomme?

    Viele Grüße,
    Sebastian

    Dienstag, 22. Februar 2011 10:32

Antworten

Alle Antworten

  • Bevor wir tiefer schürfen: hast du das runas Kommando exakt so eingetippt?
    wenn ja, mach mal zwischen Domäne und Username einen Backslash (\ ) statt einem /.

    Grüße, Denniver


    http://bytecookie.wordpress.com/
    Dienstag, 22. Februar 2011 11:36
    Moderator
  • Ein sehr guter Hinweis, danke!

    Jetzt erhalte ich den Fehler, den ich vorher schon hatte, u.a. mit der Schreibweise serviceuser@testdomain.com
    runas /netonly /user:testdomain.com\serviceuser "get-mailbox"
    Ich bekomme nun folgenden Output:

    [PS] L:\>runas /netonly /user:testdomain.com\serviceuser "get-mailbox"
    Enter the password for testdomain.com\serviceuser:
    Attempting to start get-mailbox as user "testdomain.com\serviceuser " ...
    RUNAS ERROR: Unable to run - get-mailbox
    2: The system cannot find the file specified.

    Das verwendete Passwort ist dabei völlig egal, die Fehlermeldung bleibt gleich. Der gleiche Befehl mit "ping www.microsoft.com" statt "get-mailbox" ist übrigens erfolgreich.

    Hast du noch ne Idee?

    Dienstag, 22. Februar 2011 12:45
  • Hab ich das richtig verstanden, du führst z.b.:

    runas /netonly /user:testdomain.com\serviceuser "ping localhost"

    aus und die Fehlermeldung lautet nun: "...The system cannot find the file specified." ?

    Mhm. Sind in der Testdomain GPOs aktiv? Z.b. mit Softwarerichtlinien?

    Grüße, Denniver

     


    http://bytecookie.wordpress.com/
    Dienstag, 22. Februar 2011 15:17
    Moderator
  • Danke für die Antwort. Das werde ich nachprüfen. Der PING wurde schon erfolgreich ausgeführt.

    Ich habe inzwischen viel probiert, beim Befehl:

    $c = get-credential
    get-mailbox -credential $c -DomainController dc1.testdomain.com -server HOST123

    Dieser Befehl löst folgende Fehlermeldung aus:

    Get-Mailbox : An Active Directory error 0x8007052E occurred while searching for
     domain controllers in domain proddomain.com: Logon failure: unknown user name
    or bad password.
    At line:1 char:12
    + get-mailbox <<<<  -credential $c -DomainController dc1.testdomain.com -server HOST123
        + CategoryInfo          : NotSpecified: (0:Int32) [Get-Mailbox], ADOperati
       onException
        + FullyQualifiedErrorId : 53A67889,Microsoft.Exchange.Management.Recipient
       Tasks.GetMailbox

    Kann das ein DNS-Problem sein? Leider sind die beiden Domänen einander unbekannt und ich habe die oben verwendeten Hostnamen in die .hosts Datei aufgenommen. Wenn jedoch ein nslookup durchgeführt wird, funktioniert das natürlich nicht.

    Gruß,
    Sebi

    Dienstag, 22. Februar 2011 16:16
  • Hallo Sebi

    ohne Trust wird eine Authentifizierung gegen den Remote DC immer fehlschlagen. Der DC den Du über den -DomainController Parameter angibst, wird über die Domäne in der das CMDLet ausgeführt wird, aufgelöst. i.e. Du führst den Befehl in prod aus, wird der dc1 aus test in der prod Domäne gesucht.

    Ich habe es selber noch nicht ausprobiert, aber Du könntest es mal per PowerShell Remoting ausprobieren. Theoretisch sollte damit mindestens ein lokaler Zugriff auf die Remote Maschine möglich sein:

    http://blogs.msdn.com/b/wmi/archive/2009/07/24/powershell-remoting-between-two-workgroup-machines.aspx

    Gruß
    Andrei

    Donnerstag, 24. Februar 2011 12:30
    Moderator