ARX: Troubleshooting "CIFS Access Is Denied” Messages

Introduction

It is impossible to enumerate all the scenarios under which CIFS access via or by ARX may be denied. In many cases, denial of access may be the desired behavior and can sometimes be temporary. This article is intended to aid in diagnosing the cause when it is not expected.

The simple answer; almost in all cases, the file server whose storage ARX is virtualizing returns this error because the entity accessing a file or file system data is not allowed access. In order to understand why, one needs to pay attention to the identity used by the server i.e. whether the access from ARX is:

• · On-behalf of a user accessing data by connecting to an ARX export
• · By ARX, using configured proxy-user credentials, in order to support a configuration operation (e.g. probe), import, directory striping, migration etc.

To make this decision, the file server matches file attributes (such as read-only), and security descriptor(s) associated with the accessed data with the identity (or credentials) established for the CIFS connection. In CIFS environments, a security descriptor contains an ACL that is used to grant or deny access. In addition, account privileges (e.g. Backup Operator) can be assigned to certain users and groups to bypass file system ACLs.

Share ACLs vs. File System ACLs

There are two types of ACL that are checked by a CIFS file server for access. Share ACLs apply when an ARX connects to a share, and file or directory ACLs apply when a file is opened. For ARX clients connecting via an ARX export, ARX itself has no mechanisms to perform the checks but relies on servers hosting the storage for enforcement. For this reason, the clue to the root cause of an access denial is external to the ARX.

The recommended deployment model with ARX is to use file system ACLs for access control and keep the share ACLs open to everyone. Where deployment environments demand use of share ACLs, ARX Subshares feature can be used. ARX does not manipulate share ACLs unless Subshares are being used.

A common cause for denial of access is that share ACLs are too restrictive. For non-Subshare exports, ARX itself maintains a share ACL which grants all access to everyone to file data accessed by connecting to the share; ARX does not support changing this ACL. Note that account privileges allow certain users to bypass file system ACLs but not share ACLs. This is the reason why ARX features such as Subshares and ABE require ARX proxy-user to have administrative access on the file server.

One can examine share ACLs using the Shared Folders functionality in MMC available on Windows.

Figure 1 - Shared Folders

Note that, as is the best practice, in the above example, share ACLs allow Everyone access to the share, whereas file system ACLs may not.

One can view file system ACLs, using Windows Explorer.

Figure 2 - Directory ACLs

ARX and File System ACLs

In order to use file system ACLs with ARX, one must enable the persistent-acls volume attribute in ARX configuration. If this attribute is disabled, it is important to ensure that file system ACLs are either disabled or permit all access to everyone; otherwise access may be granted to file data some times, but denied at others. It is also possible that any ACL set up for a file or directory may be lost upon migration, adding to the confusion.

When persistent-acls are enabled, ARX checks the backend storage for the volume actually supports ACLs in a consistent manner that is expected by ARX software to support file system ACLs; Enabling storage validates that proxy-user has sufficient privileges for import, directory striping, and migration involving that storage.

Persistent ACLs setting on ARX can be viewed and edited using the ARX Manager GUI.

Figure 3 - ARX Volume - Persistent ACLs

Figure 4 - ARX Volume - Edit Page

MMC Access

ARX Clients can attempt front-end management operations such as creating an export or listing exports via CIFS (DCE RPC) protocol; such operations are controlled by Windows-Management-Authorization (WMA) configuration on the ARX. WMA provides a simplified form of ACL on an ARX namespace and is not a share or file system ACL. ARX front-end export ACLs are read-only and cannot be set, say via Microsoft Management Console (MMC); ARX silently ignores share security descriptor updates.

For example, if the WMA configuration is improperly set up, the operation to examine shares using MMC (e.g. Figure 1 Shared Folders) will be denied access. One can examine and update a WMA policy on ARX using ARX Manager GUI. One or more WMA policies may be selected for a namespaces in their edit page. Example below shows editing a WMA policy of named MMC and how it is selected for namespace cifsrealm in the namespace edit page.

Figure 5 - ARX WMA Settings

Figure 6 - Applying WMA Policy to a Namespace

Potential Causes

Some of the scenarios which may cause an unexpected denial of access are

• · Misconfiguration on ARX or environment – such as restrictive share ACLs, inconsistent persistent-acls attribute, ARX proxy-user without sufficient privileges
• · Multi-protocol environments in which a file server supports only UNIX permissions or POSIX ACLs that are more restrictive compared to Windows (NTFS) ACLs.
• · Complex environments using file servers from multiple domains, one-way trusts, and SID-filtering for authentication can also interfere with proxy-user ability to stripe directories or migrate files. Note that account privileges in the windows domain for ARX proxy-user do not necessarily apply when the resource (storage) domain is different.
• · Accessing the storage configured on ARX directly on the backend storage. Especially if the file or directory ACL is modified.
• · Directories locked for pending operations.
• · DOS file attributes maintained by NTFS. These attributes such as the read-only bit will take precedence over any NTFS ACLs. However, clients that have write permission can circumvent the read-only check (i.e. by disabling the attribute).
• · ACL changes upon migration. While ARX software attempts to preserve the security descriptor upon file migration, some file servers may report success but ignore parts of the ACL or add additional access control entries to the ACL.
• · User credentials (e.g. group changes) permit access, but ARX uses existing sessions to file servers. These connections are reclaimed when all the front-end clients disconnect or are idle for some time; at that point updated credentials take effect for new connections.
• · Symbolic links with targets outside of connected tree.
• · Attempt to open a file or directory in read-only ARX volume for writing.
• · Attempt to access a Subshare export that is degraded i.e. striping of subshare is incomplete on the backend. It may require a sync subshares operation to correct it.

Conclusion

As one can see, the causes for authorization problems in CIFS environments in which ARX operates can be varied. This article has only scratched the surface with respect to facilitating an understanding of the mechanisms and identifying some potential trouble spots in ARX deployments. References below or other ARX Dev. Central topics provide additional material on ARX terminology, how ARX works with UNIX file system ACLs, ARX Subshares, MMC access to ARX, SID Translation, Access Based Enumeration (ABE), and ARX-Mac interoperability.

Supplemental Information

1. Microsoft Authorization and Access Control Technologies
2. DOS Attributes and NTFS
3. ARX CLI Storage Management Guide
4. ARX CLI Reference Manual

Author Bio

Nehru Bhandaru is a principal software engineer at F5 Networks working on file virtualization. He is the team lead for CIFS protocol support in the F5 ARX product and joined F5 in 2007 with a background in Distributed Systems, Networking, Security, and Wireless technologies.