[JBoss JIRA] (SECURITY-943) AdvancedLdapLoginModule authentication fails when some part of DN is part of LDAP URL
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-943?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-943:
--------------------------------------
Fix Version/s: Negotiation_3_0_5_CR1
(was: Negotiation_3_0_4_Final)
> AdvancedLdapLoginModule authentication fails when some part of DN is part of LDAP URL
> -------------------------------------------------------------------------------------
>
> Key: SECURITY-943
> URL: https://issues.jboss.org/browse/SECURITY-943
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_2_Final
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: Negotiation_3_0_5_CR1
>
>
> In case when part of DN is placed in LDAP URL instead of baseCtxDN then authentication fails (see [1] for details about this URL) in AdvancedLdapLoginModule. Authentication is provided by binding with user DN and password, but in this case user DN does not include DN part from LDAP URL which leads to fail.
> Thrown exception:
> {code}
> javax.naming.AuthenticationException: LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user uid=jduke,ou=People
> com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3135)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3081)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2883)
> com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2797)
> com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> javax.naming.InitialContext.init(InitialContext.java:244)
> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.constructLdapContext(AdvancedLdapLoginModule.java:486)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.authenticate(AdvancedLdapLoginModule.java:669)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.innerLogin(AdvancedLdapLoginModule.java:397)
> org.jboss.security.negotiation.AdvancedLdapLoginModule$AuthorizeAction.run(AdvancedLdapLoginModule.java:967)
> org.jboss.security.negotiation.AdvancedLdapLoginModule.login(AdvancedLdapLoginModule.java:326)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> {code}
> [1] https://tools.ietf.org/html/rfc2255
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ]
Darran Lofthouse resolved SECURITY-921.
---------------------------------------
Resolution: Done
> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
> Key: SECURITY-921
> URL: https://issues.jboss.org/browse/SECURITY-921
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final
> Environment: *
> Reporter: Harald Krause
> Assignee: Radovan Netuka
> Labels: web_security
> Fix For: Negotiation_3_0_4_Final, Negotiation_2_3_13_Final
>
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> if (mechList.get(0).equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> }
> else
> {
> boolean kerberosSupported = false;
> ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
> for (Oid oid : mechList)
> {
> if (oid.equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> break;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-921:
--------------------------------------
Fix Version/s: Negotiation_2_3_13_Final
> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
> Key: SECURITY-921
> URL: https://issues.jboss.org/browse/SECURITY-921
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final
> Environment: *
> Reporter: Harald Krause
> Assignee: Radovan Netuka
> Labels: web_security
> Fix For: Negotiation_3_0_4_Final, Negotiation_2_3_13_Final
>
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> if (mechList.get(0).equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> }
> else
> {
> boolean kerberosSupported = false;
> ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
> for (Oid oid : mechList)
> {
> if (oid.equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> break;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8394) Deprecate binary-keyed-jdbc-store and mixed-keyed-jdbc-store
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8394?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-9647 to WFLY-8394:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8394 (was: JBEAP-9647)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
> Deprecate binary-keyed-jdbc-store and mixed-keyed-jdbc-store
> ------------------------------------------------------------
>
> Key: WFLY-8394
> URL: https://issues.jboss.org/browse/WFLY-8394
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> These implementations are inefficient and are being removed without replacement in Infinispan 9.0.
> As string-keyed-jdbc-store will be the only remaining implementation, we can rename this to jdbc-store.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month