Caching "Run As" credentials

[Darhl Thomason]

I'm working on securing a workstation that is set up as a POS server
terminal. I don't want the users to be able to do anything on this terminal
except basically run the POS server software. No web browsing (which I can
limit at the router level), no program installs, basic user stuff is OK for
them to do. Unfortunately the POS software has to run with some elevated
privileges, so I set the shortcut that kicks off the software to "Run As" a
different user. Then I can put in my POS user credentials, the problem
being it does not cache this and it has to be put in every time. I don't
want my users in the remote stores to know or have the credentials, so I
need some way for the software to start up every time with the elevated
privileges.

Any ideas or suggestions would be great.

Thanks!

Darhl

 

[Guest]

Darhl,

You may look into Tqcrunas to accomplish this. We generally only use it for
applications that won't run as a user and we have no other choice. It seems
to work really well, we just create a local administrator account with a
strong password, then setup this software to run it as that account under the
user's profile. You can find the software here:

http://www.quimeras.com/Products/products.asp

-Neil

 

[Darhl Thomason]

Darhl,

You may look into Tqcrunas to accomplish this. We generally only use it
for
applications that won't run as a user and we have no other choice. It
seems
to work really well, we just create a local administrator account with a
strong password, then setup this software to run it as that account under
the
user's profile. You can find the software here:

http://www.quimeras.com/Products/products.asp

-Neil

Thanks for the idea Neil. I'll take a look at that.

d

 

[Thomas M]

Thanks for the idea Neil. I'll take a look at that.

d

I'm currently in the process of restricting about 13,000 users in a
large enterprise to only those rights afforded by a standard user
account. The users in my organization range from receptionist to
Exchange server administrators, DBAs, and software developers. I hear
the following phrase a lot, "This software REQUIRES administrator rights
in order to run." Thus far, I've not found a single application where
that is actually true.

In my experience, any software application can be made to run as a
standard user. There might be software applications where that is not
true, but I've yet to run across one.

If an application will not run without administrator rights, the next
question should be, "What is the application doing that requires rights
beyond that of a standard user?" This is usually very easy to figure
out. First, download and install Process Monitor, which is a free
download from Microsoft (watch the free Webcast by Mark Russinovich on
how to use Process Monitor). Second, load Process Monitor and start a
capture. Third, fire up the application that you are testing, and do
what ever function makes the software blow up. Forth, stop the Process
Monitor capture and filter the results. You are looking for anything
that indicates a problem with rights, and that is very often found by
looking for the words "Access denied." Finally, correct the rights
problem, either by assigning the user rights to the file and folder that
the application is trying to access, or changing an application setting
(For example, to write a log file to a location that can be accessed by
a standard user).

Here's a real life example. Our programmers told me that the Oracle 9
client absolutely MUST have administrator rights or it won't work. I
installed the Oracle 9 client, did a Process Monitor capture, and then
forced the Oracle client to hang. I filtered the Process Monitor
capture file and found a line that showed, "Access denied." The Oracle
client was attempting to write a log file back to its own folder under
the Program Files folder. A standard user does not have access to that
location. I simply set the rights to the specific folder and after that
the Oracle 9 client worked just fine as a standard user. I then re-
installed the Oracle client, and it turned out that during installation
it gave me the ability to specify the location of that log file. I told
our programmers that on all future installation they should simply set
that location where a standard user account can get to the file. Total
elapsed time from zero to solution: 45 minutes.

Don't look for a way to make the software start with elevated
privileges--that's a work-around and a security risk. Address the
underlying rights issue and you'll be way ahead of the game.

--Tom

 

[Steve Riley [MSFT]]

out. First, download and install Process Monitor, which is a free

download from Microsoft (watch the free Webcast by Mark Russinovich on
how to use Process Monitor). Second, load Process Monitor and start a
capture. Third, fire up the application that you are testing, and do
what ever function makes the software blow up. Forth, stop the Process
Monitor capture and filter the results. You are looking for anything
that indicates a problem with rights, and that is very often found by
looking for the words "Access denied." Finally, correct the rights
problem, either by assigning the user rights to the file and folder that
the application is trying to access, or changing an application setting
(For example, to write a log file to a location that can be accessed by
a standard user).

Actually, there's a more automated and less noisy way of doing this. Check
out LUA BugLight, a tool by Aaron Margosis, a Microsoft consultant who's
been studying running with least privilege for some time now. His blog has
lots of tips on how to make this easier, and also has the download link for
his tool.

http://blogs.msdn.com/aaron_margosis

 

[Thomas M]

Actually, there's a more automated and less noisy way of doing this. Check
out LUA BugLight, a tool by Aaron Margosis, a Microsoft consultant who's
been studying running with least privilege for some time now. His blog has
lots of tips on how to make this easier, and also has the download link for
his tool.

http://blogs.msdn.com/aaron_margosis

Thanks for the tip. I've had Aaron's blog bookmarked for months, but
admittedly I've been remiss in reading it. Process Monitor is a tool
that was suggested to me, and honestly I've had so few problems in my
application testing that I never really bothered to look for anything
else. I'll definitely give Aaron's tool a try, and I need to get on
reading his blog too!

Thanks again!

--Tom