Re: Security settings

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

From: "Jim Cavalaris [MS]" <jamesca@online.microsoft.com>
Date: Fri, 2 Aug 2002 01:14:24 -0700

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:
news:3d0695d6$1@news.microsoft.com

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.
"Janice" <janicel@hotmail.com> wrote in message news:3D49F531.A9060DA4@shaw.ca...
> I have XP Pro installed on my computer.  I have installed several
> programs onto this new computer and they all have been working fine as
> long as I am logged on as an administrator.  I have also created a
> 'User' with limited rights for our daily use. In some cases it has been
> necessary to change the security settings on some directories to enable
> the limited user to run the programs.  My question is, is there an easy
> way to determine what security settings need to be altered in order to
> let a limited user run programs?  So far it has been kind of a hit and
> miss effort on my part to get things running properly.  I was just
> wondering if there was an easy way to determine what needs to be
> altered.  For an example, I now have a scanner that works fine when
> logged on with admin rights.  When a regular user tries to scan, a
> message stating "Error opening data source" comes up.  The scanner
> checks out with the diagnostics in 'control panel' and can also scan
> using the built in XP Scanner Wizard.  I have run out of ideas and any
> help would be greatly appreciated.
>
> Thanks
> Janice