Hi we have many windows servers in our environment, but for one server I cannot get winrm to work.
1) I have run the winrmconfig.ps script on the server. The output is all BLUE/Green and Yellow. The user has been specified
04/12/2017 14:20:21 CURRENT LISTENER(S) INFORMATION:
04/12/2017 14:20:21 Listener: Address = * Transport = HTTPS Port = 5986 Hostname =MYSERVER.MYDOMAIN.COM Enabled = true URLPrefix = wsman CertificateThumbprint = 2e 05 19 d9 45 6f f8 3e 59 7f 23 10 81 fc e7 d16a 70 9d fb ListeningOn = 10.X.X.X, 10.X.X.X, 127.0.0.1, 172.X.X.X, ::1
04/12/2017 14:20:21 SECURITY LOG ACCESS FOR NETWORK SERVICE ACCOUNT CHECK BEGINS(WINRM SERVICE USES THIS ACCOUNT TO READ EVENT LOGS) 04/12/2017 14:20:21 Network Service SID is already added to the Security Channel ACL (Security Analytics can collect Security Event logs using the myuser@MYDOMAIN account) 04/12/2017 14:20:21 SECURITY LOG ACCESS FOR NETWORK SERVICE ACCOUNT CHECK ENDS 04/12/2017 14:20:21 COLLECTION USER RIGHTS CONFIGURATION BEGINS...
04/12/2017 14:20:21 Checking access to the CIM Root (necessary for Event log collection) 04/12/2017 14:20:21 Checking access to the CIM Root for SID S-1-5-21-606747145-527237240-6123456789-123346 04/12/2017 14:20:21 Setup call to GetSecurityDescriptor, parameters: 04/12/2017 14:20:21 Got acl 04/12/2017 14:20:21 Found trustee SID: S-1-5-21-606747145-527237240-6123456789-123346
04/12/2017 14:20:21 User myuser@MYDOMAIN with SID: S-1-5-21-606747145-527237240-6123456789-123346 is already enabled for WMI access via WinRM (Security Analytics can collect Event logs using this account)
04/12/2017 14:20:21 Checking user myuser@MYDOMAIN membership to the Event Log Readers group 04/12/2017 14:20:22 Event Log Readers member: NETWORK SERVICE 04/12/2017 14:20:22 Event Log Readers member: MYUSER 04/12/2017 14:20:22 User myuser@MYDOMAIN is already a member of Event Log Readers group 04/12/2017 14:20:22 COLLECTION USER RIGHTS CHECK ENDS HERE...
04/12/2017 14:20:22 OS Version:
2) From the logcollector I can curl to the Server on port 5986 (the https port successfully)
3) I have looked in the steps of the winrm troubleshooting guide and can see that I have kerberos tickets for this service.
note the wildcard at the end of the fqdn of the system you have the failure with
this will show any extra spn’s for that fqdn which is most liekly the issue KRB_APP_ERR_MODIFIED typically stems from this issue. The reason for these dup spins is typically because the system hosts some webserver or shrepoint instance that requires a spn due to a requirement to access the web server via a non standard port.
I have a case already open with Microsoft, i have to repro this in the VCloud here since the traces they want i doubt anyone will do in production since they want deep traces on the DC and the target system. My thinking is the DC search the ServicePrincipalName is wrong since it is not doing an exact match, of course they will typically either say FAD or we're wrong but we can let the customer chip in too if it comes to it. We now have several instances of this occurring.
When we ask kerberos for a service tciket for the system we are connecting to we pass a SPN in the form HTTP/fqdn_of_system
In Dave's case someone has assigned HTTP/fqdn_of_system to an actual account (Service Account) so we get a ticket back that is not for the actual System and when we present that to the System to access the WinRM Service it rejects the ST.
It seems that a search for a SPN in AD always seems to prioritize Service Accounts over systems presumably as they are higher in the tree..