Skip to main content
Version: FCP 25.11

Built-in User Authentication System

The built-in authentication system uses built-in LDAP and is the default in standard deployments. To change the authentication system, see User Authentication Configuration.

User Management​

  • User types
    The platform has three user types: deploy environment configuration admin, admin super admin, and other users.

    • deploy users are environment configuration admins. They can configure all platform parameters. See Environment Configuration Overview.
    • admin users are super admins. They have all platform permissions and cannot be deleted.
    • Other users are synced periodically and permissions are assigned by admin. Synced users are added to the defaultGroup group by default. defaultGroup functions the same as in built-in LDAP and is used as the default permission control group for regular users.

  • Field descriptions

    • Name: User display name.
    • Username: Username used to log in to the platform. Cannot be changed.
    • Mobile: Contact phone number.
    • Login Shell: Choose /bin/sh, /bin/bash, etc. based on your application requirements. Optional if there are no special requirements.
    • Home Directory: Custom home directory. Default: /fastone/users/<username>. Optional if there are no special requirements.
    • Status: Account status.
    • Email: User email. Required.
    • Initial Password: Initial password. Required.
    • Confirm Password: Confirm password. Required.
    • Role:
      • Administrator: Has administrative permissions, such as platform configuration and permission settings. This role has sudo permissions on clusters.
      • Regular User: Uses the platform based on permissions assigned by administrators. This role does not have cluster sudo permissions.
    • User Group: Select the user group.
    • Primary Group: Select the primary group.
    • UID: You can specify a user UID when creating a user (optional). If not specified, the system assigns one automatically. UIDs/GIDs for admin and fastone are reserved. UID/GID must be numeric. To avoid conflicts with host OS users, we recommend using values >= 2000. UID cannot be edited.

      Note: When a user is created, a same-name user group and a same-name primary group are created automatically, and the user is added to them.

  • Actions

    • Edit: Users with the Edit User Management permission can edit Name, Mobile, Status, Email, Role, User Group, and Primary Group. They cannot edit Username, Login Shell, Home Directory, or Specified UID. Regular users can edit their own Name, Email, and password. Deleted users cannot be edited.
    • Delete: Deleting users is supported.

User Groups​

  • Field descriptions

    • ID: Unique identifier of the group.
    • Group Name: User group name. The group maps one-to-one to a Linux user group.
    • Role: Assign roles. Permissions of the selected roles are granted to the group.
    • Description: Group description.
    • Users: Number of users in the group.
    • WeCom: Number of WeCom accounts bound to the group.
    • Feishu: Number of Feishu accounts bound to the group.
    • DingTalk: Number of DingTalk accounts bound to the group.
    • Created At: Group creation time.
    • GID: You can specify a group GID when creating a group (optional). If not specified, the system assigns one automatically. UIDs/GIDs for admin and fastone are reserved. UID/GID must be numeric. To avoid conflicts with host OS users, we recommend using values >= 2000.

  • Actions

    • Edit: You can edit Description, add users, add WeCom, and add Feishu.
    • Delete: Deleting groups is supported.

  • Validation rules when creating a group

    • The platform checks global uniqueness of the group and auto-generates a group ID.
    • A group record is added to the group list.
    • The group is also mapped to a Linux user group on cluster nodes. Membership relationships are mapped to cluster nodes as well.
    • Notification methods include the email addresses of all added members, and any bound WeCom/Feishu/DingTalk accounts.
      The group is not only a system user group but also an alert notification group. For example, if you create group group1 with members test1 and test2 (emails test1@123.com and test2@123.com), you can verify on a cluster node that both users belong to group1. If an alert policy targets this group, alert notifications are sent to the configured email addresses and messaging accounts.

Alert Notifications​

  • Notification methods

    • Email: Shows the email addresses of all users in the group.
    • WeCom: Shows WeCom accounts bound to the group and supports adding/removing.
    • Feishu: Shows Feishu accounts bound to the group and supports adding/removing.
    • DingTalk: Shows DingTalk accounts bound to the group and supports adding/removing.

  • Bound alert policies

Shows alert policies bound to the group. When an alert is triggered, notifications are sent to the configured email, WeCom, Feishu, and DingTalk destinations.

Role Management​

Role management assigns roles and permissions to users and groups to enable controlled access to system resources.

  • Field descriptions

    • Name: Role name.
    • Permissions: Permissions granted by the role. For details, see Permissions.
    • Description: Role description shown when assigning the role to users or groups.

  • Actions:

    • Edit: All fields above can be edited.
    • Delete: Deleting a role also removes the permissions associated with that role from all related users and groups.