none
Remote-Management über HTTPS-Transport: Zugriff verweigert RRS feed

  • Frage

  • Hallo Community,

    seit der Umstellung der SA am 1. Oktober lässt MS seine Kunden im Regen stehen. Statt Bugs zu erkennen und zu beheben, wurde mir mitgeteilt, dass Fehler die bereits von Beginn an auftreten, kein Problem von MS sind. Bedeutet wohl auch, wenn der Windows Installer mit einer Fehlermeldung abbricht, dass sie dafür auch nicht mehr zuständig sind. Weil es vorher ja auch nie funktioniert hat. Auf die Frage, wer das Problem erörtert und beseitigt, wurde ich auf Planning Services verwiesen. Und auf die Frage wer der Ansprechpartner wäre, erhielt ich als Antwort - O-Ton: Geben Sie Planning Services in die Suchmaschine ein und suchen Sie sich einen Ansprechpartner heraus. Ich kann ihnen da nicht helfen, wir sind dafür nicht verantwortlich. -. What?

    Vielleicht erwarte ich für die teuere SA ja auch zu viel, aber es ist eine schlechte Entwicklung und werde diesen "Service" in zukünftige Entscheidungen einfließen lassen, wenn es um die Auswahl von Produkten geht. 

    Soweit zum Service, ich möchte unser eigentliches Problem erörtern. Wir haben WinRM gemäß Dokumentation aktiviert und den HTTPS-Transport auf einem aktuell gepatchten Exchange 2013 STD, mit beiden Rollen installiert, konfiguriert. Folgende Settings wurden gesetzt:

    • Listener angelegt, self-signed Zertifikat an Port 5986 gebunden, Hostname im FQDN hinterlegt
    • Zertifikat in die Trusted CAs aufgenommen
    • TrustedHosts konfiguriert: *
    • Config des virt. Verz. ist Default. Basis Dir verweist auf: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell.
    • Bindings der FrontEnd-Website sowohl auf 80 und 443
    • Benutzerkonto ist Domain und Organization Admin sowie RemotePowerShellEnabled = True

    Die Verbindung mittels HTTP und Kerberos kommt zustande:

    $session=new-pssession -configurationname Microsoft.Exchange -connectionuri http://Server-FQDN/PowerShell -authentication Kerberos -allowredirection

    Beim Aufbau der verschlüsselten Verbindung erhalten wir einen Zugriffsfehler:

    $sessionoption = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
    $session=new-pssession -configurationname Microsoft.Exchange -connectionuri https://Server-FQDN/PowerShell -authentication Kerberos -allowredirection -sessionoption $sessionoption

    Ergebnis:

    • new-pssession : [Server-FQDN] Connecting to remote server exchange.dev-the-inter.net failed with the
      following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
      At line:1 char:10
      + $session=new-pssession -configurationname Microsoft.Exchange -connectionuri http ...
      + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
         gTransportException
          + FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailedConfig

    Das lässt sich nicht wirklich erklären. Firewall ist deaktiviert. Der Benutzer ist Domain und Organization Admin, RemotePowerShellEnabled = true. Zugriff ist möglich, aber eben nur über HTTP. Die Config von WinRM sieht wie folgt aus.

        MaxEnvelopeSizekb = 500
        MaxTimeoutms = 60000
        MaxBatchItems = 32000
        MaxProviderRequests = 4294967295
        Client
            NetworkDelayms = 5000
            URLPrefix = wsman
            AllowUnencrypted = true
            Auth
                Basic = true
                Digest = true
                Kerberos = true
                Negotiate = true
                Certificate = true
                CredSSP = false
            DefaultPorts
                HTTP = 5985
                HTTPS = 5986
            TrustedHosts = *
        Service
            RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
            MaxConcurrentOperations = 4294967295
            MaxConcurrentOperationsPerUser = 1500
            EnumerationTimeoutms = 240000
            MaxConnections = 300
            MaxPacketRetrievalTimeSeconds = 120
            AllowUnencrypted = true
            Auth
                Basic = false
                Kerberos = true
                Negotiate = true
                Certificate = false
                CredSSP = false
                CbtHardeningLevel = Relaxed
            DefaultPorts
                HTTP = 5985
                HTTPS = 5986
            IPv4Filter = *
            IPv6Filter = *
            EnableCompatibilityHttpListener = false
            EnableCompatibilityHttpsListener = false
            CertificateThumbprint
            AllowRemoteAccess = true
        Winrs
            AllowRemoteShellAccess = true
            IdleTimeout = 7200000
            MaxConcurrentUsers = 10
            MaxShellRunTime = 2147483647
            MaxProcessesPerShell = 25
            MaxMemoryPerShellMB = 1024
            MaxShellsPerUser = 30

    Zugriff auf WinRM über den konf. Port funktioniert:

    winrm identify -r:https://Server-FQDN:5986 -auth:kerberos -encoding:utf-8
    IdentifyResponse
        ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
        ProductVendor = Microsoft Corporation
        ProductVersion = OS: 6.3.9600 SP: 0.0 Stack: 3.0
        SecurityProfiles
            SecurityProfileName = http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/http/spnego-kerb
    eros, http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/https/spnego-kerberos

    Also liegt das Problem offensichtlich am Exchange. Der Powershell Proxy funktioniert nicht. Vielen Dank für eure Unterstützung. Viele Grüße, Matthias


    Mittwoch, 28. Oktober 2015 10:13

