none
winRM Frage RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden
    Guten Tag

    Ich habe einen PC auf welchem ich Windows Server 2012 R2 installiert habe und einen virtuellen Host über HyperV.

    Nun funktionierte einige Zeitlang winRM also damit ich über den Server-Manager glechzeitig auch den anderen Server verwalten kann z.B neue Rolle auf einen Remote-Server installieren oder auch nur das herunterfahren des anderen Servers. Nun hatte ich mal das IP-Konsept geändert und seither funktioniert winRM nicht mehr.

    Als Fehlermeldung erhalte ich:
    http://www.mcseboard.de/uploads/monthly_02_2016/post-71616-0-31611600-1456244547.png

    Wirklich viel Ahnung von winRM habe ich leider jedoch nicht. Die wenigen Seiten die Hilfe anbieten und die Grundlagen vermitteln sind oft sehr komplex sodass ich diese ohne weiteres icht verstehe.

    Kann mir jemand weiterhelfen und eventuell kurz die Grundlagen erläutern. Z.B Dienstprinzipal-Name (SPN) was das ist und was dazu noch gehört.

    Herzlichen Dank.


    Liebe Grüsse
    Nicolas

    • Bearbeitet Nicolas8989 Montag, 29. Februar 2016 16:39
    Montag, 29. Februar 2016 16:27
    |

