[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=16811234#comment-16811234 ] Emmanuel Lecharny commented on DIRAPI-337: -- You seem to use LDAP API 1.0.0. Have you tried with 1.0.2 ? > 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 (v7.6.3#76005)
[jira] [Comment Edited] (DIRAPI-337) ClosedSelectorException while searching through LDAP
[ https://issues.apache.org/jira/browse/DIRAPI-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810769#comment-16810769 ] Dom Gibson edited comment on DIRAPI-337 at 4/5/19 12:43 PM: It's connecting to our internal windows AD controller. This is the only output related to the error and it appears multiple times throughout the search. There's no other errors or stacktraces in the log: 2019-04-05 04:07:54.372 WARN 4984 — [NioProcessor-43] o.a.mina.util.DefaultExceptionMonitor : Unexpected exception. 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] was (Author: dom.gibson): It's connecting to our internal windows AD controller. This is the only output related to the error. There's no other errors or stacktraces in the log: 2019-04-05 04:07:54.372 WARN 4984 --- [NioProcessor-43] o.a.mina.util.DefaultExceptionMonitor : Unexpected exception. 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] > 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 (v7.6.3#76005)
[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=16810769#comment-16810769 ] Dom Gibson commented on DIRAPI-337: --- It's connecting to our internal windows AD controller. This is the only output related to the error. There's no other errors or stacktraces in the log: 2019-04-05 04:07:54.372 WARN 4984 --- [NioProcessor-43] o.a.mina.util.DefaultExceptionMonitor : Unexpected exception. 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] > 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 (v7.6.3#76005)
[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=16810753#comment-16810753 ] Emmanuel Lecharny commented on DIRAPI-337: -- Any logs ? Which server are you connecting to ? > 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 (v7.6.3#76005)
[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=16810741#comment-16810741
]
Dom Gibson commented on DIRAPI-337:
---
This is occurring while I'm paging through a search, the connection isn't being
closed on my end
See below
{code:java}
while (true) {
SearchRequest req = new SearchRequestImpl();
req.setBase(new Dn(rootDn));
req.setFilter("(objectclass=user)");
req.setScope(SearchScope.SUBTREE);
req.addAttributes(atts);
req.addControl(pagedSearchControl);
log.debug("Searching for all users on domain: {}", rootDn);
try (SearchCursor searchCursor = connection.search(req)) {
while (searchCursor.next()) {
Response response = searchCursor.get();
// process the SearchResultEntry
if (response instanceof SearchResultEntry) {
Entry entry = ((SearchResultEntry)
response).getEntry();
if (entry != null) {
log.trace("Checking user: {}", entry);
processUserEntry(connection, entry,
dbSpmIds);
}
}
}
SearchResultDone result = searchCursor.getSearchResultDone();
pagedSearchControl = (PagedResults)
result.getControl(PagedResults.OID);
if (result.getLdapResult().getResultCode() ==
ResultCodeEnum.UNWILLING_TO_PERFORM) {
log.warn("LDAP Server does not handle paging");
return;
}
} catch (CursorException e) {
log.error("{}", e.getMessage());
}
byte[] cookie = pagedSearchControl.getCookie();
if (Strings.isEmpty(cookie)) {
// If so, exit the loop
break;
}
// Prepare the next iteration
pagedSearchControl.setSize(1000);
}
{code}
> 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
(v7.6.3#76005)
[jira] [Commented] (DIRSTUDIO-1220) Directory Studio doesn't use the SASL confidentiality layer after negotiating its use
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810706#comment-16810706 ] Hugh Cole-Baker commented on DIRSTUDIO-1220: I should add that on Mac, I have JNDI available as an alternative choice for the API, but I have a colleague on Linux who does not have that option in Directory Studio - I think because he's using Java 11 and JNDI was disabled in Java 9+ (DIRSTUDIO-1187). So I would like to find a solution for using Apache LDAP API with our LDAP server. > Directory Studio doesn't use the SASL confidentiality layer after negotiating > its use > - > > Key: DIRSTUDIO-1220 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1220 > Project: Directory Studio > Issue Type: Bug > Components: studio-connection > Environment: Apache Directory Studio is running on Mac OS 10.14 with > jdk1.8.0_201. >Reporter: Hugh Cole-Baker >Priority: Major > > There is an issue connecting to an OpenLDAP server configured with > olcSaslSecProps: noplain,noanonymous,minssf=1 > i.e. The server requires some form of transport encryption. Having a > different issue with StartTLS (DIRSTUDIO-1219), I tried relying on the SASL > confidentiality layer that SASL's GSSAPI mechanism can provide, to meet the > requirement for encryption. I have chosen "No encryption" i.e. no SSL or > StartTLS, in the Network Parameters, and then GSSAPI authentication method > and Quality of Protection: Authentication with integrity and privacy > protection in the SASL settings. > When connecting to the server, what I can see happening when looking at the > network traffic with Wireshark is: > # Client obtains a Kerberos service ticket for the LDAP server and passes it > in the bind request for SASL GSSAPI authentication > # Server replies with a bind response, continuing SASL GSSAPI > authentication, result code 14 (SASL bind in progress), with a 4 byte message > wrapped using GSS_Wrap. The 4 bytes are 0x06 0x01 0x00 0x00 - referring to > RFC4752, the first byte indicates the server supports "Integrity protection" > and/or "Confidentiality protection" but not "No security layer", as expected. > # Client replies with a bind request, continuing SASL GSSAPI authentication, > with a 4 byte message wrapped using GSS_Wrap. The 4 bytes are 0x04 0x01 0x00 > 0x00 - again referring to RFC4752, the first byte indicates the client has > selected "Confidentiality protection". > # Server replies with a bind response with result code 0 (success). > # Client sends a search request with base DN: "", scope: base, filter: > (objectClass=*), for attributes: subschemaSubentry, **with no confidentiality > protection**. This is the point where the client violates the protocol > described in RFC4752 - after negotiating confidentiality protection, the > client needs to actually use it! > # Server interprets the lack of confidentiality protection as an error and > immediately drops the connection (this makes sense from the server's POV as > it could indicate an attempted man-in-the-middle attack) > # Client immediately re-connects to the server, **doesn't bother to bind at > all** and then issues more search requests on the base object, cn=Subschema, > etc. > # An error message appears in Directory Studio "Error while opening > connection > - Missing schema location in RootDSE, using default schema" - this is > presumably because the connection isn't bound, and the server limits what it > will disclose to un-bound clients. > # Directory Studio can't browse the directory at all because it's not > properly bound. > As you can see, there's possibly two issues here - definitely an issue with > the SASL GSSAPI mechanism, and possibly also an issue with the reconnect > logic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DIRSTUDIO-1220) Directory Studio doesn't use the SASL confidentiality layer after negotiating its use
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810693#comment-16810693 ] Hugh Cole-Baker commented on DIRSTUDIO-1220: I'm using the Apache LDAP API. If I keep all other settings the same but change the API to use JNDI, the issue doesn't occur and I can connect successfully. With JNDI I can see in the network traffic that all packets after the successful SASL GSSAPI "handshake" are protected with SASL GSSAPI confidentiality protection, as expected. > Directory Studio doesn't use the SASL confidentiality layer after negotiating > its use > - > > Key: DIRSTUDIO-1220 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1220 > Project: Directory Studio > Issue Type: Bug > Components: studio-connection > Environment: Apache Directory Studio is running on Mac OS 10.14 with > jdk1.8.0_201. >Reporter: Hugh Cole-Baker >Priority: Major > > There is an issue connecting to an OpenLDAP server configured with > olcSaslSecProps: noplain,noanonymous,minssf=1 > i.e. The server requires some form of transport encryption. Having a > different issue with StartTLS (DIRSTUDIO-1219), I tried relying on the SASL > confidentiality layer that SASL's GSSAPI mechanism can provide, to meet the > requirement for encryption. I have chosen "No encryption" i.e. no SSL or > StartTLS, in the Network Parameters, and then GSSAPI authentication method > and Quality of Protection: Authentication with integrity and privacy > protection in the SASL settings. > When connecting to the server, what I can see happening when looking at the > network traffic with Wireshark is: > # Client obtains a Kerberos service ticket for the LDAP server and passes it > in the bind request for SASL GSSAPI authentication > # Server replies with a bind response, continuing SASL GSSAPI > authentication, result code 14 (SASL bind in progress), with a 4 byte message > wrapped using GSS_Wrap. The 4 bytes are 0x06 0x01 0x00 0x00 - referring to > RFC4752, the first byte indicates the server supports "Integrity protection" > and/or "Confidentiality protection" but not "No security layer", as expected. > # Client replies with a bind request, continuing SASL GSSAPI authentication, > with a 4 byte message wrapped using GSS_Wrap. The 4 bytes are 0x04 0x01 0x00 > 0x00 - again referring to RFC4752, the first byte indicates the client has > selected "Confidentiality protection". > # Server replies with a bind response with result code 0 (success). > # Client sends a search request with base DN: "", scope: base, filter: > (objectClass=*), for attributes: subschemaSubentry, **with no confidentiality > protection**. This is the point where the client violates the protocol > described in RFC4752 - after negotiating confidentiality protection, the > client needs to actually use it! > # Server interprets the lack of confidentiality protection as an error and > immediately drops the connection (this makes sense from the server's POV as > it could indicate an attempted man-in-the-middle attack) > # Client immediately re-connects to the server, **doesn't bother to bind at > all** and then issues more search requests on the base object, cn=Subschema, > etc. > # An error message appears in Directory Studio "Error while opening > connection > - Missing schema location in RootDSE, using default schema" - this is > presumably because the connection isn't bound, and the server limits what it > will disclose to un-bound clients. > # Directory Studio can't browse the directory at all because it's not > properly bound. > As you can see, there's possibly two issues here - definitely an issue with > the SASL GSSAPI mechanism, and possibly also an issue with the reconnect > logic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DIRSTUDIO-1211) UserCertificate attribute shown as Invalid Certificate if "Apache... Client API" is used
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810688#comment-16810688 ] Preben Nilsson commented on DIRSTUDIO-1211: --- Changing the network provider on the individual connection did the trick. ADS now shows me the certificates correctly. Thank you for your help [~david tarr] > UserCertificate attribute shown as Invalid Certificate if "Apache... Client > API" is used > > > Key: DIRSTUDIO-1211 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1211 > Project: Directory Studio > Issue Type: Bug >Reporter: David Tarr >Priority: Major > Attachments: Untitled.png, image-2019-03-19-09-41-44-289.png > > > In Apache Directory Studio, any userCertificate;binary attribute is shown as > "Invalid Certificate" if the provider "Apache Directory LDAP Client API" is > used. > If the provider "JNDI (Java...)" is used, the attribute is shown correctly. > I have this behaviour after upgrading to 2.0.0.v20180908-M14 from > 2.0.0.M13. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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=16810674#comment-16810674 ] Emmanuel Lecharny commented on DIRAPI-337: -- It just says that the Selector has been closed, which means the connection has been disposed. > 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 (v7.6.3#76005)
[jira] [Commented] (DIRSTUDIO-1220) Directory Studio doesn't use the SASL confidentiality layer after negotiating its use
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810664#comment-16810664 ] Lothar Haeger commented on DIRSTUDIO-1220: -- Which API do you use in that connection, JNDI or the Apache LDAP API (--> connection properties)? Does the issue occur with both of them or is it limited to one? > Directory Studio doesn't use the SASL confidentiality layer after negotiating > its use > - > > Key: DIRSTUDIO-1220 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1220 > Project: Directory Studio > Issue Type: Bug > Components: studio-connection > Environment: Apache Directory Studio is running on Mac OS 10.14 with > jdk1.8.0_201. >Reporter: Hugh Cole-Baker >Priority: Major > > There is an issue connecting to an OpenLDAP server configured with > olcSaslSecProps: noplain,noanonymous,minssf=1 > i.e. The server requires some form of transport encryption. Having a > different issue with StartTLS (DIRSTUDIO-1219), I tried relying on the SASL > confidentiality layer that SASL's GSSAPI mechanism can provide, to meet the > requirement for encryption. I have chosen "No encryption" i.e. no SSL or > StartTLS, in the Network Parameters, and then GSSAPI authentication method > and Quality of Protection: Authentication with integrity and privacy > protection in the SASL settings. > When connecting to the server, what I can see happening when looking at the > network traffic with Wireshark is: > # Client obtains a Kerberos service ticket for the LDAP server and passes it > in the bind request for SASL GSSAPI authentication > # Server replies with a bind response, continuing SASL GSSAPI > authentication, result code 14 (SASL bind in progress), with a 4 byte message > wrapped using GSS_Wrap. The 4 bytes are 0x06 0x01 0x00 0x00 - referring to > RFC4752, the first byte indicates the server supports "Integrity protection" > and/or "Confidentiality protection" but not "No security layer", as expected. > # Client replies with a bind request, continuing SASL GSSAPI authentication, > with a 4 byte message wrapped using GSS_Wrap. The 4 bytes are 0x04 0x01 0x00 > 0x00 - again referring to RFC4752, the first byte indicates the client has > selected "Confidentiality protection". > # Server replies with a bind response with result code 0 (success). > # Client sends a search request with base DN: "", scope: base, filter: > (objectClass=*), for attributes: subschemaSubentry, **with no confidentiality > protection**. This is the point where the client violates the protocol > described in RFC4752 - after negotiating confidentiality protection, the > client needs to actually use it! > # Server interprets the lack of confidentiality protection as an error and > immediately drops the connection (this makes sense from the server's POV as > it could indicate an attempted man-in-the-middle attack) > # Client immediately re-connects to the server, **doesn't bother to bind at > all** and then issues more search requests on the base object, cn=Subschema, > etc. > # An error message appears in Directory Studio "Error while opening > connection > - Missing schema location in RootDSE, using default schema" - this is > presumably because the connection isn't bound, and the server limits what it > will disclose to un-bound clients. > # Directory Studio can't browse the directory at all because it's not > properly bound. > As you can see, there's possibly two issues here - definitely an issue with > the SASL GSSAPI mechanism, and possibly also an issue with the reconnect > logic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DIRSTUDIO-1220) Directory Studio doesn't use the SASL confidentiality layer after negotiating its use
Hugh Cole-Baker created DIRSTUDIO-1220: -- Summary: Directory Studio doesn't use the SASL confidentiality layer after negotiating its use Key: DIRSTUDIO-1220 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1220 Project: Directory Studio Issue Type: Bug Components: studio-connection Environment: Apache Directory Studio is running on Mac OS 10.14 with jdk1.8.0_201. Reporter: Hugh Cole-Baker There is an issue connecting to an OpenLDAP server configured with olcSaslSecProps: noplain,noanonymous,minssf=1 i.e. The server requires some form of transport encryption. Having a different issue with StartTLS (DIRSTUDIO-1219), I tried relying on the SASL confidentiality layer that SASL's GSSAPI mechanism can provide, to meet the requirement for encryption. I have chosen "No encryption" i.e. no SSL or StartTLS, in the Network Parameters, and then GSSAPI authentication method and Quality of Protection: Authentication with integrity and privacy protection in the SASL settings. When connecting to the server, what I can see happening when looking at the network traffic with Wireshark is: # Client obtains a Kerberos service ticket for the LDAP server and passes it in the bind request for SASL GSSAPI authentication # Server replies with a bind response, continuing SASL GSSAPI authentication, result code 14 (SASL bind in progress), with a 4 byte message wrapped using GSS_Wrap. The 4 bytes are 0x06 0x01 0x00 0x00 - referring to RFC4752, the first byte indicates the server supports "Integrity protection" and/or "Confidentiality protection" but not "No security layer", as expected. # Client replies with a bind request, continuing SASL GSSAPI authentication, with a 4 byte message wrapped using GSS_Wrap. The 4 bytes are 0x04 0x01 0x00 0x00 - again referring to RFC4752, the first byte indicates the client has selected "Confidentiality protection". # Server replies with a bind response with result code 0 (success). # Client sends a search request with base DN: "", scope: base, filter: (objectClass=*), for attributes: subschemaSubentry, **with no confidentiality protection**. This is the point where the client violates the protocol described in RFC4752 - after negotiating confidentiality protection, the client needs to actually use it! # Server interprets the lack of confidentiality protection as an error and immediately drops the connection (this makes sense from the server's POV as it could indicate an attempted man-in-the-middle attack) # Client immediately re-connects to the server, **doesn't bother to bind at all** and then issues more search requests on the base object, cn=Subschema, etc. # An error message appears in Directory Studio "Error while opening connection - Missing schema location in RootDSE, using default schema" - this is presumably because the connection isn't bound, and the server limits what it will disclose to un-bound clients. # Directory Studio can't browse the directory at all because it's not properly bound. As you can see, there's possibly two issues here - definitely an issue with the SASL GSSAPI mechanism, and possibly also an issue with the reconnect logic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DIRSTUDIO-1219) Directory Studio doesn't StartTLS before authenticating
Hugh Cole-Baker created DIRSTUDIO-1219: -- Summary: Directory Studio doesn't StartTLS before authenticating Key: DIRSTUDIO-1219 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1219 Project: Directory Studio Issue Type: Bug Components: studio-connection Environment: Apache Directory Studio is running on Mac OS 10.14 with jdk1.8.0_201. Reporter: Hugh Cole-Baker There is an issue connecting to an OpenLDAP server configured with olcSaslSecProps: noplain,noanonymous,minssf=1 i.e. The server requires some form of transport encryption. I have chosen StartTLS and SASL GSSAPI authentication, but Directory Studio doesn't actually do StartTLS before binding - I can see this by looking at the network traffic using Wireshark. I would have expected it to start TLS before attempting to bind. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (DIRSTUDIO-1211) UserCertificate attribute shown as Invalid Certificate if "Apache... Client API" is used
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810616#comment-16810616 ] David Tarr edited comment on DIRSTUDIO-1211 at 4/5/19 8:38 AM: --- Hi Preben, If I change the Default Network Provider via Windows, Preferences, Connections-screen it also has no effect for me. But I think it's because this only sets whichever Network Provider should be used by default when creating a new Connection. If I change the Provider via the "Connections" view, right click any connection and choose "Properties", a Window is shown with the details for that particular connection. It also has a *Provider* configured for that connection: !Untitled.png|width=50%! Could you check what you get when switching the Provider? was (Author: david tarr): Hi Preben, If I change the Default Network Provider via Windows, Preferences, Connections-screen it also has no effect for me. But I think it's because this only sets whichever Network Provider should be used by default when creating a new Connection. If I change the Provider via the "Connections" view, right click any connection and choose "Properties", a Window is shown with the details for that particular connection. It also has a *Provider* configured for that connection: !Untitled.png|width=50! Could you check what you get when switching the Provider? > UserCertificate attribute shown as Invalid Certificate if "Apache... Client > API" is used > > > Key: DIRSTUDIO-1211 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1211 > Project: Directory Studio > Issue Type: Bug >Reporter: David Tarr >Priority: Major > Attachments: Untitled.png, image-2019-03-19-09-41-44-289.png > > > In Apache Directory Studio, any userCertificate;binary attribute is shown as > "Invalid Certificate" if the provider "Apache Directory LDAP Client API" is > used. > If the provider "JNDI (Java...)" is used, the attribute is shown correctly. > I have this behaviour after upgrading to 2.0.0.v20180908-M14 from > 2.0.0.M13. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DIRSTUDIO-1211) UserCertificate attribute shown as Invalid Certificate if "Apache... Client API" is used
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810616#comment-16810616 ] David Tarr commented on DIRSTUDIO-1211: --- Hi Preben, If I change the Default Network Provider via Windows, Preferences, Connections-screen it also has no effect for me. But I think it's because this only sets whichever Network Provider should be used by default when creating a new Connection. If I change the Provider via the "Connections" view, right click any connection and choose "Properties", a Window is shown with the details for that particular connection. It also has a *Provider* configured for that connection: !Untitled.png|width=50! Could you check what you get when switching the Provider? > UserCertificate attribute shown as Invalid Certificate if "Apache... Client > API" is used > > > Key: DIRSTUDIO-1211 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1211 > Project: Directory Studio > Issue Type: Bug >Reporter: David Tarr >Priority: Major > Attachments: Untitled.png, image-2019-03-19-09-41-44-289.png > > > In Apache Directory Studio, any userCertificate;binary attribute is shown as > "Invalid Certificate" if the provider "Apache Directory LDAP Client API" is > used. > If the provider "JNDI (Java...)" is used, the attribute is shown correctly. > I have this behaviour after upgrading to 2.0.0.v20180908-M14 from > 2.0.0.M13. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DIRSTUDIO-1211) UserCertificate attribute shown as Invalid Certificate if "Apache... Client API" is used
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Tarr updated DIRSTUDIO-1211: -- Attachment: Untitled.png > UserCertificate attribute shown as Invalid Certificate if "Apache... Client > API" is used > > > Key: DIRSTUDIO-1211 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1211 > Project: Directory Studio > Issue Type: Bug >Reporter: David Tarr >Priority: Major > Attachments: Untitled.png, image-2019-03-19-09-41-44-289.png > > > In Apache Directory Studio, any userCertificate;binary attribute is shown as > "Invalid Certificate" if the provider "Apache Directory LDAP Client API" is > used. > If the provider "JNDI (Java...)" is used, the attribute is shown correctly. > I have this behaviour after upgrading to 2.0.0.v20180908-M14 from > 2.0.0.M13. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DIRAPI-337) ClosedSelectorException while searching through LDAP
Dom Gibson created DIRAPI-337: - Summary: 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 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 (v7.6.3#76005)
