Re: Software unavailable for different users under XP-pro

From: Jim Cavalaris [MS] (jamesca@online.microsoft.com)
Date: 08/07/02 

From: "Jim Cavalaris [MS]" <jamesca@online.microsoft.com>
Date: Wed, 7 Aug 2002 14:15:11 -0700

the program is probably also attempting to access areas of the
registry that limited users cannot access (i.e. HKLM).

a good way to track down compatibility problems due to security is
to enable the system's own object access auditing feature for any
suspected file and registry locations that might be accessed by the
program. you can see exactly what resources a program is trying to
access and what access rights are being requested and / or denied.
you can then modify the security settings on only those resources to
grant 'Users' only the necessary access rights.

below is a previous post i made describing how to do this...

hope this helps,
jim.

"Jim Cavalaris [MS]" <jamesca@online.microsoft.com> wrote in message news:...
> this is usually caused by the incompatible program making
> an incorrect assumption that users have all access to objects,
> as they did under win9x. most commonly, the program is
> trying to modify its own system-wide software settings in the
> registry (HKLM\SOFTWARE), rather than use per-user
> settings (HKCU\SOFTWARE).
>
> assuming that's the case, a good way to track this down is
> to enable auditing for access failures by users when running
> the program.
>
> this approach involves modifying machine policy, registry
> permissions, and object audit entries, so it's not really for the
> faint of heart, but it can help pinpoint the exact reason for the
> failure, and allow you to target what objects you may need
> to change the permissions on, which is usually preferable to
> having to make all users Administrators just to run incompatible
> programs.
>
> as an Administrator, modify group policy to enable auditing
> for object access (enabling auditing for failure should be sufficient,
> and will reduce the number of acceses logged so you can browse
> through the relevant ones more easily)...
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q315416#5
>
> enable auditing for a set of registry keys you suspect the
> program is trying to modify, but does not have access to...
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q315416#6
>
> with regedit on windows xp, auditing a key is available by
> selecting Edit --> Permissions for the key, (rather than
> Security --> Permissions, as described above). again, it's
> easiest and sufficient just to audit the access failures by
> any member of the "Everyone" group. as long as the auditing
> tab checkbox "Allow inheritable auditing entries ..." is checked,
> you only need to do this on the parent of the subtree you want
> to watch, not every key.
>
> in most cases, the program is trying to modify system-wide
> program settings somewhere in HKLM\SOFTWARE, which
> only Admins can modify. if the program has a subkey under
> HKLM\SOFTWARE,that's a good place to start. if you don't
> see anything suspicious there, you may have to expand your
> search to all of the SOFTWARE and/or SYSTEM branches.
>
> log out of the Admin account, log in as the limited user.
> run the program and encounter the failure. log out of the
> limited user account and back into the Administrator account,
> and view the audit entries in the eventlog (eventvwr.msc)
> "Security" log to see what registry key/value accesses failed
> for the limited user account.
>
> modify security settings on the registry keys where failure
> was encountered AS APPROPRIATE to grant the
> appropriate access to the appropriate user group(s).
> you shouldn't indiscriminately open up access to operating
> system specific settings, since that would defeat the point of
> running with limited accounts, and make the system
> vulnerable.
>
> remove the audit entries on the keys above, and disable
> auditing when you're done.
>
> if you suspect the failure is from a file access, rather than
> registry access, you can also add audit entries on files and
> directories, just as with registry keys.
>
> if you suspect the failure is from lack of privilege, the group
> policy editor also allows for auditing of privilege checks failures,
> but in most cases, this should be rare.
>
> hope this helps,
> jim.
> 

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Nic" <vavroom@bmee.net> wrote in message news:19af01c23e42$4feed110$3aef2ecf@TKMSFTNGXA09...
> I'm getting increasingly frustrated and I hope someone
> may have an answer for me :-)
>
> I'm running Win XP-pro boxes on a network, where the
> server is Win2K server.  Though that should not, in
> theory, be part of the equation at this point.
>
> On individual machines, I installed software loggin in as
> admin.  No problem, all works fine.  Then I log off, log
> back in as one of my users (regular user, no
> admin/poweruser rights).  That's when the sh*t hits the
> fan.  The software is there, listed on the start menu and
> all, but nothing happens when you try to start it up.
>
> There is another application that asks for a password
> when logged on as admin, but if you leave it blank an
> dhit "enter", it goes right in.  When you try that as a
> user, it won't let you in.  No matter how, even with
> administrator password typed in.
>
> I went in and changed the permissions to allow anyone to
> use the folders where the software was installed,
> figuring there might be an issue with that, still no go.
>
> There *must* be a way for an admin to install the
> software and for the users to use those applications.
>
> On Dragon NaturallySpeaking (the first app), I even tried
> to uninstall the app, give my user administrative rights,
> install the software, but it won't let me install the
> app, despite that user now being admin.
>
> I don't get it, and I'm getting increasingly pissed off.
>
> Help? :-)
>
> Thanks