The Lab
CDOT
8.2.2P1
SVM
= SVM01 (a brand new SVM created using ‘vserver setup’, with cifs and nfs
protocols, and SVM root volume security style NTFS)
Active
Directory Domain = Lab.priv
Cifs
Server = SVM01 with a LIF on 10.10.10.130 (A-Record for SVM01.lab.priv created)
vol1
junctioned at /vol/vol1
vol2
junctioned at /vol2
qtree1
on vol1
qtree2
on vol2
folder1
in vol1
folder2
in vol2
folderQ1
in qtree1
folderQ2
in qtree2
folderF1
in folder1
folderF2
in folder2
CIFS
shares created as below:
::>
cifs share create -share-name vol1$ -path /vol/vol1 -vserver SVM01
::>
cifs share create -share-name vol2$ -path /vol2 -vserver SVM01
::>
cifs share create -share-name qtree1$ -path /vol/vol1/qtree1 -vserver SVM01
::>
cifs share create -share-name qtree2$ -path /vol2/qtree2 -vserver SVM01
::>
cifs share create -share-name folder1$ -path /vol/vol1/folder1
::>
cifs share create -share-name folder2$ -path /vol2/folder2
::>
cifs share create -share-name folderQ1$ -path /vol/vol1/qtree1/folderQ1
::>
cifs share create -share-name folderQ2$ -path /vol2/qtree2/folderQ2
::>
cifs share create -share-name folderF1$ -path /vol/vol1/folder1/folderF1
::>
cifs share create -share-name folderF2$ -path /vol2/folder2/folderF2
The
CIFS shares are created with standard settings as in the example below for
vol1$:
::>
cifs share show vol1$ -instance
Vserver:
SVM01
Share:
vol1$
CIFS Server NetBIOS Name:
SVM01
Path:
/vol/vol1
Share Properties:
oplocks
browsable
changenotify
Symlink Properties:
enable
File Mode Creation Mask:
-
Directory Mode Creation Mask:
-
Share Comment: -
Share ACL:
Everyone / Full Control
File Attribute Cache Lifetime:
-
Volume Name:
vol1
Offline Files:
manual
Vscan File-Operations Profile:
standard
/vol in CDOT
/vol in CDOT is just a folder called vol that’s in the
root volume. The folder vol has Everyone Full Control NTFS permissions (as does /vol2 which is junction-ed directly
to root, and /vol/vol1 has permissions the same - and by default permissions
are inherited by child objects.)
Image: /vol in CDOT
as seen via the default c$ share
Modifying CIFS
Share Permissions
I’m going to lock this environment down a little via CIFS
Share Permissions (some people will argue to give CIFS shares ‘Everyone/Full
Control’, and control permissions at the NTFS level, we’re not going to do that
here ...)
The commands for one of the shares is below, this is
repeated on all 10 shares we created above:
::>
vserver cifs share access-control show -share folder1$ -vserver SVM01
::>
cifs share access-control create -share folder1$ -vserver SVM01 -user-or-group
BUILTIN\Administrators -permission Full_Control
::>
cifs share access-control create -share folder1$ -vserver SVM01 -user-or-group
"NT AUTHORITY\Authenticated Users" -permission Change
::>
cifs share access-control delete -share folder1$ -vserver SVM01 -user-or-group
Everyone
Testing Domain
User Access
I have a domain user - LAB\usertest - who is a member of the Domain Users group and also a group called testgroup. I want to make sure he can access all the shares before
I start making changes to NTFS permissions (which are currently inheriting
Everyone Full Control).
The follow net use commands should all result in “The command completed successfully” (Note: After each successful connection run
‘net
use T: /delete’ to disconnect the share.):
net
use T: \\SVM01\vol1$
net
use T: \\SVM01\vol2$
net
use T: \\SVM01\qtree1$
net
use T: \\SVM01\qtree2$
net
use T: \\SVM01\folder1$
net
use T: \\SVM01\folder2$
net
use T: \\SVM01\folderQ1$
net
use T: \\SVM01\folderQ2$
net
use T: \\SVM01\folderF1$
net
use T: \\SVM01\folderF2$
Restricting
NTFS Permissions
Now I restrict NTFS permissions on the qtrees so LAB\usertest
does not even have traverse permission, but they will have NTFS permission to
the folders in the Qtrees. qtree1 and qtree2 only have Domain Admins with Full
Control and no other permission. folderQ1 and folderQ2 have testgroup with
modify permissions.
Image: Modified
NTFS Permissions for qtree1, qtree2, folderQ1, folderQ2
And we do similar with the folders and sub-folders.
folder1 and folder2 only have Domain Admins with Full Control and no other
permission. folderF1 and folderF2 have testgroup with modify permissions.
Image: Modified
NTFS Permissions for folder1, folder2, folderF1, folderF2
Re-Testing with
Net Use
Below are the results of testing with Net Use.
net use T:
\\SVM01\vol1$
net use T:
\\SVM01\vol2$
net use T:
\\SVM01\qtree1$
net use T:
\\SVM01\qtree2$
net use T:
\\SVM01\folder1$
net use T:
\\SVM01\folder2$
net use T:
\\SVM01\folderQ1$
net use T:
\\SVM01\folderQ2$
net use T:
\\SVM01\folderF1$
net use T:
\\SVM01\folderF2$
For the lines in green we got:
The command completed
successfully.
For the lines in red it prompted for a username and then
password:
Enter the user name for 'SVM01':
The Results are
As Expected!
The results above are all as expected. If you try using
net use to connect to a share, and you don’t have NTFS permission to the folder
the share is based upon, then you won’t have access, and it will prompt for a username
and password for a user that does have access.
Note: I was
actually hoping the final four tests would fail and then I’d say “try changing
the CIFS shares to Symlink Hide and see if it works” ...
Re-Testing with
Net Use to Base Share and Folder
And these also all worked fine!
net use T:
\\SVM01\qtree1$\folderQ1
net use T:
\\SVM01\qtree2$\folderQ2
net use T:
\\SVM01\folder1$\folderF1
net use T:
\\SVM01\folder2$\folderF2
Why this Post?
I was kind of hoping the tests to folderQ1, folderQ2,
folderF1, folderF2 would fail, based on noticing a similar behaviour somewhere
else, but everything in this lab has worked perfectly - the behaviour has been
completely as expected! Even at that somewhere else, the behaviour was not
consistent, which points to some client side setting. The fix was going to be
to set Symlinks Hide on the shares, as in:
cifs
share modify -share-name folder1$ -symlink-properties hide
Note: If you are
considering doing this, please check with NetApp support before you do so, as I
understand clients will need to reboot to take the new setting - that is -
clients who are connected will continue working for a bit, then lose access
until they reboot (with 8.2.2P1)!
Comments
Post a Comment