D-PSC-DY-23 Configuring Identity Management and Authorization

Configuring Identity Management and Authorization Detailed Explanation

Identity Management

Identity management is about defining who can access the system and how they are identified. It ensures that users are correctly recognized across different systems (e.g., Linux, Windows) and that their credentials and identities are consistently mapped.

1. User and Group Management

• Sources:

  • User and group information can come from:
    1. Local: Accounts created directly on the storage system.
    2. LDAP: A centralized directory service used to manage users and groups in one place.
    3. Active Directory (AD): A Windows-based directory service for managing users and devices within a domain.

• Mapping Rules:

  • Mapping rules ensure that users and groups are recognized consistently across different systems.
    • For example, a user in a Linux system with a UNIX UID (User Identifier) can be mapped to their corresponding Windows SID (Security Identifier) for seamless access.

• Practical Example:

  • A user named "John" in the LDAP directory has a UID of 1001. The system maps this UID to his Windows SID so that John can access files, regardless of whether he logs in from a Linux or Windows machine.

2. ID Mapping

• Mechanism:

  • ID mapping links UNIX and Windows user identifiers, ensuring consistent permissions and access rights across both platforms.
  • For example:
    • A UNIX user with UID 1002 can be mapped to a Windows SID S-1-5-21-1002.
    • This mapping ensures that the same user has the correct permissions, regardless of the operating system they use.

• Configuration File:

  • The isi auth mapping configuration file is used to define and manage these mappings.
    • This file specifies rules for matching UNIX UIDs/GIDs (Group Identifiers) to Windows SIDs.
    • It also resolves conflicts where multiple users or groups might overlap.

• Practical Command:

  • To view the current mapping rules:

    isi auth mapping list
    

3. Authentication Protocols

• Definition:

  • Authentication protocols verify a user’s identity before granting access to the system.

• Supported Methods:

  • Password-Based Authentication:
    • Users provide a password to log in.
    • Example: A user enters their password when connecting to an SMB share from a Windows client.
  • Key-Based Authentication:
    • Uses cryptographic keys (e.g., SSH keys) instead of passwords, often for automated systems or secure logins from Linux clients.

• Example:

  • For Linux systems, an SSH key-based login might look like this:

    ssh -i ~/.ssh/id_rsa user@storage-cluster
    

Authorization Models

Authorization determines what a user or group is allowed to do once authenticated. It ensures proper access control to files and directories.

1. POSIX Permissions

• What is POSIX?

  • POSIX is a set of standards for UNIX-like systems. It uses three basic permissions for files and directories:
    1. Read (r): Permission to view the file's content.
    2. Write (w): Permission to modify the file.
    3. Execute (x): Permission to execute the file (for programs) or access the directory.

• Permission Structure:

  • Each file or directory has permissions for three entities:
    1. Owner: The user who owns the file.
    2. Group: A group of users who share access.
    3. Others: All other users.

• Practical Commands:

  1. Change ownership:

     chown john:developers file.txt
     

     This assigns the file file.txt to the user "John" and the group "developers".

  2. Modify permissions:

     chmod 755 file.txt
     

     This sets the file to be readable and executable by everyone, but writable only by the owner.

• Example:

  • A directory might have permissions drwxr-xr--:
    • d: Indicates a directory.
    • rwx: Owner (read, write, execute).
    • r-x: Group (read, execute).
    • r--: Others (read only).

2. ACL (Access Control List)

• What is ACL?

  • ACLs allow more detailed and flexible permission assignments compared to POSIX.
  • With ACLs, you can define permissions for specific users or groups, not just the owner, group, or others.

• Function:

  • ACLs enable complex scenarios where multiple users and groups need different access levels for the same file or directory.

• Key Commands:

  • View an ACL:

    getfacl file.txt
    

  • Set an ACL for a specific user:

    setfacl -m u:john:rw file.txt
    

    This gives "John" read and write permissions for file.txt.

• Practical Example:

  • Imagine a shared directory where:
    • The owner has full access.
    • A specific team (e.g., "Marketing") has read and write access.
    • All others have only read access.
  • With ACLs, you can configure these rules for each user and group, ensuring precise control.

Comparison: POSIX vs. ACL

Feature	POSIX	ACL
Complexity	Simple	Advanced
Permission Scope	Owner, Group, Others	Individual users/groups
Use Case	Basic environments	Complex access control

Conclusion

To configure identity management and authorization effectively:

• Use identity sources like LDAP or AD to centralize user and group management.
• Map user identifiers (UIDs and SIDs) to ensure consistent access rights across platforms.
• Choose POSIX permissions for simpler setups or ACLs for more complex access control needs.

This ensures that users can access the right resources securely and efficiently while maintaining proper control over the system.

Configuring Identity Management and Authorization (Additional Content)

1. ID Mapping – Handling Default IDs and Mapping Policies

Default ID Handling

• In a multi-protocol environment (Windows + Linux), identity mapping is crucial because Windows uses SIDs (Security Identifiers) while Linux/UNIX uses UIDs/GIDs.
• If OneFS cannot find a corresponding ID, it will handle the mapping in one of the following ways:
  1. Deny access (default behavior) – The system blocks users without a valid identity.
  2. Map to a default user (e.g., nobody with UID 99) – This allows unknown users to access the system with limited permissions.

Mapping Policies in PowerScale

Mapping Type	Description	Use Case
Auto-Generated Mapping	OneFS automatically maps Windows and UNIX identities.	Environments with minimal manual intervention.
Static Mapping	Admins manually define UID-to-SID mappings for full control.	Ensures consistency in mixed environments.
Rule-Based Mapping	PowerScale applies predefined rules to map users.	Large organizations with structured access controls.