Antworten

  • Ich habe mir selbst helfen können. Der Support sollte sich davon mal eine Scheibe abschneiden. Das wird bei den Überlegungen zur Bestellung der Software Assurance mit einfließen. 

    Lösung: Sowohl auf dem Frontend als auch Backend ist die Windowsauthentifizierung für das PowerShell-Directory zu aktivieren.

    Matthias

    • Als Antwort markiert Matthias S. _ Mittwoch, 28. Oktober 2015 17:30
    Mittwoch, 28. Oktober 2015 17:29

Alle Antworten

  • Hallo,

    das ist sicher starker Tobak. Daher habe ich versucht, den Fehler weiter einzugrenzen. Ein Trace ergab, dass die Kerberos-Authentifzierung über HTTPS fehl schlägt. WinRM erhält vom Webserver den Response 401.111: Access denied. Daher kommt also die Fehlermeldung beim Eröffnen der PSSession. Es treten keine Fehler im Ereignis Log auf.

    WinRM ist also definitiv fehlerfrei, jetzt muss nur noch herausgefunden werden, warum das Kerberos Ticket nicht weitergereicht wird. Möglicherweise gibt es ja einen Experten, der diesen Fall bereits aus anderen Situation her kennt.

    Hier ein paar Details aus dem Trace. Erster Anwendungsfall die Verbindung via HTTP:

    Url http://Server-FQDN:80/PowerShell?PSVersion=4.0
    App Pool MSExchangePowerShellFrontEndAppPool
    Authentication Kerberos
    User from token Domain\Admin


    Anschließend wird die Sitzung hergestellt:

    Url http://Server-FQDN:80/PowerShell?PSVersion=4.0&sessionID=Version_15.0_(Build_1103.0)=rJqN..Token..yw==
    App Pool MSExchangePowerShellFrontEndAppPool
    Authentication Kerberos
    User from token Domain\Admin


    Nun genau der selbe Vorgang über HTTPS:

    Url https://Server-FQDN:443/PowerShell?PSVersion=4.0
    App Pool MSExchangePowerShellFrontEndAppPool
    Authentication NOT_AVAILABLE
    User from token

    Wie man gut sehen kann, wird hier der User gar nicht erst übergeben. Demzufolge läuft der Vorgang in einen KERBAUTH_ERROR. Um sicherzugehen, dass die Kerberos Auth. bereits am WinRm scheitert, eröffnete ich eine PSSession über SSL.

    Invoke-Command -ComputerName Server-FQDN -Port 5986 -Authentication Kerberos -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck) -ScriptBlock { Write-Host "Hello from $($env:ComputerName)" }

    Ergebnis war positiv. 

    Viele Grüße,
    Matthias

    Mittwoch, 28. Oktober 2015 14:01
  • Ich habe mir selbst helfen können. Der Support sollte sich davon mal eine Scheibe abschneiden. Das wird bei den Überlegungen zur Bestellung der Software Assurance mit einfließen. 

    Lösung: Sowohl auf dem Frontend als auch Backend ist die Windowsauthentifizierung für das PowerShell-Directory zu aktivieren.

    Matthias

    • Als Antwort markiert Matthias S. _ Mittwoch, 28. Oktober 2015 17:30
    Mittwoch, 28. Oktober 2015 17:29
  • Moin,

    gebe mir mal bitte die Ticket-Nummer.

    ;)


    Gruß Norbert

    Mittwoch, 28. Oktober 2015 17:30
    Moderator
  • Hi Norbert,

    Ticket Nr. ist 115102713308036.

    Gruß,
    Matthias

    Mittwoch, 28. Oktober 2015 17:36
  • Setzte dich mal bitte mit mir in Verbindung, meine Seite im Profil.

    ;)


    Gruß Norbert

    Donnerstag, 29. Oktober 2015 11:56
    Moderator