[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3048:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1069127|https://bugzilla.redhat.com/show_bug.cgi?id=1069127] from POST to MODIFIED
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <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>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3048:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from POST to MODIFIED
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <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>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (AS7-4247) Server shutdown: Problems un-registering MBeans: CacheException: Failure while unregistering mbeans
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4247?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-4247:
----------------------------------------------
Radoslav Husar <rhusar(a)redhat.com> changed the Status of [bug 917010|https://bugzilla.redhat.com/show_bug.cgi?id=917010] from ASSIGNED to ON_QA
> Server shutdown: Problems un-registering MBeans: CacheException: Failure while unregistering mbeans
> ---------------------------------------------------------------------------------------------------
>
> Key: AS7-4247
> URL: https://issues.jboss.org/browse/AS7-4247
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.1.Final
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Minor
> Labels: JBAS010282, eap6_prd_req
> Fix For: 7.1.2.Final (EAP)
>
>
> Just ran into this, implications not yet known.
> {noformat}
> [JBossINF] 15:02:54,085 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf18/ejb|12] [perf18/ejb, perf20/ejb, perf21/ejb]
> [JBossINF] 15:02:54,086 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-6,null) ISPN000094: Received new cluster view: [perf18/web|12] [perf18/web, perf20/web, perf21/web]
> [JBossINF] 15:02:58,127 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web] (Incoming-5,null) JBAS010247: New cluster view for partition web (id: 13, delta: -1, merge: false) : [perf18/web, perf20/web]
> [JBossINF] 15:02:58,128 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,null) ISPN000094: Received new cluster view: [perf18/web|13] [perf18/web, perf20/web]
> [JBossINF] 15:02:58,135 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.ejb] (Incoming-4,null) JBAS010247: New cluster view for partition ejb (id: 13, delta: -1, merge: false) : [perf18/ejb, perf20/ejb]
> [JBossINF] 15:02:58,136 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,null) ISPN000094: Received new cluster view: [perf18/ejb|13] [perf18/ejb, perf20/ejb]
> [JBossINF] 15:03:02,476 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web] (Incoming-2,null) JBAS010247: New cluster view for partition web (id: 14, delta: -1, merge: false) : [perf18/web]
> [JBossINF] 15:03:02,477 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf18/web|14] [perf18/web]
> [JBossINF] 15:03:02,494 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.ejb] (Incoming-16,null) JBAS010247: New cluster view for partition ejb (id: 14, delta: -1, merge: false) : [perf18/ejb]
> [JBossINF] 15:03:02,495 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-16,null) ISPN000094: Received new cluster view: [perf18/ejb|14] [perf18/ejb]
> 2012/03/20 15:03:05:785 EDT [DEBUG][RMI TCP Connection(18)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossApplicationServerImpl: sfTerminateWith().
> 2012/03/20 15:03:05:785 EDT [DEBUG][RMI TCP Connection(18)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - [JBossRuntime] sfTerminateWith() invoked.
> 2012/03/20 15:03:05:790 EDT [DEBUG][Thread-33] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossShutdown server host: perf18
> 2012/03/20 15:03:05:829 EDT [DEBUG][RMI TCP Connection(18)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossShutdown command executed successfuly.
> 2012/03/20 15:03:05:830 EDT [DEBUG][RMI TCP Connection(18)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Waiting for server to shutdown.
> [JBossINF] 15:03:05,850 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000029: Passivating all entries to disk
> [JBossINF] 15:03:05,851 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-9) Pausing Coyote HTTP/1.1 on http-perf18-10.16.90.54-8080
> [JBossINF] 15:03:05,851 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-9) Stopping Coyote HTTP/1.1 on http-perf18-10.16.90.54-8080
> [JBossINF] 15:03:05,850 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-12) ISPN000029: Passivating all entries to disk
> [JBossINF] 15:03:05,851 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000030: Passivated 0 entries in 0 milliseconds
> [JBossINF] 15:03:05,855 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-12) ISPN000030: Passivated 0 entries in 4 milliseconds
> [JBossINF] 15:03:05,858 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-12) JBAS010282: Stopped org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB cache from ejb container
> [JBossINF] 15:03:05,858 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl cache from ejb container
> [JBossINF] 15:03:05,879 INFO [org.jboss.as.logging] JBAS011503: Restored bootstrap log handlers
> [JBossINF] 15:03:05,904 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
> [JBossINF] 15:03:05,904 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 0 milliseconds
> [JBossINF] 15:03:05,907 INFO [org.jboss.as.clustering.infinispan] JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> [JBossINF] 15:03:05,913 INFO [org.jboss.as.clustering.infinispan] JBAS010282: Stopped repl cache from ejb container
> [JBossINF] 15:03:05,939 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
> [JBossINF] 15:03:05,940 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 0 milliseconds
> [JBossINF] 15:03:05,941 WARN [org.infinispan.jmx.CacheJmxRegistration] ISPN000032: Problems un-registering MBeans: org.infinispan.CacheException: Failure while unregistering mbeans
> [JBossINF] at org.infinispan.jmx.ComponentsJmxRegistration.unregisterMBeans(ComponentsJmxRegistration.java:105)
> [JBossINF] at org.infinispan.jmx.AbstractJmxRegistration.unregisterMBeans(AbstractJmxRegistration.java:53)
> [JBossINF] at org.infinispan.jmx.CacheJmxRegistration.stop(CacheJmxRegistration.java:100)
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_30]
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_30]
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_30]
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_30]
> [JBossINF] at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:236)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:882)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:672)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:551)
> [JBossINF] at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:198)
> [JBossINF] at org.infinispan.CacheImpl.stop(CacheImpl.java:516)
> [JBossINF] at org.infinispan.DecoratedCache.stop(DecoratedCache.java:129)
> [JBossINF] at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:291)
> [JBossINF] at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:291)
> [JBossINF] at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.stop(DistributedCacheManager.java:127)
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.stop(DistributableSessionManager.java:447) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> [JBossINF] at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3995) [jbossweb-7.0.13.Final.jar:]
> [JBossINF] at org.jboss.as.web.deployment.WebDeploymentService.stop(WebDeploymentService.java:108) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> [JBossINF] Caused by: javax.management.InstanceNotFoundException: jboss.infinispan:type=Cache,name="//default-host//clusterbench(repl_async)",manager="web",component=Activation
> [JBossINF] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094) [rt.jar:1.6.0_30]
> [JBossINF] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:415) [rt.jar:1.6.0_30]
> [JBossINF] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:403) [rt.jar:1.6.0_30]
> [JBossINF] at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:506) [rt.jar:1.6.0_30]
> [JBossINF] at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.unregisterMBean(PluggableMBeanServerImpl.java:584)
> [JBossINF] at org.jboss.as.jmx.PluggableMBeanServerImpl.unregisterMBean(PluggableMBeanServerImpl.java:331)
> [JBossINF] at org.infinispan.jmx.JmxUtil.unregisterMBean(JmxUtil.java:109)
> [JBossINF] at org.infinispan.jmx.ComponentsJmxRegistration.unregisterMBeans(ComponentsJmxRegistration.java:101)
> [JBossINF] ... 24 more
> [JBossINF]
> [JBossINF] 15:03:05,955 INFO [org.jboss.as.clustering.infinispan] JBAS010282: Stopped //default-host//clusterbench cache from web container
> [JBossINF] 15:03:05,979 INFO [org.jboss.weld.deployer] JBAS016009: Stopping weld service for deployment clusterbench-ee6.ear
> [JBossINF] 15:03:05,992 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
> [JBossINF] 15:03:05,993 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 0 milliseconds
> [JBossINF] 15:03:06,016 INFO [org.jboss.as.clustering.infinispan] JBAS010282: Stopped repl cache from web container
> [JBossINF] 15:03:06,025 INFO [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying TransactionManagerService
> [JBossINF] 15:03:06,025 INFO [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping transaction recovery manager
> [JBossINF] 15:03:06,030 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6-ejb.jar in 172ms
> [JBossINF] 15:03:06,032 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6-web.war in 173ms
> [JBossINF] 15:03:06,052 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6.ear in 197ms
> [JBossINF] 15:03:06,074 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
> [JBossINF] 15:03:06,102 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
> [JBossINF] 15:03:06,150 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.2.Final-SNAPSHOT "Brontes" stopped in 290ms
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (DROOLS-461) Memory Leak in Drools6.0.1-JavaLexer- Whenever application is restarted in websphere
by jacob sukumar (JIRA)
[ https://issues.jboss.org/browse/DROOLS-461?page=com.atlassian.jira.plugin... ]
jacob sukumar updated DROOLS-461:
---------------------------------
Description: Everytime we restarted the application on websphere and taking the heap dumps, we could able to see around 8MB of JavaLexer(org/drools/compiler/rule/builder/dialect/java/parser/JavaLexer) is leaking. Let us say if we restarted the application for 3 times, (8*3)24MB heap memory is leaking.
Affects Version/s: 6.0.1.Final
Environment: Websphere7.0, Java
> Memory Leak in Drools6.0.1-JavaLexer- Whenever application is restarted in websphere
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-461
> URL: https://issues.jboss.org/browse/DROOLS-461
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Websphere7.0, Java
> Reporter: jacob sukumar
> Assignee: Mark Proctor
>
> Everytime we restarted the application on websphere and taking the heap dumps, we could able to see around 8MB of JavaLexer(org/drools/compiler/rule/builder/dialect/java/parser/JavaLexer) is leaking. Let us say if we restarted the application for 3 times, (8*3)24MB heap memory is leaking.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-3216) Switch default of skip-group-loading to 'true' for local auth.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-3216:
--------------------------------------
Summary: Switch default of skip-group-loading to 'true' for local auth.
Key: WFLY-3216
URL: https://issues.jboss.org/browse/WFLY-3216
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 9.0.0.CR1
The new attribute skip-group-loading was added to the local authentication definition by WFLY-3048 this needed to have a default of false for backwards compatibility purposes however in reality most would probably assume a default of true.
For WildFly 9 switch the default to true. This change in default should probably only occur if the schema version is 3 or above.
A transformer should not be required as this is not configuration that is propagated around a domain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months