Authentication and ID mapping for file access

The system supports an external authentication service to authenticate users on the system. Before you configure an authentication method, ensure that the external authentication service is set up correctly.

The following steps are involved in user authentication for file access:
  1. User tries to connect to the IBM Storage Scale system by using their credentials.
  2. The IBM Storage Scale system contacts the authentication server to validate the user.
  3. The IBM Storage Scale system contacts the ID map server that provides UIDs and GIDs of the user and user group to verify the identity of the user.
  4. If the user credentials are valid, the user gains access to the system.
The following diagram shows the high-level flow of authentication for File-based protocols.
Figure 1. High-level flow of authentication for File protocols

ID mapping

The authentication of the user or groups of users is also associated with the identification of their unique identifiers. To support data access to Microsoft Windows clients (SMB protocol) and to allow interoperability, that is, to share data among UNIX and Windows clients (SMB and NFS protocols), the IBM Storage Scale system must map Windows SID to UNIX UID/GID. This process is referred to as ID mapping and the map is referred to as ID map. The ID mapping can be done either internally in the IBM Storage Scale system or in an external authentication server.

ID mapping is part of the user identification process in user authentication. The purpose of identification is to identify users and infrastructure components. Identification methods include unique user identifiers (IDs), keys, or fingerprints such as a public Secure Shell (SSH) key, and digital certificates such as a certificate of a web server.

UNIX based systems such as the IBM Storage Scale system use user names and user identifiers (UIDs) to represent users of the system. The user name is typically a human-readable sequence of alphanumeric characters and the UID is a positive integer value. When a user logs on to a UNIX system, the operating system looks up the UID and then uses this UID for further representation of the user. User names, UIDs, and the mapping of user names to UIDs are stored locally in the /etc/passwd file or on an external directory service such as Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Keystone, or Network Information Service (NIS).

UNIX systems implement groups to maintain sets of users that have the same group permissions to access certain system resources. Similar to user names and UIDs, a UNIX system also maintains group names and group identifiers (GID). A UNIX user can be a member of one or more groups, where one group is the primary or default group. Group names, GIDs, the mapping of group names to GIDs, and the memberships of users to groups are stored locally in the /etc/group file or on an external directory service such as Active Directory, LDAP, Keystone, or NIS. The primary group of a user is stored in /etc/passwd or in an external directory service.

Windows systems reference all operating system entities as resources. For example, users, groups, computers, and so on are Windows resources. Each resource is represented by a security identifier (SID). Resource names and SIDs are stored locally in the Windows registry or in an external directory service such as Active Directory or LDAP. The following methods are used to map Windows SID to UNIX UID and GID:
  • External ID mapping methods
    • RFC2307 when AD-based authentication is used
    • LDAP when LDAP-based authentication is used
  • Internal ID mapping method
    • Automatic ID mapping when AD-based authentication is used

External ID mapping

A UID or GID of a user or group is created and stored in an external server such as Microsoft Active Directory, NIS server, or LDAP server.

External ID mapping is useful when user UID or group GID is preexisting in the environment. For example, if NFS client with UID and GID as 1000 exists in the environment, and you want a certain share to be accessed by both SMB and NFS client, then you can use an external ID mapping server, assign UID/GID 1000 to the SMB user, and thus, allow both SMB and NFS client to access same data.
Note: The external server administrator is responsible for creating or populating the UID/GID for the user/group in their respective servers.
The IBM Storage Scale system supports the following servers for external ID mapping:
  • LDAP server, where the UID or GID is stored in a dedicated field in the user or group object on the LDAP server.
  • AD server with RFC2307 schema extension defined. The UID or GID of a user or group that is defined in AD server is stored in a dedicated field of the user or group object.

The UID/GID defined in external server can be used by the IBM Storage Scale system.

LDAP ID mapping is supported only when the IBM Storage Scale is configured with LDAP authentication.

With the external ID mapping methods, a user is always mapped to a uid and a group is always mapped to a gid. This matches the user and group management in POSIX systems. It carries the limitation that a file or a directory can never be owned by a group. In Microsoft Windows and SMB semantics, it is possible for objects to be owned by a group. However, in IBM Storage Scale and an external ID mapping method, that cannot be supported.

Internal ID mapping

The UID or GID of a user or group is created automatically by the IBM Storage Scale system and stored in the internal repositories.

When an external ID mapping server is not present in the environment or cannot be used, the IBM Storage Scale system uses its internal ID mapping method to create the UID/GID.

IBM Storage Scale supports an Automatic ID mapping method if AD-based authentication is used. The Automatic ID mapping method uses a reserved ID range to allocate an ID based on the following logic: A user or group in AD is identified by SID, which includes a component that is called RID. Whenever a user or group from an AD domain accesses IBM Storage Scale, a range is allocated per AD domain. The UID or GID is then allocated depending upon this range and the RID of the user/group.

Internal ID mapping cannot be used when the user UID or group GID is preexisting in the environment. However, while using internal ID mapping, if an NFS client wants to access data, then the NFS client must have a UID or GID that is identical to the one created by the IBM Storage Scale system.

With the internal ID mapping method, both a uid and a gid are assigned to the same object at the same time. Querying both even reports user and group information for the same object. That allows to follow SMB semantics more closely, as users and groups are treated very similar in many aspects. This also enables to have an object owned by a group.

Other supported authentication elements for file access

