Hello folks, I'm running into a problem with jboss-cli when I attempt to connect locally.  This needs to happen, at minimum, so that the Wildfly service script (wildfly-init-debian.sh) can shut down the server when appropriate.  I am using Wildfly 8.0.0.Final, and the associated configuration bits follow.  Note that I have omitted most of the LDAP configuration, as I don't think it is germane to the conversation--LDAP authentication works fine.

In standalone.xml:

    <security-realm name="ManagementRealm">

        <authentication>

            <local default-user="$local" />

            <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">

                ...

            </ldap>

        </authentication>

        <authorization map-groups-to-roles="false">

            <ldap connection="...">

                ...

            </ldap>

        </authorization>

    </security-realm>

With this configuration, I am not able to connect to the server using jboss-cli, on the local machine, without being prompted for a username and password.  If I enter a valid administrator username and password from the LDAP directory, jboss-cli connects just fine.  The problem is that I need to to be able to connect without a username and password so that the init script can shut the node down when necessary.

If I comment out the <ldap .../> section in <authentication>, local authentication starts working again.  I'm able to issue a command like "jboss-cli --connect command=:shutdown" and the client connects successfully and shuts down the node with no username/password prompt.  But as soon as the <ldap .../> section is re-enabled, with no other configuration changes at all, it flips back to prompting for a username and password.

It's almost as if the LDAP authentication setup is poison-pilling local authentication and making it not work at all.

The modified stamp on the Wildfly tmp/auth directory changes when I invoke jboss-cli, so I assume that the client side is throwing a token in there for the authentication process.  The server side just never picks it up.

Note that I have tried changing @default-user in the <local .../> element to the name of an admin user within the LDAP directory, both as a full DN and as a simple username, and local authentication still does not work.  I tried this in case it's doing some kind of loop-back authentication behind the scenes or something.  No luck.

I found the following quote in the LDAP section of the documentation at Security Realms - WildFly 8 - Project Documentation Editor:

For simplicity the <local/> configuration has been removed from this example, however there it is fine to leave that in place for local authentication to remain possible.

That is kind of unfortunate, because it would be nice if the example config illustrated how to use LDAP authentication remotely, while still allowing local authentication from the local system.

Any pointers?  Is this a bug, or is my configuration incorrect?