[JBoss JIRA] (WFLY-5786) LdapExtLoginModule does not handle loops in referrals
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5786?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-5786:
-------------------------------
Affects Version/s: 10.0.0.CR5
> LdapExtLoginModule does not handle loops in referrals
> -----------------------------------------------------
>
> Key: WFLY-5786
> URL: https://issues.jboss.org/browse/WFLY-5786
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR5
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Attachments: app.war, server1.ldif, server2.ldif
>
>
> According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
> When Wildfly server is configured to use LdapExtLoginModule which uses referrals and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on Wildfly server.
> [1] http://tools.ietf.org/html/rfc4511#section-4.1.10
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5786) LdapExtLoginModule does not handle loops in referrals
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5786?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-5786:
-------------------------------
Description:
According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
When Wildfly server is configured to use LdapExtLoginModule which uses referrals and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on Wildfly server.
[1] http://tools.ietf.org/html/rfc4511#section-4.1.10
was:
According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
When EAP server is configured to use LdapExtLoginModule which uses referrals and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
We hit this issue during certification of 3rd Party LDAP servers. This issue is not regression to EAP 6.x.
[1] http://tools.ietf.org/html/rfc4511#section-4.1.10
> LdapExtLoginModule does not handle loops in referrals
> -----------------------------------------------------
>
> Key: WFLY-5786
> URL: https://issues.jboss.org/browse/WFLY-5786
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Attachments: app.war, server1.ldif, server2.ldif
>
>
> According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
> When Wildfly server is configured to use LdapExtLoginModule which uses referrals and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on Wildfly server.
> [1] http://tools.ietf.org/html/rfc4511#section-4.1.10
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5786) LdapExtLoginModule does not handle loops in referrals
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5786?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-5786:
-------------------------------
Steps to Reproduce:
1) Start two LDAP servers which use attached server1.ldif and server2.ldif
2) Add following security domain to configuration:
{code:xml}
<security-domain name="ldapSecurityDomain">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">
<module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
<module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
<module-option name="referralUserAttributeIDToCheck" value="member"/>
<module-option name="roleFilter" value="(|(objectClass=referral)(member={1}))"/>
<module-option name="roleAttributeID" value="cn"/>
<module-option name="rolesCtxDN" value="ou=Roles,dc=jboss,dc=org"/>
<module-option name="java.naming.security.authentication" value="simple"/>
<module-option name="bindDN" value="uid=admin,ou=system"/>
<module-option name="bindCredential" value="secret"/>
<module-option name="baseCtxDN" value="ou=People,dc=jboss,dc=org"/>
<module-option name="java.naming.referral" value="throw"/>
<module-option name="throwValidateError" value="true"/>
<module-option name="baseFilter" value="(uid={0})"/>
</login-module>
</authentication>
</security-domain>
{code}
3) Deploy attached application app.war
4) Run periodically
{noformat}
curl -u jduke:Password1 http://localhost:8080/app/protected/printRoles?role=TheDuke&role=Admin
{noformat}
-> java.lang.OutOfMemoryError on Wildfly server
was:
1) Start two LDAP servers which use attached server1.ldif and server2.ldif
2) Add following security domain to configuration:
{code:xml}
<security-domain name="ldapSecurityDomain">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">
<module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
<module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
<module-option name="referralUserAttributeIDToCheck" value="member"/>
<module-option name="roleFilter" value="(|(objectClass=referral)(member={1}))"/>
<module-option name="roleAttributeID" value="cn"/>
<module-option name="rolesCtxDN" value="ou=Roles,dc=jboss,dc=org"/>
<module-option name="java.naming.security.authentication" value="simple"/>
<module-option name="bindDN" value="uid=admin,ou=system"/>
<module-option name="bindCredential" value="secret"/>
<module-option name="baseCtxDN" value="ou=People,dc=jboss,dc=org"/>
<module-option name="java.naming.referral" value="throw"/>
<module-option name="throwValidateError" value="true"/>
<module-option name="baseFilter" value="(uid={0})"/>
</login-module>
</authentication>
</security-domain>
{code}
3) Deploy attached application app.war
4) Run periodically
{noformat}
curl -u jduke:Password1 http://localhost:8080/app/protected/printRoles?role=TheDuke&role=Admin
{noformat}
-> java.lang.OutOfMemoryError on EAP server
> LdapExtLoginModule does not handle loops in referrals
> -----------------------------------------------------
>
> Key: WFLY-5786
> URL: https://issues.jboss.org/browse/WFLY-5786
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Attachments: app.war, server1.ldif, server2.ldif
>
>
> According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
> When EAP server is configured to use LdapExtLoginModule which uses referrals and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
> We hit this issue during certification of 3rd Party LDAP servers. This issue is not regression to EAP 6.x.
> [1] http://tools.ietf.org/html/rfc4511#section-4.1.10
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5786) LdapExtLoginModule does not handle loops in referrals
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5786?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-5786:
-------------------------------
Attachment: app.war
server2.ldif
server1.ldif
> LdapExtLoginModule does not handle loops in referrals
> -----------------------------------------------------
>
> Key: WFLY-5786
> URL: https://issues.jboss.org/browse/WFLY-5786
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Attachments: app.war, server1.ldif, server2.ldif
>
>
> According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
> When EAP server is configured to use LdapExtLoginModule which uses referrals and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
> We hit this issue during certification of 3rd Party LDAP servers. This issue is not regression to EAP 6.x.
> [1] http://tools.ietf.org/html/rfc4511#section-4.1.10
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5786) LdapExtLoginModule does not handle loops in referrals
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-5786:
----------------------------------
Summary: LdapExtLoginModule does not handle loops in referrals
Key: WFLY-5786
URL: https://issues.jboss.org/browse/WFLY-5786
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
When EAP server is configured to use LdapExtLoginModule which uses referrals and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
We hit this issue during certification of 3rd Party LDAP servers. This issue is not regression to EAP 6.x.
[1] http://tools.ietf.org/html/rfc4511#section-4.1.10
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5785) EJB lookup fails with "No cluster context available" in failover tests
by Michal Vinkler (JIRA)
Michal Vinkler created WFLY-5785:
------------------------------------
Summary: EJB lookup fails with "No cluster context available" in failover tests
Key: WFLY-5785
URL: https://issues.jboss.org/browse/WFLY-5785
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Michal Vinkler
Assignee: Paul Ferraro
Seen in our failover tests for remote stateful EJBs - scenarios:
ejb-ejbremote-shutdown-dist-async
ejb-ejbremote-shutdown-dist-sync
ejb-ejbremote-undeploy-dist-async
After failing a node, occasionally EJB lookup starts failing - client starts logging these error messages:
{code}
2015/12/03 04:46:47:078 EST [ERROR][Runner - 9] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb>
java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:1063)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
at java.lang.Thread.run(Thread.java:745)
{code}
It stops logging these messages only after the failed node is restarted and joins the cluster again.
Link (this job was configured to use only 100 sessions in order to keep the log size small)
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5785) EJB lookup fails with "No cluster context available" in failover tests
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5785?page=com.atlassian.jira.plugin.... ]
Michal Vinkler updated WFLY-5785:
---------------------------------
Affects Version/s: 10.0.0.CR5
> EJB lookup fails with "No cluster context available" in failover tests
> ----------------------------------------------------------------------
>
> Key: WFLY-5785
> URL: https://issues.jboss.org/browse/WFLY-5785
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> Seen in our failover tests for remote stateful EJBs - scenarios:
> ejb-ejbremote-shutdown-dist-async
> ejb-ejbremote-shutdown-dist-sync
> ejb-ejbremote-undeploy-dist-async
> After failing a node, occasionally EJB lookup starts failing - client starts logging these error messages:
> {code}
> 2015/12/03 04:46:47:078 EST [ERROR][Runner - 9] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb>
> java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:1063)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> It stops logging these messages only after the failed node is restarted and joins the cluster again.
> Link (this job was configured to use only 100 sessions in order to keep the log size small)
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5520) EAP 6 HA migrated configs fail to boot server
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5520?page=com.atlassian.jira.plugin.... ]
Ladislav Thon commented on WFLY-5520:
-------------------------------------
[~rhusar] Thanks Rado. So this means that this needs to be fixed in WildFly, because the currently available workaround is wrong. Or there has to be a better workaround; do we have one?
> EAP 6 HA migrated configs fail to boot server
> ---------------------------------------------
>
> Key: WFLY-5520
> URL: https://issues.jboss.org/browse/WFLY-5520
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR2
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Attachments: eap-6.1-migrated-configs.zip, eap-6.4-migrated-configs.zip
>
>
> If you try (curated) EAP 6 standalone-ha.xml configuration on WildFly the server will fail to boot due to an EJB3 subsystem attribute.
> Server boot console log:
> mbp:migration-tests emmartins$ ./default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT/bin/standalone.sh -c standalone-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/emmartins/wildfly/migration-tests/default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 11:37:25,583 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 11:37:25,896 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 11:37:25,985 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) starting
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 7) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'default-clustered-sfsb-cache' in the resource at address '/subsystem=ejb3' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,385 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"
> 11:37:27,586 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot operations"
> 11:37:27,588 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem ejb3 boot operations\""
> 11:37:27,591 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 11:37:27,594 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 11:37:27,603 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) stopped in 6ms
> Attached is the standalone-ha.xml config, with just threads subsystem removed, and web subsystem migrated to undertow, that should be able to boot the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months