quarkusio/quarkus · error · NamingException

JNDI has been disabled, enable it with quarkus.naming.enable

Error message

JNDI has been disabled, enable it with quarkus.naming.enable-jndi=true

What it means

DisabledInitialContext is Quarkus's secure-by-default LDAP InitialLdapContext in which all JNDI operations throw a NamingException stating that JNDI is disabled unless quarkus.naming.enable-jndi=true. extendedOperation specifically rejects LDAP extended operations. This is an intentional security guard against JNDI injection, not a malfunction.

Source

Thrown at independent-projects/bootstrap/runner/src/main/java/io/quarkus/bootstrap/naming/DisabledInitialContext.java:41

/**
 * Initial context that won't allow you to actually do anything.
 * <p>
 * Used by Quarkus to disable JNDI.
 */
public class DisabledInitialContext extends InitialLdapContext {

    public static final String MESSAGE = "JNDI has been disabled, enable it with quarkus.naming.enable-jndi=true";

    public DisabledInitialContext() throws NamingException {
    }

    public DisabledInitialContext(Hashtable<?, ?> environment, Control[] connCtls) throws NamingException {
        super(environment, connCtls);
    }

    @Override
    public ExtendedResponse extendedOperation(ExtendedRequest request) throws NamingException {
        throw new NamingException(MESSAGE);
    }

    @Override
    public LdapContext newInstance(Control[] reqCtls) throws NamingException {
        throw new NamingException(MESSAGE);
    }

    @Override
    public void reconnect(Control[] connCtls) throws NamingException {
        throw new NamingException(MESSAGE);
    }

    @Override
    public Control[] getConnectControls() throws NamingException {
        throw new NamingException(MESSAGE);
    }

    @Override

View on GitHub (pinned to e1c734241f)

Solutions

  1. If JNDI/LDAP is genuinely required, set quarkus.naming.enable-jndi=true in application.properties
  2. Replace the extended operation with an API not relying on JNDI extended requests
  3. Restrict enabling JNDI to trusted input only — re-enable only where LDAP payloads are validated
  4. Document/audit the change since enabling JNDI relaxes a security default

Example fix

# before (default)
# quarkus.naming.enable-jndi is unset => disabled
# after: application.properties
quarkus.naming.enable-jndi=true
Defensive patterns

Strategy: try-catch

Validate before calling

boolean jndiEnabled = Boolean.parseBoolean(
    System.getProperty("quarkus.naming.enable-jndi",
    ConfigProvider.getConfig().getValue("quarkus.naming.enable-jndi", String.class)));
if (!jndiEnabled) throw new IllegalStateException("LDAP extended ops require quarkus.naming.enable-jndi=true");

Try / catch

try {
    ctx.extendedOperation(request);
} catch (NamingException e) {
    if (e.getMessage().contains("JNDI has been disabled")) {
        log.error("Enable quarkus.naming.enable-jndi=true or avoid extended operations");
    }
}

Prevention

When it happens

Trigger: Calling extendedOperation(ExtendedRequest) on the disabled LdapContext while the application runs with quarkus.naming.enable-jndi=false (the default).

Common situations: Application code performing LDAP extended operations (e.g. password modify, StartTLS) that worked on plain LDAP clients but now runs under Quarkus's hardened context; security-hardened deployments where JNDI was left disabled.

Related errors


AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/8191d977a301bf73. Report an issue: GitHub.