restrictions on non-admin users? cannot download ActiveX control.??

[mqsash]

Hi

Client is running IE6 Sp2 on WinXP Sp2.

I have a web page which refers to a Signed ActiveX control.

When the logged in user(client) is an Admin, opening the web page in IE
successfully downloads and installs the activeX.
BUT when logged in user is NOT-Admin then opening the web page DOES
NOT download the activeX.


I have set to "Enable" the IE secutiry property "Download
Signed ActiveX controls". for the Admin as well as the Non-Admin user
for the internet zone as well as the intranet zone.

Any idea why a non-admin cannot download the ActiveX?
Are there any restrictions in IE on a non-admin user?
I do not even get any error message. Is there any log or something
where I could get more info?


Any help will be most appreciated.

TIA
mqsash

posted to : microsoft.public.windows.inetexplorer.ie6.browser

 

[Guest]

Hi

Client is running IE6 Sp2 on WinXP Sp2.

I have a web page which refers to a Signed ActiveX control.

When the logged in user(client) is an Admin, opening the web page in
IE
successfully downloads and installs the activeX.
BUT when logged in user is NOT-Admin then opening the web page DOES
NOT download the activeX.


I have set to "Enable" the IE secutiry property "Download
Signed ActiveX controls". for the Admin as well as the Non-Admin user
for the internet zone as well as the intranet zone.

Any idea why a non-admin cannot download the ActiveX?
Are there any restrictions in IE on a non-admin user?
I do not even get any error message. Is there any log or something
where I could get more info?


Any help will be most appreciated.

TIA
mqsash

posted to : microsoft.public.windows.inetexplorer.ie6.browser

Those settings are stored under the HKEY_USERS hive (and merged into the
HKEY_CURRENT_USER hive). In other words, the security settings are
independent between users so what one user configures for their Internet
security zone is not necessarily what another user has configured for
their use of IE when logged under their own account. You imply that the
settings are the same. Are all the other AX settings the same for the
admin and non-admin accounts?

Perhaps the non-admin account doesn't have rights to install software?
Is the account (that fails to allow the AX install) a member of the
Standard User (Power User) group? You already know an admin account
will work.

Also see http://support.microsoft.com/?id=822798.

 

[mqsash]

Hi,

I realise that the security settings are independent between users, and
in my case both users ( admin and nonadmin) have their individual
settings enabled.

Regarding the questions you askedaccounts?
ANS : Yes they are.
the Standard User (Power User) group
ANS : NO, he is a member of the "users" group
software?
ANS : I am not aware of any such rights, and hence have not made any
specific assignment. The AlwaysInstallElevated group policy for the
installer enabled, but I'm not sure that this is what you are implying.

mqsash

 

[Guest]

Hi,

I realise that the security settings are independent between users,
and
in my case both users ( admin and nonadmin) have their individual
settings enabled.

Regarding the questions you asked
accounts?
ANS : Yes they are.

the Standard User (Power User) group
ANS : NO, he is a member of the "users" group

software?
ANS : I am not aware of any such rights, and hence have not made any
specific assignment. The AlwaysInstallElevated group policy for the
installer enabled, but I'm not sure that this is what you are
implying.

Is the client running any anti-spyware utilities in the background?
Some, like Microsoft's AntiSpyware (purchased from Giant), do not
function correctly under non-admin accounts. Is the client running any
intrusion prevention software (IDS), like Prevx [Home], where each
account can configure settings regarding whether to not to allow certain
behaviors along with the option to not get prompted again (i.e., the
blocking is account-specific and prompting was turned off)?

Is this client's host in a domain? If so, "By design in Windows 2000,
members of the Users group cannot install ActiveX controls from the
Internet without modifying the rights of the group"
(http://support.microsoft.com/?=280579). Probably still applies under
Windows XP. Generally, accounts in the Users group are not allowed to
install software.

Also check that the client hasn't added your site to the Restricted
Sites security zone. When they visit your web page, have them look in
the status bar to see in which security zone the browser is rendering
your web page.

 

[mqsash]

Hi

a) No antispyware or other software that you mentioned are running.
b) The site is not part of the restricted zone
c) It most probably is that "By design in Windows 2000,
members of the Users group cannot install ActiveX controls from the
Internet without modifying the rights of the group"

but reading the phrase carefully, it looks like one can modify certain
rights of the group to allow members of "users" group to install
ActiveX controls from the internet. Could you please let me know what
these rights are, so that I can verify that it is indeed a rights
issue.

TIA
mqsash

 

[Guest]

Hi

a) No antispyware or other software that you mentioned are running.
b) The site is not part of the restricted zone
c) It most probably is that "By design in Windows 2000,
members of the Users group cannot install ActiveX controls from the
Internet without modifying the rights of the group"

but reading the phrase carefully, it looks like one can modify certain
rights of the group to allow members of "users" group to install
ActiveX controls from the internet. Could you please let me know what
these rights are, so that I can verify that it is indeed a rights
issue.

TIA
mqsash

While you may not have any anti-malware programs currently running, some
such programs don't need to be running to thwart malware. For example,
SpywareBlaster adds killbit entries into the registry that prevent AX
controls with those class IDs to not execute. So you might want to
ensure that you don't have a killbit entry for your AX control's class
ID in the registry. See http://support.microsoft.com/?id=240797.

You could just temporarily switch the problematic account to the
Standard (Power Users) or Administrators group to check if they can then
install your AX control after downloading it. That would ensure that
something else isn't interferring with the install of your AX control.

You could also try defining a software policy specify for your AX
control. I haven't done this so you'll need to ask someone else how
they use this policy to manage software restrictions.

Description of the Software Restriction Policies in Windows XP
http://support.microsoft.com/?id=310791

I supposed you could even try using the RunAs command to run the browser
under admin rights.

 

[mqsash]

"...You could just temporarily switch the problematic account to
the
Standard (Power Users) or Administrators group to check if they can
then
install your AX control after downloading it..."

I have already checked that, and it works fine.
eg : When I an Administrator loads the webpage in IE, the AX is
successfully downloaded and installed. Works fine even when I load the
browser using RunAs and specify an administrator account.

regards
mqsash