Local LDAP Linux User Accounts

You can create regular Linux user accounts using the StarlingX LDAP service.

Local LDAP accounts are centrally managed on the active controller; all hosts in the cloud/cluster use the Local LDAP server on the active controller for SSH and Console authentication.

The intended use of these accounts is to provide additional admin level user accounts (in addition to sysadmin) that can SSH to the nodes of the StarlingX.


For security reasons, it is recommended that ONLY admin level users be allowed to SSH to the nodes of the StarlingX. Non-admin level users should strictly use remote CLIs or remote web GUIs.

Apart from being centrally managed, Local LDAP user accounts behave as any local user account. They can be added to the sudoers list, and can acquire Keystone administration credentials, Kubernetes kubectl, and helm administrative commands as the Kubernetes admin user, when executing on the active controller.

Local LDAP user accounts share the following set of attributes:

  • The initial password is the name of the account.

  • The initial password must be changed immediately upon first login.

  • For complete details on password rules, see System Account Password Rules.

  • Login sessions are logged out automatically after about 15 minutes of inactivity.

  • After each unsuccessful login attempt, a 15 second delay is imposed before making another attempt. If you attempt to login before 15 seconds the system will display a message such as:

    Account temporary locked (10 seconds left)


    On Debian-based StarlingX systems, this delay is 3 seconds.

    • After five consecutive unsuccessful login attempts, further attempts are blocked for about five minutes. On further attempts within 5 minutes, the system will display a message such as:

      Account locked due to 6 failed logins


      On Debian-based StarlingX systems, you are alerted on the 6th and subsequent attempts:

      Account locked due to 6 failed logins

      and an error message is displayed on subsequent attempts:

      Maximum number of tries exceeded (5)

      To clarify, on CentOS-based StarlingX systems, the 5 minute block is not an absolute window, but a sliding one. That is, if you keep attempting to log in within those 5 minutes, the window keeps sliding and the you remain blocked. Therefore, you should not attempt any further login attempts for 5 minutes after 5 unsuccessful login attempts.

      On Debian-based StarlingX systems, 5 mins after the account is locked, the failed attempts will be reset and failed attempts re-counted.

  • All authentication attempts are recorded on the file /var/log/auth.log of the target host.

  • Home directories and passwords are backed up and restored by the system backup utilities. Note that only passwords are synced across hosts (both LDAP users and sysadmin). Home directories are not automatically synced and are local to that host.

Default LDAP User Accounts

The following Local LDAP user accounts are available by default on newly deployed hosts, regardless of their personality:


A cloud administrative account, comparable to the default admin account used in the web management interface.

This user account has access to all native Linux commands not requiring root or sudo privileges, and it’s shell is preconfigured to have administrative access to StarlingX commands.


A host administrative account. It has access to all native Linux commands and is included in the sudoers list.

For increased security, the admin and operator accounts must be used from the console ports of the hosts; no SSH access is allowed.

  • These accounts serve as system access redundancies in the event that SSH access is unavailable. In the event of any issues with connectivity, user lockout, or sysadmin passwords being forgotten or not getting propagated properly, the presence of these accounts can be essential in gaining access to the deployment and rectifying things. This is why these accounts are restricted to the console port only, as a form of “manual over-ride.” The operator account enables access to the cloud deployment only, without giving unabated sudo access to the entire system.