Manually Configuring ID Mapping

To create a static ID mapping:

isi auth mapping create --unix-id=1002 --sid=S-1-5-21-1002

This command ensures UID 1002 in UNIX maps directly to SID S-1-5-21-1002 in Windows, preventing inconsistencies.

Best Practices

• Use static mapping for critical users (e.g., administrators).

• Regularly review and update mappings to avoid orphaned permissions.

• Enable mapping debug logs to troubleshoot issues:

  isi auth mapping list --verbose
  

2. Authentication Protocols – Enhancing Kerberos Integration

While PowerScale supports password-based authentication and SSH key authentication, many enterprises rely on Kerberos authentication for seamless Single Sign-On (SSO).

Key Benefits of Kerberos Authentication

• SSO Support: Users authenticate once and gain access to all Kerberos-protected resources.
• Stronger Security: Uses ticket-based authentication instead of passwords.
• Integration with Active Directory (AD): Works seamlessly with Windows environments.

Configuring Kerberos Authentication in PowerScale

1. Enable Kerberos in PowerScale

isi auth ads modify --kerberos-enable=yes

2. Verify Keytab File Configuration

• PowerScale must have a valid Kerberos keytab file to authenticate users.

klist -k /etc/krb5.keytab

3. Ensure NTP Synchronization

• Kerberos requires the system time to be within 5 minutes of the AD domain controller.

isi ntp status

Best Practices

• Use multiple domain controllers for Kerberos failover.

• Store keytab files securely and rotate them periodically.

• Verify Kerberos authentication logs for troubleshooting:

  isi auth ads view --verbose
  

3. POSIX Permissions – Special Permissions for Shared Environments

PowerScale supports standard POSIX permissions but also includes special permissions like SetUID, SetGID, and Sticky Bit that are useful in shared environments.

Special POSIX Permissions

Permission	Symbol	Function	Use Case
SetUID	s	Runs files with the owner’s privileges.	Allows non-root users to execute admin-level commands.
SetGID	s	Files inherit group ownership when created.	Ensures files in a shared directory belong to the same group.
Sticky Bit	t	Only file owners can delete files, even if others have write access.	Protects files in shared directories (e.g., /tmp).

Example Use Cases

1. Ensure all new files in /shared inherit the group ownership

chmod g+s /shared

2. Allow non-root users to execute system binaries with root privileges

chmod u+s /usr/bin/custom_script

3. Prevent accidental file deletion in shared folders

chmod +t /project_data

4. ACLs – Compatibility Between SMB and NFS

PowerScale supports both Windows ACLs (NTFS permissions) and NFSv4 ACLs, but since Windows ACLs use SIDs while NFS ACLs use UID/GIDs, compatibility issues can arise.

Differences Between SMB and NFS ACLs

Feature	SMB (NTFS ACLs)	NFS (POSIX ACLs)
Access Control	Based on Security Identifiers (SIDs)	Based on UID/GID
Permissions Granularity	Supports fine-grained permissions (e.g., read/execute/write by individual user)	Uses standard UNIX rwx permissions
Supported in PowerScale	Yes, for Windows clients	Yes, for Linux/UNIX clients

Enabling NFSv4 ACL Support

isi nfs modify --nfs4-acl-enable=yes

• This command enables ACL support for NFSv4, ensuring better compatibility with SMB ACLs.

Best Practices

• For mixed environments, use NFSv4 ACLs instead of POSIX ACLs to retain compatibility with Windows ACLs.
• Use getfacl and setfacl to manage NFSv4 ACLs manually.
• Ensure ACL consistency across protocols to prevent access control issues.

5. Role-Based Access Control (RBAC) in PowerScale

PowerScale supports RBAC, allowing administrators to assign specific roles to users, restricting access to sensitive configurations.

Built-in RBAC Roles in OneFS

Role	Permissions	Use Case
System Admin	Full administrative access.	Storage admins managing entire clusters.
Audit Admin	Can view logs but cannot modify settings.	Security teams reviewing access logs.
Backup Operator	Can manage backup/restore tasks but not other system settings.	Backup administrators.

Creating a Custom RBAC Role

isi auth roles create --name=BackupOperator --permissions=Backup

• This creates a Backup Operator role with backup-related permissions only.

Assigning the Role to a User

isi auth roles assign --role=BackupOperator --user=johndoe

• This assigns the Backup Operator role to user "johndoe".

Best Practices

• Use RBAC for delegation: Assign only the necessary permissions to each team.
• Regularly audit user roles: Ensure users have only the required privileges.
• Restrict access to security-sensitive commands.

Conclusion

1. ID Mapping Strategies: PowerScale supports default ID handling (nobody user) and manual ID mapping (isi auth mapping create).
2. Kerberos Authentication: Use isi auth ads modify --kerberos-enable=yes for SSO integration and ensure NTP synchronization.
3. Advanced POSIX Permissions: Use SetUID, SetGID, and Sticky Bit to enhance security in shared environments.
4. SMB & NFS ACL Compatibility: Enable NFSv4 ACLs (isi nfs modify --nfs4-acl-enable=yes) for better Windows ACL integration.
5. RBAC for Security: Use isi auth roles create to define custom roles, restricting administrative access based on job function.

By incorporating these enhancements, PowerScale provides a robust and secure identity and authorization framework, ensuring multi-protocol access control, enterprise authentication, and fine-grained permission management.