Wildfly 26.1.1.Final Elytron - LDAP "Context was closed"

I am following the Wildfly 26.1 Elytron documentation to try to get LDAP working for a local Wildfly 26.1.1.Final server running in standalone, but am running into an esoteric issue where the context is just closed after providing credentials. I've fiddled with the config a bit but I don't really know what I'm looking for.

Here is my standalone.xml compared to a default one for this version:

<server xmlns="urn:jboss:domain:19.0">
    ...
    <management>
        ...
        <management-interfaces>
            <http-interface http-authentication-factory="ldap-http-authentication">
                <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
                <socket-binding http="management-http"/>
            </http-interface>
        </management-interfaces>
        ...
    <profile>
        <subsystem xmlns="urn:jboss:domain:logging:8.0">
            ...
            <logger category="org.wildfly.security">
                <level name="ALL"/>
            </logger>
            ...
        </subsystem>
        ...
        <subsystem xmlns="urn:wildfly:elytron:15.1" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
            ...
            <security-domains>
                ...
                <security-domain name="LDAPDomain" default-realm="LDAPRealm" permission-mapper="default-permission-mapper">
                    <realm name="LDAPRealm" role-decoder="from-groups"/>
                </security-domain>
            </security-domains>
            <security-realms>
                ...
                <ldap-realm name="LDAPRealm" dir-context="LDAPContext">
                    <identity-mapping rdn-identifier="name" search-base-dn="OU=Users,OU=Organization,DC=myorg,DC=local">
                        <attribute-mapping>
                            <attribute from="cn" to="Groups" filter="(&amp;(objectClass=group)(member={1}))" filter-base-dn="OU=Groups,OU=Organization,DC=myorg,DC=local"/>
                        </attribute-mapping>
                        <user-password-mapper from="userPassword"/>
                    </identity-mapping>
                </ldap-realm>
                ...
            </security-realms>
            <mappers>
                ...
                <simple-role-decoder name="from-groups" attribute="Groups"/>
            </mappers>
            ...
            <http>
                <http-authentication-factory name="ldap-http-authentication" security-domain="LDAPDomain" http-server-mechanism-factory="global">
                    <mechanism-configuration>
                        <mechanism mechanism-name="BASIC">
                            <mechanism-realm realm-name="LDAPRealm"/>
                        </mechanism>
                    </mechanism-configuration>
                </http-authentication-factory>
                ...
            </http>
            <sasl>
                <sasl-authentication-factory name="management-sasl-authentication" sasl-server-factory="configured" security-domain="LDAPDomain">
                    <mechanism-configuration>
                        <mechanism mechanism-name="JBOSS-LOCAL-USER" realm-mapper="local"/>
                        <mechanism mechanism-name="DIGEST-MD5">
                            <mechanism-realm realm-name="LDAPRealm"/>
                        </mechanism>
                    </mechanism-configuration>
                </sasl-authentication-factory>
                ...
            </sasl>
            ...
            <dir-contexts>
                <dir-context name="LDAPContext" url="ldap://my.ldap.server:389" principal="CN=my_svc_acc,OU=Service Accounts,OU=Organization,DC=myorg,DC=local">
                    <credential-reference clear-text="sv_acc_password"/>
                </dir-context>
            </dir-contexts>
        <subsystem>
        ...
    </profile>
    ...
</server>

Everything omitted is default.

And here is the output I receive after trying to authenticate to the management console:

