hi,
first, i have read the whitepapers and the security docs, faqs, etc. i still have questions.
i converted qtree with user dirs from unix to ntfs.
if i look at a users home dir with secure share tool it says no acl. i look at the ntfs security perms and it says the user has full,full and that everyone has rx,rx. i understand this is coming from the unix perms that were there.
i give domain admins full control over that dir, subdirs and files. i look at it with secure share and it says root is owner [but greyed out] and there is an acl. i look at the dir and sub dirs with the nt security tab and i see domain admins full, the user full, and everyone rx,rx.
example, before creating acl
G:\o\odragan\ Owner: domain\odragan domain\nlehrer (RWX)(RWX)* domain\odragan (All)(All)* G:\o\odragan\Marti\ Owner: domain\odragan domain\nlehrer (RWX)(RWX)* domain\odragan (All)(All)* Everyone (RX)(RX) G:\o\odragan\Oksana\ Owner: domain\odragan domain\nlehrer (RWX)(RWX)* domain\odragan (All)(All)* Everyone (RX)(RX)
after
G:\o\odragan\ Owner: Administrators (lg) domain\Domain Admins (gg) (All)(All)* domain\nlehrer (RWX)(RWX)* domain\odragan (All)(All)* G:\o\odragan\Marti\ Owner: Administrators (lg) domain\Domain Admins (gg) (All)(All)* domain\nlehrer (RWX)(RWX)* domain\odragan (All)(All)* G:\o\odragan\Oksana\ Owner: Administrators (lg) domain\Domain Admins (gg) (All)(All)* domain\nlehrer (RWX)(RWX)* domain\odragan (All)(All)* ~~~~~~~~~~~~~~~~
the question is, the domain admins ace was set up when i created the acl. but, the user's ace is it still from the unix perms or from where, since i did not create it.
i have to set up ntfs acls for all copied over data so this is important. should i recreate the user's access or just leave the one that is there? i will remove the ace for everyone, but i don't understand what the user's own access represents.
any guidance would be appreciated. thanks. --
i converted qtree with user dirs from unix to ntfs.
if i look at a users home dir with secure share tool it says no acl.
Right. You should find that the switch of the qtree to NTFS will initialize the root directory with an "Everyone - Full Control" ACL, but we won't plough down through the pre-existing data and initialize a bunch of ACLs on everything by "second-guessing" ACL contents from the available UNIX permission sets. There's really no objectively correct way to do that, so the filer steps out of the way and leaves it to the administrator to initialize *exactly* what security they need from a client.
i look at the ntfs security perms and it says the user has full,full and that everyone has rx,rx. i understand this is coming from the unix perms that were there.
On the files and directories that are below the root of the qtree, yes, that's likely what you would see. These aren't real ACLs, they are just "mocked up" display ACLs.
i give domain admins full control over that dir, subdirs and files.
Which would have the effect of initializing "proper" ACLs onto all those subdirs and files. Now everything should be in full NTFS mode, and all the normal rules of NTFS security will apply for this data.
i look at it with secure share and it says root is owner [but greyed out] and there is an acl. i look at the dir and sub dirs with the nt security tab and i see domain admins full, the user full, and everyone rx,rx.
Now it's starting to sound a little wrong. You didn't say explicitely how you were initializing the ACLs, but if you were using the Windows Explorer and its "Replace permissions on subdirectories" and "Replace permissions on existing files" options, you should get exactly the ACL that you specified on every subdirectory and file. What was there before should not matter (i.e. the new information is not overlayed onto the clients view of what the pre-existing security looked like). If you are using some other mechanism that perhaps works differently to the Windows Explorer, therein might lie the problem?
Keith
Keith Brown wrote:
i converted qtree with user dirs from unix to ntfs.
if i look at a users home dir with secure share tool it says no acl.
Right. You should find that the switch of the qtree to NTFS will initialize the root directory with an "Everyone - Full Control" ACL, but we won't plough down through the pre-existing data and initialize a bunch of ACLs on everything by "second-guessing" ACL contents from the available UNIX permission sets. There's really no objectively correct way to do that, so the filer steps out of the way and leaves it to the administrator to initialize *exactly* what security they need from a client.
i look at the ntfs security perms and it says the user has full,full and that everyone has rx,rx. i understand this is coming from the unix perms that were there.
On the files and directories that are below the root of the qtree, yes, that's likely what you would see. These aren't real ACLs, they are just "mocked up" display ACLs.
i give domain admins full control over that dir, subdirs and files.
Which would have the effect of initializing "proper" ACLs onto all those subdirs and files. Now everything should be in full NTFS mode, and all the normal rules of NTFS security will apply for this data.
i look at it with secure share and it says root is owner [but greyed out] and there is an acl. i look at the dir and sub dirs with the nt security tab and i see domain admins full, the user full, and everyone rx,rx.
Now it's starting to sound a little wrong. You didn't say explicitely how you were initializing the ACLs, but if you were using the Windows Explorer and its "Replace permissions on subdirectories" and "Replace permissions on existing files" options, you should get exactly the ACL that you specified on every subdirectory and file.
yes i used the Windows Explorer and its "Replace permissions on subdirectories" and "Replace permissions on existing files" options. i got the domain admins full perm that i put in that way. the question i have is whether the "mocked up" display acls for the user and everyone should still be there???
i get the same result whether i use windows explorer or cmd line tools that i also have and hoped to use to eventually get the acls the way i want them. but i can't get there if i don't understand what is going on.
What was there before should not matter
(i.e. the new information is not overlayed onto the clients view of what the pre-existing security looked like). If you are using some other mechanism that perhaps works differently to the Windows Explorer, therein might lie the problem?
Keith
Hi Neil....
the question i have is whether the "mocked up" display acls for the user and everyone should still be there???
No, the files/dirs should be switched to NTFS security by the act of setting the ACLs on them, and they should have on them *exactly* the ACL that you're setting, no more and no less. Note that you will still see the SecureShare tab on the Windows explorer "Properties" sheet, even for files that have an ACL, but the UNIX perms you are seeing there are not relevent when it comes to evaluating access to an NTFS mode file (in fact, you should find they are greyed out, for the most part). The ACL contents shown to you through the "Security->Permissions" dialog for a file should be precisely as you set them, and should not contain any entries (ACEs) that are derived from the file's UNIX permissions.
So, if you are seeing something different than the above, I'm afraid I'm stumped, so I would suggest opening a case with our support folks. You can do this very easily through NOW, and you can even chat with a support engineer electronically. Maybe they've seen something like this before and can make a call on what might be going on.
Keith
-
Keith Brown -
neil lehrer