Local accounts

The built-in admin, and the users and groups stored in the AnsibleForms database

  1. The built-in admin
  2. Users and groups
  3. Allowing sign-in
  4. Mapping to roles
  5. Local accounts and LDAP

The built-in admin

Each start creates the local admins group and admin user if missing; three variables control the admin:

Variable Default Meaning
ADMIN_USERNAME admin Username of the admin, created in the admins group when no user has that name.
ADMIN_PASSWORD AnsibleForms!123 Password given to the admin when it is created (or reset).
REINIT_ADMIN 0 1 resets the admin’s password to ADMIN_PASSWORD and puts it back in admins.

ADMIN_PASSWORD is only used when the user is created or reset: changing it later does nothing on its own.

A local user who signs in with the public default password AnsibleForms!123 can only change it. The browser opens a change-password page that cannot be closed, and the server answers every other request with 403 (code password_change_required) until the password is changed. The new password must differ from the default; after the change, the user signs in again with it. Set ADMIN_PASSWORD to your own value before the first start to skip this step.

Changing ADMIN_USERNAME after the first start creates a second admin user with that name; the old one is kept.

REINIT_ADMIN=1 resets the password at every start while it is set. Use it to recover a lost admin password, then remove it and restart.

Users and groups

Local users and groups are managed under Access > Users and Access > Groups. A user has these fields:

Field Meaning
Username The login name. Must be unique.
Description Optional.
Password Stored as a hash. Change it later with the Change Password action.
Email Optional.
Group The user’s first local group. Add more on the Groups tab of the user’s page.

Local users change their own password on their profile; other users do so in their directory or identity provider.

A user can belong to several groups, and gets the roles of all of them. The Groups tab of a user’s page adds and removes groups, and so does the Users tab of a group’s page. A user keeps at least one group: the last one cannot be removed.

A group that still has users cannot be deleted: remove its users first. The admins group can never be deleted or renamed, and the user admin can never be deleted.

Allowing sign-in

The Details tab of a user’s page has an Allow sign-in switch, also offered as Block sign-in and Allow sign-in in the row menu of the users list. It exists for local users and for LDAP and SSO users alike:

  • On: the user signs in as usual.
  • Off: the user’s sessions end at once and every sign-in is refused, until an admin turns it on again. The page asks for confirmation first.

The switch cannot be turned off for the user admin, the way back in, nor by an admin for their own account. The page of an LDAP or SSO user also has End sessions, which signs the user out everywhere without blocking them.

Mapping to roles

Roles name local groups as local/<group> and users as local/<user>; by default admins gets admin:

roles:
  - name: admin
    groups:
      - local/admins
  - name: operator
    groups:
      - local/operators
    users:
      - local/svc-backup

Keep local/admins in the admin role, so the built-in admin can always sign in, even when the directory or the identity provider is unavailable. When config.yaml cannot be loaded at all, members of local/admins still get the admin role, so you can sign in and fix it. See Roles for the role options.

Local accounts and LDAP

A username and password login checks the local users before LDAP. When a local user has the same name as a directory user, the local account always wins and the directory password does not work for that name. Give local accounts names that cannot clash with directory accounts, for example a svc- prefix.