Powershell probe not using credentials

djp3492
Tera Expert

New to discovery, and stumped by this issue.

Consider:

  • midserver1 and midserver2. both have parameter mid.powershell.local_mid_service_credential_fallback set to false.
  • midserver1 service is running as account cmdb_discovery.
  • midserver2 service is running as local system account.
  • credential windows_creds contains cmdb_discovery as login name and a password. there are other windows credentials out there, too, but windows_creds has a lower order number.

When I attempt discovery of a windows server using midserver1, discovery is successful. The horizontal patterm works, and the powershell probe works, too.

But, when I attempt discovery of the same windows server using midserver2, discovery fails. The horizontal pattern discovery is successful, but the Powershell probe fails with authentication issue (Authentication failure with the local MID server service credential).

If I modify midserver2 to also run under the cmdb_discovery account, discovery is successful. Why are the powershell probes not using the correct credentials?

 

 

Here's the debug output from the ecc queue input record of the failed powershell probe:

Authentication failure with the local MID server service credential.</error><error>Failed to access target system.  Please check credentials and firewall settings on the target system to ensure accessibility: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))</error><debug_info>{"debug_info":[{"11.123.123.123":{"creds_failed_trying_local_mid_cred":true,"credentials_attempted":[{"credential_type":"Windows","credential_name":"windows_creds","credential_matches_affinity":true,"credential_order":"80","credential_success":false,"credential_id":"d63af7fadbe0f78040696cf3ca961930"},{"credential_type":"Windows","credential_name":"other_windows_creds","credential_matches_affinity":false,"credential_order":"100","credential_success":false,"credential_id":"c5d5141613a03200a287b9422244b012"}],"local_mid_credential_success":false,"connection_parameters":{"affinity_credential_id":"d63af7fadbe0f78040696cf3ca961930","credential_types":["Windows"],"target":"11.123.123.123"}}}]}

  

 Any insight is appreciated! Thanks!

 

1 ACCEPTED SOLUTION

Yes, I can run that command and get the appropriate results.

I believe I have tracked this down, however, to not a problem with the credentials.

Rather, the powershell script being called, I believe, is a custom script. The script executes a command, but doesn't include any credentials in the arguments. So, that should mean its running under localsystem account, and hence the failure.

I'll have to ensure credentials are being passed to the powershell script, and that the script picks them up and passes them as arguments

And that's a whole 'nother subject.

 

 

View solution in original post

6 REPLIES 6

tompowe
Tera Expert

For the local account, can you verify the following:

 

A local account that has administrator privileges and User Access Control (UAC) disabled on the same target host.

 

https://docs.servicenow.com/bundle/london-servicenow-platform/page/product/credentials/reference/r_WindowsCredentialsForm.html

Originally, the midserver service on midserver2 is just set up to run as "local system account" as defined on the windows service properties 'log on' tab.

My understanding is that all calls to targets would be done via the credentials defined in servicenow, especially since I set the parameters to not use local mid server account.

The cmdb_discovery account that I ended up running the service under is a domain account that has administrator privileges on a large group of servers...just not all of them. The login credentials for that account are also defined in servicenow credentials table, and my expectation was that those would be used for making those remote discovery calls.

My concern now is that the midserver is always using the account that the service is running under, rather than credentials defined in the credentials table, for powershell probes.

The horizontal probe that appears to be making WMI type calls is working..I see it getting CPU information, for example, in the logs.

Mark Skinner
Mega Guru

Hi,

One thing regarding local accounts is that they require specific permissions, mark sure the user can use Windows remote management, so using PowerShell try and Enter-PSSession to the remote server using your creds. 

Another thing is access to the distributed COM users. 

find_real_file.png

Make sure your user account has access to both of those and it should work.

Thanks

Mark

If this has been helpful please mark as so. If this answered your question please mark as correct

VaranAwesomenow
Mega Sage

PS C:\Users\XXXXXXXX> gwmi win32_operatingsystem -computer <targetIP> -credential <loginName> 

can you run above command from powershell of midserver 2 and see if it gives you output in below format

 

SystemDirectory : C:\Windows\system32

Organization    : XXXXX

BuildNumber     : 9600

RegisteredUser  : XXXXX

SerialNumber    : XXXXXXXXXX

Version         : 6.3.9600