The system supports the following authentication elements as well:
  • Netgroups: Groups of hosts are used to restrict access for mounting NFS exports on a set of hosts, and deny mounting on the remainder of the hosts. The IBM Storage Scale system supports only the netgroups that are stored in NIS and in Lightweight Directory Access Protocol (LDAP).
  • Kerberos: Kerberos is a network authentication protocol that provides secured communication by ensuring passwords are not sent over the network to the system. The system supports Kerberos with both AD and LDAP-based authentication. When you configure AD-based authentication for any ID mapping method (automatic, RFC2307, LDAP), the Kerberos is enabled for the SMB access by default. However, Kerberos for NFS access is supported only for RFC2307 ID mapping method in AD-based authentication, and to enable NFS Kerberos access for AD-based authentication with RFC2307 ID mapping; you need to use the --enable-nfs-kerberos and --unixmap-domains options in the mmuserauth command.

    Kerberos is optional for both SMB and NFS access in LDAP. To enable Kerberos with LDAP, you need to integrate the system with MIT KDC.

  • Transport Level Security (TLS): The TLS protocol is primarily used to increase the security and integrity of data that is sent over the network. These protocols are based on public key cryptography and use digital certificates based on X.509 for identification.

Caching user and user group information

Every UID and GID, whether generated automatically or through RFC2307 or NIS, is cached during a login attempt. For each successful user login attempt, the UID and GID are stored for seven days. For each failed user login attempt, the UID and GID are cached for two minutes.

When using an external ID mapping server, it is recommended that you not to change any previously created UID or GID. If you must change the UID or GID, plan this activity carefully, preferably before any data associated with the UID or GID exists on the IBM Storage Scale cluster. After the change, ensure that the cached entries are flushed out.

Caching user and user group information while using LDAP-based authentication

In LDAP-based user authentication, the mmuserauth service create command populates the LDAP bind user and bind password in its configuration file that is located at: /etc/pam_ldap.conf. Using this bind user and password, the username is looked up in the LDAP server with the configured login_attribute. This is the uid by default. As a result, uid=<username> is looked up in LDAP to fetch the DN for this user. If found, the DN and the password are used to perform an LDAP bind operation. The authentication fails if either the username is not found or if the bind operation fails.
Note: If LDAP is used for UNIX style login attempts, the username is also compared with what is returned from the LDAP server.

For SMB authentication, the ability to perform the LDAP bind with 'username' and 'password' are not available, since the password is in clear text. Therefore, the SMB client passes an NT hash for the password. The Samba server compares the NT hash from the client to the associated NT hash fetched from LDAP server. For this, the mmuserauth service create command configures the Samba registry with the LDAP bind user and password. The LDAP bind user and password are used to look up the Samba-related information from the LDAP server, such as the SID and the NT hash. If the NT hashes match for the bind user, then system access is granted.

User credentials, group ID mapping, and group membership caching: User credentials are not cached in the IBM Storage Scale system. The user and group ID mapping, and the group membership cache information, are stored in the SSSD component. The cache, local to each node, is for 90 minutes. There is no IBM Storage Scale native command to purge this cache. However, the sss_cache command (from the sssd-common package) can be used to refresh the cache.

SMB data caching: There is a seven-day-cache period for the user/group SID within the Samba component of the IBM Storage Scale system. This cache is local to each node. There is no IBM Storage Scale native command to manage this cache. However, the 'net cache flush' command may be used, on a per node basis, to purge the cache. A negative cache entry persists for 2 minutes.

Netgroup caching: The netgroup information from LDAP is also cached for 90 minutes with the SSSD component. The sss_cache command can be used to refresh the cache.

Caching user credentials while using NIS-based authentication for file access

Note: NIS authentication is not supported for RHEL 9.

In IBM Storage Scale, an NIS server may be used only for users and groups, UID/GID, and group membership lookups for NFS access. In addition, the netgroups defined in NIS are honored as NFS client attributes within the NFS export configuration. Users and groups, UID and GID information, names, and group membership are cached within the SSSD component. This cache, local to each node, is for 90 minutes. There is no IBM Storage Scale native command to purge this cache.

The sss_cache command from the sssd-common package may be used to refresh the cache. The sss_cache utility only marks the entries in the respective database as expired. If the NIS server is online and available, the expired entries are refreshed immediately. If the NIS server is not available, the old, cached entries that are still marked expired become valid. These values are refreshed once the server is available.

The netgroup information from the NIS is also cached for 90 minutes within the SSSD component. The sss_cache command can be used to refresh the cache.

Caching user and group ID mapping and group membership details while using AD-based authentication

The Samba component in the IBM Storage Scale system uses the SMB protocol NTLM and Kerberos authentication for user authentication. User and group SID to UID and GID mapping information is cached within the Samba component. This cache, local to each node, is maintained for seven days. There is no IBM Storage Scale native command to manage this cache. However, the net cache flush command may be used to refresh the cache. The negative cache entry persists for 2 minutes.

The group membership cache, local to each IBM Storage Scale protocol node, lies within the Samba component. For an authenticated user, its group membership cache is valid for the lifetime of that session. The group membership is only refreshed on a new authentication request. Therefore, if an SMB tree connect is requested on an existing session, the group cache is not refreshed. So, if there are group membership changes made on the AD server, all of the existing sessions for that user must be disconnected in order to obtain a new authentication request and subsequent cache refresh for the user.

If there is no new authentication request made on behalf of the user, a simple user and group information look-up is requested. For example, if you issue the id command on the protocol node, the winbind component in IBM Storage Scale searches the database to check whether that user's cached information exists from a previous authentication request. If an appropriate entry is found, it is returned. Otherwise, the winbind fetches the mapping information from the AD server and caches it for five minutes.
Note: If a user was authenticated in the past, its group membership cache information is within the database and valid for the session lifetime. Winbind keeps referring to this information and will never try to fetch new information from the AD server. To force winbind to fetch new information, you need to make an authentication request, on behalf of the user, to the node in the same way as you would connect from a CIFS client.