Alle Antworten

  • Question
    Anmelden
    2
    Anmelden
    Hallo Nicolas, führe mal bitte auf dem remote server den du verwalten möchtest den befehl "ipconfig /registerdns" und auf dem management server "ipconfig /flushdns" ... Genau in der reihenfolge. Schau mal ob das schon fixed. Den rest erklär ich dir nachher, sitze gerade im zug.

    Kind regards, Flo


    Montag, 29. Februar 2016 19:16
    |
  • Question
    Anmelden
    2
    Anmelden

    Erläuterung Service Principal Name: 

    https://msdn.microsoft.com/de-de/library/windows/desktop/ms677949%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

    Du kannst den SPN mit einem eindeutigen DNS Namen vergleichen. 

    Bei einem Service ist es z.B. Server.Domain.Toplevel / server.datacenter-flo.de

    Bei SQL Server ist der SPN z.B. Instancename/Datenbankname

    Kind regards, Flo

    Montag, 29. Februar 2016 21:53
    |
  • Question
    Anmelden
    0
    Anmelden
    Hallo Nicolas, führe mal bitte auf dem remote server den du verwalten möchtest den befehl "ipconfig /registerdns" und auf dem management server "ipconfig /flushdns" ... Genau in der reihenfolge. Schau mal ob das schon fixed. Den rest erklär ich dir nachher, sitze gerade im zug.

    Kind regards, Flo


    Hallo Florian

    Erstmals danke für deine Hilfe :-)

    Ich habe die Schritte in die von dir vorgegebenen Reihenfolge ausgeführt. Jedoch ohne Erfolg auch nachdem Refreshen des Server-Managers auf dem Management-Server. Braucht einen Reboot?

    Eine Frage habe ich jedoch, wieso "/ipconfig /flushdns" beide Server haben eine statische IP-Adresse diese ist bei beiden Servern im Netzwerk-Adapter so eingestellt. 


    Dienstag, 1. März 2016 17:45
    |
  • Question
    Anmelden
    1
    Anmelden

    Erläuterung Service Principal Name: 


    Du kannst den SPN mit einem eindeutigen DNS Namen vergleichen. 

    Bei einem Service ist es z.B. Server.Domain.Toplevel / server.datacenter-flo.de

    Bei SQL Server ist der SPN z.B. Instancename/Datenbankname

    Kind regards, Flo

    Die von dir verlinkte Seite kenne ich bereits. Ich spreche nicht sehr gut englisch, dementsprechend fällt es mir schwer solche komplexen Themen zu verstehen.

    Danke für die Grundlage bezüglich SPN. Ich habe anhand dieser Anleitung versucht das Problem zu lösen:

    https://support.microsoft.com/en-us/kb/974504

    Dabei habe ich die Schritte unter dem folgenden Punkt vorgenommen:

    - Delete the WinRM listener on port 5985

    Deshalb habe ich den SPN gelöscht und versucht neu hinzuzufügen.

    Eventuell hilft dir das ja hier:

    PS C:\Users\Administrator> winrm enumerate winrm/config/listener
    Listener
        Address = *
        Transport = HTTP
        Port = 5985
        Hostname
        Enabled = true
        URLPrefix = wsman
        CertificateThumbprint
        ListeningOn = 127.0.0.1, 169.254.40.226, 192.168.0.2, ::1, fe80::5efe:169.254.40.226%14, fe80::5efe:192.168.0.2%16,
    fe80::ffff:ffff:fffe%13, fe80::a007:7a64:64ff:28e2%15

    Die IP-Adresse 192.168.0.2 ist der Management-Server - Der Remote-Server hat am Schluss die 0.3

    Jedoch verstehe ich nicht was dieser Befehl mir da überhaupt genau anzeigt.

    Danke für deine Hilfe und einen angenehmen Abend :-)

    Gruss 

    Nicolas


    Dienstag, 1. März 2016 18:01
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 09.03.2016 schrieb Nicolass8989:

    Hat jemand noch eine Idee? Hast du meine Beiträge gelesen?

    Es haben sicherlich viele auch den Thread im MCSEBoard gelesen:
    http://www.mcseboard.de/topic/206401-winrm-funktioniert-nicht-mehr/

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Mittwoch, 9. März 2016 17:38
    |
  • Question
    Anmelden
    0
    Anmelden

    Habe nochmals etwas herumprobiert hier noch mehr Infos zum Fehler:

     

    Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "testsrv3$" empfangen. Der verwendete Zielname war DNS/testsrv3.deb.test. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Server verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort für das Zieldienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (DEB.TEST) von der Clientdomäne (DEB.TEST) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren

    Freitag, 11. März 2016 15:31
    |
  • Question
    Anmelden
    0
    Anmelden

    hm :/ mir gehen auch langsam die ideen aus. 

    check mal ob du eine zeitdifferenz größer 5 minuten zum dc hast und welche IP du auf "nslookup <servername/spn>" bekommst. 


    Kind regards, Flo

    Freitag, 11. März 2016 15:43
    |
  • Question
    Anmelden
    1
    Anmelden
    > Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server
     
    Klingt nach "krbtgt-Kennwort asynchron"...
     
    Montag, 14. März 2016 10:48
    |
  • Question
    Anmelden
    0
    Anmelden

    hm :/ mir gehen auch langsam die ideen aus. 

    check mal ob du eine zeitdifferenz größer 5 minuten zum dc hast und welche IP du auf "nslookup <servername/spn>" bekommst. 


    Kind regards, Flo

    Mh. Welche Zeitdifferenz? Die zwischen beiden Servern, also dem Management-Server und Remote-Server? Die Zeit zwischen den beiden Servern stimmt auf die Sekunde genau. Ich prüfe die Zeit mit uhrzeit.org, meine beiden Server weichen nur ca. PlusMinus 3 Sek ab.

    Auf dem Management-Server und Remote-Server habe ich "nslookup testsrv2/spn" gemacht:

    Management-Server:

    Windows PowerShell
    Copyright (C) 2014 Microsoft Corporation. Alle Rechte vorbehalten.

    PS C:\Users\Administrator> nslookup testsrv2/spn
    Server:  testsrv2.deb.test
    Address:  192.168.0.2

    *** testsrv2/spn wurde von testsrv2.deb.test nicht gefunden: Non-existent domain.
    PS C:\Users\Administrator> nslookup testsrv3/spn
    Server:  testsrv2.deb.test
    Address:  192.168.0.2

    *** testsrv3/spn wurde von testsrv2.deb.test nicht gefunden: Non-existent domain.
    PS C:\Users\Administrator> nslookup testsrv3
    Server:  testsrv2.deb.test
    Address:  192.168.0.2

    Name:    testsrv3.deb.test
    Address:  192.168.0.3

    PS C:\Users\Administrator> nslookup testsrv2
    Server:  testsrv2.deb.test
    Address:  192.168.0.2

    Name:    testsrv2.deb.test
    Address:  192.168.0.2

    PS C:\Users\Administrator>


    Auf dem Remote-Server:

    PS C:\Users\administrator.DEB>  nslookup testsrv2/spn
    Server:  testsrv3.deb.test
    Address:  192.168.0.3

    *** testsrv2/spn wurde von testsrv3.deb.test nicht gefunden: Non-existent domain.
    PS C:\Users\administrator.DEB>  nslookup testsrv3/spn
    Server:  testsrv3.deb.test
    Address:  192.168.0.3

    *** testsrv3/spn wurde von testsrv3.deb.test nicht gefunden: Non-existent domain.
    PS C:\Users\administrator.DEB>  nslookup testsrv3
    Server:  testsrv3.deb.test
    Address:  192.168.0.3

    Name:    testsrv3.deb.test
    Address:  192.168.0.3

    PS C:\Users\administrator.DEB>  nslookup testsrv2
    Server:  testsrv3.deb.test
    Address:  192.168.0.3

    Name:    testsrv2.deb.test
    Address:  192.168.0.2

    PS C:\Users\administrator.DEB>

    Also beiden DCs können sich gegenseitig auflösen das klappt ja.

    Habe mir gerade überlegt, muss "SPN" muss doch auch durch den eigentlichen Dienstnamen ausgetauscht werden. Habe etwas von "wsman" gelesen?

    Habs einfach mal mit "nslookup testsrv2/wsman" probiert auch gleicher Fehler wie oben.

    Hoffe, du kommst dem Fehler nun auf die Spur :-) 

    Grusss

    Nicolas



    Dienstag, 15. März 2016 14:17
    |
  • Question
    Anmelden
    0
    Anmelden
    > Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server
     
    Klingt nach "krbtgt-Kennwort asynchron"...
     

    Welches Kennwort? Habe das Windows Domänen-Kennwort des Admins nie geändert. Somit sollte das nicht das Problem sein oder?

    Dienstag, 15. März 2016 14:31
    |
  • Question
    Anmelden
    0
    Anmelden
    > Welches Kennwort?
     
     
    Das Kennwort wird als Secret im TGT verwendet, und wenn das nicht auf allen DCs identisch ist, passieren die lustigsten Sachen bei der Authentifizierung.
    Dienstag, 15. März 2016 15:54
    |
  • Question
    Anmelden
    0
    Anmelden
    > Welches Kennwort?
     
     
    Das Kennwort wird als Secret im TGT verwendet, und wenn das nicht auf allen DCs identisch ist, passieren die lustigsten Sachen bei der Authentifizierung.

    Verstehe nicht gerade viel... Was ist TGT? Was ich gefunden habe, ist ein Power-Shell-Script, welches diesen Secret Key zurücksetzt. Soll ich das mal ausprobieren oder was denkst du?

    Weshalb wurde den dieser Key möglicherweise geändert? Was hat das für Gründe?

    Edit:

    Habe das Skript ausgeführt jedoch kommt immer noch der Fehler, hier der Log:

    ScriptMode                      : 3
    PreFlightPassed                 : True
    DomainModePassed                : True
    NMinusOneTicketExpirationPassed : True
    RpcToDCsPassed                  : False

    Mittwoch, 16. März 2016 14:27
    |
  • Question
    Anmelden
    0
    Anmelden
    > Verstehe nicht gerade viel... Was ist TGT? Was ich gefunden habe, ist
     
     
    > ein Power-Shell-Script, welches diesen Secret Key zurücksetzt. Soll ich
    > das mal ausprobieren oder was denkst du?
     
    Ich weiß ja nicht, ob es daran liegt - es klingt halt danach. Lösung
    normalerweise:
     
    Auf betroffenem DC den KDC Dienst beenden und deaktivieren. Dann neu
    booten. KDC wieder aktivieren und starten.
     
    > Weshalb wurde den dieser Key möglicherweise geändert? Was hat das für
    > Gründe?
     
    Replikationsprobleme... Die DCs ändern das Kennwort zyklisch, und wenn
    einer die Änderung nicht mitbekommt, ist es dort asynchron - und alle
    Kerberos-Tickets, die der jetzt ausstellt, sind für die anderen ungültig.
     
     
    Mittwoch, 16. März 2016 16:24
    |
  • Question
    Anmelden
    0
    Anmelden
    > Verstehe nicht gerade viel... Was ist TGT? Was ich gefunden habe, ist
     
    > ein Power-Shell-Script, welches diesen Secret Key zurücksetzt. Soll ich
    > das mal ausprobieren oder was denkst du?
     
    Ich weiß ja nicht, ob es daran liegt - es klingt halt danach. Lösung
    normalerweise:
     
    Auf betroffenem DC den KDC Dienst beenden und deaktivieren. Dann neu
    booten. KDC wieder aktivieren und starten.
     
    > Weshalb wurde den dieser Key möglicherweise geändert? Was hat das für
    > Gründe?
     
    Replikationsprobleme... Die DCs ändern das Kennwort zyklisch, und wenn
    einer die Änderung nicht mitbekommt, ist es dort asynchron - und alle
    Kerberos-Tickets, die der jetzt ausstellt, sind für die anderen ungültig.
     
     

    Dieser "KDC-Proxyserverdienst (KPS)" Dienst ist bei meinen beiden DCs also beim Remote-Server und dem Management-Server auf manuell gesetzt, dazu sind die Dienste nicht gestartet. Wenn ich den Dienst versuche zu starten erhalte ich ein Fehler: "Fehler 5 - Zugriff verweigert" Mehr steht da in der Ereignisanzeige auch nicht drin. Auch beim Remote-Server selbes Problem, beim Starten des Dienstes kommt ein Fehler 5 mit Zugriff verweigert.

    Der Dienst "Kerberos-Schlüsselverteilungscenter" läuft hingegen und wird auf beiden DCs ausgeführt. Immerhin!

    Ich habe den Dienst "KPSSVC" KDC-Proxyserverdienst (KPS) deaktiviert auf dem Management-Server, danach den Management-Server neugestartet und den Dienst wieder aktiviert und versucht zu starten. Dann kam wieder die oben genannte Fehlermeldung. 

    Muss das Deaktivieren des Dienstes auf beiden Servern gemacht werden?

    //Edit: Versuche noch ein sfc.exe auszuführen - eventuell hat der Dienst ein Problem...

    Ich habe noch versucht mit dem Befehl: "klist purge" die Kerberos-Ticket-Cache zu löschen. Eventuell hilft das ja...

    Hat alles nichts genützt. Weder das Löschen der Kerberos Ticket noch sfc. SFC hat Fehler gefunden, die jedoch nicht repariert werden konnten.




    Montag, 21. März 2016 15:55
    |
  • Question
    Anmelden
    0
    Anmelden
    Habs bisher einfach nicht hinbekommen. Hat jemand noch einen Rat?
    Donnerstag, 24. März 2016 15:46
    |
  • Question
    Anmelden
    0
    Anmelden

    Guten Tag

    Ich möchte auf mein Problem unter https://social.technet.microsoft.com/Forums/de-DE/31ae6096-b4fe-4c63-84bd-6af2bfe71ca1/winrm-frage?forum=windowsserver8de&prof=required

    aufmerksam machen. Leider habe ich seit einiger Zeit keine Antwort mehr erhalten. Kann mir jemand weiterhelfen?

    Hier noch der letzte Schritt:

    > Verstehe nicht gerade viel... Was ist TGT? Was ich gefunden habe, ist
     
    > ein Power-Shell-Script, welches diesen Secret Key zurücksetzt. Soll ich
    > das mal ausprobieren oder was denkst du?
     
    Ich weiß ja nicht, ob es daran liegt - es klingt halt danach. Lösung
    normalerweise:
     
    Auf betroffenem DC den KDC Dienst beenden und deaktivieren. Dann neu
    booten. KDC wieder aktivieren und starten.
     
    > Weshalb wurde den dieser Key möglicherweise geändert? Was hat das für
    > Gründe?
     
    Replikationsprobleme... Die DCs ändern das Kennwort zyklisch, und wenn
    einer die Änderung nicht mitbekommt, ist es dort asynchron - und alle
    Kerberos-Tickets, die der jetzt ausstellt, sind für die anderen ungültig.
     
     

    Dieser "KDC-Proxyserverdienst (KPS)" Dienst ist bei meinen beiden DCs also beim Remote-Server und dem Management-Server auf manuell gesetzt, dazu sind die Dienste nicht gestartet. Wenn ich den Dienst versuche zu starten erhalte ich ein Fehler: "Fehler 5 - Zugriff verweigert" Mehr steht da in der Ereignisanzeige auch nicht drin. Auch beim Remote-Server selbes Problem, beim Starten des Dienstes kommt ein Fehler 5 mit Zugriff verweigert.

    Der Dienst "Kerberos-Schlüsselverteilungscenter" läuft hingegen und wird auf beiden DCs ausgeführt. Immerhin!

    Ich habe den Dienst "KPSSVC" KDC-Proxyserverdienst (KPS) deaktiviert auf dem Management-Server, danach den Management-Server neugestartet und den Dienst wieder aktiviert und versucht zu starten. Dann kam wieder die oben genannte Fehlermeldung. 

    Muss das Deaktivieren des Dienstes auf beiden Servern gemacht werden?

    //Edit: Versuche noch ein sfc.exe auszuführen - eventuell hat der Dienst ein Problem...

    Ich habe noch versucht mit dem Befehl: "klist purge" die Kerberos-Ticket-Cache zu löschen. Eventuell hilft das ja...

    Hat alles nichts genützt. Weder das Löschen der Kerberos Ticket noch sfc. SFC hat Fehler gefunden, die jedoch nicht repariert werden konnten.

    Danke!!

    Gruss

    Nicolas


    Mittwoch, 30. März 2016 18:25
    |
  • Question
    Anmelden
    0
    Anmelden
    Kann mir bitte jemand weiterhelfen? Das Problem besteht leider nachwievor. :(
    Montag, 25. April 2016 18:32
    |