Discovery with a normal user (non-admin user)

[klautrup]

Hi,

I have enabled ServiceNow Discovery on my personal developer instance to see if it is something we want to invest in.

According to the documentation:

https://docs.servicenow.com/bundle/jakarta-it-operations-management/page/product/discovery/reference...

It should be possible to use a normal user for scanning windows servers as long as that user has access to the required windows classes.

To test this I have locally on a target windows server created a normal user named 'Mid456' adding it as member of 'Users' and 'Performance Log Users' ('Performance Log Users' seems to be necessary to allow remote WMI):

The documentation mentions that a normal user requires access to these windows classes:

https://docs.servicenow.com/bundle/jakarta-it-operations-management/page/product/discovery/reference...

So to test under 'WMI Control' I gave the 'Mid456' user full access to 'root' and all sub folders:

I'm now able to test connecting using windows 'wbemtest':

And I'm able to test the credentials from ServiceNow:

If I then do a Quick Discovery, Discovery is able to login to the server and create the CI.
However, I get some errors:

Looking at the created CIs these errors seem to have something to do with missing information about 'Serial Number', 'RAM', 'Disk space (GB) and 'Chassis type':

And missing information about 'Storage Devices', 'File Systems', 'Serial Numbers', 'Memory Modules' and 'TCP Connections':

If I add the 'Mid456' user to 'Administrators' all these information are obtained and I don't see the 2 warning in the Discovery Status log.

Any idea why Discovery using a non-admin user is not able to obtain all information (according to the documentation it should be)?

Another strange behaviour using the non-admin user is that after each successfully scan Discovery is no longer able to scan or to test credentials successfully:

I tried to restart the MID server which doesn't help.

But if I update the 'WMI Control' access on the target windows server for instance by removing the access for the user 'Mid456' and re-adding it:

I'm again able to test the credentials and do 1 scan until it again fails.

If I grant the 'Mid456' users local admin access to the server I don't see this problem.

Anybody who have actually successfully been able to fully scan windows target servers using a non-admin local or AD user?

[Dave Ainsworth]

Hi Kristian,

As Adil mentions, the user needs admin share access which is listed in the additional permissions. There is a link at the bottom of the docs page you are showing above:

https://docs.servicenow.com/bundle/jakarta-it-operations-management/page/product/discovery/reference...

Some probes run a command and redirect the output to the admin share which is then read by Discovery. If the file cannot be created (or it can't access it), you will get the file does not exist error.

Having said this, I don't believe the probe to obtain serial number behaves in this way so there might be a different issue for this one. Check the ECC Queue input for the identification probe to see if there is any information.

Even if you fix this issue, there is still the problem that a command such as netstat can only output data in the context of the user running the command. So if you are not running as local admin, you might miss TCP connections for MS SQL for example as mentioned in this thread:

https://community.servicenow.com/thread/163530

If you are not interested in applcation relationships, this might be less of an issue.

Regards,

Dave

[doug_schulze · Accepted solution]

To compliment Davids response.. It is possible to have a local user discover your systems however you will only get asset (hardware information) you will not get application relationships for two reasons.

1. You wont have access to the admin share, as David perfectly talks to, although you could set up a specific share that only your user can access (after modifying the ADM probe)

2. You will not see TCP connections (netstat) outside the context of your local user, if you configure that user access to that admin only command

So if all you are looking for is asset information, absolutely you can configure a non-admin user to discover your systems however you will be faced with having to manage that user and all queries that Service now makes across all releases of your OS's.   Add that we develop with a Local Admin credential you might miss out on future capabilities.   And finally, there is only so much help our friends in support can provide, if you are having access issues it most likely is going to be a discussion between you and Microsoft in managing your user security.

So its best to configure a domain user that has local admin privileges on the targets you are looking to discover to experience the full breadth and capabilities that Discovery has to offer..

[Manuel29]

Hi Doug

I am concerned, with the fact that using a local admin account for this purpose , open a vulnerability where a potential intruder can easily develop a custom probe to do anything against the servers without any restriction. From deleting everything, to even hijack them and ask for a ransom. The possibilities are really endless.

This must be heavily guarded !!!

Is there any plan to really review this and come up with a more security friendly solution?

Appreciated,

Manuel

[doug_schulze]

Yes, but that is the trade-off, right? in an agentless method.  Remember, it's not 'us' that requires this, it's Microsofts security model.. Basically, we're riding in their car, they decide who gets to wear seat belts. And everyone has to deal with this including our friendly competitors up to and including Microsoft themselves with SCCM where agent deployment requires local admin... It's a risk we all share.

But that's not to say you don't have options...

1. You can use ACLs to prevent writes or updates to the probe table (or pattern table) for non-authorized users. And if anyone tries you can trigger an event that can let appropriate teams know "Doug" tried to do something out of the process.

2. You can use our external credential store option so to control the access to that user where it can be audited and where username and passwords are "hidden" internally.

Word around the 'water cooler' is that we continue to work on this, because you are not alone in this challenge and we feel the pain, especially in highly regulated, audited or mission-critical environments.  Things like Just Enough Admin or an Agent-based solution are in the wind.

But remember at some point, you have to trust. There is someone right now in your environment that has the big brass key to your world, it's the controls you put in place that help mitigate this very important assessment.