Re: NTFS Security Question.

I was not sure that deleting the special permissions would work but you
confirmed it did. Since Windows 2000 deny NTFS permission does not work
exactly like it did in NT4.0 and before. For example an explicit allow will
override an inherited deny and if an object has both an inherited deny and
allow permission it is possible for the inherited allow to prevail if it was
originally configured "closer" to the object in the chain of folders. I am
not sure why this was changed and it seems to be a little known/documented
fact. I have only seen it mentioned a couple of times in the dozens of books
I have read for MCSE and Windows security. This is one reason why I always
recommend that users try to configure access control lists without any deny
permissions as often the results are not what is expected and could garner a
false sense of security and instead try to configure access control lists so
that lack of permissions is what is used to control access.

Having said that it still does not seem to explain why your explicit deny
permission for the root folder for write did not work. When you apply
permissions to the main security page it applies to folders, subfolders, and
files. However explicit permissions were also applied in special permissions
for subfolders only and this folder and subfolders only. My guess is that
the operating system gives higher priority to the more specific special
permissions than the "general" permissions for folders, subfolders, and
files and therefore the write deny was overridden by the allow for create
files and create folders in special permissions.

Steve

http://technet2.microsoft.com/WindowsServer/en/library/d043701a-5a2e-4001-b659-0c23c90f76f61033.mspx?mfr=true

Notes

. Inherited Deny permissions do not prevent access to an object if the
object has an explicit Allow permission entry.

. Explicit permissions take precedence over inherited permissions,
even inherited Deny permissions




"Wiley Coyote - N2K" <mits_mvp@xxxxxxxx> wrote in message
news:Om$73zZxGHA.4568@xxxxxxxxxxxxxxxxxxxxxxx
Thanks Steven. The advanced page did it - DOH!!!

Now, I'm still not sure why the "DENY" allowed this? My understanding (and
I've been an SE and MCT for over 20 years) is that DENY means exactly
that.

In the NIX world, deny meand DENY as it does in NDS. Hmmm, perhaps I can
get rich off this and explain to the Gates Empire. NOT!

Anyway, I've been all over the web, and chatted with a lof of people. In
fact, I gave perms to a fellow in Boca Raton (whom I've know for years) to
vpn in and he checked. He was quite surprised as well.

Still looking into it, there must be something that I'm missing, but in
the meantime the Advanced Props fixed it.

Again, tx.

Wiley.

Wiley.
"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:ks-dndyyOoxa6nfZnZ2dnUVZ_oudnZ2d@xxxxxxxxxxxxxx
Hmm. You might also check the advanced page for special permissions and
remove the two special permissions for users there for creating folders
and files to see if that makes a difference. It should work just by
making sure users do not have write permissions which is an implicit
deny. If you are testing with a user account that you changed group
membership on make sure you logoff as that user so that the new logon
will reflect changes in group membership.

Steve


"Wiley Coyote - N2K" <mits_mvp@xxxxxxxx> wrote in message
news:%23gzxRgWxGHA.2448@xxxxxxxxxxxxxxxxxxxxxxx
I believe I posted this in the WRONG post - oops.

So:

I have set NTFS perms on the Root of my system volume to EVERYONE: Deny
Write. Yet, I can still create folders and files! I've been an SE for a
longggg time and never saw this before. The perms are at the Root, so
there
is nothing to inherit.

This acount that I am using is NOT a member of any supernumery group,
just
a plain Jane user account. I logged in with admin rights to check the
NTFS
perms and all seems to be OK as follows:

System: CHANGE (not FC),
Everyone Read & Exec, List, Read ((Deny Write),
C.O. : nada,
Administrators: Change,
Users: Read & Exec, List, Read (Deny Write)

One of the reasons for this level of security is to prevent certain web
sites from dropping VB apps in the root and other silly things.

Anyway, just curious as to why I can (as an ordinary user) do this.

If anyone know what is happending that would be good.

Thanks.









.

Relevant Pages

  • Re: NTFS Security Question.
    ... A subordinate object DOES not inherit the PARENT perms (in ... will assume "Nebulous" permissions that refer to the LINK ... The trick is to PROPOGATE to all FILES (not Folders and Files - that would ... Since Windows 2000 deny NTFS permission does not work ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Cannot Delete A Public Folder
    ... Permissions with a Deny. ... I don't see send as and Receive as as listed perms on my public folder ... >> Folders. ...
    (microsoft.public.exchange.admin)
  • Re: Deny folders creation/deletion without altering files accesses
    ... Yes the Advanced Special Permissions is what I used, but if you look in there ... the option is actually called "Create Folders / Append Data", ... >>> How to configure file sharing in Windows XP ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Deny folders creation/deletion without altering files accesses
    ... Have you tried the "Special Permissions" in Security\Advanced Options\Modify ... >> How to configure file sharing in Windows XP ... >> permissions for access to your files and folders. ...
    (microsoft.public.windowsxp.security_admin)
  • Re: how to restrict users to search in their own Organizational Unit
    ... I also want to say that in fact you shouldn't deny the read permission to anyone and this scenario the MOSS Administrators or who is responsible for Add users to Your Sites should be carefull when performing this action. ... Now, because you're dealing with many users, my recommendation is to create THE NECESARY Security Groups in each OU and related them with your MOSS2007 existing security groups, in future when someone creates some user, you just have to add that user to the necessary group and that user will be given the necessary permissions. ... decided a script can make it possible to accomplish, ... > If I need to create a security group per OU and then add all users ...
    (microsoft.public.windows.server.active_directory)