2022-10-05 10:36:17,376 TRACE [org.wildfly.security] (management task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@78de6b3] for mechanism [BASIC]
2022-10-05 10:36:17,377 TRACE [org.wildfly.security] (management task-1) Handling SocketAddressCallback
2022-10-05 10:36:17,377 TRACE [org.wildfly.security] (management task-1) Handling MechanismInformationCallback type='HTTP' name='BASIC' host-name='localhost' protocol='http'
2022-10-05 10:36:17,377 TRACE [org.wildfly.security] (management task-1) Handling AvailableRealmsCallback: realms = [LDAPRealm]
2022-10-05 10:36:17,377 DEBUG [org.wildfly.security.http.password] (management task-1) Username authentication. Realm: [LDAPRealm], Username: [gumpf].
2022-10-05 10:36:17,377 TRACE [org.wildfly.security] (management task-1) Handling RealmCallback: selected = [LDAPRealm]
2022-10-05 10:36:17,377 TRACE [org.wildfly.security] (management task-1) Handling NameCallback: authenticationName = gumpf
2022-10-05 10:36:17,377 TRACE [org.wildfly.security] (management task-1) Principal assigning: [gumpf], pre-realm rewritten: [gumpf], realm name: [LDAPRealm], post-realm rewritten: [gumpf], realm rewritten: [gumpf]
2022-10-05 10:36:17,377 DEBUG [org.wildfly.security] (management task-1) Obtaining lock for identity [gumpf]...
2022-10-05 10:36:17,377 DEBUG [org.wildfly.security] (management task-1) Obtained lock for identity [gumpf].
2022-10-05 10:36:17,377 DEBUG [org.wildfly.security] (management task-1) Creating [class javax.naming.directory.InitialDirContext] with environment:
2022-10-05 10:36:17,377 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.security.credentials] with value [******]
2022-10-05 10:36:17,377 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.security.authentication] with value [simple]
2022-10-05 10:36:17,377 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.provider.url] with value [ldap://my.ldap.server:389]
2022-10-05 10:36:17,377 DEBUG [org.wildfly.security] (management task-1)     Property [com.sun.jndi.ldap.read.timeout] with value [60000]
2022-10-05 10:36:17,377 DEBUG [org.wildfly.security] (management task-1)     Property [com.sun.jndi.ldap.connect.pool] with value [false]
2022-10-05 10:36:17,378 DEBUG [org.wildfly.security] (management task-1)     Property [com.sun.jndi.ldap.connect.timeout] with value [5000]
2022-10-05 10:36:17,378 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.security.principal] with value [CN=my_svc_acc,OU=Service Accounts,OU=Organization,DC=myorg,DC=local]
2022-10-05 10:36:17,378 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.referral] with value [ignore]
2022-10-05 10:36:17,378 DEBUG [org.wildfly.security] (management task-1)     Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory]
2022-10-05 10:36:17,381 DEBUG [org.wildfly.security] (management task-1) [javax.naming.ldap.InitialLdapContext@4b805c78] successfully created. Connection established to LDAP server.
2022-10-05 10:36:17,381 DEBUG [org.wildfly.security] (management task-1) Trying to create identity for principal [gumpf].
2022-10-05 10:36:17,381 DEBUG [org.wildfly.security] (management task-1) Executing search [(name={0})] in context [OU=Users,OU=Organization,DC=myorg,DC=local] with arguments [gumpf]. Returning attributes are [userPassword]. Binary attributes are [].
2022-10-05 10:36:17,382 DEBUG [org.wildfly.security] (management task-1) Found entry [CN=gumpf,OU=Users,OU=Organization,DC=myorg,DC=local].
2022-10-05 10:36:17,382 DEBUG [org.wildfly.security] (management task-1) Identity for principal [gumpf] found at [CN=gumpf,OU=Users,OU=Organization,DC=myorg,DC=local].
2022-10-05 10:36:17,382 DEBUG [org.wildfly.security] (management task-1) Context [javax.naming.ldap.InitialLdapContext@4b805c78] was closed. Connection closed or just returned to the pool.
2022-10-05 10:36:17,383 DEBUG [org.wildfly.security.http.basic] (management task-1) User gumpf authentication failed.
2022-10-05 10:36:17,383 TRACE [org.wildfly.security] (management task-1) Handling AuthenticationCompleteCallback: fail

Here is the current LDAP structure I am using which was fed into the commands listed in the aforementioned Elytron documentation:

dn: dc=myorg,dc=local
dc: myorg
objectClass: top
objectClass: domain

dn: ou=Organization,dc=myorg,dc=local
objectClass: organizationalUnit
objectClass: top
ou: Organization
 
dn: ou=Users,ou=Organization,dc=myorg,dc=local
objectClass: organizationalUnit
objectClass: top
ou: Users
 
dn: cn=gumpf,ou=Users,ou=Organization,dc=myorg,dc=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: gumpf
name: gumpf
 
dn: ou=Groups,ou=Organization,dc=myorg,dc=local
objectclass: top
objectclass: organizationalUnit
ou: Groups
 
dn: cn=Dev,ou=Groups,ou=Organization,dc=myorg,dc=local
objectClass: top
objectClass: group
cn: Dev
member: cn=gumpf,ou=Users,ou=Organization,dc=myorg,dc=local

dn: cn=my_svc_acc,ou=Servuce Accounts,ou=Organization,dc=myorg,dc=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: my_svc_acc
name: my_svc_acc

Note that this is constructed from what I myself have access to. I assume the userPassword attribute exists, but is not visible to me. This is an assumption with a limited understanding of LDAP, so if it should appear in some way or its lack of presence is a cause for my issue, please let me know.

I had previously enabled the org.wildfly.security logging to get more details (before I could even get the server to connect to LDAP), but the message does not suggest why the user's authentication fails. Is there any way to get more specific information on the moment-to-moment operations the javax.naming.ldap.InitialLdapContext is performing? Or, if to someone else this output or config describes the reason for the failure, why is it failing?

Other things I have tried:

• The service account and my own credentials are both being entered correctly
• An ldapsearch on my account against my.ldap.server works
• The service account and my own account are both present in Active Directory Explorer

Not sure why it fixed it, but I changed this:

<ldap-realm name="LDAPRealm" dir-context="LDAPContext">
    <identity-mapping rdn-identifier="name" search-base-dn="OU=Users,OU=Organization,DC=myorg,DC=local">
        <attribute-mapping>
            <attribute from="cn" to="Groups" filter="(&amp;(objectClass=group)(member={1}))" filter-base-dn="OU=Groups,OU=Organization,DC=myorg,DC=local"/>
        </attribute-mapping>
        <user-password-mapper from="userPassword"/>
    </identity-mapping>
</ldap-realm>

To this:

<ldap-realm name="LDAPRealm" dir-context="LDAPContext" direct-verification="true">
    <identity-mapping rdn-identifier="name" search-base-dn="OU=Organization,DC=myorg,DC=local" use-recursive-search="true">
        <attribute-mapping>
            <attribute from="name" to="Groups" filter="(&amp;(objectClass=group)(member={1}))" filter-base-dn="OU=Organization,DC=myorg,DC=local"/>
        </attribute-mapping>
        <user-password-mapper from="userPassword"/>
    </identity-mapping>
</ldap-realm>