Strony

wtorek, 7 kwietnia 2015

PowerShell - The WinRM service could not use the following listener to receive WS-Management requests

Napisałem skrypt w PowerShell, który docelowo ma zdalnie odpytywać serwer o jego parametry i wpisywać wynik do bazy danych.
Lokalnie wszystko działało ok, lecz napotkałem problem przy próbie wykonania skryptu zdalnie.

Konfiguracja serwera według standarodwej procedury:
PS C:\Windows\system32> Enable-PSRemoting -Force
WinRM already is set up to receive requests on this machine.
WinRM has been updated for remote management.
WinRM firewall exception enabled. 
PS C:\Windows\system32> Set-Item wsman:\localhost\client\trustedhosts *

WinRM Security Configuration.
This command modifies the TrustedHosts list for the WinRM client. The computers in the TrustedHosts list might not be
authenticated. The client might send credential information to these computers. Are you sure that you want to modify
this list?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): Y
PS C:\Windows\system32> Restart-Service WinRM
Po stronie klietna jednak coś nie tak:
PS U:\> Enter-PSSession -computerName SERVER_NAME
Enter-PSSession : Connecting to remote server failed with the following error message : Klient nie może połączyć się zmiejscem docelowym określonym w żądaniu. Sprawdź, czy usługa w miejscu docelowym jest uruchomiona i akceptuje żądania.
Sprawdź dzienniki i zapoznaj się z dokumentacją usługi WS-Management uruchomionej w miejscu docelowym, najczęściej jest to usługa IIS lub WinRM. Jeśli usługa docelowa to WinRM, w miejscu docelowym uruchom następujące polecenie w celu przeanalizowania i skonfigurowania usługi WinRM: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:16
+ Enter-PSSession <<<<  -computerName
SERVER_NAME
    + CategoryInfo          : InvalidArgument: (
SERVER_NAME:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
oraz
PS C:\> winrm get winrm/config -r:SERVER_NAME
WSManFault
    Message = Klient nie może połączyć się z miejscem docelowym określonym w żądaniu. Sprawdź, czy usługa w miejscu doce
lowym jest uruchomiona i akceptuje żądania. Sprawdź dzienniki i zapoznaj się z dokumentacją usługi WS-Management uruchom
ionej w miejscu docelowym, najczęściej jest to usługa IIS lub WinRM. Jeśli usługa docelowa to WinRM, w miejscu docelowym
 uruchom następujące polecenie w celu przeanalizowania i skonfigurowania usługi WinRM: "winrm quickconfig".

Numer błędu:  -2144108526 0x80338012
Klient nie może połączyć się z miejscem docelowym określonym w żądaniu. Sprawdź, czy usługa w miejscu docelowym jest uru
chomiona i akceptuje żądania. Sprawdź dzienniki i zapoznaj się z dokumentacją usługi WS-Management uruchomionej w miejsc
u docelowym, najczęściej jest to usługa IIS lub WinRM. Jeśli usługa docelowa to WinRM, w miejscu docelowym uruchom nastę
pujące polecenie w celu przeanalizowania i skonfigurowania usługi WinRM: "winrm quickconfig".
Szybka diagnostyka po stronie serwera:
Wpis w EventLog ID: 10150 - Serwis WinRM nie może ustawić listener'a na porcie 5985
Log Name:      System
Source:        Microsoft-Windows-WinRM
Date:          2015-04-07 09:42:14
Event ID:      10150
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SERVER_NAME
Description:
The WinRM service could not use the following listener to receive WS-Management requests.  The listener is enabled but the listener does not have an IP address configured.

 User Action
 Check the underlying network configuration to determine if this listener has at least one valid IP. If the IP is valid, ensure that WinRM configuration does not exclude that IP address by using the following command:

 winrm get winrm/config/service

 Additional Data
 Listener transport: HTTP
 Listener address: *
PS C:\Windows\system32> winrm enum winrm/config/listener
Listener [Source="GPO"]
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = null
 Potwierdzenie: brak listenera na serwerze na porcie TCP 5985:
PS C:\Windows\system32> netstat -ano | findstr LIST | findstr 5985
PS C:\Windows\system32>
Sprawdzenie za pomocą RSoP ustawień serwisy WinRM


Rozwiązanie problemu:
Za pomocą Group Policy Object Editor modyfikujemy:

Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management\WinRM Service

Pozycję:
Allow automatic configuration of listeners

W miejscu IPv4 filter należy wpisać "*" (Gwiazdka, lub adres IP na którym ma słuchać usługa)


Ponowne RSoP powinno pokazać prowisłową konfigurację z "*"

PS C:\Windows\system32> netstat -ano | findstr LIST | findstr 5985
  TCP    0.0.0.0:5985           0.0.0.0:0              LISTENING       4
  TCP    [::]:5985              [::]:0                 LISTENING       4
PS C:\Windows\system32>
PS C:\Windows\system32> winrm enum winrm/config/listener
Listener [Source="GPO"]
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = IP.IP.IP.IP, 127.0.0.1
PS C:\> winrm get winrm/config -r:SERVER_NAME
Config
    MaxEnvelopeSizekb = 150
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        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)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 15
        EnumerationTimeoutms = 60000
        MaxConnections = 25
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = * [Source="GPO"]
        IPv6Filter [Source="GPO"]
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 180000
        MaxConcurrentUsers = 5
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 15
        MaxMemoryPerShellMB = 150
        MaxShellsPerUser = 5
