Desktop Icons and Least User Privilege

[Guest 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

[Guest Terry R.]

Re: Desktop Icons and Least User Privilege

 

 

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.

[Guest Thomas M.]

Re: Desktop Icons and Least User Privilege

 

 

"Terry R." <F1ComNOSPAM@pobox.com> wrote in message

news:OXxygXneIHA.4696@TK2MSFTNGP05.phx.gbl...

>

> 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.

 

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

[Guest Thomas M.]

Re: Desktop Icons and Least User Privilege

 

>> 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

 

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