Manage superuser access requests
-
PDF of this doc site
- Cluster administration
-
Volume administration
- Logical storage management with the CLI
-
NAS storage management
- Configure NFS with the CLI
- Manage NFS with the CLI
-
Manage SMB with the CLI
- Manage file access using SMB
- Security and data encryption
- Data protection and disaster recovery
Collection of separate PDF docs
Creating your file...
When you configure export policies, you need to consider what you want to happen if the storage system receives a client access request with user ID 0, meaning as a superuser, and set up your export rules accordingly.
In the UNIX world, a user with the user ID 0 is known as the superuser, typically called root, who has unlimited access rights on a system. Using superuser privileges can be dangerous for several reasons, including breach of system and data security.
By default, ONTAP maps clients presenting with user ID 0 to the anonymous user. However, you can specify the - superuser
parameter in export rules to determine how to handle clients presenting with user ID 0 depending on their security type. The following are valid options for the -superuser
parameter:
-
any
-
none
This is the default setting if you do not specify the
-superuser
parameter. -
krb5
-
ntlm
-
sys
There are two different ways how clients presenting with user ID 0 are handled, depending on the -superuser
parameter configuration:
If the -superuser parameter and the client's security type… |
Then the client… |
---|---|
Match |
Gets superuser access with user ID 0. |
Do not match |
Gets access as the anonymous user with the user ID specified by the |
If a client presents with user ID 0 to access a volume with NTFS security style and the -superuser
parameter is set to none
, ONTAP uses the name mapping for the anonymous user to obtain the proper credentials.
The export policy contains an export rule with the following parameters:
-
-protocol
nfs3
-
-clientmatch
10.1.16.0/255.255.255.0
-
-rorule
any
-
-rwrule
krb5,ntlm
-
-anon
127
Client #1 has the IP address 10.1.16.207, has user ID 746, sends an access request using the NFSv3 protocol, and authenticated with Kerberos v5.
Client #2 has the IP address 10.1.16.211, has user ID 0, sends an access request using the NFSv3 protocol, and authenticated with AUTH_SYS.
The client access protocol and IP address matches for both clients. The read-only parameter allows read-only access to all clients regardless of the security type they authenticated with. However, only client #1 gets read-write access because it used the approved security type Kerberos v5 to authenticate.
Client #2 does not get superuser access. Instead, it gets mapped to anonymous because the -superuser
parameter is not specified. This means it defaults to none
and automatically maps user ID 0 to anonymous. Client #2 also only gets read-only access because its security type did not match the read-write parameter.
The export policy contains an export rule with the following parameters:
-
-protocol
nfs3
-
-clientmatch
10.1.16.0/255.255.255.0
-
-rorule
any
-
-rwrule
krb5,ntlm
-
-superuser
krb5
-
-anon
0
Client #1 has the IP address 10.1.16.207, has user ID 0, sends an access request using the NFSv3 protocol, and authenticated with Kerberos v5.
Client #2 has the IP address 10.1.16.211, has user ID 0, sends an access request using the NFSv3 protocol, and authenticated with AUTH_SYS.
The client access protocol and IP address matches for both clients. The read-only parameter allows read-only access to all clients regardless of the security type they authenticated with. However, only client #1 gets read-write access because it used the approved security type Kerberos v5 to authenticate. Client #2 does not get read-write access.
The export rule allows superuser access for clients with user ID 0. Client #1 gets superuser access because it matches the user ID and security type for the read-only and -superuser
parameters. Client #2 does not get read-write or superuser access because its security type does not match the read-write parameter or the -superuser
parameter. Instead, client #2 is mapped to the anonymous user, which in this case has the user ID 0.