NFS and deny permissions

There's always "bonus features" that get stuck into products that may or may not be useful.   But the hard part of all this is when you start using that "bonus feature", then your locked in and... BANG!  They gotcha!  Then when you want to migrate off....   BOOM! You can't. 
Is it really locking you in?  Maybe... maybe not.  There are certain features that are life savers and you need to make a decision on whether or not to really abandon that product and go with another that doesn't have that feature.   For other features, you just need a way to do the same ting in another way.
Once of these features is a "deny permissions" setting on another NAS vendor's system.  This in essence denies anyone from being able to change the permissions of a file via NFS.  This means no chmod's allowed.  Is that a good thing?  Well maybe.  It may allow the permissions to be set initially on a file but all subsequent changes are denied.  This is great, but there's other mechanisms in the world to provide the same or similar behavior.  And why do you really need this?  For one, some unified permissions schemas are so insecure, this is a way to be "secure".


Deny Permissions on NFS the easy way.  With NTFS.
Lets look at ONTAP and the "deny permissions" flag.   How can you "deny permissions" for chmod in ONTAP?   Well, the easiest way is to create an NTFS volume (or change the security style of an existing volume).   If an NFS client tries to perform "chmod" operations to the files or directories in that volume, the operation will be denied.  This can cause problems with some Linux applications that can't have chmod return errors; like vi.  For this, ONTAP has a setting called "ignore security operations on NTFS volumes" (-ntfs-unix-security-ops ) .  When this is set, ONTAP will return a success to the chmod, which makes the application happy, but in reality, it just discards the chmod op.  This way, the only way to change the permissions is via Windows or SMB.  Now you can use Windows ACLs to further limit permissions and access.  Why is this good?  Well, you can set the initial permissions at the volume level and then be sure that all files and folders inherit the exact same permissions without fail.  If you don't allow SMB access, then noone will be able to change it.

In action?   Why sure.  Here we go.  (Assuming SVMs, CIFS server, protocols, and other Vserver is already done)
1.  Create an NTFS volume
cluster::> volume create -vserver svm0 -volume no_chmods -aggregate aggr1_node1 -size 100G -security-style ntfs -junction-path /no_chmods
2.  Change the setting to ignore the NFS chmods

cluster::*> vserver nfs modify -vserver svm0 -ntfs-unix-security-ops ignore

Then what happens?  Well you need to create the export policy for the volume, but then you just mount the volume and viola.....  there's no way to chmod.  You can't chown either from an NFS client.  You can only change the ACL from an SMB client.

So here I have the volume mounted, touched a file and then chmod'd it.  As you can see, there was no error to the chmod, just a return, but the chmod did nothing.  This is because when ONTAP is presenting an NTFS style volume to NFS clients, NFS security operations cannot  modify the file permissions.  

Bonus Material:   The NTFS permissions can even be locked down beyond what's listed via SLAG (Storage Level Access Guard) in ONTAP.  SLAG allows you to put another set of ACLs on the volume and further deny (SLAG can only limit and not allow more permission) access to the files.

Deny permissions on NFS with NFSv4 ACLs on UNIX style volumes.

You don't want to use NTFS style volumes?  There definitely is another way of limiting access to chmod, and that's via NFSv4 ACLs.  Those ACLs work similarly to NTFS ACLs and can deny rights to change permissions and ownership if necessary.  If you are not familiar with NFSv4 ACLs, go visit my favorite resource for them at die.net (https://linux.die.net/man/5/nfs4_acl).  There's some good resources I've relied on forever.  Here's the catch....  you can't limit the chmod for the file owner.  Bummer.  

How do you do this one?  Let's see.....

1.  Allow NFSv4 on the NFS server and allow the ACLs.  We're assuming you already have an SVM, an export policy and a volume exported.

cluster::> vserver nfs modify -vserver svm0 -v4.0 enabled -v4.0-acl enabled -v4.1 enabled -v4.1-acl enabled

2.  Enable the setting to force the ACL over mode bits to be applied on new files & folders

cluster::*> vserver nfs modify -vserver svm0 -v4-inherited-acl-preserve enabled

3.  Enable the setting to not clobber the ACLs when an actual chmod is run by someone who is allowed

cluster::*> vserver nfs modify -vserver svm01 -v4-acl-preserve enabled

Then you can mount the volume either NFSv3 or NFSv4 and the same ACL is applied to both protocols.  First you do have to set the ACL properly for this to work.  Let's see how this is done.

First set the proper permissions.  What you don't want in there is "write attributes" (capital T), write named attributes (capital N..  and it's optional) and write ACL (capital C)

# nfs4_setacl -a A::testerdlu0002@ntap.local:rwaxtncy testfile

This will allow the user to perform any operation except modify the ACL, owner and mode bits.

So now, when the user tries to chmod the file... viola.. permission denied!

Can you also do it with SLAG and UNIX style volumes??

Well sure you can.  You have to be a little careful with SLAG though.  There are a few caveats.  First, you have to have a CIFS server created on the SVM.  Easy enough.  Second, you MUST have Unix->Windows usermapping working perfectly.  Without it, SLAG won't be applied properly since it used the Windows user creds to apply it.  Third, it also looks to have an implicit default DENY rule at the end of it.  No bueno if you want to ensure the same access.

Here's the policy I was using that had some success.  Notice the 2 deny rules at the top.  The access rights hex value (c0110) translates to WriteEA,Write Attributes, Write DAC and Write Owner in the NTFS permission world.  This basically denies everyone the right to chmod.

cluster::*> file-directory ntfs dacl show -vserver svm0

  (vserver security file-directory ntfs dacl show)