Rzekł bym "bangla"
PS C:\Windows> Enter-PSSession -computerName SERVER_NAME
[SERVER_NAME]: PS C:\Users\USER_NAME\Documents> hostname
SERVER_NAME
[SERVER_NAME]: PS C:\Users\USER_NAME\Documents>

HELP:
Jak sprawdzić wersję  WinRm:
PS C:\Windows\system32> winrm id
IdentifyResponse
    ProductVendor = Microsoft Corporation
    ProductVersion = OS: 6.1.7601 SP: 1.0 Stack: 2.0

Version number for %Windir%\System32\wsmsvc.dll
WinRM version
5.2.3790.2075
0.5
6.0.6000.16386
1.0
5.1.2600.3191
1.1
5.2.3790.2990
1.1
5.2.3790.4131
1.1
6.0.6001.18000
2.0
6.1.7600.16385
2.0




środa, 18 marca 2015

KB3002657 breaks everything! - Windows Server 2003 - NTLM - Audit Failure - EventID: 4625 - 0xc000006d


Poprawka KB3002657 (w wersji V1) wdrożona przed 16 marca 2015 na kontrolerze domeny Windows Server 2003 powoduje że serwery nie mogą autoryzować się do kontrolera domeny używając NTLM
Podczas sprawdzania nazwy konta autoryzującego się do kontrolera domeny, autoryzacje były nieprawidłowo klasyfikowane i próba logowania kończyła się błędem (jak poniżej)

Błąd w kodzie pierwotnej poprawki łata poprawka KB3002657-v2
https://technet.microsoft.com/en-us/library/security/ms15-027.aspx


Problem moża zauważyć w logach maszyny klienckiej
Log EventID:4625 w gałęzi Security po stronie serwera.

Jeśli wdrożyliście ta poprawkę tylko na jednym kontrolerze rozwiązaniem jest przełączenie się na kontroler na któym poprawka nie została wgrana.

To do jakiego kontrolera jesteśmy podłączeni można zweryfikować:
nltest /sc_query:domain_name

Podczas resetu hasła konta komputera (security channel) serwer może zmienić kontrlore do którego wcześniej był zalogowany.
netdom reset server_name /domain:domain_name
 Błąd, po którym możemy rozpoznać, że problem występuje to Event ID: 4625


Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          2015-03-17 08:58:42
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      [servername]
Description:
An account failed to log on.

Subject:
Security ID:                NULL SID
Account Name:                -
Account Domain:                -
Logon ID:                0x0

Logon Type:                        3

Account For Which Logon Failed:
Security ID:                NULL SID
Account Name:                [doamin_user_name]
Account Domain:               [domain]

Failure Information:
Failure Reason:                An Error occured during Logon.
Status:                        0xc000006d
Sub Status:                0x0

Process Information:
Caller Process ID:        0x0
Caller Process Name:        -

Network Information:
Workstation Name:        [client_computer_name]
Source Network Address:        -
Source Port:                -

Detailed Authentication Information:
Logon Process:                NtLmSsp
Authentication Package:        NTLM
Transited Services:        -
Package Name (NTLM only):        -
Key Length:                0