[jira] [Resolved] (DIRSTUDIO-1300) Use LookupTranslator instead of chained replace() calls
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann resolved DIRSTUDIO-1300.
Resolution: Fixed
> Use LookupTranslator instead of chained replace() calls
> ---
>
> Key: DIRSTUDIO-1300
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1300
> Project: Directory Studio
> Issue Type: Improvement
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
>Reporter: Fredrik Roubert
>Priority: Minor
> Fix For: 2.0.0-M18
>
>
> Using chained calls to {{String.replace()}} is simple but suboptimal, it'd be
> better to use the
> [LookupTranslator|https://commons.apache.org/proper/commons-text/javadocs/api-release/org/apache/commons/text/translate/LookupTranslator.html]
> from the commons-text library instead.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-933) Order search value history by creation date instead of alphabetically
[ https://issues.apache.org/jira/browse/DIRSTUDIO-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-933. --- Resolution: Fixed > Order search value history by creation date instead of alphabetically > - > > Key: DIRSTUDIO-933 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-933 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M17 >Reporter: Nabil Sayegh >Assignee: Lothar Haeger >Priority: Trivial > Labels: dropdownlist, history, search > Fix For: 2.0.0-M18 > > > The search value history shouldn't be sorted alphabetically but rather > historically, either by creation date or last use date -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1298) The RFC 4517 Postal Address value editor en-/decoding is incomplete
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1298. Resolution: Fixed Thanks [~roubert] for the PR > The RFC 4517 Postal Address value editor en-/decoding is incomplete > --- > > Key: DIRSTUDIO-1298 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1298 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M17 >Reporter: Fredrik Roubert >Priority: Major > Fix For: 2.0.0-M18 > > > The current implementation only handles newlines but not the other two > (dollar sign and backslash) character for which RFC 4517 specifies an > encoding, meaning that it can't handle addresses containing these characters. > These characters are rare in real life postal addresses (even though the RFC > contains a somewhat convincing example address) and this is probably the > reason for why no-one else has cared until now, but it would still be better > to implement the standard correctly than incompletely. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1298) The RFC 4517 Postal Address value editor en-/decoding is incomplete
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1298: --- Fix Version/s: 2.0.0-M18 > The RFC 4517 Postal Address value editor en-/decoding is incomplete > --- > > Key: DIRSTUDIO-1298 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1298 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M17 >Reporter: Fredrik Roubert >Priority: Major > Fix For: 2.0.0-M18 > > > The current implementation only handles newlines but not the other two > (dollar sign and backslash) character for which RFC 4517 specifies an > encoding, meaning that it can't handle addresses containing these characters. > These characters are rare in real life postal addresses (even though the RFC > contains a somewhat convincing example address) and this is probably the > reason for why no-one else has cared until now, but it would still be better > to implement the standard correctly than incompletely. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1296) Export doesn't decode RFC 4517 Postal Address syntax
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann resolved DIRSTUDIO-1296.
Resolution: Fixed
Thanks again Frederik for the proposal and the PR, and apologies for the very
late response.
> Export doesn't decode RFC 4517 Postal Address syntax
>
>
> Key: DIRSTUDIO-1296
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1296
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
>Reporter: Fredrik Roubert
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> When exporting any entries using the RFC 4517 Postal Address syntax
> (1.3.6.1.4.1.1466.115.121.1.41) to any non-LDAP data format (CSV, Excel, …)
> these entries aren't decoded but the RFC 4517 escaped data is instead
> exported as-is, like this:
> \241,000,000 Sweepstakes$PO Box 100$Anytown, CA 12345$USA
> … instead of this:
> $1,000,000 Sweepstakes
> {{PO Box 100}}
> {{Anytown, CA 12345}}
> {{USA}}
> I think it's safe to assume that no non-LDAP software is expected to be able
> to decode RFC 4517 escaped data, so not doing this decoding upon export must
> be a bug.
> (This data is correctly decoded and encoded by default for display and edit
> within Directory Studio itself.)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1295) When closing connection to LDAP, connection doesn't UNBIND and resulting in a lost connection from server
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1295:
---
Fix Version/s: 2.0.0-M18
> When closing connection to LDAP, connection doesn't UNBIND and resulting in a
> lost connection from server
> -
>
> Key: DIRSTUDIO-1295
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1295
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-connection
>Affects Versions: 2.0.0-M17
> Environment: N/A
>Reporter: Manuel FLURY
>Priority: Minor
> Fix For: 2.0.0-M18
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When opening a connection to LDAP server with credentials, connection is
> opened, but when pushing the "close connection" using contextual menu, it
> doesn't UNBIND before triggering a connection lost error
>
> {{Feb 14 16:41:43 myLDAPserver slapd[1946001]: conn=1000 fd=13 ACCEPT from
> IP=10.153.200.152:58180 (IP=0.0.0.0:11389)}}
> {{Feb 14 16:41:43 myLDAPserver slapd[1946001]: conn=1000 op=0 BIND
> dn="cn=Directory Manager,dc=example,dc=com" method=128}}
> {{Feb 14 16:41:43 myLDAPserver slapd[1946001]: conn=1000 op=0 BIND
> dn="cn=Directory Manager,dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=0}}
> {{Feb 14 16:41:43 myLDAPserver slapd[1946001]: conn=1000 op=0 RESULT tag=97
> err=0 qtime=0.14 etime=0.000105 text=}}
> {{{}.../...{}}}{{{}Feb 14 17:37:17 myLDAPserver slapd[1946001]: conn=1000
> op=29 SEARCH RESULT tag=101 err=0 qtime=0.18 etime=0.000108 nentries=1
> text={}}}
> {{{color:#de350b}Feb 14 17:37:27 myLDAPserver slapd[1946001]: conn=1000 fd=13
> closed (connection lost){color}}}
> {{}}
> I think there should be an UNBIND before closing connection.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-953) LDAP Browser - Quick Search Entry fields for attr and value do not support copy/paste by keystroke on Win7
[ https://issues.apache.org/jira/browse/DIRSTUDIO-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-953: -- Fix Version/s: 2.0.0-M18 > LDAP Browser - Quick Search Entry fields for attr and value do not support > copy/paste by keystroke on Win7 > -- > > Key: DIRSTUDIO-953 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-953 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Win7-64, Linux >Reporter: Lothar Haeger >Priority: Major > Fix For: 2.0.0-M18 > > > CTRL-C and CTRL-V do not work in quick search entry fields for attr names and > values -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-826) Impossible to paste into Quick Search fields
[ https://issues.apache.org/jira/browse/DIRSTUDIO-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-826: -- Fix Version/s: 2.0.0-M18 > Impossible to paste into Quick Search fields > > > Key: DIRSTUDIO-826 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-826 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 1.5.3, 2.0.0-M1 (2.0.0.v20120111), 2.0.0-M2 > (2.0.0.v20120127), 2.0.0-M3 (2.0.0.v20120224) > Environment: OS X Lion > OS X Mountain Lion >Reporter: Nabil Sayegh >Assignee: Pierre-Arnaud Marcelot >Priority: Major > Labels: clipboard, paste, quicksearch > Fix For: 2.0.0-M18 > > > Paste into quicksearch fields doesn't work on OS X (Lion/Mountain Lion) -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1284:
---
Fix Version/s: (was: 2.0.0-M15)
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M18
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1284:
---
Fix Version/s: 2.0.0-M18
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M15, 2.0.0-M18
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1289) Can't connect to ldaps behind haproxy in M17
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1289:
---
Fix Version/s: 2.0.0-M18
> Can't connect to ldaps behind haproxy in M17
>
>
> Key: DIRSTUDIO-1289
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1289
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
> Environment: OS: Linux, v.5.13.13-arch1-1, x86_64 / gtk 3.24.30
> Java version: 16.0.2
>Reporter: Josef Vybíhal
>Priority: Minor
> Labels: LDAPS, haproxy
> Fix For: 2.0.0-M16, 2.0.0-M18
>
>
> I have noticed, that I can not connect to ldaps server which is behind SSL
> terminated haproxy.
> The error seems to be timeout
> {code:java}
> Error while opening connectionError while opening connection -
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was
> found.org.apache.directory.studio.connection.core.io.StudioLdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.toStudioLdapException(DirectoryApiConnectionWrapper.java:1350)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$2(DirectoryApiConnectionWrapper.java:1342)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:483)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1261)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:488)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:323)
> at
> org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.run(OpenConnectionsRunnable.java:114)
> at
> org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:109)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)Caused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1578)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bindSimple(DirectoryApiConnectionWrapper.java:339)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$5(DirectoryApiConnectionWrapper.java:333)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:395)
> ... 6 moreCaused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04170_TIMEOUT_OCCURED TimeOut occurred at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1549)
> ... 9 more
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found.{code}
> In the haproxy log, I can see the connection was made. The ldap servers in
> the backed are definitely responding properly (I can connect to them
> directly, and numerous applications are using this haproxy as ldap source,
> and it works perfectly fine).
> I suspect it is something in M17.
> When I downgraded to 2.0.0.v20210213-M16, it works fine - I can connect as
> expected. I have tried M17 with java-16-jdk and java-11-openjdk, no change.
> Is there anything I could investigate more and help discovering what the
> issue might be?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1287) Error connecting to LDAPS server
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1287:
---
Fix Version/s: 2.0.0-M18
> Error connecting to LDAPS server
>
>
> Key: DIRSTUDIO-1287
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1287
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0-M17
>Reporter: Robin
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> In trying to connect to an LDAP server via TLS I have run into what I believe
> to be a bug.
> The LDAP server is the built-in one on a Synology NAS with a valid
> certificate installed.
> I am able to successfully bind to it using LDAPS on port 636 using
> javax.naming:
> {code:java}
> Hashtable env = new Hashtable();
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory");
> env.put(Context.PROVIDER_URL, ldapUrl);
> env.put(Context.SECURITY_AUTHENTICATION, authentication);
> env.put(Context.SECURITY_PRINCIPAL, bindDN);
> env.put(Context.SECURITY_CREDENTIALS, password);
> return new InitialLdapContext (env, null);
> {code}
> However, when trying to connect using Apache Directory Studio I keep getting
> an error:
> The authentication failed ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue
> has been emptied, no response was found.
> I started Directory Studio with -Djavax.net.debug=all to see what happens and
> this is what I found:
> * There's a bunch of logging which eventually ends with this line:
> {code:java}
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:20.548
> BST|SSLSessionImpl.java:242|Session initialized:
> Session(1629363140485|TLS_AES_128_GCM_SHA256){code}
> * It then idles for a while after which this happens:
> {code:java}
> javax.net.ssl|ALL|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineImpl.java:752|Closing outbound of SSLEngine
> javax.net.ssl|WARNING|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:168|outbound has closed, ignore outbound
> application data
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:505|WRITE: TLS13 alert, length = 2
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLCipher.java:2036|Plaintext before ENCRYPTION (
> : 01 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0010: 00 00 00 ...
> )
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:523|Raw write (
> : 17 03 03 00 23 00 65 A2 9A C7 DD 2C 23 8D 18 75 #.e,#..u
> 0010: 98 7F 17 DD 3B 01 61 36 C8 83 9A E1 0D 41 B0 00 ;.a6.A..
> 0020: 07 8D 20 48 EB 1E 31 7B.. H..1.
> )
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:50.513
> BST|SSLEngineImpl.java:724|Closing inbound of SSLEngine
> javax.net.ssl|ERROR|34|NioProcessor-5|2021-08-19 09:52:50.514
> BST|TransportContext.java:341|Fatal (INTERNAL_ERROR): closing inbound before
> receiving peer's close_notify (
> "throwable" : {
> javax.net.ssl.SSLException: closing inbound before receiving peer's
> close_notify
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
> at
> java.base/sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:733)
> at org.apache.mina.filter.ssl.SslHandler.destroy(SslHandler.java:209)
> at
> org.apache.mina.filter.ssl.SslFilter.sessionClosed(SslFilter.java:485)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:606)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:1092)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:98)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:606)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireSessionClosed(DefaultIoFilterChain.java:599)
> at
> org.apache.mina.core.service.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupp
[jira] [Updated] (DIRSTUDIO-1293) Fails to start on MacOS Monterey
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1293:
---
Fix Version/s: 2.0.0-M18
> Fails to start on MacOS Monterey
>
>
> Key: DIRSTUDIO-1293
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1293
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
> Environment: Model Name:MacBook Pro
> Model Identifier: MacBookPro18,2
> Chip: Apple M1 Max
> Total Number of Cores: 10 (8 performance and 2 efficiency)
> Memory: 32 GB
> System Firmware Version:7429.41.5
> OS Loader Version: 7429.41.5
>Reporter: Philip Peake
>Priority: Major
> Fix For: 2.0.0-M18
>
> Attachments: alert.png
>
>
> Launching Directory Studio fails with an error (see attached image),
> basically saying that the JNI_CreateJavaVM symbol is not found in
> libjvm.dylib.
> The symbol is actually there:
>
> {code:java}
> bin philip$ nm ../lib/server/libjvm.dylib | grep -i jni_create
> 004e3190 T _JNI_CreateJavaVM
> {code}
>
> Tried two different java versions:
> * zulu-11.jdk
> * zulu-17.jdk
> Tried adding the path to the java version explicitly in the Info.plist file:
>
> {code:java}
>
>
>
>
> -vm/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home/bin/java
> -keyring
> ~/.eclipse_keyring
>
>
> {code}
>
> This appears to be a problem in Eclipse/Directory Studio.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1296) Export doesn't decode RFC 4517 Postal Address syntax
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1296:
---
Fix Version/s: 2.0.0-M18
> Export doesn't decode RFC 4517 Postal Address syntax
>
>
> Key: DIRSTUDIO-1296
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1296
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
>Reporter: Fredrik Roubert
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> When exporting any entries using the RFC 4517 Postal Address syntax
> (1.3.6.1.4.1.1466.115.121.1.41) to any non-LDAP data format (CSV, Excel, …)
> these entries aren't decoded but the RFC 4517 escaped data is instead
> exported as-is, like this:
> \241,000,000 Sweepstakes$PO Box 100$Anytown, CA 12345$USA
> … instead of this:
> $1,000,000 Sweepstakes
> {{PO Box 100}}
> {{Anytown, CA 12345}}
> {{USA}}
> I think it's safe to assume that no non-LDAP software is expected to be able
> to decode RFC 4517 escaped data, so not doing this decoding upon export must
> be a bug.
> (This data is correctly decoded and encoded by default for display and edit
> within Directory Studio itself.)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-933) Order search value history by creation date instead of alphabetically
[ https://issues.apache.org/jira/browse/DIRSTUDIO-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-933: -- Fix Version/s: 2.0.0-M18 > Order search value history by creation date instead of alphabetically > - > > Key: DIRSTUDIO-933 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-933 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M17 >Reporter: Nabil Sayegh >Assignee: Lothar Haeger >Priority: Trivial > Labels: dropdownlist, history, search > Fix For: 2.0.0-M18 > > > The search value history shouldn't be sorted alphabetically but rather > historically, either by creation date or last use date -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1296) Export doesn't decode RFC 4517 Postal Address syntax
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537149#comment-17537149
]
Stefan Seelmann commented on DIRSTUDIO-1296:
Thanks for the proposal and the PR. Your proposal makes proper sense to me for
the export to CSV/Excel/ODF.
> Export doesn't decode RFC 4517 Postal Address syntax
>
>
> Key: DIRSTUDIO-1296
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1296
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
>Reporter: Fredrik Roubert
>Priority: Major
>
> When exporting any entries using the RFC 4517 Postal Address syntax
> (1.3.6.1.4.1.1466.115.121.1.41) to any non-LDAP data format (CSV, Excel, …)
> these entries aren't decoded but the RFC 4517 escaped data is instead
> exported as-is, like this:
> \241,000,000 Sweepstakes$PO Box 100$Anytown, CA 12345$USA
> … instead of this:
> $1,000,000 Sweepstakes
> {{PO Box 100}}
> {{Anytown, CA 12345}}
> {{USA}}
> I think it's safe to assume that no non-LDAP software is expected to be able
> to decode RFC 4517 escaped data, so not doing this decoding upon export must
> be a bug.
> (This data is correctly decoded and encoded by default for display and edit
> within Directory Studio itself.)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1287) Error connecting to LDAPS server
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492582#comment-17492582
]
Stefan Seelmann commented on DIRSTUDIO-1287:
It's a know issue. Either we get a fixed Mina and API version soon, otherwise
we can remove the usage of TLSv1.3 from Studio (it's hard-coded).
https://issues.apache.org/jira/browse/DIRAPI-381
> Error connecting to LDAPS server
>
>
> Key: DIRSTUDIO-1287
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1287
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0-M17
>Reporter: Robin
>Priority: Major
>
> In trying to connect to an LDAP server via TLS I have run into what I believe
> to be a bug.
> The LDAP server is the built-in one on a Synology NAS with a valid
> certificate installed.
> I am able to successfully bind to it using LDAPS on port 636 using
> javax.naming:
> {code:java}
> Hashtable env = new Hashtable();
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory");
> env.put(Context.PROVIDER_URL, ldapUrl);
> env.put(Context.SECURITY_AUTHENTICATION, authentication);
> env.put(Context.SECURITY_PRINCIPAL, bindDN);
> env.put(Context.SECURITY_CREDENTIALS, password);
> return new InitialLdapContext (env, null);
> {code}
> However, when trying to connect using Apache Directory Studio I keep getting
> an error:
> The authentication failed ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue
> has been emptied, no response was found.
> I started Directory Studio with -Djavax.net.debug=all to see what happens and
> this is what I found:
> * There's a bunch of logging which eventually ends with this line:
> {code:java}
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:20.548
> BST|SSLSessionImpl.java:242|Session initialized:
> Session(1629363140485|TLS_AES_128_GCM_SHA256){code}
> * It then idles for a while after which this happens:
> {code:java}
> javax.net.ssl|ALL|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineImpl.java:752|Closing outbound of SSLEngine
> javax.net.ssl|WARNING|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:168|outbound has closed, ignore outbound
> application data
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:505|WRITE: TLS13 alert, length = 2
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLCipher.java:2036|Plaintext before ENCRYPTION (
> : 01 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0010: 00 00 00 ...
> )
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:523|Raw write (
> : 17 03 03 00 23 00 65 A2 9A C7 DD 2C 23 8D 18 75 #.e,#..u
> 0010: 98 7F 17 DD 3B 01 61 36 C8 83 9A E1 0D 41 B0 00 ;.a6.A..
> 0020: 07 8D 20 48 EB 1E 31 7B.. H..1.
> )
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:50.513
> BST|SSLEngineImpl.java:724|Closing inbound of SSLEngine
> javax.net.ssl|ERROR|34|NioProcessor-5|2021-08-19 09:52:50.514
> BST|TransportContext.java:341|Fatal (INTERNAL_ERROR): closing inbound before
> receiving peer's close_notify (
> "throwable" : {
> javax.net.ssl.SSLException: closing inbound before receiving peer's
> close_notify
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
> at
> java.base/sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:733)
> at org.apache.mina.filter.ssl.SslHandler.destroy(SslHandler.java:209)
> at
> org.apache.mina.filter.ssl.SslFilter.sessionClosed(SslFilter.java:485)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:606)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:1092)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:98)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:606)
> at
> org.apache.mina.core.filt
[jira] [Commented] (DIRSTUDIO-1289) Can't connect to ldaps behind haproxy in M17
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492581#comment-17492581
]
Stefan Seelmann commented on DIRSTUDIO-1289:
It's a know issue. Either we get a fixed Mina and API version soon, otherwise
we can remove the usage of TLSv1.3 from Studio (it's hard-coded).
https://issues.apache.org/jira/browse/DIRAPI-381
> Can't connect to ldaps behind haproxy in M17
>
>
> Key: DIRSTUDIO-1289
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1289
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
> Environment: OS: Linux, v.5.13.13-arch1-1, x86_64 / gtk 3.24.30
> Java version: 16.0.2
>Reporter: Josef Vybíhal
>Priority: Minor
> Labels: LDAPS, haproxy
> Fix For: 2.0.0-M16
>
>
> I have noticed, that I can not connect to ldaps server which is behind SSL
> terminated haproxy.
> The error seems to be timeout
> {code:java}
> Error while opening connectionError while opening connection -
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was
> found.org.apache.directory.studio.connection.core.io.StudioLdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.toStudioLdapException(DirectoryApiConnectionWrapper.java:1350)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$2(DirectoryApiConnectionWrapper.java:1342)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:483)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1261)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:488)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:323)
> at
> org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.run(OpenConnectionsRunnable.java:114)
> at
> org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:109)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)Caused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1578)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bindSimple(DirectoryApiConnectionWrapper.java:339)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$5(DirectoryApiConnectionWrapper.java:333)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:395)
> ... 6 moreCaused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04170_TIMEOUT_OCCURED TimeOut occurred at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1549)
> ... 9 more
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found.{code}
> In the haproxy log, I can see the connection was made. The ldap servers in
> the backed are definitely responding properly (I can connect to them
> directly, and numerous applications are using this haproxy as ldap source,
> and it works perfectly fine).
> I suspect it is something in M17.
> When I downgraded to 2.0.0.v20210213-M16, it works fine - I can connect as
> expected. I have tried M17 with java-16-jdk and java-11-openjdk, no change.
> Is there anything I could investigate more and help discovering what the
> issue might be?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (FC-305) Upgrade OpenLDAP Docker Container
[ https://issues.apache.org/jira/browse/FC-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467709#comment-17467709 ] Stefan Seelmann commented on FC-305: +1, sounds good to me. The increase of 40 MB is worth it. > Upgrade OpenLDAP Docker Container > - > > Key: FC-305 > URL: https://issues.apache.org/jira/browse/FC-305 > Project: FORTRESS > Issue Type: Improvement >Affects Versions: 2.0.7 >Reporter: Shawn McKinney >Assignee: Shawn McKinney >Priority: Major > Fix For: 2.0.8 > > > A number of improvements: > - upgrade to OpenLDAP 2.5 > - run as non-root user > - update slapd.conf, schema supports, ACL's -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (FC-306) Upgrade ApacheDS Docker Container
[ https://issues.apache.org/jira/browse/FC-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467708#comment-17467708 ] Stefan Seelmann commented on FC-306: +1, sounds great, thanks Shawn! > Upgrade ApacheDS Docker Container > - > > Key: FC-306 > URL: https://issues.apache.org/jira/browse/FC-306 > Project: FORTRESS > Issue Type: Improvement >Affects Versions: 2.0.7 >Reporter: Shawn McKinney >Assignee: Shawn McKinney >Priority: Major > Fix For: 2.0.8 > > > Use: > a) FROM openjdk:11-jre-slim-buster > b) ENV APACHEDS_VERSION=2.0.0.AM25 > Slim image: > before: 554MB > after: 251MB > Other benefits: > 1. use recent jdk > 2. " apacheds release -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Deleted] (DIR-340) Salam Joker
[ https://issues.apache.org/jira/browse/DIR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann deleted DIR-340: > Salam Joker > --- > > Key: DIR-340 > URL: https://issues.apache.org/jira/browse/DIR-340 > Project: Directory > Issue Type: Improvement >Reporter: JoKero >Assignee: Emmanuel Lécharny >Priority: Major > Labels: performance > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > Ketelitian, evaluasi dan improvement selalu diperlukan ketika developer > membangun website yang akan diluncurkan. Begitu juga dengan situs Joker > Gaming yang satu ini Joker188, agar siap diperkenalkan pada berbagai > directory online gaming yang tepat, serta platform yang mendukung. > Bagi Anda yang sedang kepo dengan permainan dengan berbagai nama ini, ada > yang mengatakannya Joker128, Joker388 serta game Joker188 Slot, sila kunjungi > pada link alternatif ini [https://188.166.225.61|https://188.166.225.61/] > Mampirlah dan boleh melakukan registrasi agar bisa ikut bermain. > Salam Joker dari Jokero Slotter Mania -- 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] [Comment Edited] (DIRSTUDIO-1290) Setup custom Java path that have a space in name nor working
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415554#comment-17415554
]
Stefan Seelmann edited comment on DIRSTUDIO-1290 at 9/15/21, 2:33 PM:
--
Which Studio version do you use? I see that your ini file contains
{{-Dosgi.requiredJavaVersion=1.8}}, but since Studio 2.0.0-M16 it requires Java
11. Is that an ini file from a previous installation maybe? Please change it to
{{-Dosgi.requiredJavaVersion=11}}.
was (Author: seelmann):
Which Studio version do you use? I see that your ini file contains {{-vmargs
-Dosgi.requiredJavaVersion=1.8 }}, but since Studio 2.0.0-M16 it requires Java
11. Is that an ini file from a previous installation maybe? Please change it to
{{-Dosgi.requiredJavaVersion=11}}.
> Setup custom Java path that have a space in name nor working
>
>
> Key: DIRSTUDIO-1290
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1290
> Project: Directory Studio
> Issue Type: Question
> Components: studio-apacheds-configuration
>Reporter: Philipp Homberger
>Priority: Minor
> Attachments: image-2021-09-15-07-48-14-809.png
>
>
> h3.
> https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
> h3. How to set the Java VM to use?
> Add the following content to _ApacheDirectoryStudio.ini_ file (before the
> “-vmargs” line):
>
> {{-vm
> }}
> *Not woring with a path that have space in the name like C:/Program
> Files/java/java.exe*{{}}
> I have try with Quotes uws.
> But I jave at the moment no Idea. {{}}
--
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] (DIRSTUDIO-1290) Setup custom Java path that have a space in name nor working
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415554#comment-17415554
]
Stefan Seelmann commented on DIRSTUDIO-1290:
Which Studio version do you use? I see that your ini file contains {{-vmargs
-Dosgi.requiredJavaVersion=1.8 }}, but since Studio 2.0.0-M16 it requires Java
11. Is that an ini file from a previous installation maybe? Please change it to
{{-Dosgi.requiredJavaVersion=11}}.
> Setup custom Java path that have a space in name nor working
>
>
> Key: DIRSTUDIO-1290
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1290
> Project: Directory Studio
> Issue Type: Question
> Components: studio-apacheds-configuration
>Reporter: Philipp Homberger
>Priority: Minor
> Attachments: image-2021-09-15-07-48-14-809.png
>
>
> h3.
> https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
> h3. How to set the Java VM to use?
> Add the following content to _ApacheDirectoryStudio.ini_ file (before the
> “-vmargs” line):
>
> {{-vm
> }}
> *Not woring with a path that have space in the name like C:/Program
> Files/java/java.exe*{{}}
> I have try with Quotes uws.
> But I jave at the moment no Idea. {{}}
--
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] [Comment Edited] (DIRSTUDIO-1290) Setup custom Java path that have a space in name nor working
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415319#comment-17415319
]
Stefan Seelmann edited comment on DIRSTUDIO-1290 at 9/15/21, 4:56 AM:
--
I tested it on Windows 10 and it works. I used the backslash \ instead of
forward slack /, maybe that's the reason?
Here is the full ini file for reference:
{noformat}
-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
{noformat}
was (Author: seelmann):
I tested it on Windows 10 and it works. I used the backslash \ instead of
forward slack /, maybe that's the reason?
Here is the full ini file for reference:
{noformat}
-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
{noformat}
> Setup custom Java path that have a space in name nor working
>
>
> Key: DIRSTUDIO-1290
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1290
> Project: Directory Studio
> Issue Type: Question
> Components: studio-apacheds-configuration
>Reporter: Philipp Homberger
>Priority: Minor
>
> h3.
> https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
> h3. How to set the Java VM to use?
> Add the following content to _ApacheDirectoryStudio.ini_ file (before the
> “-vmargs” line):
>
> {{-vm
> }}
> *Not woring with a path that have space in the name like C:/Program
> Files/java/java.exe*{{}}
> I have try with Quotes uws.
> But I jave at the moment no Idea. {{}}
--
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] (DIRSTUDIO-1290) Setup custom Java path that have a space in name nor working
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17415319#comment-17415319
]
Stefan Seelmann commented on DIRSTUDIO-1290:
I tested it on Windows 10 and it works. I used the backslash \ instead of
forward slack /, maybe that's the reason?
Here is the full ini file for reference:
{noformat}
-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###-startup
plugins/org.eclipse.equinox.launcher_1.6.0.v20200915-1508.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.2.0.v20200915-1442
/studio-rcp/resources/icons/linux/studio.xpm
###
#Uncomment_to_configure_the_language
#https://directory.apache.org/studio/faqs.html#how-to-set-the-language-of-studio
#-nl
#en
###
#Uncomment_to_configure_Java_version_to_use
#https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
-vm
C:\Program Files\AdoptOpenJDK\jdk-11.0.11.9-hotspot - Copy\bin\java.exe
-vmargs
-Dosgi.requiredJavaVersion=11
###
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
#Uncomment_to_configure_heap_memory
#https://directory.apache.org/studio/faqs.html#how-to-increase-the-heap-memory
#-Xms1g
#-Xmx2g
{noformat}
> Setup custom Java path that have a space in name nor working
>
>
> Key: DIRSTUDIO-1290
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1290
> Project: Directory Studio
> Issue Type: Question
> Components: studio-apacheds-configuration
>Reporter: Philipp Homberger
>Priority: Minor
>
> h3.
> https://directory.apache.org/studio/faqs.html#how-to-set-the-java-vm-to-use
> h3. How to set the Java VM to use?
> Add the following content to _ApacheDirectoryStudio.ini_ file (before the
> “-vmargs” line):
>
> {{-vm
> }}
> *Not woring with a path that have space in the name like C:/Program
> Files/java/java.exe*{{}}
> I have try with Quotes uws.
> But I jave at the moment no Idea. {{}}
--
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] (DIRSTUDIO-1288) LDIF not running on Directory Studio M17
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17402551#comment-17402551 ] Stefan Seelmann commented on DIRSTUDIO-1288: I'm afraid I can't reproduce it. I took your exact LDIF snippet and executed it via the LDIF editor and get an error in the modification logs view. Obviously, as I run it against OpenLDAP, it won't work, but it executes, the server returns an error, and the error is shown. I tested with both Java 11 and Java 16 on Linux. On a side note I admit we need to improve the error handling, the error popup should show a better message and more information. !screenshot-1.png! > LDIF not running on Directory Studio M17 > > > Key: DIRSTUDIO-1288 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1288 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M17 > Environment: PROD >Reporter: Gage Harris >Priority: Major > Attachments: screenshot-1.png > > > We just upgraded to Apache Directory Studio M17 from M14. In order to get > the app to open, we also had to upgrade to Java 16(openJDK 16.0.1). Everyone > on M17 can not run the ldif command shown below, but those on M14 can run the > same LDIF: > DN: uid=testusr,cn=testusers,ou=testservice,O=testorg > changetype:modify > replace: ibm-pwdIndividualPolicyDN > ibm-pwdIndividualPolicyDN: cn=servPwdPolicy, cn=ibmpolicies > > When we try to run this, we get a dialog popup that says 'Execute LDIF' has > encountered a problem. Error while executing LDIF - 1 errors occurred, see > logfile for details" > When looking at the error log we see this: > Plug-in: org.apache.directory.studio.common.core.jobs > "An exception stack trace is not available" > Session Data: > eclipse.buildId=unknown > java.version=16.0.1 > java.vendor=AdoptOpenJDK > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm -- 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] [Updated] (DIRSTUDIO-1288) LDIF not running on Directory Studio M17
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1288: --- Attachment: screenshot-1.png > LDIF not running on Directory Studio M17 > > > Key: DIRSTUDIO-1288 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1288 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M17 > Environment: PROD >Reporter: Gage Harris >Priority: Major > Attachments: screenshot-1.png > > > We just upgraded to Apache Directory Studio M17 from M14. In order to get > the app to open, we also had to upgrade to Java 16(openJDK 16.0.1). Everyone > on M17 can not run the ldif command shown below, but those on M14 can run the > same LDIF: > DN: uid=testusr,cn=testusers,ou=testservice,O=testorg > changetype:modify > replace: ibm-pwdIndividualPolicyDN > ibm-pwdIndividualPolicyDN: cn=servPwdPolicy, cn=ibmpolicies > > When we try to run this, we get a dialog popup that says 'Execute LDIF' has > encountered a problem. Error while executing LDIF - 1 errors occurred, see > logfile for details" > When looking at the error log we see this: > Plug-in: org.apache.directory.studio.common.core.jobs > "An exception stack trace is not available" > Session Data: > eclipse.buildId=unknown > java.version=16.0.1 > java.vendor=AdoptOpenJDK > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm -- 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] (DIRSTUDIO-1288) LDIF not running on Directory Studio M17
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17402392#comment-17402392 ] Stefan Seelmann commented on DIRSTUDIO-1288: No, I mean the modification logs view, at the bottom center of the Studio UI. https://nightlies.apache.org/directory/studio/2.0.0.v20210717-M17/userguide/ldap_browser/tools_modification_logs_view.html https://nightlies.apache.org/directory/studio/2.0.0.v20210717-M17/userguide/ldap_browser/tools_ldap_perspective.html Also, how do you run the LDIF? Via the LDIF import wizard, or via the LDIF editor? > LDIF not running on Directory Studio M17 > > > Key: DIRSTUDIO-1288 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1288 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M17 > Environment: PROD >Reporter: Gage Harris >Priority: Major > > We just upgraded to Apache Directory Studio M17 from M14. In order to get > the app to open, we also had to upgrade to Java 16(openJDK 16.0.1). Everyone > on M17 can not run the ldif command shown below, but those on M14 can run the > same LDIF: > DN: uid=testusr,cn=testusers,ou=testservice,O=testorg > changetype:modify > replace: ibm-pwdIndividualPolicyDN > ibm-pwdIndividualPolicyDN: cn=servPwdPolicy, cn=ibmpolicies > > When we try to run this, we get a dialog popup that says 'Execute LDIF' has > encountered a problem. Error while executing LDIF - 1 errors occurred, see > logfile for details" > When looking at the error log we see this: > Plug-in: org.apache.directory.studio.common.core.jobs > "An exception stack trace is not available" > Session Data: > eclipse.buildId=unknown > java.version=16.0.1 > java.vendor=AdoptOpenJDK > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm -- 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] (DIRSTUDIO-1288) LDIF not running on Directory Studio M17
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17402341#comment-17402341 ] Stefan Seelmann commented on DIRSTUDIO-1288: Can you please check the "Modification Logs", was there an error returned by the server? > LDIF not running on Directory Studio M17 > > > Key: DIRSTUDIO-1288 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1288 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M17 > Environment: PROD >Reporter: Gage Harris >Priority: Major > > We just upgraded to Apache Directory Studio M17 from M14. In order to get > the app to open, we also had to upgrade to Java 16(openJDK 16.0.1). Everyone > on M17 can not run the ldif command shown below, but those on M14 can run the > same LDIF: > DN: uid=testusr,cn=testusers,ou=testservice,O=testorg > changetype:modify > replace: ibm-pwdIndividualPolicyDN > ibm-pwdIndividualPolicyDN: cn=servPwdPolicy, cn=ibmpolicies > > When we try to run this, we get a dialog popup that says 'Execute LDIF' has > encountered a problem. Error while executing LDIF - 1 errors occurred, see > logfile for details" > When looking at the error log we see this: > Plug-in: org.apache.directory.studio.common.core.jobs > "An exception stack trace is not available" > Session Data: > eclipse.buildId=unknown > java.version=16.0.1 > java.vendor=AdoptOpenJDK > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm -- 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] (DIRSTUDIO-1287) Error connecting to LDAPS server
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401846#comment-17401846
]
Stefan Seelmann commented on DIRSTUDIO-1287:
In M17 we integrated LDAP API 2.1.0 which enables TLS 1.3
(https://issues.apache.org/jira/browse/DIRAPI-375) which seems it was a mistake
as https://issues.apache.org/jira/browse/DIRMINA-1132 seems to be an issue
after all.
In your debug log I see {{TLS13 alert}} so I assume it's related.
> Error connecting to LDAPS server
>
>
> Key: DIRSTUDIO-1287
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1287
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0-M17
>Reporter: Robin
>Priority: Major
>
> In trying to connect to an LDAP server via TLS I have run into what I believe
> to be a bug.
> The LDAP server is the built-in one on a Synology NAS with a valid
> certificate installed.
> I am able to successfully bind to it using LDAPS on port 636 using
> javax.naming:
> {code:java}
> Hashtable env = new Hashtable();
> env.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory");
> env.put(Context.PROVIDER_URL, ldapUrl);
> env.put(Context.SECURITY_AUTHENTICATION, authentication);
> env.put(Context.SECURITY_PRINCIPAL, bindDN);
> env.put(Context.SECURITY_CREDENTIALS, password);
> return new InitialLdapContext (env, null);
> {code}
> However, when trying to connect using Apache Directory Studio I keep getting
> an error:
> The authentication failed ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue
> has been emptied, no response was found.
> I started Directory Studio with -Djavax.net.debug=all to see what happens and
> this is what I found:
> * There's a bunch of logging which eventually ends with this line:
> {code:java}
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:20.548
> BST|SSLSessionImpl.java:242|Session initialized:
> Session(1629363140485|TLS_AES_128_GCM_SHA256){code}
> * It then idles for a while after which this happens:
> {code:java}
> javax.net.ssl|ALL|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineImpl.java:752|Closing outbound of SSLEngine
> javax.net.ssl|WARNING|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:168|outbound has closed, ignore outbound
> application data
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:505|WRITE: TLS13 alert, length = 2
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLCipher.java:2036|Plaintext before ENCRYPTION (
> : 01 00 15 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0010: 00 00 00 ...
> )
> javax.net.ssl|DEBUG|32|Worker-4: Open Connection|2021-08-19 09:52:50.512
> BST|SSLEngineOutputRecord.java:523|Raw write (
> : 17 03 03 00 23 00 65 A2 9A C7 DD 2C 23 8D 18 75 #.e,#..u
> 0010: 98 7F 17 DD 3B 01 61 36 C8 83 9A E1 0D 41 B0 00 ;.a6.A..
> 0020: 07 8D 20 48 EB 1E 31 7B.. H..1.
> )
> javax.net.ssl|ALL|34|NioProcessor-5|2021-08-19 09:52:50.513
> BST|SSLEngineImpl.java:724|Closing inbound of SSLEngine
> javax.net.ssl|ERROR|34|NioProcessor-5|2021-08-19 09:52:50.514
> BST|TransportContext.java:341|Fatal (INTERNAL_ERROR): closing inbound before
> receiving peer's close_notify (
> "throwable" : {
> javax.net.ssl.SSLException: closing inbound before receiving peer's
> close_notify
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:133)
> at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:336)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292)
> at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:283)
> at
> java.base/sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:733)
> at org.apache.mina.filter.ssl.SslHandler.destroy(SslHandler.java:209)
> at
> org.apache.mina.filter.ssl.SslFilter.sessionClosed(SslFilter.java:485)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:606)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:49)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:1092)
> at
> org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:98)
> at
> org.apache.mina.core.filterchain.DefaultIoFi
[jira] [Updated] (DIRSTUDIO-1286) Windows installer: the software version is missing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1286: --- Fix Version/s: 2.0.0-M18 > Windows installer: the software version is missing > -- > > Key: DIRSTUDIO-1286 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1286 > Project: Directory Studio > Issue Type: Improvement > Components: studio-installer >Affects Versions: 2.0.0-M17 > Environment: Windows 10 >Reporter: Elvis Bortoletto >Priority: Minor > Fix For: 2.0.0-M18 > > Attachments: image-2021-08-17-18-31-32-731.png, > image-2021-08-17-18-32-47-581.png > > > Once installed the Directory Studio, the version is not reported in "Control > Panel | Programs and Features". > !image-2021-08-17-18-32-47-581.png! > As a side effect, "winget upgrade" gets confused, reporting the Directory > Studio in the list of the packages with an available upgrade. > !image-2021-08-17-18-31-32-731.png! > Maybe reporting the software version would enhance the user experience and > would fix the winget behavior. -- 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] [Resolved] (DIRSTUDIO-1286) Windows installer: the software version is missing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1286. Resolution: Fixed > Windows installer: the software version is missing > -- > > Key: DIRSTUDIO-1286 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1286 > Project: Directory Studio > Issue Type: Improvement > Components: studio-installer >Affects Versions: 2.0.0-M17 > Environment: Windows 10 >Reporter: Elvis Bortoletto >Priority: Minor > Fix For: 2.0.0-M18 > > Attachments: image-2021-08-17-18-31-32-731.png, > image-2021-08-17-18-32-47-581.png > > > Once installed the Directory Studio, the version is not reported in "Control > Panel | Programs and Features". > !image-2021-08-17-18-32-47-581.png! > As a side effect, "winget upgrade" gets confused, reporting the Directory > Studio in the list of the packages with an available upgrade. > !image-2021-08-17-18-31-32-731.png! > Maybe reporting the software version would enhance the user experience and > would fix the winget behavior. -- 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] (DIRSTUDIO-1286) Windows installer: the software version is missing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401839#comment-17401839 ] Stefan Seelmann commented on DIRSTUDIO-1286: Great, thank for reporting and the patch :) > Windows installer: the software version is missing > -- > > Key: DIRSTUDIO-1286 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1286 > Project: Directory Studio > Issue Type: Improvement > Components: studio-installer >Affects Versions: 2.0.0-M17 > Environment: Windows 10 >Reporter: Elvis Bortoletto >Priority: Minor > Fix For: 2.0.0-M18 > > Attachments: image-2021-08-17-18-31-32-731.png, > image-2021-08-17-18-32-47-581.png > > > Once installed the Directory Studio, the version is not reported in "Control > Panel | Programs and Features". > !image-2021-08-17-18-32-47-581.png! > As a side effect, "winget upgrade" gets confused, reporting the Directory > Studio in the list of the packages with an available upgrade. > !image-2021-08-17-18-31-32-731.png! > Maybe reporting the software version would enhance the user experience and > would fix the winget behavior. -- 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] (DIRSTUDIO-1286) Windows installer: the software version is missing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401278#comment-17401278 ] Stefan Seelmann commented on DIRSTUDIO-1286: Thanks for the proposal. I added the change here: https://github.com/apache/directory-studio/commit/37d3378f38d8347647a1402b560960a21e4dbbc7 and uploaded the Windows installer here, in case you want to try it out: https://home.apache.org/~seelmann/ > Windows installer: the software version is missing > -- > > Key: DIRSTUDIO-1286 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1286 > Project: Directory Studio > Issue Type: Improvement > Components: studio-installer >Affects Versions: 2.0.0-M17 > Environment: Windows 10 >Reporter: Elvis Bortoletto >Priority: Minor > Attachments: image-2021-08-17-18-31-32-731.png, > image-2021-08-17-18-32-47-581.png > > > Once installed the Directory Studio, the version is not reported in "Control > Panel | Programs and Features". > !image-2021-08-17-18-32-47-581.png! > As a side effect, "winget upgrade" gets confused, reporting the Directory > Studio in the list of the packages with an available upgrade. > !image-2021-08-17-18-31-32-731.png! > Maybe reporting the software version would enhance the user experience and > would fix the winget behavior. -- 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] [Comment Edited] (DIRSTUDIO-1285) Proxied auth leads to wrong DIT/rootDSE being used
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398875#comment-17398875
]
Stefan Seelmann edited comment on DIRSTUDIO-1285 at 8/13/21, 7:23 PM:
--
The reason that "dc=baz,dc=quux" is not shown as context entry in the DIT is
that for a base object search no entry is returned, see the extract of the logs
you provided below. Can you try to run that ldapsearch command and maybe vary
it a bit (filter, returned attributes)? Is there an access control in place
that this entry is not visible for the used user?
{noformat}
#!SEARCH REQUEST (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.364
# LDAP URL :
ldap://baz.domain.tld:389/dc=baz,dc=quux?hasSubordinates,objectClass??(objectClass=*)
# command line : ldapsearch -H ldap://baz.domain.tld:389 -ZZ -x -D
"cn=joe,dc=foo,dc=bar" -W -b "dc=baz,dc=quux" -s base -a always -z 1
"(objectClass=*)" "hasSubordinates" "objectClass"
# baseObject : dc=baz,dc=quux
# scope: baseObject (0)
# derefAliases : derefAlways (3)
# sizeLimit: 1
# timeLimit: 0
# typesOnly: False
# filter : (objectClass=*)
# attributes : hasSubordinates objectClass
#!SEARCH RESULT DONE (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.385
# numEntries : 0
{noformat}
was (Author: seelmann):
The reason that "dc=baz,dc=quux" is shown as context entry in the DIT is that
for a base object search no entry is returned, see the extract of the logs you
provided below. Can you try to run that ldapsearch command and maybe vary it a
bit (filter, returned attributes)? Is there an access control in place that
this entry is not visible for the used user?
{noformat}
#!SEARCH REQUEST (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.364
# LDAP URL :
ldap://baz.domain.tld:389/dc=baz,dc=quux?hasSubordinates,objectClass??(objectClass=*)
# command line : ldapsearch -H ldap://baz.domain.tld:389 -ZZ -x -D
"cn=joe,dc=foo,dc=bar" -W -b "dc=baz,dc=quux" -s base -a always -z 1
"(objectClass=*)" "hasSubordinates" "objectClass"
# baseObject : dc=baz,dc=quux
# scope: baseObject (0)
# derefAliases : derefAlways (3)
# sizeLimit: 1
# timeLimit: 0
# typesOnly: False
# filter : (objectClass=*)
# attributes : hasSubordinates objectClass
#!SEARCH RESULT DONE (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.385
# numEntries : 0
{noformat}
> Proxied auth leads to wrong DIT/rootDSE being used
> --
>
> Key: DIRSTUDIO-1285
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1285
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: brent s.
>Priority: Major
> Attachments: connect_disconnect.log, enable_base_dn_server.log
>
>
> If using Apache Directory Studio as a client to OpenLDAP using [remote
> bind|https://www.openldap.org/faq/data/cache/532.html] (see *Identity
> Assertion*), the incorrect DIT/rootDSE is used and the proper DIT/rootDSE is
> seemingly never detected.
> For example, the following scenario:
>
> BindDN (as configured in the connection profile): _cn=joe,dc=foo,dc=bar_
> Server (as configured in the connection profile): _ldap://baz.domain.tld:389_
> _ldap://baz.domain.tld:389_ contains *dc=baz,dc=quux*.
> *dc=baz,dc=quux* is configured to proxy all bind requests for *anything under
> dc=foo,dc=bar* to proxy (back-ldap) the bind request to
> _ldap://foo.domain.tld:389_ using identity assertion.
> _ldap://foo.domain.tld:389_ obviously contains *dc=foo,dc=bar*.
>
>
> When the above bindDN and Server is used, binding successfully takes place.
> However, the only DIT/rootDSE visible is *dc=foo,dc=bar* and _*not*_
> *dc=baz,dc=quux*! In other words, the DIT that exists on the actual server.
> This is, obviously, incorrect.
> This is handled correctly in the openLDAP clients (e.g. _ldapsearch_).
>
> Ensuring "Get base DNs from Root DSE" is checked in the connection profile
> does not change this behavior. _Ensuring that is disabled and specifying
> e.g._ *dc=baz,dc=quux* _manually as the base DN does not change this
> behavior!_ Using the "Fetch Base DNs" button does not change this behavior;
> it only detects *dc=foo,dc=bar*.
>
> I can see both DIT DNs in the root DSE's _namingContexts_ attributes.
--
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] (DIRSTUDIO-1285) Proxied auth leads to wrong DIT/rootDSE being used
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398875#comment-17398875
]
Stefan Seelmann commented on DIRSTUDIO-1285:
The reason that "dc=baz,dc=quux" is shown as context entry in the DIT is that
for a base object search no entry is returned, see the extract of the logs you
provided below. Can you try to run that ldapsearch command and maybe vary it a
bit (filter, returned attributes)? Is there an access control in place that
this entry is not visible for the used user?
{noformat}
#!SEARCH REQUEST (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.364
# LDAP URL :
ldap://baz.domain.tld:389/dc=baz,dc=quux?hasSubordinates,objectClass??(objectClass=*)
# command line : ldapsearch -H ldap://baz.domain.tld:389 -ZZ -x -D
"cn=joe,dc=foo,dc=bar" -W -b "dc=baz,dc=quux" -s base -a always -z 1
"(objectClass=*)" "hasSubordinates" "objectClass"
# baseObject : dc=baz,dc=quux
# scope: baseObject (0)
# derefAliases : derefAlways (3)
# sizeLimit: 1
# timeLimit: 0
# typesOnly: False
# filter : (objectClass=*)
# attributes : hasSubordinates objectClass
#!SEARCH RESULT DONE (14) OK
#!CONNECTION ldap://baz.domain.tld:389
#!DATE 2021-08-13T05:44:34.385
# numEntries : 0
{noformat}
> Proxied auth leads to wrong DIT/rootDSE being used
> --
>
> Key: DIRSTUDIO-1285
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1285
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: brent s.
>Priority: Major
> Attachments: connect_disconnect.log, enable_base_dn_server.log
>
>
> If using Apache Directory Studio as a client to OpenLDAP using [remote
> bind|https://www.openldap.org/faq/data/cache/532.html] (see *Identity
> Assertion*), the incorrect DIT/rootDSE is used and the proper DIT/rootDSE is
> seemingly never detected.
> For example, the following scenario:
>
> BindDN (as configured in the connection profile): _cn=joe,dc=foo,dc=bar_
> Server (as configured in the connection profile): _ldap://baz.domain.tld:389_
> _ldap://baz.domain.tld:389_ contains *dc=baz,dc=quux*.
> *dc=baz,dc=quux* is configured to proxy all bind requests for *anything under
> dc=foo,dc=bar* to proxy (back-ldap) the bind request to
> _ldap://foo.domain.tld:389_ using identity assertion.
> _ldap://foo.domain.tld:389_ obviously contains *dc=foo,dc=bar*.
>
>
> When the above bindDN and Server is used, binding successfully takes place.
> However, the only DIT/rootDSE visible is *dc=foo,dc=bar* and _*not*_
> *dc=baz,dc=quux*! In other words, the DIT that exists on the actual server.
> This is, obviously, incorrect.
> This is handled correctly in the openLDAP clients (e.g. _ldapsearch_).
>
> Ensuring "Get base DNs from Root DSE" is checked in the connection profile
> does not change this behavior. _Ensuring that is disabled and specifying
> e.g._ *dc=baz,dc=quux* _manually as the base DN does not change this
> behavior!_ Using the "Fetch Base DNs" button does not change this behavior;
> it only detects *dc=foo,dc=bar*.
>
> I can see both DIT DNs in the root DSE's _namingContexts_ attributes.
--
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] (DIRSTUDIO-1285) Proxied auth leads to wrong DIT/rootDSE being used
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398275#comment-17398275 ] Stefan Seelmann commented on DIRSTUDIO-1285: bq. Full version string is 2.0.0.v20210213-M16. I've followed the procedure above but both the log window and the exported log file is completely empty, even with Search Result Entry Logs enabled, before, during, and after the connection and disconnect. This is a known bug in this version. Can you please try to latest version 2.0.0.v20210717-M17 that was release 2 weeks ago? (It also solves some issues with the namingContexts, even if yours sounds different, see changelog https://directory.apache.org/studio/changelog.html) > Proxied auth leads to wrong DIT/rootDSE being used > -- > > Key: DIRSTUDIO-1285 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1285 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: brent s. >Priority: Major > > If using Apache Directory Studio as a client to OpenLDAP using [remote > bind|https://www.openldap.org/faq/data/cache/532.html] (see *Identity > Assertion*), the incorrect DIT/rootDSE is used and the proper DIT/rootDSE is > seemingly never detected. > For example, the following scenario: > > BindDN (as configured in the connection profile): _cn=joe,dc=foo,dc=bar_ > Server (as configured in the connection profile): _ldap://baz.domain.tld:389_ > _ldap://baz.domain.tld:389_ contains *dc=baz,dc=quux*. > *dc=baz,dc=quux* is configured to proxy all bind requests for *anything under > dc=foo,dc=bar* to proxy (back-ldap) the bind request to > _ldap://foo.domain.tld:389_ using identity assertion. > _ldap://foo.domain.tld:389_ obviously contains *dc=foo,dc=bar*. > > > When the above bindDN and Server is used, binding successfully takes place. > However, the only DIT/rootDSE visible is *dc=foo,dc=bar* and _*not*_ > *dc=baz,dc=quux*! In other words, the DIT that exists on the actual server. > This is, obviously, incorrect. > This is handled correctly in the openLDAP clients (e.g. _ldapsearch_). > > Ensuring "Get base DNs from Root DSE" is checked in the connection profile > does not change this behavior. _Ensuring that is disabled and specifying > e.g._ *dc=baz,dc=quux* _manually as the base DN does not change this > behavior!_ Using the "Fetch Base DNs" button does not change this behavior; > it only detects *dc=foo,dc=bar*. > > I can see both DIT DNs in the root DSE's _namingContexts_ attributes. -- 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] (DIRSTUDIO-1285) Proxied auth leads to wrong DIT/rootDSE being used
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398253#comment-17398253 ] Stefan Seelmann commented on DIRSTUDIO-1285: Which Studio version do you use? (full version string) So namingContexts contains both dc=baz,dc=quux and dc=foo,dc=bar, correct? Can you please clear the "Search Logs", enable the "Search Result Entry Logs" option, open the connection once, then post the "Search Logs" output (anonymize the data please). Disable the "Search Result Entry Logs" afterwards again as it logs a lot otherwise. https://nightlies.apache.org/directory/studio/2.0.0.v20210717-M17/userguide/ldap_browser/tools_search_logs_view.html > Proxied auth leads to wrong DIT/rootDSE being used > -- > > Key: DIRSTUDIO-1285 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1285 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: brent s. >Priority: Major > > If using Apache Directory Studio as a client to OpenLDAP using [remote > bind|https://www.openldap.org/faq/data/cache/532.html] (see *Identity > Assertion*), the incorrect DIT/rootDSE is used and the proper DIT/rootDSE is > seemingly never detected. > For example, the following scenario: > > BindDN (as configured in the connection profile): _cn=joe,dc=foo,dc=bar_ > Server (as configured in the connection profile): _ldap://baz.domain.tld:389_ > _ldap://baz.domain.tld:389_ contains *dc=baz,dc=quux*. > *dc=baz,dc=quux* is configured to proxy all bind requests for *anything under > dc=foo,dc=bar* to proxy (back-ldap) the bind request to > _ldap://foo.domain.tld:389_ using identity assertion. > _ldap://foo.domain.tld:389_ obviously contains *dc=foo,dc=bar*. > > > When the above bindDN and Server is used, binding successfully takes place. > However, the only DIT/rootDSE visible is *dc=foo,dc=bar* and _*not*_ > *dc=baz,dc=quux*! In other words, the DIT that exists on the actual server. > This is, obviously, incorrect. > This is handled correctly in the openLDAP clients (e.g. _ldapsearch_). > > Ensuring "Get base DNs from Root DSE" is checked in the connection profile > does not change this behavior. _Ensuring that is disabled and specifying > e.g._ *dc=baz,dc=quux* _manually as the base DN does not change this > behavior!_ Using the "Fetch Base DNs" button does not change this behavior; > it only detects *dc=foo,dc=bar*. > > I can see both DIT DNs in the root DSE's _namingContexts_ attributes. -- 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] [Comment Edited] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17389780#comment-17389780
]
Stefan Seelmann edited comment on DIRSTUDIO-1284 at 7/29/21, 9:36 AM:
--
Which LDAP server do you use? Googling for the error message ("Must supply
correct old password to change to new one") reveals it's OpenLDAP and
especially the password policy overlay, but I better ask for it.
Can you also check in the "Modification Logs" view which modify operation is
sent in both Studio versions to the server? (don't post real passwords) Does it
send a combindes delete+add or a replace, see attached screenshot for an
example: !screenshot-1.png!
Last not least, since Studio version M16 there is support for the "Password
Modify Extended Operation" which provides better support for changing
passwords: Right-click on the entry -> Extended Operations -> Password Modify...
was (Author: seelmann):
Which LDAP server do you use? Googling for the error message ("Must supply
correct old password to change to new one") reveals it's OpenLDAP and
especially the password policy overlay, but I better ask for it.
Can you also check in the "Modification Logs" view which modify operation is
sent in both Studio versions to the server? Does it send a combindes delete+add
or a replace, see attached screenshot for an example: !screenshot-1.png!
Last not least, since Studio version M16 there is support for the "Password
Modify Extended Operation" which provides better support for changing
passwords: Right-click on the entry -> Extended Operations -> Password Modify...
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M15
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
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] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17389780#comment-17389780
]
Stefan Seelmann commented on DIRSTUDIO-1284:
Which LDAP server do you use? Googling for the error message ("Must supply
correct old password to change to new one") reveals it's OpenLDAP and
especially the password policy overlay, but I better ask for it.
Can you also check in the "Modification Logs" view which modify operation is
sent in both Studio versions to the server? Does it send a combindes delete+add
or a replace, see attached screenshot for an example: !screenshot-1.png!
Last not least, since Studio version M16 there is support for the "Password
Modify Extended Operation" which provides better support for changing
passwords: Right-click on the entry -> Extended Operations -> Password Modify...
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M15
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
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] [Updated] (DIRSTUDIO-1284) Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] - Must supply correct old password to change to new one
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann updated DIRSTUDIO-1284:
---
Attachment: screenshot-1.png
> Error while executing LDIF - [LDAP result code 53 - unwillingToPerform] -
> Must supply correct old password to change to new one
> ---
>
> Key: DIRSTUDIO-1284
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1284
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldifeditor
>Affects Versions: 2.0.0-M17
> Environment: Mac OS 11.4, running on a MacBook Pro (16-inch, 2019)
>Reporter: Katie Golan
>Priority: Major
> Fix For: 2.0.0-M15
>
> Attachments: Screen Shot 2021-07-06 at 9.22.13 AM.jpg, Screen Shot
> 2021-07-28 at 3.36.39 PM.png, screenshot-1.png
>
>
> The current version of Apache Directory Studio (2.0.0.v20210717-M17) seems to
> have a bug with password resets. I’ve confirmed that version
> {{2.0.0.v20200411-M15}} does not have this bug.
> # In Password Editor, the same password is entered for "Enter New Password"
> and "Confirm New Password"
> # When you click "OK", the following error results:
> "Error while executing LDIF
> - [LDAP result code 53 - unwillingToPerform] Must supply correct old
> password to change to new one"
>
> * I successfully reset the password for User A on version M15.
> * After upgrading to version M17, I got the above error when attempting a
> password reset for User A.
> * I then uninstalled Apache, rebooted, and reinstalled version M15.
> * After M15 reinstall, I was able to successfully reset User A's password
> again.
--
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] [Updated] (DIRSTUDIO-1280) Studio browser connections to replicated LDAP dont work with Mac OS Big Sur
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1280: --- Fix Version/s: 2.0.0-M17 > Studio browser connections to replicated LDAP dont work with Mac OS Big Sur > --- > > Key: DIRSTUDIO-1280 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1280 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Mac OS Big Sur 11.2.3 > Mac OS Big Sur 11.4 >Reporter: Sourabh Idoorkar >Priority: Major > Fix For: 2.0.0-M17 > > > I was using Apache Studio to connect to my LDAP which is setup in a > replicated topology. Mostly the LDAP Browser to view and edit data. This was > working fine. But recently my Mac went through the Big Sur update and since > then the studio browser to a replicated topology is not working. > I see the Root DSE as blank on the LDAP Browser > Reason I think this could be a Studio issue with the Mac Big Sur version > # I have investigated everything possible from my LDAP end and there have > been no recent changes to begin with > # I ended up trying Apache Studio from my Windows laptop and that worked > fine for the same LDAP. No issues with connection or browsing. That was with > M13 version > # I have since tried JXplorer to isolate if maybe its something to do with > MAC to LDAP connection rather than Studio to LDAP. But connections via > JXplorer work fine - view as well as edits > # Re-importing connections to Studio did not work - I thought maybe the > connections have a new format and the old one doesnt work anymore > # I tried it on a friend's laptop which is also MAC but older OS and it > works fine there > # Trying to run an older version M14 in the Mac Big Sur results in - > java.lang.NullPointerException: Cannot invoke > "org.eclipse.swt.internal.cocoa.NSGraphicsContext.graphicsPort()" because > "graphicsContext" is null -- 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] [Closed] (DIRSTUDIO-1280) Studio browser connections to replicated LDAP dont work with Mac OS Big Sur
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann closed DIRSTUDIO-1280. -- Resolution: Fixed > Studio browser connections to replicated LDAP dont work with Mac OS Big Sur > --- > > Key: DIRSTUDIO-1280 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1280 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Mac OS Big Sur 11.2.3 > Mac OS Big Sur 11.4 >Reporter: Sourabh Idoorkar >Priority: Major > Fix For: 2.0.0-M17 > > > I was using Apache Studio to connect to my LDAP which is setup in a > replicated topology. Mostly the LDAP Browser to view and edit data. This was > working fine. But recently my Mac went through the Big Sur update and since > then the studio browser to a replicated topology is not working. > I see the Root DSE as blank on the LDAP Browser > Reason I think this could be a Studio issue with the Mac Big Sur version > # I have investigated everything possible from my LDAP end and there have > been no recent changes to begin with > # I ended up trying Apache Studio from my Windows laptop and that worked > fine for the same LDAP. No issues with connection or browsing. That was with > M13 version > # I have since tried JXplorer to isolate if maybe its something to do with > MAC to LDAP connection rather than Studio to LDAP. But connections via > JXplorer work fine - view as well as edits > # Re-importing connections to Studio did not work - I thought maybe the > connections have a new format and the old one doesnt work anymore > # I tried it on a friend's laptop which is also MAC but older OS and it > works fine there > # Trying to run an older version M14 in the Mac Big Sur results in - > java.lang.NullPointerException: Cannot invoke > "org.eclipse.swt.internal.cocoa.NSGraphicsContext.graphicsPort()" because > "graphicsContext" is null -- 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] [Comment Edited] (DIRSTUDIO-1283) Generated update site is broken
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386678#comment-17386678
]
Stefan Seelmann edited comment on DIRSTUDIO-1283 at 7/24/21, 8:58 AM:
--
As a workaround for 2.0.0-M17 release it's possible to delete the *.xml.xz
files, the Eclipse update will then fallback to the *.jar files which contain
the correct content.
https://lists.apache.org/thread.html/r29efa567f0638cb951e0c2dffbf161129d19e1970564879350719bfa%40%3Ccommits.directory.apache.org%3E
{noformat}
svn commit: r48977 - in
/release/directory/studio/2.0.0.v20210717-M17/update/dependencies:
artifacts.xml.xz artifacts.xml.xz.asc artifacts.xml.xz.sha256
artifacts.xml.xz.sha512 content.xml.xz content.xml.xz.asc content.xml.xz.sha256
content.xml.xz.sha512
Author: seelmann
Date: Sat Jul 24 08:32:41 2021
New Revision: 48977
Log:
DIRSTUDIO-1283: Workaround for broken update site: remove wrong xml.xz files,
fallback to jars
Removed:
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/artifacts.xml.xz
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/artifacts.xml.xz.asc
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/artifacts.xml.xz.sha256
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/artifacts.xml.xz.sha512
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/content.xml.xz
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/content.xml.xz.asc
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/content.xml.xz.sha256
release/directory/studio/2.0.0.v20210717-M17/update/dependencies/content.xml.xz.sha512
{noformat}
was (Author: seelmann):
As a workaround for 2.0.0-M17 release it's possible to delete the *.xml.xz
files, the Eclipse update will then fallback to the *.jar files which contain
the correct content.
> Generated update site is broken
> ---
>
> Key: DIRSTUDIO-1283
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1283
> Project: Directory Studio
> Issue Type: Task
>Affects Versions: 2.0.0-M17
>Reporter: Stefan Seelmann
>Assignee: Stefan Seelmann
>Priority: Blocker
> Fix For: 2.0.0-M18
>
>
> The artifacts.xml.xz and content.xml.xz files that are generated for the
> update site dependencies is wrong, they only contains parts of the
> dependencies. This means that the update site doesn't work.
--
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] (DIRSTUDIO-1283) Generated update site is broken
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386678#comment-17386678 ] Stefan Seelmann commented on DIRSTUDIO-1283: As a workaround for 2.0.0-M17 release it's possible to delete the *.xml.xz files, the Eclipse update will then fallback to the *.jar files which contain the correct content. > Generated update site is broken > --- > > Key: DIRSTUDIO-1283 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1283 > Project: Directory Studio > Issue Type: Task >Affects Versions: 2.0.0-M17 >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Blocker > Fix For: 2.0.0-M18 > > > The artifacts.xml.xz and content.xml.xz files that are generated for the > update site dependencies is wrong, they only contains parts of the > dependencies. This means that the update site doesn't work. -- 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] (DIRSTUDIO-1283) Generated update site is broken
Stefan Seelmann created DIRSTUDIO-1283: -- Summary: Generated update site is broken Key: DIRSTUDIO-1283 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1283 Project: Directory Studio Issue Type: Task Affects Versions: 2.0.0-M17 Reporter: Stefan Seelmann Assignee: Stefan Seelmann Fix For: 2.0.0-M18 The artifacts.xml.xz and content.xml.xz files that are generated for the update site dependencies is wrong, they only contains parts of the dependencies. This means that the update site doesn't work. -- 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] (DIRSTUDIO-1280) Studio browser connections to replicated LDAP dont work with Mac OS Big Sur
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17382757#comment-17382757 ] Stefan Seelmann commented on DIRSTUDIO-1280: Which LDAP servers do you use? If it's Oracle then likely then it's like the same reason as in DIRSTUDIO-1271. The next Studio release is currently voted on, if you want you can already test it, infos are here: https://lists.apache.org/thread.html/r19666e069490491eb7c58420dde9c8900ac6dbf3eb001f5f1250ba8e%40%3Cdev.directory.apache.org%3E > Studio browser connections to replicated LDAP dont work with Mac OS Big Sur > --- > > Key: DIRSTUDIO-1280 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1280 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Mac OS Big Sur 11.2.3 > Mac OS Big Sur 11.4 >Reporter: Sourabh Idoorkar >Priority: Major > > I was using Apache Studio to connect to my LDAP which is setup in a > replicated topology. Mostly the LDAP Browser to view and edit data. This was > working fine. But recently my Mac went through the Big Sur update and since > then the studio browser to a replicated topology is not working. > I see the Root DSE as blank on the LDAP Browser > Reason I think this could be a Studio issue with the Mac Big Sur version > # I have investigated everything possible from my LDAP end and there have > been no recent changes to begin with > # I ended up trying Apache Studio from my Windows laptop and that worked > fine for the same LDAP. No issues with connection or browsing. That was with > M13 version > # I have since tried JXplorer to isolate if maybe its something to do with > MAC to LDAP connection rather than Studio to LDAP. But connections via > JXplorer work fine - view as well as edits > # Re-importing connections to Studio did not work - I thought maybe the > connections have a new format and the old one doesnt work anymore > # I tried it on a friend's laptop which is also MAC but older OS and it > works fine there > # Trying to run an older version M14 in the Mac Big Sur results in - > java.lang.NullPointerException: Cannot invoke > "org.eclipse.swt.internal.cocoa.NSGraphicsContext.graphicsPort()" because > "graphicsContext" is null -- 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] (DIRSERVER-2350) Database corruption
[
https://issues.apache.org/jira/browse/DIRSERVER-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17371575#comment-17371575
]
Stefan Seelmann commented on DIRSERVER-2350:
https://directory.apache.org/apacheds/production-readiness.html
> Database corruption
> ---
>
> Key: DIRSERVER-2350
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2350
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0.AM26
>Reporter: Matt Pavlovich
>Priority: Major
>
> A test-only LDAP server running with a small number of entries appears to
> have become corrupt and will no longer start clean
> {noformat}
> [09:28:54] WARN [org.apache.directory.api.ldap.model.entry.Value] -
> MSG_13202_AT_IS_NULL ()
> [09:28:54] WARN [org.apache.directory.api.ldap.model.entry.Value] -
> MSG_13202_AT_IS_NULL ()
> [09:28:54] ERROR [org.apache.directory.server.UberjarMain] - Failed to start
> the service.
> org.apache.directory.api.ldap.model.exception.LdapOtherException
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:91)
> at
> org.apache.directory.server.core.DefaultDirectoryService.initialize(DefaultDirectoryService.java:1986)
> at
> org.apache.directory.server.core.DefaultDirectoryService.startup(DefaultDirectoryService.java:1244)
> at
> org.apache.directory.server.ApacheDsService.initDirectoryService(ApacheDsService.java:390)
> at
> org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:205)
> at
> org.apache.directory.server.ApacheDsService.start(ApacheDsService.java:152)
> at org.apache.directory.server.UberjarMain.start(UberjarMain.java:153)
> at org.apache.directory.server.UberjarMain.main(UberjarMain.java:80)
> Caused by: org.apache.directory.api.ldap.model.exception.LdapOtherException
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:91)
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.addContextPartition(DefaultPartitionNexus.java:834)
> at
> org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.doInit(DefaultPartitionNexus.java:242)
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:86)
> ... 7 more
> Caused by: org.apache.directory.api.ldap.model.exception.LdapOtherException
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.convertAndInit(JdbmPartition.java:835)
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.setupSystemIndices(AbstractBTreePartition.java:437)
> at
> org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.doInit(AbstractBTreePartition.java:629)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.doInit(JdbmPartition.java:511)
> at
> org.apache.directory.server.core.api.partition.AbstractPartition.initialize(AbstractPartition.java:86)
> ... 10 more
> Caused by: java.io.EOFException
> at
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2797)
> at
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3272)
> at
> java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:932)
> at java.io.ObjectInputStream.(ObjectInputStream.java:394)
> at jdbm.helper.Serialization.deserialize(Serialization.java:93)
> at jdbm.helper.DefaultSerializer.deserialize(DefaultSerializer.java:95)
> at jdbm.recman.BaseRecordManager.fetch(BaseRecordManager.java:329)
> at jdbm.recman.CacheRecordManager.fetch(CacheRecordManager.java:264)
> at jdbm.recman.CacheRecordManager.fetch(CacheRecordManager.java:243)
> at jdbm.btree.BTree.load(BTree.java:248)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.(JdbmTable.java:150)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.initTables(JdbmIndex.java:209)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.init(JdbmIndex.java:166)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.convertAndInit(JdbmPartition.java:831)
> ... 14 more
> {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] [Resolved] (DIRAPI-377) Add LDAP Relax Rules Control
[ https://issues.apache.org/jira/browse/DIRAPI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRAPI-377. Resolution: Fixed https://github.com/apache/directory-ldap-api/commit/12353c1487412b0c7e0d36a68297ab713dd0 > Add LDAP Relax Rules Control > > > Key: DIRAPI-377 > URL: https://issues.apache.org/jira/browse/DIRAPI-377 > Project: Directory Client API > Issue Type: Improvement >Reporter: Stefan Seelmann >Assignee: Shawn McKinney >Priority: Minor > Fix For: 2.1.0 > > -- 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-377) Add LDAP Relax Rules Control
Stefan Seelmann created DIRAPI-377: -- Summary: Add LDAP Relax Rules Control Key: DIRAPI-377 URL: https://issues.apache.org/jira/browse/DIRAPI-377 Project: Directory Client API Issue Type: Improvement Reporter: Stefan Seelmann Assignee: Shawn McKinney Fix For: 2.1.0 -- 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] [Resolved] (DIRAPI-376) Change getRootDse() to return all user and operational attibutes
[ https://issues.apache.org/jira/browse/DIRAPI-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRAPI-376. Resolution: Fixed > Change getRootDse() to return all user and operational attibutes > > > Key: DIRAPI-376 > URL: https://issues.apache.org/jira/browse/DIRAPI-376 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > -- 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-376) Change getRootDse() to return all user and operational attibutes
[ https://issues.apache.org/jira/browse/DIRAPI-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17368413#comment-17368413 ] Stefan Seelmann commented on DIRAPI-376: https://github.com/apache/directory-ldap-api/commit/06d26e840ee316b5f510ab48019c6390ec972747 > Change getRootDse() to return all user and operational attibutes > > > Key: DIRAPI-376 > URL: https://issues.apache.org/jira/browse/DIRAPI-376 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > -- 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] [Updated] (DIRAPI-376) Change getRootDse() to return all user and operational attibutes
[ https://issues.apache.org/jira/browse/DIRAPI-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRAPI-376: --- Component/s: (was: ldap) Fix Version/s: (was: 2.0.3) 2.0.3 Key: DIRAPI-376 (was: DIRSERVER-2349) Affects Version/s: (was: 2.0.2) 2.0.2 Project: Directory Client API (was: Directory ApacheDS) > Change getRootDse() to return all user and operational attibutes > > > Key: DIRAPI-376 > URL: https://issues.apache.org/jira/browse/DIRAPI-376 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > -- 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] (DIRSERVER-2349) Change getRootDse() to return all user and operational attibutes
Stefan Seelmann created DIRSERVER-2349: -- Summary: Change getRootDse() to return all user and operational attibutes Key: DIRSERVER-2349 URL: https://issues.apache.org/jira/browse/DIRSERVER-2349 Project: Directory ApacheDS Issue Type: Improvement Components: ldap Affects Versions: 2.0.2 Reporter: Stefan Seelmann Fix For: 2.0.3 -- 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] [Updated] (DIRSTUDIO-1279) Show SSL/TLS connection info and certificates
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1279: --- Description: Add a button to view the used protcol, cipher suite, and the certificate chain for a connection if SSL or StartTLS is configured. (was: Add a button to view the certificate chain for a connection if SSL or StartTLS is configured.) Summary: Show SSL/TLS connection info and certificates (was: Show connection certificate) > Show SSL/TLS connection info and certificates > - > > Key: DIRSTUDIO-1279 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1279 > Project: Directory Studio > Issue Type: Improvement > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Add a button to view the used protcol, cipher suite, and the certificate > chain for a connection if SSL or StartTLS is configured. -- 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] (DIRSTUDIO-1279) Show SSL/TLS connection info and certificates
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367007#comment-17367007 ] Stefan Seelmann commented on DIRSTUDIO-1279: https://github.com/apache/directory-studio/commit/3712a950b9f33664bbd70f19e97d5cbc7e6d0022 > Show SSL/TLS connection info and certificates > - > > Key: DIRSTUDIO-1279 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1279 > Project: Directory Studio > Issue Type: Improvement > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Add a button to view the used protcol, cipher suite, and the certificate > chain for a connection if SSL or StartTLS is configured. -- 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] [Resolved] (DIRSTUDIO-1011) ApacheStudio sends SSLv2 Client Hello
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann resolved DIRSTUDIO-1011.
Resolution: Done
Tested with a current Java 11.0.11 and 17-ea, Studio sends either TLSv1.2 or
TLSv1.3.
I assume it was caused by usage of older Java versions.
> ApacheStudio sends SSLv2 Client Hello
> -
>
> Key: DIRSTUDIO-1011
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1011
> Project: Directory Studio
> Issue Type: Bug
>Affects Versions: 2.0.0-M8 (2.0.0.v20130628)
>Reporter: Roy Wellington
>Priority: Major
>
> I'm attempting to configure TLS on a ApacheDS server. I've checked the boxes
> indicated by the docs; attempting to connect over either StartTLS or LDAPS
> both result in "SSL handshake failed."
> Tracing the conversation in Wireshark shows that ApacheDS is sending an SSLv2
> (!) Client Hello, which the server responds to with a TLSv1.0 "Unexpected
> Message" (which is correct). ApacheDS should not be sending an SSLv2 Client
> Hello; instead, it should use the most recent version of TLS. (SSLv2, and
> SSLv3, are broken, and insecure.)
> Simply running,
> {noformat}
> % ldapsearch -H ldaps://:10636
> {noformat}
> …gets me further in the conversation. (Although {{ldapsearch}} complains
> about a bad certificate, but that's because the cert is self-signed;
> Wireshark shows that it _is_ getting further in the SSL conversation (it is
> getting a Server Hello back) than ApacheDS.)
> Note: I'm connecting to an ApacheDS server running on a linux VM, through an
> SSH tunnel; I've edited /etc/hosts so that the DNS name still points to the
> right spot. This should not matter, and I can still connect with openssl (to
> the LDAPS side; obviously openssl is not capable of StartTLS).
--
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] [Resolved] (DIRAPI-375) Add TLSv1.3 to default protocols
[ https://issues.apache.org/jira/browse/DIRAPI-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRAPI-375. Resolution: Fixed https://github.com/apache/directory-ldap-api/commit/4322886f8ed9fe0d2c588f0c557e92e4d160149f > Add TLSv1.3 to default protocols > > > Key: DIRAPI-375 > URL: https://issues.apache.org/jira/browse/DIRAPI-375 > Project: Directory Client API > Issue Type: Improvement >Reporter: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > -- 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-375) Add TLSv1.3 to default protocols
Stefan Seelmann created DIRAPI-375: -- Summary: Add TLSv1.3 to default protocols Key: DIRAPI-375 URL: https://issues.apache.org/jira/browse/DIRAPI-375 Project: Directory Client API Issue Type: Improvement Reporter: Stefan Seelmann Fix For: 2.0.3 -- 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] [Resolved] (DIRSTUDIO-761) GSSAPI Authentication fails when using ADS LDAP Client API
[ https://issues.apache.org/jira/browse/DIRSTUDIO-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-761. --- Resolution: Fixed This has been fixed in scope of the linked issues and tests have been added. > GSSAPI Authentication fails when using ADS LDAP Client API > -- > > Key: DIRSTUDIO-761 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-761 > Project: Directory Studio > Issue Type: Bug > Components: studio-connection >Affects Versions: 2.0.0-M1 (2.0.0.v20120111) > Environment: Debian Wheezy >Reporter: Bill MacAllister >Priority: Minor > Fix For: 2.0.0-M17 > > > GSSAPI connections to an OpenLDAP server fail when using ADS LDAP Client API > with the following error message: > Error while opening connection > - Missing schema location in RootDSE, using default schema. > Missing schema location in RootDSE, using default schema. > The connection succeeds when the connection is changed to use JNDI. -- 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] (DIRSTUDIO-1219) Directory Studio doesn't StartTLS before authenticating
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366162#comment-17366162
]
Stefan Seelmann commented on DIRSTUDIO-1219:
Changed usage of {{useTls}} flag in the LDAP API:
https://issues.apache.org/jira/browse/DIRAPI-374
https://github.com/apache/directory-ldap-api/commit/bf32f0e902ffb08839defcaf3c1de5164d83e092
Call {{startTls()}} always after connect, verify that the connection is
secured. Also add various tests where the server requries confidentiality:
https://github.com/apache/directory-studio/commit/b53667ab3b87afcfcd6f1b1df90d733636cfc888
> 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
>Affects Versions: 2.0.0-M16
> Environment: Apache Directory Studio is running on Mac OS 10.14 with
> jdk1.8.0_201.
>Reporter: Hugh Cole-Baker
>Assignee: Stefan Seelmann
>Priority: Blocker
> Fix For: 2.0.0-M17
>
>
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1219) Directory Studio doesn't StartTLS before authenticating
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1219. Resolution: Fixed > 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 >Affects Versions: 2.0.0-M16 > Environment: Apache Directory Studio is running on Mac OS 10.14 with > jdk1.8.0_201. >Reporter: Hugh Cole-Baker >Assignee: Stefan Seelmann >Priority: Blocker > Fix For: 2.0.0-M17 > > > 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 (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] (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&focusedCommentId=17366138#comment-17366138 ] Stefan Seelmann commented on DIRSTUDIO-1220: Implemented SASL security layer in the LDAP API https://issues.apache.org/jira/browse/DIRAPI-373: https://github.com/apache/directory-ldap-api/commit/2cf66a14c58d4c0ddd3dd3700566a4e72cdb3518 Use that LDAP API version and added tests: https://github.com/apache/directory-studio/commit/18ad16e89deb2998ee0fef0f16a9a85a0df1ddd2 > 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 > Fix For: 2.0.0-M17 > > > 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 (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (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:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1220. Assignee: Stefan Seelmann Resolution: Fixed > 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 >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > 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 (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-1670) DIGEST-MD5 authentication mechanism must support encryption
[ https://issues.apache.org/jira/browse/DIRSERVER-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSERVER-1670. Fix Version/s: (was: 2.0.0-RC1) 2.0.0.AM27 Resolution: Fixed Fixed in https://issues.apache.org/jira/browse/DIRSERVER-1632 > DIGEST-MD5 authentication mechanism must support encryption > --- > > Key: DIRSERVER-1670 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1670 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 1.5.7 > Environment: all >Reporter: Hendy Irawan >Priority: Major > Fix For: 2.0.0.AM27 > > > While DIGEST-MD5 should work, encryption doesn't work currently. > A workaround is to disable data security at the client side: > ldapsearch -O "maxssf=0" ... > However, this doesn't work for all clients. (e.g. Thunderbird) -- 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] [Resolved] (DIRSERVER-1632) Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP API fails and throws a decoder exception
[ https://issues.apache.org/jira/browse/DIRSERVER-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSERVER-1632. Resolution: Fixed > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception > -- > > Key: DIRSERVER-1632 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1632 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 2.0.0-M1 >Reporter: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0.AM27 > > > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception. > This only happens when we use the Apache LDAP API to connect to the server. > It works fine using JNDI (with Studio for example). > Two test cases have been added to the > org.apache.directory.server.operations.bind.SaslBindIT class: > - testSaslDigestMd5BindSaslQoPAuthInt() > - testSaslDigestMd5BindSaslQoPAuthConf() > These two tests have been ignored at the moment to avoid build breakage. > Here's the complete stacktrace: > # > org.apache.mina.filter.codec.ProtocolDecoderException: > org.apache.directory.shared.ldap.codec.api.ResponseCarryingException: > ERR_1_BAD_TRANSITION_FROM_STATE Bad transition from state START_STATE, > tag 0x00 (Hexdump: 30 36 02 01 02 61 31 0A 01 00 04 00 04 00 87 28 72 73 70 > 61 75 74 68 3D 63 34 31 63 34 35 65 34 37 31 39 63 33 62 66 37 63 38 63 63 39 > 37 61 64 33 66 32 66 61 37 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00
[jira] [Commented] (DIRSERVER-1632) Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP API fails and throws a decoder exception
[ https://issues.apache.org/jira/browse/DIRSERVER-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366127#comment-17366127 ] Stefan Seelmann commented on DIRSERVER-1632: Added additional tests using openldap cmdline tools: https://github.com/apache/directory-server/commit/77a842e7442936903141ad031eeabdd7ffb0573f > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception > -- > > Key: DIRSERVER-1632 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1632 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 2.0.0-M1 >Reporter: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0.AM27 > > > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception. > This only happens when we use the Apache LDAP API to connect to the server. > It works fine using JNDI (with Studio for example). > Two test cases have been added to the > org.apache.directory.server.operations.bind.SaslBindIT class: > - testSaslDigestMd5BindSaslQoPAuthInt() > - testSaslDigestMd5BindSaslQoPAuthConf() > These two tests have been ignored at the moment to avoid build breakage. > Here's the complete stacktrace: > # > org.apache.mina.filter.codec.ProtocolDecoderException: > org.apache.directory.shared.ldap.codec.api.ResponseCarryingException: > ERR_1_BAD_TRANSITION_FROM_STATE Bad transition from state START_STATE, > tag 0x00 (Hexdump: 30 36 02 01 02 61 31 0A 01 00 04 00 04 00 87 28 72 73 70 > 61 75 74 68 3D 63 34 31 63 34 35 65 34 37 31 39 63 33 62 66 37 63 38 63 63 39 > 37 61 64 33 66 32 66 61 37 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00
[jira] [Commented] (DIRSERVER-1632) Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP API fails and throws a decoder exception
[ https://issues.apache.org/jira/browse/DIRSERVER-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366109#comment-17366109 ] Stefan Seelmann commented on DIRSERVER-1632: https://github.com/apache/directory-server/commit/e71b7260dcdddf8611701384cfe0559c53ec03a5 > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception > -- > > Key: DIRSERVER-1632 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1632 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 2.0.0-M1 >Reporter: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0.AM27 > > > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception. > This only happens when we use the Apache LDAP API to connect to the server. > It works fine using JNDI (with Studio for example). > Two test cases have been added to the > org.apache.directory.server.operations.bind.SaslBindIT class: > - testSaslDigestMd5BindSaslQoPAuthInt() > - testSaslDigestMd5BindSaslQoPAuthConf() > These two tests have been ignored at the moment to avoid build breakage. > Here's the complete stacktrace: > # > org.apache.mina.filter.codec.ProtocolDecoderException: > org.apache.directory.shared.ldap.codec.api.ResponseCarryingException: > ERR_1_BAD_TRANSITION_FROM_STATE Bad transition from state START_STATE, > tag 0x00 (Hexdump: 30 36 02 01 02 61 31 0A 01 00 04 00 04 00 87 28 72 73 70 > 61 75 74 68 3D 63 34 31 63 34 35 65 34 37 31 39 63 33 62 66 37 63 38 63 63 39 > 37 61 64 33 66 32 66 61 37 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[jira] [Updated] (DIRSERVER-1632) Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP API fails and throws a decoder exception
[ https://issues.apache.org/jira/browse/DIRSERVER-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSERVER-1632: --- Fix Version/s: (was: 2.0.0-RC1) 2.0.0.AM27 > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception > -- > > Key: DIRSERVER-1632 > URL: https://issues.apache.org/jira/browse/DIRSERVER-1632 > Project: Directory ApacheDS > Issue Type: Bug > Components: authn >Affects Versions: 2.0.0-M1 >Reporter: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0.AM27 > > > Setting SASL QoP to 'auth-int' or 'auth-conf' while connecting using the LDAP > API fails and throws a decoder exception. > This only happens when we use the Apache LDAP API to connect to the server. > It works fine using JNDI (with Studio for example). > Two test cases have been added to the > org.apache.directory.server.operations.bind.SaslBindIT class: > - testSaslDigestMd5BindSaslQoPAuthInt() > - testSaslDigestMd5BindSaslQoPAuthConf() > These two tests have been ignored at the moment to avoid build breakage. > Here's the complete stacktrace: > # > org.apache.mina.filter.codec.ProtocolDecoderException: > org.apache.directory.shared.ldap.codec.api.ResponseCarryingException: > ERR_1_BAD_TRANSITION_FROM_STATE Bad transition from state START_STATE, > tag 0x00 (Hexdump: 30 36 02 01 02 61 31 0A 01 00 04 00 04 00 87 28 72 73 70 > 61 75 74 68 3D 63 34 31 63 34 35 65 34 37 31 39 63 33 62 66 37 63 38 63 63 39 > 37 61 64 33 66 32 66 61 37 39 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
[jira] [Resolved] (DIRAPI-373) Implement SASL integrity and confidentiality layer
[ https://issues.apache.org/jira/browse/DIRAPI-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRAPI-373. Resolution: Fixed > Implement SASL integrity and confidentiality layer > -- > > Key: DIRAPI-373 > URL: https://issues.apache.org/jira/browse/DIRAPI-373 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > > The LDAP API currently only implements SASL authentication, the security > layer with integrity and confidentiality is not implemented. -- 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] [Resolved] (DIRAPI-374) Consistify LdapConnectionConfig useTls and useSsl flags
[
https://issues.apache.org/jira/browse/DIRAPI-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann resolved DIRAPI-374.
Resolution: Fixed
> Consistify LdapConnectionConfig useTls and useSsl flags
> ---
>
> Key: DIRAPI-374
> URL: https://issues.apache.org/jira/browse/DIRAPI-374
> Project: Directory Client API
> Issue Type: Improvement
>Affects Versions: 2.0.2
>Reporter: Stefan Seelmann
>Assignee: Stefan Seelmann
>Priority: Major
> Fix For: 2.0.3
>
>
> The {{LdapConnectionConfig}} class contains two flags {{useSsl}} and
> {{useTls}}. If {{useSsl}} is true the {{SslFilter}} added to the filter chain
> during {{connect()}} and the secure layer is automatically established. If
> {{useTls}} is true that's not the case, the {{SslFilter}} is only added when
> calling {{startTls()}} explicitly or if a simple or anonymous bind is
> performed, but for example not if a SASL bind is performed.
--
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-374) Consistify LdapConnectionConfig useTls and useSsl flags
[
https://issues.apache.org/jira/browse/DIRAPI-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366017#comment-17366017
]
Stefan Seelmann commented on DIRAPI-374:
https://github.com/apache/directory-ldap-api/commit/bf32f0e902ffb08839defcaf3c1de5164d83e092
> Consistify LdapConnectionConfig useTls and useSsl flags
> ---
>
> Key: DIRAPI-374
> URL: https://issues.apache.org/jira/browse/DIRAPI-374
> Project: Directory Client API
> Issue Type: Improvement
>Affects Versions: 2.0.2
>Reporter: Stefan Seelmann
>Assignee: Stefan Seelmann
>Priority: Major
> Fix For: 2.0.3
>
>
> The {{LdapConnectionConfig}} class contains two flags {{useSsl}} and
> {{useTls}}. If {{useSsl}} is true the {{SslFilter}} added to the filter chain
> during {{connect()}} and the secure layer is automatically established. If
> {{useTls}} is true that's not the case, the {{SslFilter}} is only added when
> calling {{startTls()}} explicitly or if a simple or anonymous bind is
> performed, but for example not if a SASL bind is performed.
--
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-374) Consistify LdapConnectionConfig useTls and useSsl flags
Stefan Seelmann created DIRAPI-374:
--
Summary: Consistify LdapConnectionConfig useTls and useSsl flags
Key: DIRAPI-374
URL: https://issues.apache.org/jira/browse/DIRAPI-374
Project: Directory Client API
Issue Type: Improvement
Affects Versions: 2.0.2
Reporter: Stefan Seelmann
Assignee: Stefan Seelmann
Fix For: 2.0.3
The {{LdapConnectionConfig}} class contains two flags {{useSsl}} and
{{useTls}}. If {{useSsl}} is true the {{SslFilter}} added to the filter chain
during {{connect()}} and the secure layer is automatically established. If
{{useTls}} is true that's not the case, the {{SslFilter}} is only added when
calling {{startTls()}} explicitly or if a simple or anonymous bind is
performed, but for example not if a SASL bind is performed.
--
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-373) Implement SASL integrity and confidentiality layer
[ https://issues.apache.org/jira/browse/DIRAPI-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365666#comment-17365666 ] Stefan Seelmann commented on DIRAPI-373: https://github.com/apache/directory-ldap-api/commit/2cf66a14c58d4c0ddd3dd3700566a4e72cdb3518 > Implement SASL integrity and confidentiality layer > -- > > Key: DIRAPI-373 > URL: https://issues.apache.org/jira/browse/DIRAPI-373 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.3 > > > The LDAP API currently only implements SASL authentication, the security > layer with integrity and confidentiality is not implemented. -- 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-373) Implement SASL integrity and confidentiality layer
Stefan Seelmann created DIRAPI-373: -- Summary: Implement SASL integrity and confidentiality layer Key: DIRAPI-373 URL: https://issues.apache.org/jira/browse/DIRAPI-373 Project: Directory Client API Issue Type: Improvement Affects Versions: 2.0.2 Reporter: Stefan Seelmann Assignee: Stefan Seelmann Fix For: 2.0.3 The LDAP API currently only implements SASL authentication, the security layer with integrity and confidentiality is not implemented. -- 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] [Updated] (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:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1220: --- Fix Version/s: 2.0.0-M17 > 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 > Fix For: 2.0.0-M17 > > > 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 (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-761) GSSAPI Authentication fails when using ADS LDAP Client API
[ https://issues.apache.org/jira/browse/DIRSTUDIO-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-761: -- Fix Version/s: 2.0.0-M17 > GSSAPI Authentication fails when using ADS LDAP Client API > -- > > Key: DIRSTUDIO-761 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-761 > Project: Directory Studio > Issue Type: Bug > Components: studio-connection >Affects Versions: 2.0.0-M1 (2.0.0.v20120111) > Environment: Debian Wheezy >Reporter: Bill MacAllister >Priority: Minor > Fix For: 2.0.0-M17 > > > GSSAPI connections to an OpenLDAP server fail when using ADS LDAP Client API > with the following error message: > Error while opening connection > - Missing schema location in RootDSE, using default schema. > Missing schema location in RootDSE, using default schema. > The connection succeeds when the connection is changed to use JNDI. -- 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] (DIRSTUDIO-1279) Show connection certificate
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355915#comment-17355915 ] Stefan Seelmann commented on DIRSTUDIO-1279: Added here: https://github.com/apache/directory-studio/commit/832c1e90837a30ab60c0504cab5c1470cfdbef7c > Show connection certificate > --- > > Key: DIRSTUDIO-1279 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1279 > Project: Directory Studio > Issue Type: Improvement > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Add a button to view the certificate chain for a connection if SSL or > StartTLS is configured. -- 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] [Resolved] (DIRSTUDIO-1279) Show connection certificate
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1279. Resolution: Fixed > Show connection certificate > --- > > Key: DIRSTUDIO-1279 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1279 > Project: Directory Studio > Issue Type: Improvement > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Add a button to view the certificate chain for a connection if SSL or > StartTLS is configured. -- 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] (DIRSTUDIO-1278) SSL certificate always trusgt option is failing
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17354545#comment-17354545
]
Stefan Seelmann commented on DIRSTUDIO-1278:
The actual error is {{Algorithm HmacPBESHA256 not available}} when writing the
accepted certificate to the keystore file.
The HmacPBESHA256 algorithm was added in Java 12 only (but it's now backported
to older Java versions, seehttps://bugs.openjdk.java.net/browse/JDK-8267701).
Did you use Studio before with a newer Java version than Java 11?
A workaround is to delete (or rename/move) the keystore, the file path is
{{~/.ApacheDirectoryStudio/.metadata/.plugins/org.apache.directory.studio.connection.core/permanent.jks}}.
> SSL certificate always trusgt option is failing
> ---
>
> Key: DIRSTUDIO-1278
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1278
> Project: Directory Studio
> Issue Type: Question
> Components: studio-apacheds
>Affects Versions: 2.0.0-M16
>Reporter: steve balon
>Priority: Major
> Attachments: .log, image-2021-05-28-14-43-20-932.png,
> image-2021-05-31-10-21-24-120.png
>
>
> Hi,
>
> I have a new laptop and I install the latest version of Apache Directory
> studio M16.
> I had to play around Java and even if I install the Java SE Version 8 Update
> 291 64 bits.
> Directory studio fail to load.
> so I finally decide to install the openjdk 11LTS and edit the
> ApacheDirectoryStudio.ini to use the openJDK installed.
>
> It finally work but when I connect to my LDAP server, I got always the
> untrusted certificat.
> Which is a valid one raised by GlobalSign.
>
> I can only connect if I accept for once the cert, but then it always ask the
> question.
> I try to find where to add but I'm unable.
> also the always trust fail.
> any idea how to solve that.
>
> and I also add to change the replace parameter as a modification with no
> equality matching rule was not working :(
> I add to use always replace.
>
--
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] [Assigned] (DIRSTUDIO-1219) Directory Studio doesn't StartTLS before authenticating
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann reassigned DIRSTUDIO-1219: -- Fix Version/s: 2.0.0-M17 Affects Version/s: 2.0.0-M16 Assignee: Stefan Seelmann Priority: Blocker (was: Major) > 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 >Affects Versions: 2.0.0-M16 > Environment: Apache Directory Studio is running on Mac OS 10.14 with > jdk1.8.0_201. >Reporter: Hugh Cole-Baker >Assignee: Stefan Seelmann >Priority: Blocker > Fix For: 2.0.0-M17 > > > 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 (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] (DIRSTUDIO-1219) Directory Studio doesn't StartTLS before authenticating
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353933#comment-17353933 ] Stefan Seelmann commented on DIRSTUDIO-1219: Wow, that's correct. Why did we ignore this issue so long? When using SASL authentication StartTLS is not activated and the connections remains unencrypted, even if usage of StartTLS is configured! > 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 >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. 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 (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] (DIRSTUDIO-1279) Show connection certificate
Stefan Seelmann created DIRSTUDIO-1279: -- Summary: Show connection certificate Key: DIRSTUDIO-1279 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1279 Project: Directory Studio Issue Type: Improvement Components: studio-ldapbrowser Affects Versions: 2.0.0-M16 Reporter: Stefan Seelmann Assignee: Stefan Seelmann Fix For: 2.0.0-M17 Add a button to view the certificate chain for a connection if SSL or StartTLS is configured. -- 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] [Comment Edited] (DIRSTUDIO-1278) SSL certificate always trusgt option is failing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353504#comment-17353504 ] Stefan Seelmann edited comment on DIRSTUDIO-1278 at 5/29/21, 7:35 AM: -- Regarding the untrusted certificate: What exact error message do you get? Regarding the certificate reset error in the preferences: Can you please check for errors and stack traces in the "Error Log" view or in the log file (~/.ApacheDirectoryStudio/.metadata/.log) Regarding the Java version: Since 2.0.0.M16 Java 11 is required, that's also mentioned at the download pages, e.g. https://directory.apache.org/studio/download/download-linux.html Regarding replace mode for modifications: Correct, the default behavior changed in 2.0.0.M16, please see https://issues.apache.org/jira/browse/DIRSTUDIO-744 for the reason. was (Author: seelmann): Regarding the certificate reset error: Can you please check for errors and stack traces in the "Error Log" view or in the log file (~/.ApacheDirectoryStudio/.metadata/.log) Regarding the Java version: Since 2.0.0.M16 Java 11 is required, that's also mentioned at the download pages, e.g. https://directory.apache.org/studio/download/download-linux.html Regarding replace mode for modifications: Correct, the default behavior changed in 2.0.0.M16, please see https://issues.apache.org/jira/browse/DIRSTUDIO-744 for the reason. > SSL certificate always trusgt option is failing > --- > > Key: DIRSTUDIO-1278 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1278 > Project: Directory Studio > Issue Type: Question > Components: studio-apacheds >Affects Versions: 2.0.0-M16 >Reporter: steve balon >Priority: Major > Attachments: image-2021-05-28-14-43-20-932.png > > > Hi, > > I have a new laptop and I install the latest version of Apache Directory > studio M16. > I had to play around Java and even if I install the Java SE Version 8 Update > 291 64 bits. > Directory studio fail to load. > so I finally decide to install the openjdk 11LTS and edit the > ApacheDirectoryStudio.ini to use the openJDK installed. > > It finally work but when I connect to my LDAP server, I got always the > untrusted certificat. > Which is a valid one raised by GlobalSign. > > I can only connect if I accept for once the cert, but then it always ask the > question. > I try to find where to add but I'm unable. > also the always trust fail. > any idea how to solve that. > > and I also add to change the replace parameter as a modification with no > equality matching rule was not working :( > I add to use always replace. > -- 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] (DIRSTUDIO-1278) SSL certificate always trusgt option is failing
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353504#comment-17353504 ] Stefan Seelmann commented on DIRSTUDIO-1278: Regarding the certificate reset error: Can you please check for errors and stack traces in the "Error Log" view or in the log file (~/.ApacheDirectoryStudio/.metadata/.log) Regarding the Java version: Since 2.0.0.M16 Java 11 is required, that's also mentioned at the download pages, e.g. https://directory.apache.org/studio/download/download-linux.html Regarding replace mode for modifications: Correct, the default behavior changed in 2.0.0.M16, please see https://issues.apache.org/jira/browse/DIRSTUDIO-744 for the reason. > SSL certificate always trusgt option is failing > --- > > Key: DIRSTUDIO-1278 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1278 > Project: Directory Studio > Issue Type: Question > Components: studio-apacheds >Affects Versions: 2.0.0-M16 >Reporter: steve balon >Priority: Major > Attachments: image-2021-05-28-14-43-20-932.png > > > Hi, > > I have a new laptop and I install the latest version of Apache Directory > studio M16. > I had to play around Java and even if I install the Java SE Version 8 Update > 291 64 bits. > Directory studio fail to load. > so I finally decide to install the openjdk 11LTS and edit the > ApacheDirectoryStudio.ini to use the openJDK installed. > > It finally work but when I connect to my LDAP server, I got always the > untrusted certificat. > Which is a valid one raised by GlobalSign. > > I can only connect if I accept for once the cert, but then it always ask the > question. > I try to find where to add but I'm unable. > also the always trust fail. > any idea how to solve that. > > and I also add to change the replace parameter as a modification with no > equality matching rule was not working :( > I add to use always replace. > -- 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] (DIRSERVER-2348) Mavibot partition data disappears
Stefan Seelmann created DIRSERVER-2348:
--
Summary: Mavibot partition data disappears
Key: DIRSERVER-2348
URL: https://issues.apache.org/jira/browse/DIRSERVER-2348
Project: Directory ApacheDS
Issue Type: Bug
Components: backend, mavibot
Affects Versions: 2.0.0.AM26
Environment: ArchLinux
OpenJDK 1.8.0_292
ApacheDS 2.0.0.AM26
Reporter: Stefan Seelmann
Start a new ApacheDS 2.0.0.AM26 (tar.gz archive on Linux)
Create a connection in Studio 2.0.0.M16, open the ApacheDS configuration, add a
partition type:Mavibot with id:mavibot and suffix:dc=mavibot,dc=com, and save.
Observations:
* The new config is visible in the config partition:
ads-partitionId=mavibot,ou=partitions,ads-directoryServiceId=default,ou=config
(expected).
* The namingContext doesn't yet exist in the Root DSE (expected).
* The partition directory instances/default/partitions doesn't exist yet
(expected).
Restart ApacheDS.
Observations:
* The partition directory {{instances/default/partitions/mavibot}} and a
{{mavibot.db}} was created (expected).
* The {{namingContext:dc=mavibot,dc=com}} exists in the RootDSE (expected)
* The context entry does not exist, despite configured (unexptected!)
Inject the context entry and some other data
{noformat}
dn: dc=mavibot,dc=com
objectclass: domain
objectclass: top
dc: mavibot
{noformat}
Observations:
* The data is there, even after close/open the connection (expected)
* The partition file {{instances/default/partitions/mavibot/mavibot.db}} grow
and has a recent modification time (expected)
Restart ApacheDS
Observations:
* The partition file {{instances/default/partitions/mavibot/mavibot.db}} is
still there, has the same size, but the modification time changed (expected)
* The {{namingContext:dc=mavibot,dc=com}} still exists in the RootDSE (expected)
* The context entry is gone (unexpected!)
Context:
https://lists.apache.org/thread.html/r6142d8abfaf233401ffdc3e96160a3a1b2c38beab24f958757311b20%40%3Cdev.directory.apache.org%3E
--
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] [Closed] (DIRSTUDIO-1053) P2 repository / update site for RCP product
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann closed DIRSTUDIO-1053. -- Resolution: Won't Fix I don't remember why it's needed. > P2 repository / update site for RCP product > --- > > Key: DIRSTUDIO-1053 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1053 > Project: Directory Studio > Issue Type: Task >Reporter: Stefan Seelmann >Priority: Major > > Follow up for DIRSTUDIO-1023. The P2 repository for the Studio product needs > to be generated. Configuration is tricky because Eclipse dependencies should > not be included. -- 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] [Updated] (DIRSTUDIO-1189) dom4j illegal reflective access with Java 11
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1189: --- Fix Version/s: (was: 2.0.0) 2.0.0-M17 > dom4j illegal reflective access with Java 11 > > > Key: DIRSTUDIO-1189 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1189 > Project: Directory Studio > Issue Type: Task >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > When running Studio with Java 11 the following warning is printed, should be > investigated > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.dom4j.io.SAXContentHandler > (file:/.../directory-studio/product/target/products/org.apache.directory.studio.product/linux/gtk/x86_64/ApacheDirectoryStudio/plugins/org.dom4j_1.6.1.v20170815-1500.jar) > to method > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser$LocatorProxy.getEncoding() > -- 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] [Resolved] (DIRSTUDIO-1189) dom4j illegal reflective access with Java 11
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1189. Resolution: Fixed > dom4j illegal reflective access with Java 11 > > > Key: DIRSTUDIO-1189 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1189 > Project: Directory Studio > Issue Type: Task >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > When running Studio with Java 11 the following warning is printed, should be > investigated > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.dom4j.io.SAXContentHandler > (file:/.../directory-studio/product/target/products/org.apache.directory.studio.product/linux/gtk/x86_64/ApacheDirectoryStudio/plugins/org.dom4j_1.6.1.v20170815-1500.jar) > to method > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser$LocatorProxy.getEncoding() > -- 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] [Resolved] (DIRSTUDIO-1272) Remove Network Connections preferences page (socks proxy settings)
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1272. Resolution: Fixed > Remove Network Connections preferences page (socks proxy settings) > -- > > Key: DIRSTUDIO-1272 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1272 > Project: Directory Studio > Issue Type: Task > Components: studio-rcp >Affects Versions: 2.0.0-M16 >Reporter: Stefan Seelmann >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > We have several bug reports [1][2][3] that SOCKS proxy settings don't > work, however there is a preference page [4] in Studio which gives the > impression it's supported. > That preference page is provided by Eclipse. What is does is to set Java > system properties [5]. There are known limitations, e.g. socks > authentication and proxy bypass don't work [6]. There is no additional > code in Studio to support proxies, and also zero tests. > In the past with JNDI the basic settings of a SOCKS proxy worked because > it is handled by Java old blocking IO. > However after the JNDI removal we only support the LDAP API which uses > Mina and new IO where those system properties don't work [7]. > I'd suggest to remove that preference page and related documentation > because its presence gives users the impression it would work. > Remains the question if we should implement proxy support properly in > Studio. It's clearly possible, Mina even implements a proxy filter and > connector. However it's significant effort and requires changes in the > LDAP API and new UIs in Studio and proper unit/integration testing. On > the other side there are dedicated tools which provide transparent SOCKS > proxy support. So I have doubts if it makes sense to implement it in > Studio. > [1] https://issues.apache.org/jira/browse/DIRSTUDIO-501 > [2] https://issues.apache.org/jira/browse/DIRSTUDIO-846 > [3] https://issues.apache.org/jira/browse/DIRSTUDIO-1269 > [4] > https://nightlies.apache.org/directory/studio/2.0.0.v20210213-M16/userguide/apache_directory_studio/network_connections.html > [5] > https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html > [6] https://bugs.eclipse.org/bugs/show_bug.cgi?id=291717 > [7] https://bugs.openjdk.java.net/browse/JDK-8199457 > Discussion one the mailing list: > https://lists.apache.org/thread.html/re4b0474a838a71428e3a624e3a52a55358a01fe72c9cb23ac23a0e30%40%3Cdev.directory.apache.org%3E -- 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] [Resolved] (DIRSTUDIO-1271) Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with M16, previous releases are OK.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1271. Resolution: Fixed > Oracle OUD 11.1.2.3 does not list any Naming Contexts in ldapbrowser with > M16, previous releases are OK. > > > Key: DIRSTUDIO-1271 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1271 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M16 > Environment: Windows with Oracle JDK 11 or Graal/JDK11 >Reporter: Mark Davis >Assignee: Stefan Seelmann >Priority: Major > Fix For: 2.0.0-M17 > > > Using M16, and connecting to Oracle OUD 11.1.2.3 shows Root DSE only, and all > contexts underneath are missing. I can see the available namingContexts in > the Root DSE entry. > Release M14 and before are fine. > A fast test with Forgerock/OpenDJ7.0.1 (derived from the same source, but > diverged) is OK. > -- 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] [Resolved] (DIRSTUDIO-1269) SOCKS proxy is not working
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1269. Resolution: Won't Fix > SOCKS proxy is not working > -- > > Key: DIRSTUDIO-1269 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1269 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M16 > Environment: Windows 10. Apache Directory Studio installed via scoop >Reporter: Philip Brusten >Priority: Major > Fix For: 2.0.0-M17 > > Attachments: image-2021-03-01-10-44-13-793.png > > > When I configure to use SOCKS proxy (SSH-tunnel), the proxy is not used. > My connections eventually timeout. > Screenshot of config: > !image-2021-03-01-10-44-13-793.png! -- 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] [Updated] (DIRSTUDIO-1269) SOCKS proxy is not working
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSTUDIO-1269: --- Fix Version/s: 2.0.0-M17 > SOCKS proxy is not working > -- > > Key: DIRSTUDIO-1269 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1269 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M16 > Environment: Windows 10. Apache Directory Studio installed via scoop >Reporter: Philip Brusten >Priority: Major > Fix For: 2.0.0-M17 > > Attachments: image-2021-03-01-10-44-13-793.png > > > When I configure to use SOCKS proxy (SSH-tunnel), the proxy is not used. > My connections eventually timeout. > Screenshot of config: > !image-2021-03-01-10-44-13-793.png! -- 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] [Resolved] (DIRSTUDIO-1275) I updated on my mac to m16. Now only the proxy servers show the directory tree.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSTUDIO-1275. Resolution: Fixed > I updated on my mac to m16. Now only the proxy servers show the directory > tree. > > > Key: DIRSTUDIO-1275 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1275 > Project: Directory Studio > Issue Type: Bug >Affects Versions: 2.0.0-M16 > Environment: mac os big sur 11.2.3 > apache dir server 2.0.0.v20210213-M16 >Reporter: Cathryn Major >Assignee: Stefan Seelmann >Priority: Minor > Fix For: 2.0.0-M17 > > > In apache dir studio When I open a directory server the only thing it shows > is the Root DSE. I cannot fetch the dn. > The DSE shows two name contexts-one for changelog > dc=### (not showing acutal values for dc) > For the proxy connection the DSE shows DSE2 and the components underneath it. > And these only show the dc name context. -- 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] [Resolved] (DIRAPI-372) Publish new Version on Maven Central to get rid of vulnerable dependency
[
https://issues.apache.org/jira/browse/DIRAPI-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seelmann resolved DIRAPI-372.
Resolution: Fixed
The release is on its way.
> Publish new Version on Maven Central to get rid of vulnerable dependency
>
>
> Key: DIRAPI-372
> URL: https://issues.apache.org/jira/browse/DIRAPI-372
> Project: Directory Client API
> Issue Type: Wish
>Affects Versions: 2.0.1
>Reporter: Valentin Brandl
>Priority: Major
> Fix For: 2.0.2
>
>
> The current version {{2.0.1}} still depends on
> {{org.apache.servicemix.bundles:org.apache.servicemix.bundles.dom4j:2.1.1_1}},
> which has known vulnerabilities:
> https://nvd.nist.gov/vuln/detail/CVE-2020-10683
> The dom4j dependency has been [updated 12 month
> ago|https://github.com/apache/directory-ldap-api/commit/b323881665ca6b530112b2017b2641065b07]
> but since then, there hasn't been a new release.
> It would be nice to have a new version in maven central that removes this
> vulnerable dependency.
--
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] [Resolved] (DIRSERVER-2322) ApacheDS default server instance not starting - Error 1067
[ https://issues.apache.org/jira/browse/DIRSERVER-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSERVER-2322. Resolution: Fixed > ApacheDS default server instance not starting - Error 1067 > -- > > Key: DIRSERVER-2322 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2322 > Project: Directory ApacheDS > Issue Type: Bug > Components: installer >Affects Versions: 2.0.0.AM26 >Reporter: yangsoo song >Assignee: Stefan Seelmann >Priority: Blocker > Labels: newbie > Fix For: 2.0.0.AM27 > > Attachments: Screen Shot 2020-07-22 at 1.58.01 PM.png > > > !Screen Shot 2020-07-22 at 1.58.01 PM.png! > Hey guys, > I followed official documents to install ApacheDS on my windows machine. I've > been trying to start the ApacheDS - default service but keep getting this > error, I've tried it on multiple machines but still getting the same message. > Has anyone encountered this issue and resolved it? > Thank you. -- 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] [Resolved] (DIRSERVER-2347) Incorrect Password Modify response (extended response)
[ https://issues.apache.org/jira/browse/DIRSERVER-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann resolved DIRSERVER-2347. Resolution: Fixed > Incorrect Password Modify response (extended response) > -- > > Key: DIRSERVER-2347 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2347 > Project: Directory ApacheDS > Issue Type: Bug > Components: asn1, changepw >Affects Versions: 2.0.0.AM26 >Reporter: Oleksandr Andreiev >Priority: Major > Fix For: 2.0.0.AM27 > > Attachments: 2021-05-14_09-00.png > > > Hello, > I'm using ApacheDS as LDAP Server along with Linux PAM. > When I try to change user's password via `passwd` ApacheDS actually changes > it, but sends some extra bytes with ExtendedResp packet. Because these bytes > an extra `pam_ldap` library cannot parse it and generates an decoding error. > The same issue is described here: > [https://lists.arthurdejong.org/nss-pam-ldapd-users/2019/msg00030.html] > Is there a way to handle it or probably some workaround? > Regards, > Oleksandr -- 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] (DIRSERVER-2347) Incorrect Password Modify response (extended response)
[ https://issues.apache.org/jira/browse/DIRSERVER-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17347806#comment-17347806 ] Stefan Seelmann commented on DIRSERVER-2347: Thanks for the confirmation. The LDAP API will be released soon which is a pre-requirement. But I'm not aware of actual release plans for ApacheDS. > Incorrect Password Modify response (extended response) > -- > > Key: DIRSERVER-2347 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2347 > Project: Directory ApacheDS > Issue Type: Bug > Components: asn1, changepw >Affects Versions: 2.0.0.AM26 >Reporter: Oleksandr Andreiev >Priority: Major > Fix For: 2.0.0.AM27 > > Attachments: 2021-05-14_09-00.png > > > Hello, > I'm using ApacheDS as LDAP Server along with Linux PAM. > When I try to change user's password via `passwd` ApacheDS actually changes > it, but sends some extra bytes with ExtendedResp packet. Because these bytes > an extra `pam_ldap` library cannot parse it and generates an decoding error. > The same issue is described here: > [https://lists.arthurdejong.org/nss-pam-ldapd-users/2019/msg00030.html] > Is there a way to handle it or probably some workaround? > Regards, > Oleksandr -- 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] [Updated] (DIRSERVER-2347) Incorrect Password Modify response (extended response)
[ https://issues.apache.org/jira/browse/DIRSERVER-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seelmann updated DIRSERVER-2347: --- Fix Version/s: 2.0.0.AM27 > Incorrect Password Modify response (extended response) > -- > > Key: DIRSERVER-2347 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2347 > Project: Directory ApacheDS > Issue Type: Bug > Components: asn1, changepw >Affects Versions: 2.0.0.AM26 >Reporter: Oleksandr Andreiev >Priority: Major > Fix For: 2.0.0.AM27 > > Attachments: 2021-05-14_09-00.png > > > Hello, > I'm using ApacheDS as LDAP Server along with Linux PAM. > When I try to change user's password via `passwd` ApacheDS actually changes > it, but sends some extra bytes with ExtendedResp packet. Because these bytes > an extra `pam_ldap` library cannot parse it and generates an decoding error. > The same issue is described here: > [https://lists.arthurdejong.org/nss-pam-ldapd-users/2019/msg00030.html] > Is there a way to handle it or probably some workaround? > Regards, > Oleksandr -- 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] (DIRSERVER-2347) Incorrect Password Modify response (extended response)
[ https://issues.apache.org/jira/browse/DIRSERVER-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17345732#comment-17345732 ] Stefan Seelmann commented on DIRSERVER-2347: Original commit in LDAP API: https://github.com/apache/directory-ldap-api/commit/931f932b6983a8ba9daa3a8d085d8b5b4b2c9083. This patch was built in https://ci-builds.apache.org/job/Directory/job/dir-ldap-api-pipeline/74/ and deployed as LDAP API 2.0.2-SNAPSHOT . That LDAP API snapshot should be included in ApacheDS pipeline https://ci-builds.apache.org/job/Directory/job/dir-server-pipeline/93/ or later. Disclaimer: because snapshot versions are used one can never be sure if it's really included. > Incorrect Password Modify response (extended response) > -- > > Key: DIRSERVER-2347 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2347 > Project: Directory ApacheDS > Issue Type: Bug > Components: asn1, changepw >Affects Versions: 2.0.0.AM26 >Reporter: Oleksandr Andreiev >Priority: Major > Attachments: 2021-05-14_09-00.png > > > Hello, > I'm using ApacheDS as LDAP Server along with Linux PAM. > When I try to change user's password via `passwd` ApacheDS actually changes > it, but sends some extra bytes with ExtendedResp packet. Because these bytes > an extra `pam_ldap` library cannot parse it and generates an decoding error. > The same issue is described here: > [https://lists.arthurdejong.org/nss-pam-ldapd-users/2019/msg00030.html] > Is there a way to handle it or probably some workaround? > Regards, > Oleksandr -- 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
