pgAdmin 6.8 changes LDAP distinguished-name matching

An administration interface has an authentication system of its own. Connecting to pgAdmin and connecting through pgAdmin to PostgreSQL are related activities, but the identity accepted by the web application needs its own configuration. A change in that configuration can affect access before anyone opens a database connection.

The pgAdmin 6.8 announcement, published on April 8, calls out a change to LDAP distinguished-name handling. During a bind request, pgAdmin now treats the LDAP DN case insensitively by default. A new LDAP_DN_CASE_SENSITIVE setting restores the previous behavior when set to True. This deserves attention beyond the release listing because it changes the default interpretation of an identity-related value.

I value the predictability of PostgreSQL administration. Authentication in an accompanying tool is part of that predictability, even when the database server itself has no corresponding change. An explicit compatibility setting makes the changed behavior easier to understand and control.

The setting concerns distinguished names

The LDAP documentation included with 6.8 defines LDAP_DN_CASE_SENSITIVE as the switch controlling whether distinguished names are case sensitive. It accepts True or False, with False as the default. The release announcement explains that setting it to True returns to the previous behavior.

That is a narrower statement than saying LDAP authentication has become generally case insensitive. The documented switch names DNs. It does not describe a change to password comparison or a universal normalization rule for every directory attribute. Keeping the scope explicit avoids turning a compatibility change into an unsupported claim about directory security.

For an installation that needs the previous behavior, the configuration assignment is small.

LDAP_DN_CASE_SENSITIVE = True

The LDAP documentation places these settings in config_local.py or config_system.py for a server-mode installation. This example is an override for the changed behavior, not a complete LDAP setup. It does not select a directory server or establish which authentication sources the application should consult.

Authentication source order is separate

The same documentation describes AUTHENTICATION_SOURCES. Its default is internal authentication. Including LDAP enables directory authentication, and the order of the list determines the order in which pgAdmin attempts the sources. A list containing LDAP followed by internal authentication tries LDAP first and falls back to internal user entries if it fails. Reversing the order changes that sequence.

That setting answers a different question from DN case matching. Source order determines which identity system gets an attempt. The new switch determines a part of LDAP behavior when that source is in use. A complete description of an installation needs both pieces, because a successful login through a fallback source does not demonstrate that the LDAP path accepted the identity.

The documentation also distinguishes the username attribute from the search base DN. The username attribute identifies the directory attribute containing usernames. A search base DN limits the part of the directory searched, while a separate search filter specifies matching criteria. These settings give the new option context without suggesting that it replaces the existing directory selection rules.

I prefer configuration changes that identify the exact behavior they control. Here, the option lets an administrator preserve the earlier DN treatment without changing authentication-source order or rewriting the directory search settings. Those choices can remain explicit in the installation configuration.

Overrides have a documented order

The configuration-file documentation for this release describes several files read at startup. The main config.py provides defaults and should remain unmodified. Packagers can supply config_distro.py. End users can then override settings in config_local.py, and system administrators can apply system-wide settings in config_system.py.

Because the system file loads after the local file, reading one assignment in isolation does not establish the effective setting. The documented order explains where a later override can come from. On Linux, the system file lives at /etc/pgadmin/config_system.py, outside the installation directory. This supports an administrative policy that does not depend on editing the packaged defaults.

That organization matters for the new compatibility option. A deployment can record its intended DN behavior in the appropriate override file instead of changing application code. Keeping the choice with the existing LDAP configuration also makes it easier to see which behavior the installation expects after an update.

The release also improves the administration view

The 6.8 release notes add transaction start time to the server-activity sessions view and unique-key support to the entity relationship diagram tool. They also list support for running the container under OpenShift with alternate user IDs. These changes concern different parts of administering or hosting pgAdmin, rather than one database-server feature.

Several repairs address whether the interface represents schema operations accurately. The release fixes missing database revoke SQL and foreign-key relationships that failed to update after a primary-key change. It also corrects schema-diff handling of function arguments whose default values contain commas. Those are concrete interpretation problems in a tool that generates and displays SQL.

The LDAP change is especially relevant to deployments using pgAdmin as a shared server application. Its default now accepts case-insensitive DN treatment during binding, and the release supplies a named override for the previous behavior. Recording that decision in the documented configuration hierarchy makes the authentication behavior part of the installation configuration that administrators can inspect.