Archived from groups: microsoft.public.win2000.security (
More info?)
Steve
Thanks again for the input. I think I will set up a test
server/client to see how much damage a user can do using
the command prompt. I see what you are saying about
logging, however I would like to stop users making my
life a misery, not just see which user has
If I make any significant progress, I will post in this
site. Once again, many thanks.
Regards
P Basham
>-----Original Message-----
>If you need to run logon scripts your options to limit
cmd.exe are limited
>as you mentioned. The ntfs permissions problem is
perplexing. I would check
>the permissions and ownership to that file before you
delete it to see if
>they are what you expected. Keep in mind that when you
are setting ntfs
>permissions always check advanced permissions also to
make sure that users
>or groups are not listed in there that you do not want
to have permissions.
>The other issue if the creator owner is present the
creator owner of a file
>folder will have those permissions applied to them.
Enabling of first object
>access and then auditing permissions to a file or folder
can help track down
>how file and folders are being accessed. I don't
recommend leaving auditing
>of object access enabled all the time though because it
can fill up the
>security log quickly. --- Steve
>
>
>"P Basham" <anonymous@discussions.microsoft.com> wrote
in message
>news:2ad801c4ad42$0a5eac80$a601280a@phx.gbl...
>> Steve
>>
>> Thanks for the reply.
>>
>> I suspected it was going to be difficult. We need to
>> allow cmd.exe to run when a user logs on to allow
scripts
>> to run. I found if I disable the command prompt script
>> processing in the "prevent access to the command
prompt"
>> policy discussed earlier, the user gets nothing but a
>> blue desktop. Obviously this is not good.
>>
>> As for ntfs permissions, hows this for an odd one. I
>> created a file, temp.txt on the root of C:\.
Permissions,
>> Everyone-Read, Dom Admins-Full control. Logged on as a
>> user, ran a .bat script to open command prompt, and was
>> able to delete the file. BTW, this action was performed
>> over a terminal service session from a thin client.
>>
>> Now I'm very worried
>>
>> Regards
>> P Basham
>>>-----Original Message-----
>>>That is going to be difficult to do in W2K. If you use
>> XP Pro you can use
>>>Software Restriction Policies to lock down a computer.
>> One thing you could
>>>try is to remove the users group from ntfs permissions
>> for every instance of
>>>cmd.exe and command.com on the computer. You will have
>> to search the
>>>computer for those files as they may be located in more
>> than one place such
>>>as in the dllcache folder or service pack files folder.
>> Even so that will
>>>not stop a user from copying a cmd.exe from a floppy
to
>> their user profile
>>>to access if they are that determined. As far as users
>> being able to delete
>>>files from the hard drive, you may have to review your
>> ntfs permissions for
>>>the users. If they are local administrators or power
>> users fro some reason
>>>that will be next to impossible to do. -- Steve
>>>
>>>
>>>"Pbas" <anonymous@discussions.microsoft.com> wrote in
>> message
>>>news:3f0a01c4ac6f$3774df10$a501280a@phx.gbl...
>>>> Hi
>>>>
>>>> We have a problem I hope someone can help us with.
>>>>
>>>> In an OU group policy for a group of users we have
>>>> enabled the User Configuration-Admin Templates-
System-
>>>> "Prevent access to the command prompt". We have also
>>>> added cmd.exe to the "Don't run specified windows
>>>> applications". However we have found that if a user
>> runs
>>>> a .bat file with say, ipconfig as the text, Windows
is
>>>> quite happy to allow the user to open the command
>> prompt
>>>> window. From here, the user can view and delete files
>> on
>>>> the hard drive.
>>>>
>>>> If the user types cmd.exe from the command prompt,
this
>>>> is in fact disallowed. How do we stop the user from
>>>> opening the command prompt.
>>>>
>>>> Regards
>>>> P Basham
>>>
>>>
>>>.
>>>
>
>
>.
>
Facebook
Twitter
Instagram