Authentication for file access

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

The following steps are involved in the user authentication for file access:

User tries to connect to the IBM Spectrum Scale™ system by using their credentials.
The IBM Spectrum Scale system contacts the authentication server to validate the user.
The IBM Spectrum 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.
If the user credentials are valid, the user gains access to the system.

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 Spectrum 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 Spectrum 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 system such as the IBM Spectrum 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. 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 100 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 100 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 Spectrum 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 Spectrum Scale system.

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

Internal ID mapping

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

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

IBM Spectrum Scale supports Automatic ID mapping method if AD-based authentication is used. Automatic ID mapping method uses a reserved ID range to allocate 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 Spectrum Scale, a range is allocated per AD domain. 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 and if an NFS client wants to access data, then the NFS client must have UID or GID that is identical to the one created by the IBM Spectrum Scale system.

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 Spectrum 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, the Kerberos is enabled for the SMB access by default and Kerberos for NFS access is not supported.
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

All the UID and GID, whether generated automatically or in RFC2307 or NIS, are cached. For every positive user login, UID and GID are stored for seven days. For negative user login attempts, where login attempts to the cluster fails, the UID and GID are cached for 2 minutes.

When using external ID mapping server, it is recommended not to change the already created UID or GIDs. If you are required to change the UID or SID, you must plan this activity well, preferably before data exists on IBM Spectrum Scale. After the change, ensure that the cached entries are flushed out.

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

In the LDAP-based user authentication, the mmuserauth service create command creates LDAP bind user and bind password in its configuration file (/etc/pam_ldap.conf). Using this bind user and password, the 'username' is looked up in the LDAP server with the configured 'login_attribute', which is 'uid' by default. So, 'uid=<username>' is looked up in the 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 the bind operation is failed.

Note: As LDAP is used for UNIX style logins, the user name characters are also matched for the user input versus what is returned from the LDAP server.

For SMB authentication, the privilege of performing the LDAP bind with 'username' and 'password' is not available as the passwords in clear text. The SMB client passes the NT hash for the password. The Samba server matches the NT hash from the client versus the hash fetched from LDAP server. For this, the mmuserauth service create command configures samba registry with the LDAP bind user and password. This user name and password are used to look up the samba-related information from the LDAP server, such as SID, NT hash. If the user name and the hashes are matched, the system grants permission to access the system.

User credentials, group ID mapping, and group membership caching:The user credentials are not cached in the IBM Spectrum Scale system. The user and group ID mapping and group membership cache information are stored in the SSSD component of IBM Spectrum Scale. This cache is for 90 minutes and local to a node and there is no IBM Spectrum Scale native command to purge this cache. However, the sss_cache command (from sssd-common package) might be used to refresh the cache. The sss_cache utility marks only the entries in the respective database as expired. If the LDAP server is online and available, the expired entries are refreshed immediately. If the LDAP server is not available, the old cached entries that are still marked expired become valid. These values are refreshed once the server is available.

SMB data caching:There is a 7 day cache period for the user/group SID with the Samba component of the IBM Spectrum Scale system. This cache is local to a node and there is no IBM Spectrum Scale native command to purge this cache. However, 'net cache flush' command can be used, per node basis, to purge this. The negative cache entry is for 2 minutes.

Netgroup caching:The netgroup information from the 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

In IBM Spectrum Scale, the NIS server is used only for user and group name, UID/GID, and group membership lookups for NFS access. Also, the netgroups that are defined in NIS are honored for NFS client information in the NFS export configuration. User and group UID and GID information, names, and group membership are cached with the SSSD component of the IBM Spectrum Scale system. This cache is for 90 minutes and local to a node and there is no IBM Spectrum Scale native command to purge this cache.

However, sss_cache command from the sssd-common package might 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 with 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 of the IBM Spectrum Scale system used the SMB protocol NTLM and Kerberos authentication for user authentication. User and group SID to UID and GID mapping information are cached with the SAMBA component of IBM Spectrum Scale. This cache is maintained for seven days and local to a node and there is no IBM Spectrum Scale native command to purge this cache. However, 'net cache flush' can be used to refresh the cache. The negative cache entry is for 2 minutes.

Group membership cache on IBM Spectrum Scale lies with the Samba component and it is local to each protocol node. For an authenticated user, its group membership cache is valid for the lifetime of that session. The group membership is refreshed on a new authentication request only. 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 AD, all the existing session for that use must be disconnected so that there is a new authentication request and cache refresh for the user. If there is no new authentication request that is made by the user, just a simple user and group information look is requested. For example, issue 'id' command on the protocol node, the winbind component of IBM Spectrum Scale searches the database to check whether that user's cached information is there, from any previous authentication request or not. If such an entry is found, that is returned. Otherwise, the winbind fetches the mapping information from AD and caches it for 5 minutes.

Note: If a user was authenticated in the past, its group membership cache information is with the database and valid for a lifetime. Winbind keeps referring this information and will never try to fetch the new information from the AD. To force winbind to return new information, you need to make an authentication request to the node in the same way as connecting from CIFS client.