Vserver: svm0

  NTFS Security Descriptor Name: deny_write_attr_everyone

    Account Name     Access   Access             Apply To

                     Type     Rights

    --------------   -------  -------            -----------

    BUILTIN\Users    deny     c0110             this-folder, sub-folders, files

    CREATOR OWNER    deny     c0110             this-folder, sub-folders, files

    BUILTIN\Administrators

                     allow    full-control      this-folder, sub-folders, files

    BUILTIN\Users    allow    full-control      this-folder, sub-folders, files

    CREATOR OWNER    allow    full-control      this-folder, sub-folders, files

    NT AUTHORITY\SYSTEM

                     allow    full-control      this-folder, sub-folders, files

6 entries were displayed.

The bottom line?   Well... to be honest, the only reason that some NAS appliances have this "deny chmod" feature is in order to keep files secure and to enforce a consistent set of permissions across a volume.  Well...  if you really want to do that, let's use NTFS volume security.  That's the easiest.  Then you can manage permissions once when the volume is created (apply inheritable permissions at the volume root) and then its applied everywhere.  If you REALLY Need it in a UNIX style volume.....  You can use NFSv4 ACLs to deny write attributes.  If you ABSOLUTELY need it to apply to the owner too, look into using SLAG.

Microsoft, ONTAP, and the LDAP Channel Binding Apocalypse

Howdy Folks!  I'm sure that everyone has heard and is panicking about the patch that Microsoft announced around LDAP communication and channel binding.  For those of you that are living under a rock with an early 2000's flip phone, here's the link: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

Well, let me be your guide around what this means when it comes to ONTAP.  Buckle up, and here we go.
                              

FIRST OFF:  LDAP CHANNEL BINDING TOKENS
The MS update (when it comes out.  as of this writing, it is now pushed to 2H CY2020) will require channel binding tokens(CBT) only if the client supports it.  That is the default registry setting of 1 that the patch will set.  So, when you install the patch and do nothing else, there will be no effect on ONTAP since ONTAP does not support CBT.   At some point, Microsoft may change the default setting to 2, or your AD team or security team may require a setting of 2, but until ONTAP supports CBTs, a setting of 2 is not compatible with ONTAP.   The default setting of 1 or a setting of 0 (never required) is compatible with ONTAP.
NOTE:  ONTAP above includes all releases of Cluster Mode and 7-Mode ONTAP and Data ONTAP.

NEXT:  THE REAL PROBLEM.....   LDAP SIGNING REQUIRED
The MS update will change the behavior of the settings for LDAP signing required.  This means that if you have never touched the setting, it will now behave as if LDAP signing is required in your environment.  Here's a little cheat matrix to help you.



If you explicitly set the LDAP Signing Requirement to "OFF" in your environment, you will have no impact after the patch.  Nothing will change.  The patch will not modify the setting.  Remember though, this will need to have been EXPLICITLY SET TO OFF either in a GPO or registry setting on the DCs.

If you are currently using "Signing required" in your environment (setting of 2), then you have already done everything in your environment necessary to support it.  The patch will not modify, enhance or change that setting.  You will have no impact after the patch.  Remember, you will have had to set this EXPLICITLY in a GPO or registry setting on the DCs.

For everything else, you need to do some changes.

I have an SVM with a CIFS server
If you are already using StartTLS, LDAPS, or signing/sealing for the CIFS security, you do not have to do anything.  Any of those settings will meet the requirements of the patch.  Here's an example SVM with none of the 3 set properly:

If you are like the above and have none of the possible settings set, the easiest setting to modify is the signing & sealing (client session security) option. This is because StartTLS and LDAPS both require certificates and if you don't have a certificate infrastructure in your environment, well...  its complicated.  In order to set signing use the following command:
 vserver cifs security modify -vserver svm0 -session-security-for-ad-ldap sign
Replace "svm0" with your vserver name.  That's it for the CIFS server.

This will only work for ONTAP 9 and higher.  For Data ONTAP 7-mode, the connection automatically upgrades to sign when it encounters an AD where signing is required.  There is nothing additional needed to do for 7-mode.  For ONTAP cluster-mode versions older than 9, you'll need to set up StartTLS.  There's plenty of documentation and resources on how to set up StartTLS for the CIFS server.  I'm not going to go into it here.

I have and SVM with a UNIX LDAP client
Here's where it gets a little complicated due to the amount of permutations of the LDAP config there are.  Now, what I can say is that the same rules apply for UNIX LDAP connections as the CIFS server security settings.  If you are already using StartTLS, LDAPS or signing/sealing for the configuration, then you are in the clear and you are meeting the requirements of the patch.  Here's a screenshot of a client config with none of the 3 set properly"

NOTE:   As of ONTAP 9.5, if you use "636"  for the LDAP Server Port, LDAPS will be used automatically

Now, I am not going to go through all the iterations of possible configurations and what their outcomes are, but I will point you to the best practice and what is the easiest; use the AD-Domain setting, use the bind-as-cifs-server setting, and use the signing & sealing (Client Session Security) option.  Using the AD-Domain setting will automatically discover AD DCs and attach to the closest one using sites and services.  Using the bind-as-cifs-server setting will guarantee a sasl bind and enable the ability to sign or seal.  Then using at least signing for that configuration will use signing for the LDAP connection similar to the CIFS server operation I explained above and satisfy the requirement.

Want to read the official NetApp KB article?  Click on this:  https://kb.netapp.com/app/answers/answer_view/a_id/1103575

**Whew**  Now that we've muddled though alot of the muck on this, I hope you followed me through the configurations and now you know what you need to do to stay operational once the patch hits and gets applied to your DCs.  Apocalypse.....  carry on!