[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ] Adriano Teixeira de Souza edited comment on WFLY-14284 at 1/22/21 8:24 AM: --------------------------------------------------------------------------- Hi [~ochaloup] The $local authentication is not disabled according to what I can see. If it's this. {code:java} <security-realms> <security-realm name="ManagementRealm"> <server-identities> <secret value="YWRtaW5AYWxmYQo="/> </server-identities> <authentication> <local default-user="$local" skip-group-loading="true"/> <properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization map-groups-to-roles="false"> <properties path="mgmt-groups.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="application.keystore" relative-to="jboss.domain.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/> </ssl> </server-identities> <authentication> <local default-user="$local" allowed-users="*" skip-group-loading="true"/> <properties path="application-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="remote-ejb-security-realm"> <server-identities> <secret value="ZWpi"/> </server-identities> </security-realm> </security-realms> {code}   Our lookup in almost of case is like this {code:java} Properties props = new Properties(); props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");        Context context = new InitialContext(props); StringBuilder jndiName = new StringBuilder(); jndiName.append("ejb:"); jndiName.append(module.getApplicationName()); jndiName.append("/"); jndiName.append(module.getModuleName()); jndiName.append("/"); jndiName.append(ejbName); jndiName.append("!"); jndiName.append(intefaceName);         Object bean = context.lookup(jndiName.toString()); {code} I'll configure to remote+http instead of http-remoting (it commes from Wildfly 10 configuration) and -Dwildfly.config.url with wildfly-config.xml and I will observe the server logs and behavior on the stoping operations On error scenario we have a wildfly domain with our applications and four servers working behind a haproxy load balance  I'll set jboss.tx.node.id on server instances in order to get a better scenario too. Some information about your point: 1 - We are a software development providing to many companies and we are configuring ejb as remote call because we have three modules that can be deployed together on the same instance or on different instance according to our client needs. It's just by convenience.  2 - On this scenario we don't using @EJB or java:app with local lookup because we have a large software ecosystem and we need to normalize all development activities to a standard ways (in this case using Context lookup) in order to get more easy and flexible development activities and get more predictable thing to solve problems. There are many places we are using local lookup but in this case is where are sure there is no remote call. 3 - Becouse our company directives we don't use nom specification annotation like @ClientTransaction I'll bring some more information about our tests after do it. By the time I say thanks was (Author: JIRAUSER147207): Hi [~ochaloup] The $local authentication is not disabled according to what I can see. If it's this. {code:java} <security-realms> <security-realm name="ManagementRealm"> <server-identities> <secret value="YWRtaW5AYWxmYQo="/> </server-identities> <authentication> <local default-user="$local" skip-group-loading="true"/> <properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization map-groups-to-roles="false"> <properties path="mgmt-groups.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="ApplicationRealm"> <server-identities> <ssl> <keystore path="application.keystore" relative-to="jboss.domain.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/> </ssl> </server-identities> <authentication> <local default-user="$local" allowed-users="*" skip-group-loading="true"/> <properties path="application-users.properties" relative-to="jboss.domain.config.dir"/> </authentication> <authorization> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/> </authorization> </security-realm> <security-realm name="remote-ejb-security-realm"> <server-identities> <secret value="ZWpi"/> </server-identities> </security-realm> </security-realms> {code}   I'll configure to remote+http instead of http-remoting (it commes from Wildfly 10 configuration) and -Dwildfly.config.url with wildfly-config.xml and I will observe the server logs and behavior on the stoping operations On error scenario we have a wildfly domain with our applications and four servers working behind a haproxy load balance  I'll set jboss.tx.node.id on server instances in order to get a better scenario too. Some information about your point: 1 - We are a software development providing to many companies and we are configuring ejb as remote call because we have three modules that can be deployed together on the same instance or on different instance according to our client needs. It's just by convenience.  2 - On this scenario we don't using @EJB or java:app with local lookup because we have a large software ecosystem and we need to normalize all development activities to a standard ways (in this case using Context lookup) in order to get more easy and flexible development activities and get more predictable thing to solve problems. There are many places we are using local lookup but in this case is where are sure there is no remote call. 3 - Becouse our company directives we don't use nom specification annotation like @ClientTransaction I'll bring some more information about our tests after do it. By the time I say thanks -- This message was sent by Atlassian Jira (v8.13.1#813001)