Desktop Icons and Least User Privilege

[Thomas M.]

XP SP2

We are in the process of restricting all our employees to standard user
accounts on the desktop. For the most part this has all gone just fine, but
today I ran into a problem that I have not previously encountered. I
converted a group of users to standard user accounts and all of them lost
the ability to launch Attachmate Extra from the desktop icon. Now, I tested
Extra in advance and found that I needed to tweak the NTFS permissions to
make it run as a standard user, and I added the appropriate file rights to
our group policy. In fact, I currently have standard users running Extra
without problems, so I know that I've got that end of things nailed down.
The problem today was that the desktop icon does not work, and when I
checked the properties of the icon I found that all the fields had been
emptied out. This situation never arose in our testing.

I have the same problem with another product called BeyondCompare.

Both the Extra and BeyondCompare icons are located on the All Users desktop.
There are other icons on the All Users desktop that appear to have been
unaffected, or at least no one complained about them today.

Does anyone know why the icons for these two products were essentially made
into empty shells simply by removing the admin rights of the user? Does
this have something to do with the way the installation packages for these
products created the shortcuts? Also, can I possibly fix the problem by
giving the user rights to those specific icons via the group policy?

Any information you can offer will be greatly appreciated.

--Tom

 

[Terry R.]

The date and time was 2/28/2008 5:35 PM, and on a whim, Thomas M.
pounded out on the keyboard:

XP SP2

We are in the process of restricting all our employees to standard user
accounts on the desktop. For the most part this has all gone just fine, but
today I ran into a problem that I have not previously encountered. I
converted a group of users to standard user accounts and all of them lost
the ability to launch Attachmate Extra from the desktop icon. Now, I tested
Extra in advance and found that I needed to tweak the NTFS permissions to
make it run as a standard user, and I added the appropriate file rights to
our group policy. In fact, I currently have standard users running Extra
without problems, so I know that I've got that end of things nailed down.
The problem today was that the desktop icon does not work, and when I
checked the properties of the icon I found that all the fields had been
emptied out. This situation never arose in our testing.

I have the same problem with another product called BeyondCompare.

Both the Extra and BeyondCompare icons are located on the All Users desktop.
There are other icons on the All Users desktop that appear to have been
unaffected, or at least no one complained about them today.

Does anyone know why the icons for these two products were essentially made
into empty shells simply by removing the admin rights of the user? Does
this have something to do with the way the installation packages for these
products created the shortcuts? Also, can I possibly fix the problem by
giving the user rights to those specific icons via the group policy?

Any information you can offer will be greatly appreciated.

--Tom

Hi Tom,

We have users connecting to TS via RDP, and I had to add user rights to
the specific icons in order for the user to gain access to the program.
That may be the same in your situation.

--
Terry R.

***Reply Note***
Anti-spam measures are included in my email address.
Delete NOSPAM from the email address after clicking Reply.

 

[Thomas M.]

The date and time was 2/28/2008 5:35 PM, and on a whim, Thomas M. pounded
out on the keyboard:



Hi Tom,

We have users connecting to TS via RDP, and I had to add user rights to
the specific icons in order for the user to gain access to the program.
That may be the same in your situation.

--
Terry R.

***Reply Note***
Anti-spam measures are included in my email address.
Delete NOSPAM from the email address after clicking Reply.

That's what I was thinking. Interestingly, I found out this morning that
the users having problems are running version 7.1 of Extra, and another user
who is running version 8 and tried it for the first time just this morning
is not having a problem. So I think that my solution is upgrading users to
version 8.

In general terms, I'm kind of thinking that the installation process for
some applications may give the desktop icon some special properties, kind of
like the way that the My Documents icon and the Outlook icons have special
properties beyond what you get with just your basic icon, but that's just a
wild guess.

I'll try to do some testing on this next week and will try to report back
for the benefit of anyone who is interested.

--Tom

 

[Thomas M.]

Hi Tom,

That's what I was thinking. Interestingly, I found out this morning that
the users having problems are running version 7.1 of Extra, and another
user who is running version 8 and tried it for the first time just this
morning is not having a problem. So I think that my solution is upgrading
users to version 8.

In general terms, I'm kind of thinking that the installation process for
some applications may give the desktop icon some special properties, kind
of like the way that the My Documents icon and the Outlook icons have
special properties beyond what you get with just your basic icon, but
that's just a wild guess.

I'll try to do some testing on this next week and will try to report back
for the benefit of anyone who is interested.

--Tom

I have identified the problem, and it turns out that it was an issue that my
previous testing *did* identify. Unfortunately, the write-up of my notes
from that testing was a little unclear and I just couldn't quite pull the
information out of the ol' memory banks. Basically, the Extra session file
is customizable and because of that we install the session file to the My
Document folder (or some other location that a standard user account can
access). In this particular case the software had been installed a long
time ago, before we started locking down desktops, and that session file got
installed to the application folder under Program Files, which a standard
user account cannot write to, so when we took away the admin rights of that
user he lost the ability to launch the session from that location because
the software was looking for write permissions to that folder. Once I
assigned the write permissions it started working again.

It shouldn't have taken me so long to realize the problem, but truth be told
I was only giving it half my attention because I have had bigger fish to fry
lately. Once I got the time to give it my full attention it was a real
Homer Simpson "DOH!" moment! ;-)

--Tom