Quantum/StorNext/SNFS/CVFS - Windows Permissions using an Active Directory Domain

Quantum/StorNext/SNFS/CVFS - Windows Permissions using an Active Directory Domain information provided by Quantum Support

From the StorNext "Operating Guidelines and Limitations" section of the release notes (beginning with version 3.5.3), as well as in the associated user's guides*:

“In StorNext releases prior to 3.5, the StorNext Windows client attempted to keep the UNIX uid, gid and mode bits synchronized with similar fields in the Windows security descriptor. However, these Windows and UNIX fields were often not synchronized correctly due to mapping and other problems. One consequence of this problem was that changing the owner in Windows incorrectly changed the UNIX uid and file permissions and propagated these errors into sub-directories. Beginning with release 3.5, the StorNext Windows client sets the UNIX uid, gid and mode bits only when Windows creates a file. The StorNext Windows client will no longer change the Unix uid, gid or mode bits when a Windows user changes the Windows security descriptor or Read-Only file attribute.

If you change the UNIX mode bits and the file is accessible from Windows, you must change the Windows security descriptor (if Windows Security is configured On) or Read-Only file attribute to ensure the change is reflected on both Windows and UNIX.”

 

Below is the description of the settings related to Windows and Active Directory usage in the StorNext file system config files.

The options that are related to Active Directory in a windows environment are:

The "windowsSecurity" variable is passed back to a Microsoft Windows client.

The WindowsSecurity variable enables or disables the use of the Windows Security Reference Monitor (ACLs) on Windows clients. This makes use of an Active Directory domain in which LDAP services must be enabled.

The "unixIdFabricationOnWindows" variable is passed back to a Microsoft Windows client.

The client uses this information to turn on/off "fabrication" of uid/gids from a Microsoft Active Directory obtained GUID for a given Windows user.

A value of yes will cause the client for this file system to fabricate the uid/gid and possibly override any specific uid/gid already in Microsoft Active Directory for the Windows user.

This setting should only be enabled if it is necessary for compatibility with Apple MacOS clients.

The default is false, unless the meta-data server is running on Apple MacOS, in which case it is true.

The "unixNobodyGidOnWindows" variable instructs the FSM to pass this value back to a Microsoft Windows client.

The Windows SNFS clients will then use this value as the gid for a Windows user when no gid can be found using Microsoft Active Directory.

The default value is 60001. This value must be between 0 and 2147483647, inclusive.

The "unixNobodyUidOnWindows" variable instructs the FSM to pass this value back to Microsoft Windows clients.

The Windows SNFS clients will then use this value as the uid for a Windows user when no uid can be found using Microsoft Active Directory.

The default value is 60001. This value must be between 0 and 2147483647, inclusive.

The remaining options for a unix to Windows conversion have to do with files and directories:

The "unixFileCreationModeOnWindows" variable instructs the FSM to pass this value back to Microsoft Windows clients.

The Windows SNFS clients will then use this value as the permission mode when creating a file.

The default  value is 0644.  This value must be between 0 and 0777, inclusive.

The "unixDirectoryCreationModeOnWindows" variable instructs the FSM to pass this value back to Microsoft Windows clients.

The Windows SNFS clients will then use this value as the permission mode when creating a directory.   

The default value is 0755.  This value must be between 0 and 0777, inclusive.

 

In conclusion and to try and make this understandable:

If the "windowsSecurity" option is set to false, then the uid/gid for any files created by any Windows Client will be the default settings established in the "unixNobodyGidOnWindows" and “unixNobodyUidOnWindows” options.

If the "windowsSecurity" option is set to true, then the StorNext client makes a call with the Windows API DsGetDcName() and it returns either an error 1355 (ERROR_NO_SUCH_DOMAIN) or successfully connects to the domain control.  If an error is returned to the API query then we use the defaults as described earlier.  If the AD is reached and the logged in user is a member described in that domain, then StorNext expects the uid/gid information under the Unix Attributes tab to be populated and uses it instead of the default settings established in the file system configuration file(s).

 

Warning: Once the "windowsSecurity" option is enabled (configuration option set to true and file system restarted) the only way to disable it is to rebuild the file system with the "windowsSecurity" setting set to false.  Quantum Support has stated there is no additional metadata overhead and the only "down side" would have to be inferred from the *first section.