pgAdmin 6.3 adds two-factor authentication with optional forced enrollment

Enabling two-factor authentication and requiring every user to configure it are different deployment decisions. pgAdmin 6.3 exposes separate settings for them. The feature is enabled by default in the release configuration, while forced registration is disabled. An administrator adopting the release needs to understand both values before describing the login policy.

The December 16 announcement introduces two-factor authentication alongside a control for automatic server discovery. It also continues the React conversion with backup dialogs. The authentication change is the most consequential addition for a shared pgAdmin service because it changes entry into the administration application.

I want database access controls to remain explicit at each relevant interface. pgAdmin login protects an administration application, while PostgreSQL has its own connection and permission decisions. Treating the new option as a pgAdmin login feature keeps its purpose clear.

Enabled support does not force registration

The 6.3 configuration file sets MFA_ENABLED to True and MFA_FORCE_REGISTRATION to False. Its supported methods are email and authenticator. The file describes email as a one-time code and the authenticator option as TOTP-based.

These defaults establish availability of the mechanism. They do not express a policy that every user must enroll on the next login. The second setting exists to make that requirement explicit.

The release-tagged setup documentation applies to pgAdmin running in server mode. It directs administrators to put settings in config_local.py or config_system.py. A deployment that wants enrollment at login can express the policy directly.

MFA_ENABLED = True
MFA_FORCE_REGISTRATION = True
MFA_SUPPORTED_METHODS = ["email", "authenticator"]

The supported-method variable here follows the actual 6.3 configuration file. The setup page's parameter table uses a different name, SUPPORTED_MFA_LIST. Reading the configuration shipped with the release resolves that inconsistency without assuming that every name in the prose is executable configuration.

Email verification also requires mail-server settings. The documentation names that dependency explicitly. Making email an available method does not supply the transport needed to deliver its codes.

Enrollment belongs to the individual user

The documented enrollment workflow starts in the User menu's Two-factor Authentication entry. It lists the supported methods and provides a Setup action for each. A configured method instead has a Delete action that deregisters it for the current user.

That workflow separates administrator policy from user configuration. An administrator decides which methods the application supports and whether registration is mandatory. A user configures a supported method through the account interface.

The separation matters when interpreting an upgrade. Installing 6.3 provides the new code and its default settings. It does not mean each existing account already has a configured factor. Forced registration supplies a policy for accounts with no configured method when they log in.

I find those separate controls useful because they make an authentication rollout inspectable. The default feature flag, the enrollment requirement and the available methods answer different questions. Each can be checked in the configuration that the service actually loads.

Automatic discovery becomes configurable

The announcement also adds AUTO_DISCOVER_SERVERS. Setting it to False in config_local.py or config_distro.py disables discovery of database servers on the local machine. The release configuration keeps it True by default.

This affects which local servers pgAdmin discovers automatically. It is not a grant of database access and does not replace authentication to a discovered server. The control is useful where the administrator wants explicit server registration to determine the application's initial server list.

The configuration file shows distribution overrides loading before local overrides, followed by system overrides. That order gives deployment policy a defined place in the configuration process. A visible default in the packaged file can therefore differ from the effective value after those files load.

Administration output also receives corrections

The 6.3 release notes include fixes to reverse-engineered SQL for aggregates and definitions for PostgreSQL 14 functions or procedures using ATOMIC. These concern the accuracy of the SQL pgAdmin presents for existing objects.

That accuracy matters when generated definitions become material for a schema change. An interface can display an object successfully while still reconstructing the wrong command. The listed fixes identify specific definitions whose presentation needed repair.

The release also allows choosing an extension's schema during creation and repairs a missing Change Password menu option when internal authentication appears alongside other authentication sources. Those changes affect different kinds of administration state, with one controlling object placement and the other exposing an existing account operation.

Backup Global, Backup Server and object backup dialogs move to React in this release. Alert and confirmation dialogs also receive React replacements. Alongside the new login controls, these changes continue the work on administration workflows while preserving distinct configuration choices for authentication and local server discovery.