
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2020 03:34 PM
Hi,
We have a challenge where our windows admin team is not happy to give us admin privileges for Domain controllers for discovery purpose. Now that we have upgraded to Orlando, i found out we can use property called "mid.powershell.target_base_dir" to set the directory to a temp folder instead of Admin$ that needs admin privileges.
I am going to play around with this property and use it but thought will ask around if anyone has used it with success to save time. Here is my approach and i will post how it goes later on.
1) Set up a temp folder on the DC host machine by working with Windows admin team.
2) Ask windows admin to get us user and password for the user with non-administrative persmission so that we can add that to SN credentials table.
3) Set MID server property mid.powershell.target_base_dir to point to new temp share folder created in step 1.
4) Run discovery and see how it goes!
Solved! Go to Solution.
- Labels:
-
Discovery
-
Orchestration (ITOM)

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-18-2020 03:56 PM
Part 2:
I just wanted to share with you where we are now after raising HI ticket and trying out few more things.
HI Ticket:
Windows Discovery is writing to C:\Temp (\\<server>\C$\Temp) temporarily during Discovery, need to know if this default location can be modify with alternative pat.
So the support team did the investigation and find out that there are 2 mid server script files that have c:\temp hard coded!
Navigate to -> MID Server -> Script Files -> Then search for
WMIFileOperations.psm1
WinRMFileOperations.psm1
Need to change c:\temp in the above scripts to other accessible folders.
Testing after changing the above:
So we went ahead and changed the "C:\temp" to "C:\SNITOM\Temp"
So, when we ran discovery using admin privilege, it no long write those temp file to C:\temp but unfortunately, when we ran discovery using non-admin privilege, it failed with same message as before "Failed to launch process powershell -ExecutionPolicy ByPass -NonInteractive -WindowStyle Hidden -command "& {mode...."
So, it appears that you would still require “Admin” credentials to accessADMIN$/C$/D$/E$.
Other options:
1) we convince our Windows team to grant us "admin" cred and limit when we can run discovery for DC i.e. one hour daily or weekly. Also, if possible automate the grant of admin priviledge for that one hour only and rotate the password every time.
Lastly, We are thinking of exploring JEA functionality that was released as part of Orlando but SN Support team confirmed they have given skeleton scripts only and customers would have to develop their own to discovery DC.
If anyone has any luck with this, I would be keen to understand it.
Thanks,
Jaskaran Walia
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-01-2020 01:00 PM
Thanks for bringing this up. I'm about to venture on this route as well. Did you get to see what this user did with his service account:
Did you do the same when you configured the account?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-18-2020 02:49 PM
Hi Marc.See
Yeah I had a look into that article before my post and the conclusion of that document is that you need admin creds. However, we were hoping that in orlando using this property the need to have access to admin share is mitigated but looks like not.
Quote from that article
"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"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-27-2020 10:23 AM
Right exactly.
Based on our meeting with Doug Schulze, he mentioned that the method above may work on Windows devices, but based on his experience and according to Microsoft, DC's require domain administrator.
Since I'm not a Windows SME, I can't attest to this. I was wondering if your method above did produce enough attributes for asset information.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-27-2020 01:55 PM
Hi Marc.See,
No, we didn't want few attributes so didn't went in that direction at all. Our aim is to do full discovery on DC including TCP connections for admin context as we want to be able to leverage that information to build Service Map.
So, in our case, we wanted to see if this property avoid need of admin cred and still give us all but it didn't! So unfortunately, we are now seeking full domain creds with mitigations like once a week for one hour from one specific mid server only and password rotated weekly! Also, put in alerts using qradar/rapid7 etc to see if that user is used by any other host apart from dedicated mid server and that too only on the listed DC.
Once we have this in place, i will update this thread and share the learning.
Really hoping in next few release, microsoft and SN, can come up with oob JEA scripts to achieve all this without root creds.
Thanks,
Jaskaran Walia
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-09-2020 02:03 PM
Looking forward to your findings, but it seems like you're confirming the inevitable.