Are you checking off any enabled protocols when you save the configuration? I leave all those blank b/c I get errors when I check any of them.
I am doing start TLS on port 389 rather than LDAPS on 636/10636. I just check Enable TLS in the server config and when I connect from directory studio I choose encryption method of start tls and specify port 389. I don't think I needed to install the cert as trusted in order for directory studio to use it but the cert i issued for the directory was in my windows trust store so it might have used that. The error you are getting could just be a SSL trust issue (your client doesn't trust certificate on server). On Fri, Mar 11, 2016 at 2:00 PM, Pepersack, Bob G <[email protected]> wrote: > I tried M10 studio and M21 directory with JDK 1.8.-71 and I still get the > same exception. In the modification logs, I see that "ads-keystoreFile" > has been set with forward slashes in spite of the exception when I try to > save. But, when I try to connect on port 10636, I get this exception: > > Error while opening connection > - SSL handshake failed. > org.apache.directory.ldap.client.api.exception.InvalidConnectionException: > SSL handshake failed. > at > org.apache.directory.ldap.client.api.LdapNetworkConnection.writeRequest(LdapNetworkConnection.java:4149) > at > org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1300) > at > org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1198) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:365) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1171) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:457) > at > org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:303) > 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:54) > > Also, I have tried escaping the slashes with backslashes and forward > slashes without success. > > -----Original Message----- > From: Hal Deadman [mailto:[email protected]] > Sent: Friday, March 11, 2016 8:34 AM > To: [email protected] > Subject: Re: Directory Studio: Backslash in DN breaks studio > > Are you sure the config editor doesn't work if you are using forward slash? > I am able to save this as the keystore with M10 studio and M21 directory. > > D:/ProgramData/xyz/ldap/instances/default/xyz.jks > > I did get different errors with different versions of studio and/or server. > > It is stored in ldap under: > > dn: > ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config > ... > ads-keystoreFile: D:/ProgramData/xyz/ldap/instances/default/xyz.jks > > On Fri, Mar 11, 2016 at 8:18 AM, Pepersack, Bob G <[email protected]> > wrote: > > > Is there a configuration where I can set my keystore settings with a > > text editor, or some other kind of editor? > > > > When I build the project from "directory-studio-trunk.zip" with "mvn > > clean install -Dmaven.test.skip=true", it throws this exception: > > > > [INFO] Scanning for projects... > > [ERROR] Internal error: > > org.eclipse.tycho.core.osgitools.OsgiManifestParserException: > > Exception parsing OSGi MANIFEST > > > C:\bit9prog\dev\Installation\directory-studio-trunk\plugins\aciitemeditor\META-INF\MANIFEST.MF: > > Manifest file not found -> [Help 1] > > org.apache.maven.InternalErrorException: Internal error: > > org.eclipse.tycho.core.osgitools.OsgiManifestParserException: > > Exception parsing OSGi MANIFEST > > C:\bit9prog\dev\Installation\directory-studio-tru > > nk\plugins\aciitemeditor\META-INF\MANIFEST.MF: Manifest file not found > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166) > > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) > > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > > at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:497) > > at > > > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > > at > > > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > > at > > > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > > at > > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:3 > > 56) Caused by: > > org.eclipse.tycho.core.osgitools.OsgiManifestParserException: > > Exception parsing OSGi MANIFEST > > > C:\bit9prog\dev\Installation\directory-studio-trunk\plugins\aciitemeditor\META-INF\MANIFEST.MF: > > Manifest file not found > > at > > > org.eclipse.tycho.core.osgitools.DefaultBundleReader.loadManifestFromDirectory(DefaultBundleReader.java:95) > > at > > > org.eclipse.tycho.core.osgitools.DefaultBundleReader.doLoadManifest(DefaultBundleReader.java:59) > > at > > > org.eclipse.tycho.core.osgitools.DefaultBundleReader.loadManifest(DefaultBundleReader.java:50) > > at > > > org.eclipse.tycho.core.osgitools.OsgiBundleProject.readArtifactKey(OsgiBundleProject.java:147) > > at > > > org.eclipse.tycho.core.osgitools.OsgiBundleProject.setupProject(OsgiBundleProject.java:142) > > at > > > org.eclipse.tycho.core.resolver.DefaultTychoResolver.setupProject(DefaultTychoResolver.java:74) > > at > > > org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:90) > > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:310) > > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) > > ... 11 more > > > > -----Original Message----- > > From: Emmanuel Lécharny [mailto:[email protected]] > > Sent: Thursday, March 10, 2016 7:18 PM > > To: [email protected]; [email protected] > > Subject: Re: Directory Studio: Backslash in DN breaks studio > > > > Le 10/03/16 22:58, Stefan Seelmann a écrit : > > > On 03/09/2016 07:59 PM, Emmanuel Lécharny wrote: > > >> Le 09/03/16 18:54, Philip Peake a écrit : > > >> Can you be a bit more explicit ? > > >> > > > Probably same cause as in > > > https://issues.apache.org/jira/browse/DIRSTUDIO-1087 and > > > https://issues.apache.org/jira/browse/DIRSERVER-2109 > > > > > I took some time last week-end to re-think the whole problem. There > > are a lot of things we are doing wrong, IMO. Don't get me wrong though : > > most of the time, it simply works. > > > > FTR, I send this mail to the dev list, copying it to the users list. > > > > <this is going to be a long mail...> > > > > First of all, we need to distinguish the clients from the server. They > > are to different beasts, and we should assume the server *always* > > receive data that are potentially harmful and incorrect. > > > > Then we also need to distinguish String values and Binary values. The > > reason we make this distinction is that String values are going to be > > encoded in UTF-8 thus using multi-bytes, and also because we need to > > convert them from UTF-8 to Unicode (and back). > > > > Let's put aside the binary data at the moment. > > > > The server > > ========== > > > > Value > > ----- > > > > We receive UTF-8 Strings, we convert them to Unicode and now we can > > process them in Java. We do need this conversion because we need to > > check the values before injecting them in the backend. Doing such > > checks in UTF-8 would be very impracticable. > > > > There is one critical operation that is done on values when we process > > them : we most of the time need to compare them to another value : > > typically, when we have an index associated with this value, or when > > we have a search filter. Comparing two values is not as simple as > > doing an lexicographic comparison sadly. We need to 'prepare' the > > values accordingly to some very specific rules, and we should also > 'normalize' > > those values accordingly to some syntax. > > > > A comparison is done following this process : > > > > Val 1 -> normalization -> preparation-+ > > \ > > .--> Comparison > > / Val 2 -> normalization -> > > preparation-+ > > > > We can save some processing if one of the two values has already been > > normalized or prepared. Actually, we should do that only once for each > > value : when they are injected into the server for the first time. But > > doing so would also induce some constraint : disk usage (saving many > > forms of a data cost space, and time when it comes to read them from > > disk. This is all about balance...). > > > > Anyway, most of the time, we get a value and we just need to store it > > into the backend after having checked its syntax. And that's the key : > > checking the syntax requires some preparation. Here is how we proceed > > when we just need to chck teh syntax : > > > > Value --> normalization --> syntax check > > > > There is no string preparation. > > > > The normalization is specific to each AttributeType. The String > > Preparation is the same for all the values. > > > > > > Now, there are two specific use cases : filters, and DN. > > > > > > Filter > > ------ > > > > A filter always contains a String that needs to be processed to give a > > tuple : <attributeType, value>. There are rules that must be applied > > to transform the incoming filter to this tuple. Once we have created > > this tuple, we can normalize and prepare the tuple's value : something > > that might be complex, especially when dealing with substring matches. > > > > So for filter, the process is : > > > > fliter -> preProcessing -> Tuple<AttributeType, Value> -> > > normalization > > -> preparation > > > > > > The String preparation is required because the filter's value will be > > compared with what we fetch from the backend. > > > > DN > > -- > > > > The DN is not a String. It's a list of RDN, where each RDN is a list > > of AVA, where each AVA is a tuple <attributeType, Value> Although, as > > a filter, when it's received, or stored, it's as a String, and there > > are some specific rules to follow to get the String being transformed to > RDNs. > > Bottom line, the DN preprocessing is the following : > > > > DN String --> preProcessing -> Rdns, AVA, Tuple<AttributeType, value> > > [-> normalization -> preparation] (for each AVA) > > > > Again, the String preparation is needed because we will store the RDN > > into an index, and that requires some comparison (note that it's not > > always the case, typically for attributeType with a DN syntax). > > > > > > Comparing values > > ---------------- > > > > We saw that we need to normalize and prepare values before being able > > to compare them. A good question would be : do we need to prepare the > > String beforehand or when we need to compare values ? That's quite > irrelevant : > > it's a choice that need to be make at some point, but it just impacts > > the performance and the storage size. We can consider that when we > > start comparing two values, they are already prepared (either because > > we have stored a prepared version of the String, or because we have > > just prepared teh String on the fly before calling the compare method). > > > > > > > > The Client > > ========== > > > > I will just talk about the Ldap API here, I'm not interested in any > > other client. > > > > We have two flavors : schema eware and schema agnostic. We also have > > to consider two aspects : when we send data to the server, and when we > > process the result. > > > > > > Schema agnostic client > > ---------------------- > > > > There is no so much we can do here. we have no idea about what can be > > the value's syntax, so we can't normalize the value. Bottom line, here > > is the basic processing of a value sent to the server : > > > > - we don't touch the values. At all. We just convert them from Unicode > > to > > UTF-8 > > - we pre-process filters to feed the SearchRequest. values are > > unescaped (ie the escaped chars are replaced by their binary > > counterpart) > > - we don't touch the DN > > > > Whe values are received from the server, we need to process the data > > this way : > > > > - we don't touch the values, we just convert them from UTF-8 to > > Unicode > > - we don't touch the DN : it's already in String format, we just > > convert them from UTF-8 to Unicode > > > > Schema aware client > > ------------------- > > > > This is more complex, because now, we can process the values before > > sending them to the server. This put some load on the client side > > instead of pounding the server with incorrect data that will get > rejected anyway. > > > > - Values : we normalize them, prepare them and check their syntax. At > > the end, we convert the original value from Unicode to UTF-8. As we > > can see, we lose the normalized and prepared value. > > - Filter : we unescape them, then we convert them to UTF-8 > > - Dn : we parse it, unescape it, normalizing each value, and at the > > end, if the DN is valid, we send the original value as is, after > > having converting it to UTF-8 > > > > > > As we can see, all what we do is to check the values before sending > > them to the remote server, except for the filter. > > > > For the received values, we first convert them to Unicode and that's > > pretty much it. > > > > > > Escaping > > -------- > > > > DN and Filters need some pre-processing called unescaping when we have > > to transform them from a String to an internal instance. For Filter, > > this is always done on the client side, for the DN is done on the > > server side. The idea is to transform those values from a String > > (human > > readable) form to a binary form. > > > > > > What we do wrong > > ---------------- > > > > We will only focus on the schema aware API here. This is what we use > > on the server side anyway... > > > > * First, we are depending on the same API on both side (client and > > server). This make things more complex, because the context is different. > > For instance, there is no need to parse the DN on the client, but we > > still do it. I'm not sure that we could easily abvoid doing so. > > To some extent, we are penalizing the client. > > > > * The most complex situation is when we have to procesds the DN. This > > is always done in two phases : > > - slice the DN into RDNs, the RDNs into AVAs containg Values > > - apply the schema on each value > > > > We coulde easily imagine doing the processing in one single pass. > > Actually, this is an error not to do so : this cost time, and the > > classes are therfore not immutable. > > > > * One specific problematic point is when we process escaped chars. For > > instance, something like : 'cn=a\ \ \ b' is just a cn with a value > > containing 3 spaces. This is what should be returned to the user, and > > not a value with only one space. *But* we will be able to retrieve > > this value using one of those filters : (cn=a b) or (cn=a b) or (cn= > > a b). Actually the number of spaces is irrelevant when comparing > > the value, it's not when it comes to send back the value to the user. > > Again, it has all to see with the distinction between storing values > > and comparing values. > > For filters, we must unescape the String before sending it to the server. > > The server does not handle the Filter as a String. > > > > * The PrepareString class needs to be reviewed. We don't handle spaces > > the way it's supposed to be done. > > > > Value Class > > ----------- > > > > I'm not exactly proud of it. It was a way to avoid having code like : > > > > if ( value instance of String ) > > { > > // This is a String > > } > > else > > { > > // This is a byte[] > > } > > > > so now, we have StringValue and BinaryValue, both of them could be > > used with an AttributeType when they are SchemaAware. In retrospect, I > > think the distinction between String and Binary values was an error. > > We should have a Value, holding both, with a flag in it. Chaning that > > means we review the entire code, again... > > > > > > > > Conclusion > > ========== > > > > This is not a pleasant situation. We have some cases where we don't > > handle things correctly, and this is largely due to some choices made > > a decade ago. Now, I don't think that this should be kept as is. > > Sometime a big refactoring is better than patching this and that... > > > > > > Now, feel free to express yourself, I would be vert happy to have your > > opinion. > > > > Many thanks ! > > > > >
