Decision Block the Drupal user 1 account in production environments

accepted

The first user account in a Drupal site (often referred to as "administrator" or "user 1") is granted every permission automatically. If the account credentials are compromised, an attacker can easily inject JavaScript to attack site visitors and can likely execute arbitrary PHP code.

Decision

The Drupal admin account will be blocked on production environments. Individually named user accounts will be created and granted appropriate roles as needed. Even though users may have equivalent permissions by being granted the "Administrator" role, admin actions will be logged with the actioning user's identity.

The administrator user account will be unblocked as needed for staging, development, and local environments.

For example, using drush:

drush user:unblock

In Drush 11 and newer, the --uid flag can be used:

drush user:unblock --uid=1

Otherwise for older versions of Drush and Drupal 8 or 9, and when the admin username is unknown, it can be determined with and unblocked with a subcommand:

drush user:unblock "$(drush user:information --uid=1 --fields=name --format=string)"

For Drupal 7 and older versions drush sqlq can be used to get the user name:

drush sqlq 'SELECT name FROM users WHERE uid=1';

The administrator user account will have a long, random password set that is discarded. This will prevent exposing Administrator logins if the account is accidentally unblocked.

Disable the super user access policy

From Drupal 10.3.0 onwards, user 1's implicit access to every permission is provided by the SuperUserAccessPolicy. This should be disabled in services.yml on all non-local environments:

parameters:
  security.enable_super_user: false

After changing this parameter, rebuild the container (e.g. drush cr).

Once disabled, ensure user 1 does not hold the Administrator role, otherwise they will still have full access through that role rather than the policy.

To re-enable super user access on a local environment — for example after importing a production database — set the parameter back to true in the local services.yml override and rebuild:

parameters:
  security.enable_super_user: true

Consequences

Teams may need to add a Drush command to unblock the administrator account when pulling production databases into environments like Tugboat. Local development tools also offer ways to automatically unblock accounts with Drush after a database import.

Disabling the super user policy means user 1 behaves as a regular user. This is the desired state for production, but teams must ensure at least one other account holds the Administrator role before disabling it to avoid losing access.