Service Account Security & End Users

[MARS822]

Add my voice to the ever growing list of fans...I use Everything both at home and work on a daily basis.

I've been pondering setting up the HTTP server on my file server at work to help end-users find files in our rather disorganized shares. I would have to run the service using an account that has at least local admin rights on the server, tho' I'd prefer to use a Domain Admin level account for monitoring and auditing purposes. My question is if doing so will break all of my NTFS permissions since the process will be running as Admin. IOW - it seems to me that an end-user browsing via the share links at the top of the browser page will have complete access to the file system, regardless of NTFS permissions, since Everything will be running as Admin. Does that make sense? Can you confirm or deny?

Thanks,

M-

[void]

it seems to me that an end-user browsing via the share links at the top of the browser page will have complete access to the file system, regardless of NTFS permissions, since Everything will be running as Admin.

Correct.
Everything will grant access to any file indexed.

Please make sure you index only what you want users to be able to download.

[MARS822]

Thanks so much for your reply. Due to the complexity of our permissions I'm afraid the HTTP server won't really work. It was just an idea, so no loss. I still think Everything is one of the most useful apps out there. Thanks again for making it happen.

[NotNull]

I have never used the HTTP server option, but at some time I did some experimenting with the ETP server.
There you could also download the files and thus bypassing all share/ACL permissions.

You could add an entry in the Everything.ini of the ETP server to disable downloading and thereby using the 'ETP client' (Everything.exe on users' computers) to open the files. That was done with the rights the user has.
So users could see all files that were indexed by he ETP server, but were only able to access the ones they were entitled to based on ACL's.
That INI entry was: etp_server_allow_file_download and according to the help: "Allow or disallow file downloading from the ETP server. Set to 1 to allow. Set to 0 to disallow."

The HTTP server has a similar option: http_server_allow_file_download. As said: no experience with it, but maybe this can help you.
I would say: take it for a spin and see if it works for you

P.S. Very likely I also tested moving and copying files, but can't remember the outcome of that.

[void]

If security is a concern, please consider disabling the HTTP/ETP/FTP servers:

• Exit Everything (right click the Everything tray icon and click Exit).
• Open your Everything.ini in the same location as your Everything.exe
• Change the following lines:
  allow_http_server=1
  allow_etp_server=1
• to:
  allow_http_server=0
  allow_etp_server=0
• Save changes and restart Everything.

This will prevent the user from starting a HTTP/ETP/FTP server.

Your Everything.exe and Everything.ini should be located in C:\Program Files, so only administrators will be able to change these values.

[bobm]

As a workaround, is there anyway to share a central database so that users can see filenames but only actually access them if they have the necessary permissions?

I've tried setting this up but adding the folder name containing the shared database in Options > Indexes > Database location, doesn't appear to result in Everything recognizing the existing database. And there is nothing in the users local .ini file that references this location,

[NotNull]

is there anyway to share a central database so that users can see filenames but only actually access them if they have the necessary permissions?

That is a pretty good description of what an ETP Server does
(provided that you set this INI setting: etp_server_allow_file_download=0)

[bobm]

I don't think so.

I run an ETP server that indexes network drives and anyone who access files via that server has access to any file I can view, even though their own access control permissions may forbid it. Which, although part of Everything's design, is obviously a security issue.

Having individuals running their own Everything client which then points at a central database would seem to be a workaround, but having tried this as another user, Everything appears to ignore the existing database and immediately starts creating a fresh one, even though the path to the existing one is identical, ie it doesn't recognise there is already one available.

[NotNull]

I run an ETP server that indexes network drives and anyone who access files via that server has access to any file I can view, even though their own access control permissions may forbid it. Which, although part of Everything's design, is obviously a security issue.

Having individuals running their own Everything client which then points at a central database would seem to be a workaround, but having tried this as another user, Everything appears to ignore the existing database and immediately starts creating a fresh one, even though the path to the existing one is identical, ie it doesn't recognise there is already one available.

This raises a lot of questions on my side. Let's start with the first two:
- How did you install Everything on the user's system?
- How do you connect from this Everything client to the ETP Server?

[bobm]

The client user just ran the Everything.exe on his machine then changed set Everything Options > Indexes > Database location to point at the publicly shared database.

To connect to my ETP server, the client ran Everything.exe then used Tools > Connect to ETP Server.

[NotNull]

Ok, that is a bit a-typical.

If that is how you want to run the ETP Clients on users computers, try it like this:


On the computer where the ETP Server is running:

• On the ETP Server, go to Menu:Tools > Options > ETP/HTTP Server
• Write down what you configured for Listen on port:, Username:, Password:.
• Write down the computername (how this machine is known in the network)
  For this example:
  • Listen on port=2121
  • Username:ETP-Username
  • Password:ETP-Password
  • computername=Server
• Create a shortcut in the fodler where Everything.exe is, with the following command:

  Code: Select all

  "X:\path to\Everything.exe" -instance "%USERNAME%" -config "%APPDATA%\Everything\Everything.ini" -connect ETP-username:ETP-Password@Server:2121  -nodb

  Replace "X:\path to\Everything.exe" with the path as the client would see it.

On the client computers (where the ETP Client will run):

• Double-click the shortcut you just created in "X:\path to\"
• If you see this dialog box, choose Do not index NTFS volumes.
  Most likely causes:
  • Wrong connection details (port, username, password, computername)
  • Firewall settings that doesn't allow this connection.
  • ETP Server not running

  

  2020-02-04 20_28_21-Window.png (9.66 KiB) Viewed 8139 times

Result
You should now be able to see a list of files .
Probably not exactly how you want it, but these are the first steps.

[bobm]

I think we're talking at cross purposes.

The clients run their own local version of Everything.exe since they do not have access to the executable on the Server machine (my PC). Therefore, the "X:\path to\Everything.exe" can't work.

Clients currently connect via Tools > Connect to ETP server using Host and Port credentials, with username and password blank as it's a public service. But that gives them my access privileges.

My original suggestion was to put the Everything database in a shared location that the clients could use, but not the Everything executable. Even if I moved the .exe to some central so the clients used the same one, I don't understand how that would give them different access rights to files that I'm allowed to see that that they aren't.

[NotNull]

I think we're talking at cross purposes.

Well, that is because you answered this question:

- How did you install Everything on the user's system?

with:

The client user just ran the Everything.exe on his machine then changed set Everything Options > Indexes > Database location to point at the publicly shared database.

No description of any installation at all so it had to be the external everything.exe.


Anyway ... my time is limited. I spend quite a lot of time on this already (for nothing, it turns out).
Hope someone else steps in to take over.

[bobm]

There was no installation on the client PC (or mine for that matter). Just a separate copy of Everything.exe on each machine, which each user runs independently.

You assumed I was talking about a single executable.

Anyway, thanks for your contribution.

It doesn't sound like it's an easily solvable problem.