I've learned from experience that the more you try to lock down a
windows box the higher your chance are of breaking functionality.
Similar to using the NT4 policy of only allowing a list of specific
applications to run, attempting to lock down a 2k or xp box in this
manner will most likely create problems for you. In the worst case
scenario you can attempt to create a sort of kiosk system. see:
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.
mspx
V
Harlan Carvey wrote:
>
>>The users are not local administrators. We
>>configure
>>group policy to prevent user installs but it seems
>>that it blocks only .msi packages. Users still can
>>install applications through ex. setup.exe...Can we
>>really block users from installing applications
>>through Group policy?
>>
>>Any idea or thoughts on this?
>
>
> Sure. Disable access to the write to certain
> locations of the hard drive. While some applications
> require the ability to write to a temp directory, most
> users shouldn't have write access to the system32
> dir...read and execute usually suffice.
>
> First, though...some background. Do you have a policy
> in place that states that users shall not install
> software? If you do, the next step should be to put
> technical measures in place to not only prevent it,
> but monitor it. Monitoring can be done easily through
> freeware and WMI.
>
>
>>Plus, if we need to block users from saving .mp3
>>file
>>on their computers, can we do it through group
>>policy?
>
>
> Again, the first step should be a security policy.
> Next, how do they download the .mp3s? If it's via
> file sharing (or rather, pretty much any method other
> than FTP, HTTP, or bringing in a CD), then there is
> probably an *installed application* that they're
> using. Also, there is very likely an *installed
> application* they're using to play the .mp3s, right?
>
> You won't be able to completely prevent the download
> of files to the local hard drive through ACLs...the
> users still need some write access to the drive.
> However, you *can* monitor this by simply using 'dir'.
> Map a drive (x:\) and type the following command:
>
> c:\>dir /s x:\*.mp3
>
> If you want, you can follow this up with the judicious
> use of 'del'.
>
> Hope that helps,
>
>
> =====
> ------------------------------------------
> Harlan Carvey, CISSP
> "Windows Forensics and Incident Recovery"
> http://www.windows-ir.com
> http://groups.yahoo.com/group/windowsir/
>
> "Meddle not in the affairs of dragons, for
> you are crunchy, and good with ketchup."
>
> "The simplicity of this game amuses me.
> Bring me your finest meats and cheeses."
> ------------------------------------------
>
> ------------------------------------------------------------------------
---
> ------------------------------------------------------------------------
---
windows box the higher your chance are of breaking functionality.
Similar to using the NT4 policy of only allowing a list of specific
applications to run, attempting to lock down a 2k or xp box in this
manner will most likely create problems for you. In the worst case
scenario you can attempt to create a sort of kiosk system. see:
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.
mspx
V
Harlan Carvey wrote:
>
>>The users are not local administrators. We
>>configure
>>group policy to prevent user installs but it seems
>>that it blocks only .msi packages. Users still can
>>install applications through ex. setup.exe...Can we
>>really block users from installing applications
>>through Group policy?
>>
>>Any idea or thoughts on this?
>
>
> Sure. Disable access to the write to certain
> locations of the hard drive. While some applications
> require the ability to write to a temp directory, most
> users shouldn't have write access to the system32
> dir...read and execute usually suffice.
>
> First, though...some background. Do you have a policy
> in place that states that users shall not install
> software? If you do, the next step should be to put
> technical measures in place to not only prevent it,
> but monitor it. Monitoring can be done easily through
> freeware and WMI.
>
>
>>Plus, if we need to block users from saving .mp3
>>file
>>on their computers, can we do it through group
>>policy?
>
>
> Again, the first step should be a security policy.
> Next, how do they download the .mp3s? If it's via
> file sharing (or rather, pretty much any method other
> than FTP, HTTP, or bringing in a CD), then there is
> probably an *installed application* that they're
> using. Also, there is very likely an *installed
> application* they're using to play the .mp3s, right?
>
> You won't be able to completely prevent the download
> of files to the local hard drive through ACLs...the
> users still need some write access to the drive.
> However, you *can* monitor this by simply using 'dir'.
> Map a drive (x:\) and type the following command:
>
> c:\>dir /s x:\*.mp3
>
> If you want, you can follow this up with the judicious
> use of 'del'.
>
> Hope that helps,
>
>
> =====
> ------------------------------------------
> Harlan Carvey, CISSP
> "Windows Forensics and Incident Recovery"
> http://www.windows-ir.com
> http://groups.yahoo.com/group/windowsir/
>
> "Meddle not in the affairs of dragons, for
> you are crunchy, and good with ketchup."
>
> "The simplicity of this game amuses me.
> Bring me your finest meats and cheeses."
> ------------------------------------------
>
> ------------------------------------------------------------------------
---
> ------------------------------------------------------------------------
---
--
___________ ___________
__/ V ;
@ Vic Brown |
| Comp Supp Spec |
| FSU-Panama |
> vabrown (at) fsu (dot) edu [email concealed] <
| Phone: (507)-314-0367 |
| mailer.fsu.edu/~vabrown |
@__________________________;
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
[ reply ]