- Introduction
- NFS in Modern SAP Architectures: Key Advantages Over SAN
- NFSv3 Compared to NFSv4: Why NFSv4 Is Better
- Disadvantages of Decentralized User Management
- Windows Active Directory (AD) Configuration
- Add AD Group “sapsys”
- Add SAP System User(s)
- ONTAP Storage System Configuration
- Add an existing SVM into AD
- Create a new SVM and add it into AD
- Create Volume
- Advanced SVM settings
- Configure LDAP settings
- Linux Host Configuration
- Add Server into AD
- Configure SSSD on the Linux Host
- Checking the Configuration for Correctness
- Log into the Linux Server as user “tstadm”
- Mount NFS volume from SVM using NFSv4.1
Introduction
This document describes the use of NFSv4.1 for operating SAP (HANA) systems with centralized user management on a Microsoft Active Directory (AD) server. The centrally managed users are used on both a NetApp storage system and a Linux server – on which the SAP system is running – to ensure granular access and rights distribution.
The document “SAP HANA on NetApp AFF Systems with NFS - Configuration Guide” recommends setting the parameter "-v4-numeric-ids" to “disabled” when using NFSv4.1 as protocol This parameter determines whether the NFSv4 server sends numeric UID/GID values or names (user and group names) to NFS clients. If “-v4-numeric-ids = enabled”, ONTAP sends only numeric IDs (UID/GID) instead of string names to the client. If “-v4-numeric-ids = disabled”, the server attempts to send user and group names. This requires working name resolution (LDAP, NIS, or local users/groups). If no consistent name resolution is available, files stored on a volume may be shown as owned by the user “nobody” (User ID 65534) and the group “nogroup” (Group ID 65534). With this ownership assignment, it is not possible for applications to run properly on this volume.
This document assumes knowledge in the following areas:
- Linux - especially NFSv4.1, user and group configuration
- Windows - Active Directory administration, user and group administration
- NetApp ONTAP - SVM (Storage Virtual Machine) administration and configuration
Compared to NFSv4.1, NFSv3 does not require consistent name resolution because NFSv3 uses only numeric UIDs and GIDs.
NFS in Modern SAP Architectures: Key Advantages Over SAN
In modern SAP landscapes, storage systems are connected via NFS to achieve a high degree of flexibility through automation. NFS offers the following advantages over SAN:
- NFS allows for easy administration over IP networks. No special Fiber Channel infrastructure is required.
- NFS mounts are easy to share between servers and allow shared access, whereas SAN-based LUNs are usually assigned to only one host, and changing the LUN assignment often requires adjustments to the SAN infrastructure.
- The development speed in LAN environments is significantly higher than in SAN environments (LAN current standard 100 Gbit/s (next jump to 200 Gbit/s and 400 Gbit/s), SAN current standard 32 Gbit/s (next jump to 64 Gbit/s))
- When using NFS as the storage protocol, the costs for expensive dedicated SAN components (switches, HBAs, etc.) are eliminated.
- Vendor lock-in is significantly lower with NFS than with FC infrastructure
- Nearly identical latency with appropriately optimized infrastructure
- Data throughput with NFS will be significantly higher than with FC in the future – 400 Gbit Ethernet vs. 64 Gbit FC
NFSv3 Compared to NFSv4: Why NFSv4 Is Better
The first NFSv3 specification, from 1995, relied on the UDP protocol and only allowed server authentication. NFSv4.1, whose specification dates back to 2010, uses the TCP protocol, requires only a single TCP port, and supports user authentication in addition to server authentication. The advantages of NFSv4.1 over NFSv3, especially the higher access security for files and shares, are leading many companies to adopt the NFS v4.1 protocol.
To use the NFSv4.1 user authentication security mechanism, the user(s) who will access files via NFSv4.1 must be known on both the NFS server and the client. One option is to create the users locally on the NFS server and all NFS clients, or to provide them via a central user management system such as a Microsoft Active Directory (AD) server.
Disadvantages of Decentralized User Management
Decentralized user management in the data center means that user accounts, rights, and access are not managed centrally, but rather maintained locally on the respective systems.
This can work in small environments, but it has significant disadvantages in larger IT infrastructures.
- Increased administrative effort
User accounts must be created, modified, and deleted separately on multiple systems.
This leads to duplicated work and increases the time required for administrators. - Security risks
Orphaned accounts often remain active because they are forgotten on some systems.
A lack of oversight makes it difficult to control permissions and ensure compliance. - Lack of Consistency and Transparency
Different systems may contain conflicting or outdated user information.
There is no central point of view to see who has access to what. - Difficulties with Access Management and Role Management
Role and rights concepts are difficult to enforce or verify centrally. - Delays in User Provisioning
Missing users on individual systems hinder system deployments. - Low Scalability
As the number of systems and users grows, the effort increases not linearly, but exponentially. - Poor Auditability and Compliance
Security checks, reviews, and audits are becoming significantly more complex.
Therefore, modern organizations rely on centralized identity and access management systems like Active Directory to manage users, groups, and permissions uniformly and automatically.
Windows Active Directory (AD) Configuration
This chapter describes how to create and configure the necessary users and groups in an existing Windows Active Directory to ensure the use of consistent user and group IDs across the entire system.
To ensure the use of consistent user and group IDs, attributes of Windows AD users and groups must be set. These attributes can only be set if "Advanced Features" are enabled. Enable "Advanced Features" as shown in the screenshot below.
Add AD Group “sapsys”
Now we are creating the group "sapsys" in Active Directory.
Next, we select the group “sapsys”, then right-click on "Properties" and then on "Attribute Editor" within the "Properties".
In the "Attribute Editor", we assign the group ID to the "gidNumber" attribute, which the "sapsys" group should receive on all Linux servers and the ONTAP SVMs. In our example, the group receives the group ID “233”.
Add SAP System User(s)
For illustration purposes, we will create a sample user with the username "tstadm" in our example Windows Domain having the Domain Name “MASTER”.
Enter a password according to your password guidelines.
Press “Finish” to create user “tstadm”
Next, we select the user “tstadm”, then right-click on "Properties”
Select the"Attribute Editor" within the "Properties".
In the "Attribute Editor", we configure the following attributes for the user “tstadm”:
- gidNumber
- uidNumber
- uid
- unixHomeDirectory
- loginShell
First, we assign the same group ID to the user "tstadm" that we assigned to the group "sapsys", since "sapsys" is the primary group of SAP system administration users. Therefore go to the attribute “gidNumber” and assign it the value “233”.
Then we assign a unique user ID to the user "tstadm". In our example the user “tstadm” gets the user ID “1233” to the attribute file “uidNumber”. Make sure that you do not have duplicated user IDs across your landscape.
Next, we configure the "uid" attribute by assigning the user's username to it. In our example, the username is "tstadm".
We need to configure the user's home directory. If the home directory does not exist on the Linux server, it will be created the first time the user logs in (this also includes a “switch user” (su)). The user "tstadm" is assigned the default home directory "/home/tstadm".
Next, we configure the login shell for the user "tstadm". The default shell for SAP system administrators is "csh", so we assign the value "/bin/csh" to the "loginShell" attribute. It must be ensured that the assigned shell is installed on the Linux servers.
Now the configuration of necessary Windows Active Directory users and groups are completed.
ONTAP Storage System Configuration
In our environment we are using a NetApp system running NetApp ONTAP Release 9.16.1P6
To use centralized user management in Microsoft Windows Active Directory, the NetApp SVM must be added to Windows Active Directory. There are two ways to do this:
- Add an existing SVM to Windows Active Directory
- Create a new SVM and specify during creation that this SVM should be added to Windows Active Directory.
Add an existing SVM into AD
If you want to configure an existing SVM, you must add it into your AD.
There are two options for existing SVMs:
- The SVM hasn’t enabled CIFS at all
You can create a CIFS server in your SVM and add the SVM into an AD in one step. Please execute the steps described in the following documentation:
https://docs.netapp.com/us-en/ontap-cli/vserver-cifs-create.html - THE SVM has enabled CIFS as WORKGROUP
To ADD the SVM into your AD, execute the steps described in the following documentation:
https://docs.netapp.com/us-en/ontap/smb-admin/join-svm-active-directory-domain-task.html
Create a new SVM and add it into AD
In this chapter, we explain how to set up a new SVM and integrate it directly into Microsoft Active Directory during setup.
The following picture shows the already existing SVMs.
By clicking the "+ Add" button, we create a new SVM that supports both the CIFS and NFS protocols. The SVM is named "smb-svm". Next, the Microsoft Active Directory settings are configured so that the SVM can be added to Microsoft Active Directory directly upon creation.
The following fields must be completed:
- Administrator Name
A user with the necessary permissions to add a computer to Microsoft Active Directory - Password
The user's password - Server Name
The name under which the SVM will be created in Active Directory. This name must be resolvable in DNS with the SVM's IP address. - Active Directory domain
- Organizational Unit
The folder/group in Microsoft Active Directory in which the SVM will be created - Domains
DNS Search Domain - Name Servers
DNS Server
Next, access is enabled via the NFS protocol. To access the SVM via NFS protocol, we configure an export policy which specifies an IP address or range of IP addresses which are allowed to mount existing volumes from the SVM. Then we set the default language and the IP address for accessing the SVM is configured. We also enabled administrative access to the SVM using the user "vsadmin" using a password we are specifying. Enabling administrative access has nothing to do with the configured Microsoft Active Directory users and groups. Administrative access is i.e. needed when changing settings inside the SVM, adding the SVM to an existing SnapCenter backup environment or doing some other SVM configuration or tasks.
The following picture shows the SVM details
Now we are checking whether the SVM has been added into the Microsoft Active Directory. Let us first check it on SVM level.
Afterwards check the added “Computer” inside Microsoft Active Directory
Microsoft Active Directory also displays the NetApp ONTAP Release details of the release the SVM has been added into Microsoft Active Directory.
Create Volume
After creating the SVM, we need to create a volume that can be mounted on a Linux server using the NFSv4.1 protocol. We also do this in the graphical interface. The volume is named "nfstest" within the SVM "smb.svm" and has a size of 5 GB (which is sufficient for testing purposes).
We configure NFSv4.1 access to the volume with the "default" export policy, which allows all computers on the 192.168.71.0/24 subnet to mount the volume. To also mount the volume on Windows machines, we share it via the CIFS protocol – this can be useful, for example, for exchanging files between Linux and Windows systems. Clicking "Save" creates the volume.
Advanced SVM settings
After the SVM and volume have been created, a few things still need to be configured in the SVM:
- We'll go straight to “diag” mode, since some settings can only be made in this mode.
testcl1::> set diag
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y - Set NFSv4 domain ID
nfs modify -vserver smb-svm -v4-id-domain master.de - Enable NFSv4.1
nfs modify -vserver smb-svm -v4.1 enabled - Disable NFSv4 numeric IDs
nfs modify -vserver smb-svm -v4-numeric-ids disabled - Create “root” User inside the SVM
vserver services unix-user modify -vserver smb-svm -user root -primary -gid 0
Configure LDAP settings
Now we need to configure the LDAP client in the SVM so that users can be resolved for permissions in the context of the NFSv4.1 protocol in Microsoft Active Directory.
- vserver services name-service ldap client create -vserver smb-svm -client-config ad_test -ad-domain MASTER.DE -schema MS-AD-BIS
Next, we specify that users and groups should first be resolved via Microsoft Active Directory and then locally in the SVM.
- vserver services name-service ns-switch modify -vserver smb-svm -database passwd -sources ldap,files
- vserver services name-service ns-switch modify -vserver smb-svm -database group -sources ldap,files
Now we create the client configuration and a corresponding mapping of Unix <-- --> Windows and Windows <-- --> Unix for the users and groups.
- vserver services name-service ldap create -vserver smb-svm -client-config ad_test
- vserver name-mapping create -vserver smb-svm -direction win-unix -position 1 -pattern MASTER\\(.+) -replacement \1
- vserver name-mapping create -vserver smb-svm -direction unix-win -position 2 -pattern (.+) -replacement MASTER\\\1
Finally, we'll check the settings and verify, that the user “tstadm” can be resolved out of the Microsoft Active Directory on our ONTAP system be executing the following commands:
- vserver services name-service ns-switch show -vserver smb-svm
Source
Vserver Database Order
--------------- ------------ ---------
smb-svm hosts files,
dns
smb-svm group files,ldap
smb-svm passwd files,ldap
smb-svm netgroup files
smb-svm namemap files
5 entries were displayed. - getxxbyyy getpwbyname -vserver smb-svm -username tstadm -node testcl1-01
(vserver services name-service getxxbyyy getpwbyname)
pw_name: tstadm
pw_passwd:
pw_uid: 1233
pw_gid: 233
pw_gecos: tstadm
pw_dir: /home/tstadm
pw_shell: /bin/csh
Linux Host Configuration
In our environment, we use SUSE Linux SLES-15 SP6 as the Linux system.
First, we check the DNS settings and whether the LDAP service "MASTER.DE" can be resolved correctly in the DNS.
Next, the following RPM packages (including any required dependencies) must be installed:
- realmd
- sssd
- sssd-ad
- sssd-tools
Add Server into AD
Now, the Linux server is added to the Microsoft Active Directory using the command "realm join master.de -v" (-v = verbose for more detailed output), as shown in the following image.
We check whether adding the server into Microsoft Active Directory was successful, as shown in the following image, by calling "realm list".
Then we check the file /etc/nsswitch.conf to see if users and groups should be resolved via SSSD in Microsoft Active Directory.
This is how the Linux server appears in Microsoft Active Directory
The operating system displayed is “suse-linux-gnu”.
Configure SSSD on the Linux Host
Now we must configure the SSSD daemon on the Linux server.
SSSD stands for System Security Services Daemon and is a utility that connects Linux/Unix systems to central directory services such as Active Directory or OpenLDAP.
Other names for Service Caching Daemons - in SUSE, the default name is nscd service caching daemon - must be stopped and disabled as shown in the following image
Now the file etc/sssd/sssd.conf needs to be adjusted. Domain-specific settings are highlighted in red.
[sssd]
config_file_version = 2
services = nss, pam
domains = master.de
[nss]
[pam]
[domain/master.de]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = MASTER.DE
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = master.de
use_fully_qualified_names = False
ldap_id_mapping = False
ldap_schema = ad
access_provider = ad
enumerate = True
Important:
- use_fully_qualified_names = False
- ldap_id_mapping = False
- cache_credentials = True
- enumerate = True
Finally, the SSSD is started and configured to start automatically at every system startup.
Checking the Configuration for Correctness
In this chapter, we will finally show the result of the setup we have done before
Log into the Linux Server as user “tstadm”
The following image shows the login of the user "tstadm" to the server "saptest5" and how the home directory is created during the initial login. We verify the user and group IDs configured in Microsoft Active Directory by calling the command "id".
Mount NFS volume from SVM using NFSv4.1
Now we'll display the available NFS volumes of the SVM "smb-svm" using the command "showmount -e". We also see the volume "nfstest" that we created. Instead of the SVM's IP address, its name "SMB-TESTSERVER" can of course also be used.
Next, we mount the volume "nfstest" via NFSv4.1 into the directory /mnt using the command "mount -o vers=4.1 192.168.71.35/nfstest /mnt"
We check if the existing files belong to the user "tstadm" and the group "sapsys". Then, as the user "root", we create another file named "abc", change the ownership to "tstadm:sapsys" using the numerical UID and GID, and finally check the result.
Everything is working as expected. Central user management for the Linux server and the SVM is set up, and the volume is prepared for a potential SAP installation.