[jira] [Commented] (DIRAPI-387) More info on PasswordException
[
https://issues.apache.org/jira/browse/DIRAPI-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705250#comment-17705250
]
Natan Abolafya commented on DIRAPI-387:
---
Awesome! Thank you very much.
> More info on PasswordException
> --
>
> Key: DIRAPI-387
> URL: https://issues.apache.org/jira/browse/DIRAPI-387
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Natan Abolafya
>Priority: Minor
> Attachments: debug.png
>
>
> It would be nice to get more info on PasswordException.
> Here is a response coming from Active Directory.
>
> {code:java}
> Message ID : 7
> BindResponse
> Ldap Result
> Result code : (INVALID_CREDENTIALS) invalidCredentials
> Matched Dn : ''
> Diagnostic message : '80090308: LdapErr: DSID-0C090446, comment:
> AcceptSecurityContext error, data 533, v4563 '
> ){code}
>
>
> The information in Diagnostic message can be quite useful sometimes. In this
> case, the "data 533" means the account is disabled which would be quite
> useful information for diagnostics. I am attaching how the exception looks
> like on debugger also.
>
> Normal LdapExceptions have this information but not the PasswordException. It
> would be really nice to add it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-387) More info on PasswordException
[
https://issues.apache.org/jira/browse/DIRAPI-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705236#comment-17705236
]
Natan Abolafya commented on DIRAPI-387:
---
When I run the test, I can see this message in the logs however.
Message ID : 7
BindResponse
Ldap Result
Result code : (INVALID_CREDENTIALS) invalidCredentials
Matched Dn : ''
Diagnostic message : '80090308: LdapErr: DSID-0C090446, comment:
AcceptSecurityContext error, data 533, v4563 ')
Could it be that this message is received in the wrong thread/scope or
something like that?
> More info on PasswordException
> --
>
> Key: DIRAPI-387
> URL: https://issues.apache.org/jira/browse/DIRAPI-387
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Natan Abolafya
>Priority: Minor
> Attachments: debug.png
>
>
> It would be nice to get more info on PasswordException.
> Here is a response coming from Active Directory.
>
> {code:java}
> Message ID : 7
> BindResponse
> Ldap Result
> Result code : (INVALID_CREDENTIALS) invalidCredentials
> Matched Dn : ''
> Diagnostic message : '80090308: LdapErr: DSID-0C090446, comment:
> AcceptSecurityContext error, data 533, v4563 '
> ){code}
>
>
> The information in Diagnostic message can be quite useful sometimes. In this
> case, the "data 533" means the account is disabled which would be quite
> useful information for diagnostics. I am attaching how the exception looks
> like on debugger also.
>
> Normal LdapExceptions have this information but not the PasswordException. It
> would be really nice to add it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRAPI-387) More info on PasswordException
[
https://issues.apache.org/jira/browse/DIRAPI-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705220#comment-17705220
]
Natan Abolafya edited comment on DIRAPI-387 at 3/27/23 7:33 AM:
{code:java}
org.apache.directory.ldap.client.template.exception.PasswordException
at
org.apache.directory.ldap.client.template.AbstractPasswordPolicyResponder.fail(AbstractPasswordPolicyResponder.java:80)
at
org.apache.directory.ldap.client.template.AbstractPasswordPolicyResponder.process(AbstractPasswordPolicyResponder.java:121)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticateConnection(LdapConnectionTemplate.java:228)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticate(LdapConnectionTemplate.java:212)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticate(LdapConnectionTemplate.java:198)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticate(LdapConnectionTemplate.java:171)
..our code
{code}
was (Author: natan.abolafya):
{code:java}
org.apache.directory.ldap.client.template.exception.PasswordException
at
org.apache.directory.ldap.client.template.AbstractPasswordPolicyResponder.fail(AbstractPasswordPolicyResponder.java:80)
at
org.apache.directory.ldap.client.template.AbstractPasswordPolicyResponder.process(AbstractPasswordPolicyResponder.java:121)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticateConnection(LdapConnectionTemplate.java:228)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticate(LdapConnectionTemplate.java:212)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticate(LdapConnectionTemplate.java:198)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticate(LdapConnectionTemplate.java:171)
..our code
{code}
> More info on PasswordException
> --
>
> Key: DIRAPI-387
> URL: https://issues.apache.org/jira/browse/DIRAPI-387
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Natan Abolafya
>Priority: Minor
> Attachments: debug.png
>
>
> It would be nice to get more info on PasswordException.
> Here is a response coming from Active Directory.
>
> {code:java}
> Message ID : 7
> BindResponse
> Ldap Result
> Result code : (INVALID_CREDENTIALS) invalidCredentials
> Matched Dn : ''
> Diagnostic message : '80090308: LdapErr: DSID-0C090446, comment:
> AcceptSecurityContext error, data 533, v4563 '
> ){code}
>
>
> The information in Diagnostic message can be quite useful sometimes. In this
> case, the "data 533" means the account is disabled which would be quite
> useful information for diagnostics. I am attaching how the exception looks
> like on debugger also.
>
> Normal LdapExceptions have this information but not the PasswordException. It
> would be really nice to add it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-387) More info on PasswordException
[
https://issues.apache.org/jira/browse/DIRAPI-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705220#comment-17705220
]
Natan Abolafya commented on DIRAPI-387:
---
{code:java}
org.apache.directory.ldap.client.template.exception.PasswordException
at
org.apache.directory.ldap.client.template.AbstractPasswordPolicyResponder.fail(AbstractPasswordPolicyResponder.java:80)
at
org.apache.directory.ldap.client.template.AbstractPasswordPolicyResponder.process(AbstractPasswordPolicyResponder.java:121)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticateConnection(LdapConnectionTemplate.java:228)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticate(LdapConnectionTemplate.java:212)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticate(LdapConnectionTemplate.java:198)
at
org.apache.directory.ldap.client.template.LdapConnectionTemplate.authenticate(LdapConnectionTemplate.java:171)
..our code
{code}
> More info on PasswordException
> --
>
> Key: DIRAPI-387
> URL: https://issues.apache.org/jira/browse/DIRAPI-387
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Natan Abolafya
>Priority: Minor
> Attachments: debug.png
>
>
> It would be nice to get more info on PasswordException.
> Here is a response coming from Active Directory.
>
> {code:java}
> Message ID : 7
> BindResponse
> Ldap Result
> Result code : (INVALID_CREDENTIALS) invalidCredentials
> Matched Dn : ''
> Diagnostic message : '80090308: LdapErr: DSID-0C090446, comment:
> AcceptSecurityContext error, data 533, v4563 '
> ){code}
>
>
> The information in Diagnostic message can be quite useful sometimes. In this
> case, the "data 533" means the account is disabled which would be quite
> useful information for diagnostics. I am attaching how the exception looks
> like on debugger also.
>
> Normal LdapExceptions have this information but not the PasswordException. It
> would be really nice to add it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-387) More info on PasswordException
[
https://issues.apache.org/jira/browse/DIRAPI-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705209#comment-17705209
]
Natan Abolafya commented on DIRAPI-387:
---
Hi! Thanks Emmanuel.
Yes, that's normally the case when we get an *LdapException* but not the case
in {*}PasswordException{*}. It has an *ldapException* field but it is null. At
least as far as I can see. Check the debug screenshot I have attached on the
issue.
> More info on PasswordException
> --
>
> Key: DIRAPI-387
> URL: https://issues.apache.org/jira/browse/DIRAPI-387
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Natan Abolafya
>Priority: Minor
> Attachments: debug.png
>
>
> It would be nice to get more info on PasswordException.
> Here is a response coming from Active Directory.
>
> {code:java}
> Message ID : 7
> BindResponse
> Ldap Result
> Result code : (INVALID_CREDENTIALS) invalidCredentials
> Matched Dn : ''
> Diagnostic message : '80090308: LdapErr: DSID-0C090446, comment:
> AcceptSecurityContext error, data 533, v4563 '
> ){code}
>
>
> The information in Diagnostic message can be quite useful sometimes. In this
> case, the "data 533" means the account is disabled which would be quite
> useful information for diagnostics. I am attaching how the exception looks
> like on debugger also.
>
> Normal LdapExceptions have this information but not the PasswordException. It
> would be really nice to add it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-387) More info on PasswordException
[
https://issues.apache.org/jira/browse/DIRAPI-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17651219#comment-17651219
]
Natan Abolafya commented on DIRAPI-387:
---
I am either really bad at Jira or I don't have edit rights. I just realized the
issue lacks this context:
The PasswordException in this case is triggered by
*LdapConnectionTemplate.authenticate* call.
> More info on PasswordException
> --
>
> Key: DIRAPI-387
> URL: https://issues.apache.org/jira/browse/DIRAPI-387
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Natan Abolafya
>Priority: Minor
> Attachments: debug.png
>
>
> It would be nice to get more info on PasswordException.
> Here is a response coming from Active Directory.
>
> {code:java}
> Message ID : 7
> BindResponse
> Ldap Result
> Result code : (INVALID_CREDENTIALS) invalidCredentials
> Matched Dn : ''
> Diagnostic message : '80090308: LdapErr: DSID-0C090446, comment:
> AcceptSecurityContext error, data 533, v4563 '
> ){code}
>
>
> The information in Diagnostic message can be quite useful sometimes. In this
> case, the "data 533" means the account is disabled which would be quite
> useful information for diagnostics. I am attaching how the exception looks
> like on debugger also.
>
> Normal LdapExceptions have this information but not the PasswordException. It
> would be really nice to add it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-387) More info on PasswordException
Natan Abolafya created DIRAPI-387:
-
Summary: More info on PasswordException
Key: DIRAPI-387
URL: https://issues.apache.org/jira/browse/DIRAPI-387
Project: Directory Client API
Issue Type: Improvement
Reporter: Natan Abolafya
Attachments: debug.png
It would be nice to get more info on PasswordException.
Here is a response coming from Active Directory.
{code:java}
Message ID : 7
BindResponse
Ldap Result
Result code : (INVALID_CREDENTIALS) invalidCredentials
Matched Dn : ''
Diagnostic message : '80090308: LdapErr: DSID-0C090446, comment:
AcceptSecurityContext error, data 533, v4563 '
){code}
The information in Diagnostic message can be quite useful sometimes. In this
case, the "data 533" means the account is disabled which would be quite useful
information for diagnostics. I am attaching how the exception looks like on
debugger also.
Normal LdapExceptions have this information but not the PasswordException. It
would be really nice to add it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-337) ClosedSelectorException while searching through LDAP
[ https://issues.apache.org/jira/browse/DIRAPI-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204815#comment-17204815 ] Natan Abolafya commented on DIRAPI-337: --- I get this sometimes when I call _LdapConnectionPool.close()._ Couldn't figure out any pattern on that but it's probably what you said. Connection is already closed by the remote server. But I think the way the library handles this can be improved. The exception occurs on a standalone thread and provides no way to handle it as it's not delegated anywhere. So it ends up on a `DefaultExceptionMonitor`, polluting the logs. > ClosedSelectorException while searching through LDAP > > > Key: DIRAPI-337 > URL: https://issues.apache.org/jira/browse/DIRAPI-337 > Project: Directory Client API > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Dom Gibson >Priority: Major > > Getting the below stack trace several times randomly while searching through > LDAP. > > java.nio.channels.ClosedSelectorException: null > at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source) ~[na:1.8.0_171] > at sun.nio.ch.SelectorImpl.select(Unknown Source) ~[na:1.8.0_171] > at > org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:98) > ~[mina-core-2.0.16.jar!/:na] > at > org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1075) > ~[mina-core-2.0.16.jar!/:na] > at > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) > [mina-core-2.0.16.jar!/:na] > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > [na:1.8.0_171] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > [na:1.8.0_171] > at java.lang.Thread.run(Unknown Source) [na:1.8.0_171] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-69) API does not allow StartTLS hostname verification
[ https://issues.apache.org/jira/browse/DIRAPI-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127374#comment-17127374 ] Natan Abolafya commented on DIRAPI-69: -- Hi Daniel. Thanks for getting back. Yeah, I spent quite a bit of time on that idea first and did check ldaptive code also. But I don't think DIRAPI is passing the right object with the necessary details to the TrustManagers. I don't remember the exactly, but I think the passed *SSLSession* object wasn't an *ExtendedSSLSession* and *getPeerHost()* returned *null*. > API does not allow StartTLS hostname verification > - > > Key: DIRAPI-69 > URL: https://issues.apache.org/jira/browse/DIRAPI-69 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 1.0.0-M9 >Reporter: Daniel Fisher >Assignee: Pierre-Arnaud Marcelot >Priority: Major > Fix For: 3.0.0 > > > The current API does not have any features for controlling hostname > verification. In addition, it appears that *no* hostname verification occurs > by default. See RFC 2830 section 3.6 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-69) API does not allow StartTLS hostname verification
[
https://issues.apache.org/jira/browse/DIRAPI-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123958#comment-17123958
]
Natan Abolafya commented on DIRAPI-69:
--
Well, just realized that I had the hostname already while creating
LdapConnectionConfig object. So creating a specific TrustManager for that and
verifying the hostname should do fine. But if there is any better way to do it,
please let me know.
{color:#00}TrustManagerFactory tmf {color}=
{color:#00}TrustManagerFactory{color}.getInstance({color:#00}TrustManagerFactory{color}.getDefaultAlgorithm());
{color:#00}tmf{color}.init(({color:#00}KeyStore{color})
{color:#0033b3}null{color});
{color:#00}TrustManager{color}[]
{color:#00}trustManagersWithHostnameVerification {color}=
{color:#00}Arrays{color}.stream({color:#00}tmf{color}.getTrustManagers()).map(tm
-> {
{color:#0033b3}if {color}(tm {color:#0033b3}instanceof
{color}{color:#00}X509ExtendedTrustManager{color}) {
{color:#0033b3}return new
{color}{color:#00}X509ExtendedTrustManager{color}() {
{color:#0033b3}private final {color}{color:#00}X509ExtendedTrustManager
{color}{color:#871094}trustManager {color}=
({color:#00}X509ExtendedTrustManager{color}) {color:#851691}tm{color};
{color:#8c8c8c}// Use apache http client hostname verifier
{color} {color:#0033b3}private final
{color}{color:#00}DefaultHostnameVerifier
{color}{color:#871094}hostnameVerifier {color}= {color:#0033b3}new
{color}DefaultHostnameVerifier();
{color:#0033b3}private final {color}{color:#00}String
{color}{color:#871094}ldapHostname {color}= {color:#851691}hostname{color};
{color:#9e880d}@Override
{color} {color:#0033b3}public void
{color}{color:#00627a}checkClientTrusted{color}({color:#00}X509Certificate{color}[]
chain, {color:#00}String {color}authType, {color:#00}Socket
{color}socket) {color:#0033b3}throws {color}{color:#00}CertificateException
{color}{
{color:#871094}trustManager{color}.checkClientTrusted(chain, authType, socket);
}
{color:#9e880d}@Override
{color} {color:#0033b3}public void
{color}{color:#00627a}checkServerTrusted{color}({color:#00}X509Certificate{color}[]
chain, {color:#00}String {color}authType, {color:#00}Socket
{color}socket) {color:#0033b3}throws {color}{color:#00}CertificateException
{color}{
{color:#871094}trustManager{color}.checkServerTrusted(chain, authType, socket);
}
{color:#9e880d}@Override
{color} {color:#0033b3}public void
{color}{color:#00627a}checkClientTrusted{color}({color:#00}X509Certificate{color}[]
chain, {color:#00}String {color}authType, {color:#00}SSLEngine
{color}engine) {color:#0033b3}throws {color}{color:#00}CertificateException
{color}{
{color:#871094}trustManager{color}.checkClientTrusted(chain, authType, engine);
}
{color:#9e880d}@Override
{color} {color:#0033b3}public void
{color}{color:#00627a}checkServerTrusted{color}({color:#00}X509Certificate{color}[]
chain, {color:#00}String {color}authType, {color:#00}SSLEngine
{color}engine) {color:#0033b3}throws {color}{color:#00}CertificateException
{color}{
{color:#871094}trustManager{color}.checkServerTrusted(chain, authType, engine);
{color:#0033b3}try {color}{
{color:#871094}hostnameVerifier{color}.verify({color:#871094}ldapHostname{color},
chain[{color:#1750eb}0{color}]);
} {color:#0033b3}catch {color}({color:#00}SSLException {color}e) {
{color:#0033b3}throw new {color}CertificateException(e.getMessage(), e);
}
}
{color:#9e880d}@Override
{color} {color:#0033b3}public void
{color}{color:#00627a}checkClientTrusted{color}({color:#00}X509Certificate{color}[]
chain, {color:#00}String {color}authType) {color:#0033b3}throws
{color}{color:#00}CertificateException {color}{
{color:#871094}trustManager{color}.checkClientTrusted(chain, authType);
}
{color:#9e880d}@Override
{color} {color:#0033b3}public void
{color}{color:#00627a}checkServerTrusted{color}({color:#00}X509Certificate{color}[]
chain, {color:#00}String {color}authType) {color:#0033b3}throws
{color}{color:#00}CertificateException {color}{
{color:#871094}trustManager{color}.checkServerTrusted(chain, authType);
}
{color:#9e880d}@Override
{color} {color:#0033b3}public {color}{color:#00}X509Certificate{color}[]
{color:#00627a}getAcceptedIssuers{color}() {
{color:#0033b3}return
{color}{color:#871094}trustManager{color}.getAcceptedIssuers();
}
};
}
{color:#0033b3}return {color}tm;
}).toArray({color:#00}TrustManager{color}[]::{color:#0033b3}new{color});
{color:#00}config{color}.setTrustManagers({color:#00}trustManagersWithHostnameVerification{color});
> API does not allow StartTLS hostname verification
> -
>
> Key: DIRAPI-69
> URL: https://issues.apache.org/jira/browse/DIRAPI-69
>
[jira] [Comment Edited] (DIRAPI-69) API does not allow StartTLS hostname verification
[
https://issues.apache.org/jira/browse/DIRAPI-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123912#comment-17123912
]
Natan Abolafya edited comment on DIRAPI-69 at 6/2/20, 3:08 PM:
---
Hi,
I noticed the issue now, 8 years after it was reported :). It's non-negotiable
for us to not have hostname verification so I've been looking to work around it
but didn't manage yet. When I create my own TrustManager and debug it, I see it
lands in
{color:#9e880d}@Override{color}{color:#0033b3}public void
{color}{color:#00627a}checkServerTrusted{color}({color:#00}X509Certificate{color}[]
chain, {color:#00}String {color}authType, {color:#00}SSLEngine
{color}engine) {color:#0033b3}throws {color}{color:#00}CertificateException
{color}{
But the SSLEngine object is not something I managed to verify. I can't find
neither the hostname/ip used nor the certificates in it.
Do you have any tips to work with this?
Relevant: [https://xkcd.com/979/]
Thanks.
was (Author: natan.abolafya):
Hi,
I noticed the issue now, 8 years after it was reported :). It's non-negotiable
for us to not have hostname verification so I've been looking to work around it
but didn't manage yet. When I create my own TrustManager and debug it, I see it
lands in
{color:#9e880d}@Override
{color}{color:#0033b3}public void
{color}{color:#00627a}checkServerTrusted{color}({color:#00}X509Certificate{color}[]
chain, {color:#00}String {color}authType, {color:#00}SSLEngine
{color}engine) {color:#0033b3}throws {color}{color:#00}CertificateException
{color}{
But the SSLEngine object is not something I managed to verify. I can't find
neither the hostname/ip used nor the certificates in it.
Do you have any tips to work with this? https://xkcd.com/979/
Thanks.
> API does not allow StartTLS hostname verification
> -
>
> Key: DIRAPI-69
> URL: https://issues.apache.org/jira/browse/DIRAPI-69
> Project: Directory Client API
> Issue Type: Improvement
>Affects Versions: 1.0.0-M9
>Reporter: Daniel Fisher
>Assignee: Pierre-Arnaud Marcelot
>Priority: Major
> Fix For: 3.0.0
>
>
> The current API does not have any features for controlling hostname
> verification. In addition, it appears that *no* hostname verification occurs
> by default. See RFC 2830 section 3.6
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-69) API does not allow StartTLS hostname verification
[
https://issues.apache.org/jira/browse/DIRAPI-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123912#comment-17123912
]
Natan Abolafya commented on DIRAPI-69:
--
Hi,
I noticed the issue now, 8 years after it was reported :). It's non-negotiable
for us to not have hostname verification so I've been looking to work around it
but didn't manage yet. When I create my own TrustManager and debug it, I see it
lands in
{color:#9e880d}@Override
{color}{color:#0033b3}public void
{color}{color:#00627a}checkServerTrusted{color}({color:#00}X509Certificate{color}[]
chain, {color:#00}String {color}authType, {color:#00}SSLEngine
{color}engine) {color:#0033b3}throws {color}{color:#00}CertificateException
{color}{
But the SSLEngine object is not something I managed to verify. I can't find
neither the hostname/ip used nor the certificates in it.
Do you have any tips to work with this? https://xkcd.com/979/
Thanks.
> API does not allow StartTLS hostname verification
> -
>
> Key: DIRAPI-69
> URL: https://issues.apache.org/jira/browse/DIRAPI-69
> Project: Directory Client API
> Issue Type: Improvement
>Affects Versions: 1.0.0-M9
>Reporter: Daniel Fisher
>Assignee: Pierre-Arnaud Marcelot
>Priority: Major
> Fix For: 3.0.0
>
>
> The current API does not have any features for controlling hostname
> verification. In addition, it appears that *no* hostname verification occurs
> by default. See RFC 2830 section 3.6
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-358) File Descriptor leak on connection failure with LdapConnectionTemplate
[
https://issues.apache.org/jira/browse/DIRAPI-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102377#comment-17102377
]
Natan Abolafya commented on DIRAPI-358:
---
I have tried 2.0.1 and it's the same unfortunately.
The limit assigned by the default Ubuntu, 1024. In normal cases the connection
limit is not causing any issues on heavy load either. But when there is a leak
on connection failure, that's a different situation.
I didn't have time to create a minimal reproducing application unfortunately,
so I'm using our application which has its own connections here and there. Here
are the extra file descriptors after aI make two attempts to a non existing
LDAP server.
{quote}java 19710 czd-ca 232u a_inode 0,14 0 12414 [eventpoll]
java 19710 czd-ca 233r FIFO 0,13 0t0 4871838 pipe
java 19710 czd-ca 234w FIFO 0,13 0t0 4871838 pipe
java 19710 czd-ca 235u a_inode 0,14 0 12414 [eventpoll]
java 19710 czd-ca 236r FIFO 0,13 0t0 4871839 pipe
java 19710 czd-ca 237w FIFO 0,13 0t0 4871839 pipe
java 19710 czd-ca 238u a_inode 0,14 0 12414 [eventpoll]
java 19710 czd-ca 239r FIFO 0,13 0t0 4871840 pipe
java 19710 czd-ca 240w FIFO 0,13 0t0 4871840 pipe
java 19710 czd-ca 241u IPv6 4871846 0t0 TCP
10.97.159.42:33974->172.17.40.29:ldap (SYN_SENT)
java 19710 czd-ca 242u a_inode 0,14 0 12414 [eventpoll]
java 19710 czd-ca 243r FIFO 0,13 0t0 4871842 pipe
java 19710 czd-ca 244w FIFO 0,13 0t0 4871842 pipe
java 19710 czd-ca 245u IPv6 4871847 0t0 TCP
10.97.159.42:33976->172.17.40.29:ldap (SYN_SENT)
{quote}
And this is after some 10-20 seconds
{quote}java 19710 czd-ca 232u a_inode 0,14 0 12414 [eventpoll]
java 19710 czd-ca 233r FIFO 0,13 0t0 4871838 pipe
java 19710 czd-ca 234w FIFO 0,13 0t0 4871838 pipe
java 19710 czd-ca 235u a_inode 0,14 0 12414 [eventpoll]
java 19710 czd-ca 236r FIFO 0,13 0t0 4871839 pipe
java 19710 czd-ca 237w FIFO 0,13 0t0 4871839 pipe
java 19710 czd-ca 238u a_inode 0,14 0 12414 [eventpoll]
java 19710 czd-ca 239r FIFO 0,13 0t0 4871840 pipe
java 19710 czd-ca 240w FIFO 0,13 0t0 4871840 pipe
java 19710 czd-ca 242u a_inode 0,14 0 12414 [eventpoll]
java 19710 czd-ca 243r FIFO 0,13 0t0 4871842 pipe
java 19710 czd-ca 244w FIFO 0,13 0t0 4871842 pipe
{quote}
> File Descriptor leak on connection failure with LdapConnectionTemplate
> --
>
> Key: DIRAPI-358
> URL: https://issues.apache.org/jira/browse/DIRAPI-358
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.0.0.AM4, 2.0.0, 2.0.1
>Reporter: Natan Abolafya
>Priority: Major
>
> Seems to have appeared on AM4.
>
> We had two instances crashing after half an hour outage on the LDAP server
> because the process ran out of file descriptor limit.
>
>
> {noformat}
> var template = createLdapConnectionTemplate();
> template.searchFirst();
> {noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-358) File Descriptor leak on connection failure with LdapConnectionTemplate
[
https://issues.apache.org/jira/browse/DIRAPI-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101785#comment-17101785
]
Natan Abolafya commented on DIRAPI-358:
---
Oh, sorry, I thought it would be clear enough and more concise this way. I'm
newbie to Jira so not sure if it's because I can't find how to edit the
description or it's not allowed. So I guess I'll paste how we generate the
template here:
{quote}{color:#00}LdapConnectionConfig config {color}= {color:#0033b3}new
{color}LdapConnectionConfig();
{color:#00}config{color}.setTimeout({color:#00}1{color});
{color:#00}config{color}.setLdapHost({color:#00}hostname{color});
{color:#00}config{color}.setLdapPort(port);
{color:#00}config{color}.setUseSsl(sslEnabled);{color:#8c8c8c}
{color}{color:#00}config{color}.setName(adminUsername);
{color:#00}config{color}.setCredentials(adminPassword);
// Use java's trust manager
{color:#00}TrustManagerFactory tmf {color}=
{color:#00}TrustManagerFactory{color}.getInstance({color:#00}TrustManagerFactory{color}.getDefaultAlgorithm());
{color:#00}tmf{color}.init(({color:#00}KeyStore{color})
{color:#0033b3}null{color});
{color:#00}config{color}.setTrustManagers({color:#00}tmf{color}.getTrustManagers());
{color:#00}DefaultLdapConnectionFactory connectionFactory {color}=
{color:#0033b3}new
{color}DefaultLdapConnectionFactory({color:#00}config{color});
{color:#00}connectionFactory{color}.setTimeOut({color:#00}1{color});
{color:#00}GenericObjectPoolConfig poolConfig {color}= {color:#0033b3}new
{color}GenericObjectPoolConfig();
{color:#00}poolConfig{color}.setMaxTotal({color:#1750eb}64{color});
{color:#00}poolConfig{color}.setTestOnBorrow({color:#0033b3}true{color});
{color:#00}poolConfig{color}.setTimeBetweenEvictionRunsMillis({color:#1750eb}30
{color}* {color:#1750eb}6{color}); {color:#8c8c8c}// Every thirty minutes,
idle connections will be cleaned up.
{color}{color:#00}poolConfig{color}.setMinEvictableIdleTimeMillis({color:#1750eb}2
{color}* {color:#1750eb}6{color}); {color:#8c8c8c}// the connections that
are idle for at least 2 minutes will be "evicted"
{color}{color:#00}poolConfig{color}.setNumTestsPerEvictionRun({color:#1750eb}64{color});
{color:#8c8c8c}// default is 3; go through them all.
{color}{color:#0033b3}var template = new
{color}LdapConnectionTemplate({color:#0033b3}new
{color}LdapConnectionPool({color:#0033b3}new
{color}ValidatingPoolableLdapConnectionFactory({color:#00}connectionFactory{color}),
{color:#00}poolConfig{color}));
template.searchFirst();
{quote}
Normally we store the template and reuse it and so on as it's designed to be
and it used to work fine on 2.0.0.AM2. The problem appeared when we upgraded to
AM4. Then I started testing different versions and it seems to be fine on AM3
also.
I did some simple testing to verify the problem. Ran this command to see how
many file descriptors our application has:
{color:#e01e5a}lsof -n -p | wc -l{color}
Then made the application connect to a random IP and fail a few times. Then ran
the command again to see how much increase has occurred. On AM3 and older, the
fd count went back to the original after some 10-20 seconds while on AM4 and
older, it never went back even when I left it overnight.
> File Descriptor leak on connection failure with LdapConnectionTemplate
> --
>
> Key: DIRAPI-358
> URL: https://issues.apache.org/jira/browse/DIRAPI-358
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.0.0.AM4, 2.0.0, 2.0.1
>Reporter: Natan Abolafya
>Priority: Major
>
> Seems to have appeared on AM4.
>
> We had two instances crashing after half an hour outage on the LDAP server
> because the process ran out of file descriptor limit.
>
>
> {noformat}
> var template = createLdapConnectionTemplate();
> template.searchFirst();
> {noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-358) File Descriptor leak on connection failure with LdapConnectionTemplate
Natan Abolafya created DIRAPI-358:
-
Summary: File Descriptor leak on connection failure with
LdapConnectionTemplate
Key: DIRAPI-358
URL: https://issues.apache.org/jira/browse/DIRAPI-358
Project: Directory Client API
Issue Type: Bug
Affects Versions: 2.0.0, 2.0.0.AM4, 2.0.1
Reporter: Natan Abolafya
Seems to have appeared on AM4.
We had two instances crashing after half an hour outage on the LDAP server
because the process ran out of file descriptor limit.
{noformat}
var template = createLdapConnectionTemplate();
template.searchFirst();
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-301) Ldaps connection trusts all certificates
Natan Abolafya created DIRAPI-301: - Summary: Ldaps connection trusts all certificates Key: DIRAPI-301 URL: https://issues.apache.org/jira/browse/DIRAPI-301 Project: Directory Client API Issue Type: Bug Affects Versions: 1.0.0-RC3 Environment: Windows 10 & Ubuntu 14.04 Reporter: Natan Abolafya Thankfully we had an integration test for this, otherwise this is a major security issue. This was working as expected on 1.0.0-RC2 but as soon as I bumped to 1.0.0, the test started failing. "Affects version" says there is no 1.0.0 btw, but Maven disagrees. I don't know about the raw APIs but this happens when `LdapConnectionTemplate` is used. Thankfully I was able to work around it by assigning Java's default TrustManager. LdapConnectionConfig config = new LdapConnectionConfig(); TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); tmf.init((KeyStore) null); config.setTrustManagers(tmf.getTrustManagers()); ... DefaultLdapConnectionFactory connectionFactory = new DefaultLdapConnectionFactory(config); return new LdapConnectionTemplate(new LdapConnectionPool(new ValidatingPoolableLdapConnectionFactory(connectionFactory; -- This message was sent by Atlassian JIRA (v6.4.14#64029)
