You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(10) |
Feb
|
Mar
(2) |
Apr
(4) |
May
(1) |
Jun
|
Jul
(13) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(13) |
| 2011 |
Jan
(1) |
Feb
(4) |
Mar
(25) |
Apr
(8) |
May
(14) |
Jun
|
Jul
(6) |
Aug
(6) |
Sep
(6) |
Oct
(12) |
Nov
(4) |
Dec
(4) |
| 2012 |
Jan
(5) |
Feb
|
Mar
(6) |
Apr
(6) |
May
(32) |
Jun
(16) |
Jul
(8) |
Aug
(6) |
Sep
(1) |
Oct
(3) |
Nov
(5) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(12) |
Jul
(7) |
Aug
|
Sep
|
Oct
(9) |
Nov
(1) |
Dec
(4) |
| 2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
(4) |
May
(57) |
Jun
(12) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2015 |
Jan
|
Feb
(15) |
Mar
(7) |
Apr
(6) |
May
(5) |
Jun
(5) |
Jul
|
Aug
(3) |
Sep
(4) |
Oct
(3) |
Nov
|
Dec
(4) |
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(14) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(7) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(1) |
| 2018 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2020 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2022 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(6) |
Jun
(1) |
Jul
(6) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Neil W. <nei...@pi...> - 2018-01-23 20:57:33
|
We have just released the UnboundID LDAP SDK for Java version 4.0.4, available for download from the LDAP.com website <https://www.ldap.com/unboundid-ldap-sdk-for-java>, from the releases page <https://github.com/pingidentity/ldapsdk/releases> of our GitHub repository, from the Files page <https://sourceforge.net/projects/ldap-sdk/files/> of our SourceForge project, and from the Maven Central Repository <https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.unboundid%22%20AND%20a%3A%22unboundid-ldapsdk%22> . There are a few noteworthy changes included in this release. The release notes <https://docs.ldap.com/ldap-sdk/docs/release-notes.html> go into more detail, but the highlights of these changes include: - We updated the way that the LDAP SDK generates exception messages to make them more user-friendly. They are now less likely to include stack traces, and they are less likely to include repeated information (like LDAP SDK build information, and information duplicated from an exception’s cause). - We fixed an issue that could cause multiple application threads to block in the course of closing a connection pool. - We updated the way that the LDAP SDK sends LDAP messages so that it is more resilient to stalls in the TLS negotiation process. - We updated the LDAP SDK’s ServerSet implementations so that they can perform authentication and post-connect processing, which can make health checks against newly established connections more reliable. - We updated the GetEntryLDAPConnectionPoolHealthCheck class to provide support for invoking the health check after a pooled connection has been authenticated. - We fixed a bug in the GetEntryLDAPConnectionPoolHealthCheck class that could cause it to behave incorrectly when checking the validity of a connection after an LDAPException was caught. - We updated the Attribute.hasValue method to be more efficient for attributes with multiple values, and especially for attributes with a lot of values or with more complicated matching rules. This will also improve the Filter.matchesEntry method for equality filters that target similar types of attributes. - We updated the prompt trust manager to provide better output formatting, and to provide additional warnings about conditions that may make a server certificate chain less trustworthy. - We updated the LDAPConnectionOptions class to adjust the initial default connect timeout and operation response timeout, and the default operation response timeout can now be set differently for each type of operation. Most of the default values for options in the LDAPConnectionOptions class can now be set via system properties. -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* |
|
From: Neil W. <nei...@pi...> - 2017-12-05 20:06:43
|
We have just released the UnboundID LDAP SDK for Java version 4.0.3. As usual, you can get this release of the LDAP SDK from LDAP.com ( https://www.ldap.com/unboundid-ldap-sdk-for-java), from GitHub ( https://github.com/pingidentity/ldapsdk), from SourceForge ( https://sourceforge.net/projects/ldap-sdk/), or from the Maven Central Repository ( https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.unboundid%22%20AND%20a%3A%22unboundid-ldapsdk%22 ). There was also a 4.0.2 release, but we found a bug in that version just after the release was published (in the new code used to generate and verify signatures in certificates and certificate signing requests), so we pushed a new 4.0.3 release to include the fix for that bug. The most significant changes over the 4.0.1 release are: * Added a new manage-certificates tool that can be used to interact with JKS and PKCS #12 keystores, generate certificates and certificate signing requests, sign certificates, and perform a number of other certificate-related features. It’s like keytool, but it offers additional functionality, and it’s a lot more user-friendly. The LDAP SDK also provides classes for generating and parsing certificates and certificate signing requests programmatically. * Added a new variant of the Entry.diff method that can be used to perform a byte-for-byte comparison of attribute values instead of using the associated attribute syntax. This can help identify changes that result in logically equivalent values, like changing the value of a case-insensitive attribute in a way that only affects capitalization. * Added a new PasswordReader.readPasswordChars method that can be used to read a password into a character array. Previously, it was only possible to read a password as a byte array. * Added a new LDAPConnection.closeWithoutUnbind method that can be used to close a connection without first sending an LDAP unbind request. While this isn’t usually recommended, it can be useful in cases where the connection is known to be invalid, and especially if there is the potential for sending the unbind request to cause the connection to block. * Improved support for validating object identifiers (OIDs). The LDAP SDK now offers a strict validation mode that requires the OID to be comprised of at least two components, that requires the first component to be between zero and two, and that requires the second component to be between zero and thirty-nine if the first component is zero or one. There is also a new OIDArgumentValueValidator class that can be used when requesting command-line arguments whose values are expected to be numeric OIDs. * Fixed a bug that could cause the LDAP SDK to leak a connection if it was configured with an SSLSocketVerifier and that verifier rejected the connection for some reason. * Fixed a bug that could cause the LDAP SDK to block for twice as long as it should in the event that a failure occurred while trying to send a simple bind request on a connection operating in synchronous mode and the attempt to send the request blocks. * Added support for new ASN.1 element types, including bit string, object identifier, generalized time, UTC time, UTF-8 string, IA5 string, printable string, and numeric string. Also added support for a new integer type that is backed by a BigInteger and can support values of any magnitude. * Added convenience methods that make it easier to determine the type class and primitive/constructed state of an ASN.1 element. * Added support for a new uniqueness request control that can be included in add, modify, and modify DN requests sent to the Ping Identity Directory Server. This control requests that the server identify attribute value conflicts that might arise as a result of the changes performed by the associated operation. The ldapmodify tool has also been updated to support this control. * Updated the searchrate tool to make it possible to set the search size limit, time limit, dereference policy, and typesOnly flag. * Updated the in-memory directory server to support the UnboundID/Ping-proprietary ignore NO-USER-MODIFICATION request control. * Updated the UnboundID/Ping-proprietary password policy state extended operation to make it possible to determine whether the target user has a static password. * Updated the argument parser to make it possible to hide subcommand names and argument identifiers so that they can be used but will not appear in generated usage information. * Improved the quality of LDAP request debug messages. * Updated the set of LDAP-related specifications to include updated versions of existing specifications, and to add a number of certificate-related specifications. -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* |
|
From: Neil W. <nei...@pi...> - 2017-10-10 17:35:50
|
I did see and respond to your original message, but the response only went to the mailing list, and I guess you wouldn’t have seen it if you weren’t subscribed to the list or looking at the archive. This time, I’m responding to both the list and to you specifically, so I apologize if you get it twice, but hopefully you’ll get it at least once. Here’s the response that I sent: -----BEGIN ORIGINAL RESPONSE----- Thanks for reporting this problem. This is a very strange issue because the NullPointerException shows that the server is encountering a null variable (the suppressNextResponse AtomicBoolean member in the LDAPListenerClientConnection class) that is final and initialized to a non-null value in the LDAPListenerClientConnection constructor. However, I think that what’s going on is that the LDAPListenerClientConnection constructor is creating a new request handler instance before it’s initializing that suppressNextResponse variable, and it’s providing an instance of the partially-initialized client connection instance to that request handler. In this case, that request handler happens to be an instance of your ProxyListenerRequestHandler, but I don’t think that anything in your code is responsible for the exception. I just committed a change that I think will fix this. It ensures that suppressNextResponse (and one other variable) are initialized before creating the request handler instance. You can test it by checking out and building the LDAP SDK from either the SourceForge or GitHub repository (just check out the code and run build.sh or build.bat, then take the unboundid-ldapsdk.jar file from the resulting build/package/unboundid-ldapsdk-4.0.2 directory). If this works, then you can just run with that version that you built for yourself until the next release of the LDAP SDK, which should hopefully happen around the end of the month. -----END ORIGINAL RESPONSE----- Neil On Tue, Oct 10, 2017 at 12:30 PM, Bryan Larson <bla...@gm...> wrote: > I apologize if this came through as a duplicate. I received a > notification that my initial attempt was caught in a filter with a reason > of: Post by non-member to a members-only list. I have since joined the > mailing list. > > I've recently implemented an LDAP proxy cache using Unboundid to handle > the requests. I accomplished this by extending the > LDAPListenerRequestHandler class and forwarding to a ProxyRequestHandler > for binds, etc. and overriding the search and other relevant operations to > look in a cache (using the search filter as the cache key). > > The above appears to be working successfully. However, I've had > difficulty when running the proxy under load. I will start to get flooded > with this stack trace: > > java.lang.NullPointerException > > at com.unboundid.ldap.listener.LDAPListenerClientConnection.sen > dMessage(LDAPListenerClientConnection.java:661) > > at com.unboundid.ldap.listener.LDAPListenerClientConnection.sen > dSearchResultEntry(LDAPListenerClientConnection.java:728) > > at com.unboundid.ldap.listener.LDAPListenerClientConnection.sen > dSearchResultEntry(LDAPListenerClientConnection.java:797) > > at ldap.proxy.cache.ProxyListenerRequestHandler.processSearchRe > quest(ProxyListenerRequestHandler.java:122) > > at com.unboundid.ldap.listener.LDAPListenerClientConnection.run > (LDAPListenerClientConnection.java:584) > > FYI - the ProxyListenerRequestHandler class is my own. There's nothing > overly proprietary in there, so I would be willing to disclose my own > source code if it helped track down an issue. > > It's worth noting that I'm currently using version 3.2.0 of the LDAP SDK. > It's also worth noting that I am not tethered to that version. Open to > upgrading if it's worthwhile. > > Anything stand out, or anywhere that I should look? I'm fearful that > there are some non-threadsafe things going on here, but not sure at the > moment. > > Thanks, > Bryan > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ldap-sdk-discuss mailing list > lda...@li... > https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* |
|
From: Bryan L. <bla...@gm...> - 2017-10-10 17:30:31
|
I apologize if this came through as a duplicate. I received a notification that my initial attempt was caught in a filter with a reason of: Post by non-member to a members-only list. I have since joined the mailing list. I've recently implemented an LDAP proxy cache using Unboundid to handle the requests. I accomplished this by extending the LDAPListenerRequestHandler class and forwarding to a ProxyRequestHandler for binds, etc. and overriding the search and other relevant operations to look in a cache (using the search filter as the cache key). The above appears to be working successfully. However, I've had difficulty when running the proxy under load. I will start to get flooded with this stack trace: java.lang.NullPointerException at com.unboundid.ldap.listener.LDAPListenerClientConnection.sendMessage( LDAPListenerClientConnection.java:661) at com.unboundid.ldap.listener.LDAPListenerClientConnection. sendSearchResultEntry(LDAPListenerClientConnection.java:728) at com.unboundid.ldap.listener.LDAPListenerClientConnection. sendSearchResultEntry(LDAPListenerClientConnection.java:797) at ldap.proxy.cache.ProxyListenerRequestHandler.processSearchRequest( ProxyListenerRequestHandler.java:122) at com.unboundid.ldap.listener.LDAPListenerClientConnection.run( LDAPListenerClientConnection.java:584) FYI - the ProxyListenerRequestHandler class is my own. There's nothing overly proprietary in there, so I would be willing to disclose my own source code if it helped track down an issue. It's worth noting that I'm currently using version 3.2.0 of the LDAP SDK. It's also worth noting that I am not tethered to that version. Open to upgrading if it's worthwhile. Anything stand out, or anywhere that I should look? I'm fearful that there are some non-threadsafe things going on here, but not sure at the moment. Thanks, Bryan |
|
From: Neil W. <nei...@pi...> - 2017-10-02 21:34:33
|
Thanks for reporting this problem. This is a very strange issue because the NullPointerException shows that the server is encountering a null variable (the suppressNextResponse AtomicBoolean member in the LDAPListenerClientConnection class) that is final and initialized to a non-null value in the LDAPListenerClientConnection constructor. However, I think that what’s going on is that the LDAPListenerClientConnection constructor is creating a new request handler instance before it’s initializing that suppressNextResponse variable, and it’s providing an instance of the partially-initialized client connection instance to that request handler. In this case, that request handler happens to be an instance of your ProxyListenerRequestHandler, but I don’t think that anything in your code is responsible for the exception. I just committed a change that I think will fix this. It ensures that suppressNextResponse (and one other variable) are initialized before creating the request handler instance. You can test it by checking out and building the LDAP SDK from either the SourceForge or GitHub repository (just check out the code and run build.sh or build.bat, then take the unboundid-ldapsdk.jar file from the resulting build/package/unboundid-ldapsdk-4.0.2 directory). If this works, then you can just run with that version that you built for yourself until the next release of the LDAP SDK, which should hopefully happen around the end of the month. Neil On Mon, Oct 2, 2017 at 2:44 PM, Bryan Larson <bla...@gm...> wrote: > Hello, > > I've recently implemented an LDAP proxy cache using Unboundid to handle > the requests. I accomplished this by extending the > LDAPListenerRequestHandler class and forwarding to a ProxyRequestHandler > for binds, etc. and overriding the search and other relevant operations to > look in a cache (using the search filter as the cache key). > > The above appears to be working successfully. However, I've had > difficulty when running the proxy under load. I will start to get flooded > with this stack trace: > > java.lang.NullPointerException > > at com.unboundid.ldap.listener.LDAPListenerClientConnection.sendMessage( > LDAPListenerClientConnection.java:661) > > at com.unboundid.ldap.listener.LDAPListenerClientConnection. > sendSearchResultEntry(LDAPListenerClientConnection.java:728) > > at com.unboundid.ldap.listener.LDAPListenerClientConnection. > sendSearchResultEntry(LDAPListenerClientConnection.java:797) > > at ldap.proxy.cache.ProxyListenerRequestHandler.processSearchRequest( > ProxyListenerRequestHandler.java:122) > > at com.unboundid.ldap.listener.LDAPListenerClientConnection.run( > LDAPListenerClientConnection.java:584) > > FYI - the ProxyListenerRequestHandler class is my own. There's nothing > overly proprietary in there, so I would be willing to disclose my own > source code if it helped track down an issue. > > It's worth noting that I'm currently using version 3.2.0 of the LDAP SDK. > It's also worth noting that I am not tethered to that version. Open to > upgrading if it's worthwhile. > > Anything stand out, or anywhere that I should look? I'm fearful that > there are some non-threadsafe things going on here, but not sure at the > moment. > > Thanks, > Bryan > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ldap-sdk-discuss mailing list > lda...@li... > https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* |
|
From: Bryan L. <bla...@gm...> - 2017-10-02 19:44:11
|
Hello, I've recently implemented an LDAP proxy cache using Unboundid to handle the requests. I accomplished this by extending the LDAPListenerRequestHandler class and forwarding to a ProxyRequestHandler for binds, etc. and overriding the search and other relevant operations to look in a cache (using the search filter as the cache key). The above appears to be working successfully. However, I've had difficulty when running the proxy under load. I will start to get flooded with this stack trace: java.lang.NullPointerException at com.unboundid.ldap.listener.LDAPListenerClientConnection.sendMessage(LDAPListenerClientConnection.java:661) at com.unboundid.ldap.listener.LDAPListenerClientConnection.sendSearchResultEntry(LDAPListenerClientConnection.java:728) at com.unboundid.ldap.listener.LDAPListenerClientConnection.sendSearchResultEntry(LDAPListenerClientConnection.java:797) at ldap.proxy.cache.ProxyListenerRequestHandler.processSearchRequest(ProxyListenerRequestHandler.java:122) at com.unboundid.ldap.listener.LDAPListenerClientConnection.run(LDAPListenerClientConnection.java:584) FYI - the ProxyListenerRequestHandler class is my own. There's nothing overly proprietary in there, so I would be willing to disclose my own source code if it helped track down an issue. It's worth noting that I'm currently using version 3.2.0 of the LDAP SDK. It's also worth noting that I am not tethered to that version. Open to upgrading if it's worthwhile. Anything stand out, or anywhere that I should look? I'm fearful that there are some non-threadsafe things going on here, but not sure at the moment. Thanks, Bryan |
|
From: Neil W. <nei...@pi...> - 2017-09-05 20:12:53
|
The UnboundID LDAP SDK for Java version 4.0.1 has been released. It is available for immediate download from the LDAP.com website <https://www.ldap.com/unboundid-ldap-sdk-for-java>, from our GitHub repository <https://github.com/pingidentity/ldapsdk>, from the SourceForge project <https://sourceforge.net/projects/ldap-sdk/>, or from the Maven Central Repository <https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.unboundid%22%20AND%20a%3A%22unboundid-ldapsdk%22> . This release fixes a number of issues and adds a few small features. Some of the most significant changes are: - Added a new JVMDefaultTrustManager class that can be used to automatically trust any certificate signed by an authority that the JVM considers trusted by default. The command-line tool framework has been updated so that if you don’t explicitly specify a trust behavior, it will now check the JVM-default trust manager before prompting about whether to trust the server certificate. - Updated the in-memory directory server to add support for encoding clear-text passwords using a pluggable mechanism. For example, you can automatically have clear-text passwords transformed so that they are stored as the base64-encoded representation of a salted message digest. - Updated the in-memory directory server to indicate which attributes will be treated as password attributes. Any password attribute can be used to provide credentials for a bind operation, and the values of password attributes will be encoded with the configured password encoder (if any). The server was formerly hard-coded to use userPassword as the password attribute, and this is still the default configuration, but it is now possible to configure the server to use one or more other attributes instead of or in addition to userPassword. - Added support for a new password update behavior request control. This control can be used in an upcoming release of the Ping Identity Directory Server to override the behavior the server would otherwise have used for a number of password-related properties (e.g., whether the password update is a self change or an administrative reset, whether to allow a pre-encoded password, which password storage scheme to use, etc.). The ldapmodify tool has been updated to make it easy to include this control in add and modify requests. - Updated the identify-unique-attribute-conflicts example tool to provide support for identifying conflicts between combinations of attributes. For example, you can use this feature to identify cases in which there may be duplicate uid values within the same organization, but ignore duplicate uid values for users in different organizations. - Fixed an OSGi problem in the jar file manifest. When the LDAP SDK supported Java 1.5 or later, the correct value for the Bundle-RequiredExecutionEnvironment property was “J2SE-1.5”. When we updated the LDAP SDK to require Java 7 or later, the value of this property was updated to be “J2SE-1.7” instead of the correct new value of “JavaSE-1.7”. - Fixed a problem that prevented the complete set of argument validation from being performed when running a tool in interactive mode. In particular, the interactive mode framework did not perform validation related to required, exclusive, and dependent argument sets. - Fixed an issue with the way that command-line tools handled trailing arguments in interactive mode. If the tool didn’t require any trailing arguments but allowed any number of them to be provided, then interactive mode did not allow trailing argument values to be provided. - Fixed an issue with the way that relative paths were handled in command-line tools run in interactive mode. When a Java File object is created from a relative path rather than an absolute path, the getParentFile() method may return null, and this could cause the LDAP SDK to incorrectly believe that the file’s parent didn’t exist. To avoid this, the LDAP SDK now uses getAbsoluteFile().getParentFile() in order to get the parent for any File that may have been created from a relative path. - Fixed an issue with command-line tools that default to interactive mode that could arise if the tool is invoked without any arguments, but if it tries to use a properties file referenced by an environment variable or JVM property. If the properties file contained some but not all of the arguments needed to invoke the tool, the command-line tool framework would still try to invoke the tool with just the arguments from the properties file, which could result in erratic behavior, unexpected errors, or uncaught exceptions. The tool will now launch in interactive mode to allow the missing arguments to be specified. - The ldapsearch tool has been updated so that the base DN argument is now optional in all circumstances. Previously, you had to explicitly provide either a base DN or an LDAP URL file, but this created a usability problem if you ran ldapsearch in interactive mode and wanted to search with a null base DN (that is, the DN with the empty string representation). Now, if you don’t provide either a base DN or an LDAP URL file, then ldapsearch will assume a null base DN. - Updated the class-level Javadoc documentation for a number of classes that implement controls and extended requests and responses. If it takes an encoded value, the Javadoc documentation now describes the encoding for that value. - Fixed a couple of problems with message format strings that had incorrect property references (for example, they referenced “{1}” when they should have referenced “{0}” as the first argument). The LDAP SDK build process has been updated to better catch these kinds of problems. - Improved the ByteStringBuffer.append(CharSequence) method so that it will be much more efficient for CharSequence implementations in which iterating through the characters using the charAt(int) method is expensive. -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* |
|
From: <g....@au...> - 2017-08-31 08:16:54
|
Hello Neil,
das schema vs scheme was a typo in my mail.
Yes, it does. I also saw this.
But that is the way - at least - the Apache Directory Studio works.
So I tried to emulate it. And it works perfectly.
Gruß
Gerrit
Von: Neil Wilson via ldap-sdk-discuss [mailto:lda...@li...]
Gesendet: Donnerstag, 31. August 2017 09:45
An: LDAP SDK Discussions
Cc: Neil Wilson
Betreff: Re: [ldap-sdk-discuss] Adding referral to InMemoryDirectoryServer
Are you sure that you’re looking for the right attribute? RFC 4511 section 4.2 states that the correct attribute is subschemaSubentry, not subschemeSubentry. The in-memory directory server does correctly return the subschemaSubentry attribute in the root DSE, and in every other entry. Note that it is an operational attribute so you need to explicitly ask for it (or ask for “+”, which indicates that the server should return all operational attributes).
Neil
On Thu, Aug 31, 2017 at 2:28 AM, <g....@au...> wrote:
Hello Neil,
I wanted to rebuild the more or less exact behavior of a Microsoft Active Directory LDAP service.
And at least the Apache Directory Studio does a query on the base DN "" using filter "(objectClass=*)" asking for attribute "subschemeSubentry".
The AD LDAP response with an entry having the DN "" and the attribute "subschemeSubentry".
That's the reason.
Now I simply intercept that query and reply with the right answer. No referral needed.
Gruß
Gerrit
Von: Neil Wilson via ldap-sdk-discuss [mailto:lda...@li...]
Gesendet: Mittwoch, 30. August 2017 18:00
An: LDAP SDK Discussions
Cc: Neil Wilson
Betreff: Re: [ldap-sdk-discuss] Adding referral to InMemoryDirectoryServer
What behavior do you expect?
If you search with a base DN of the empty string (the null base DN), then the in-memory directory server will exhibit the standard LDAPv3 behavior. If you use a scope of BASE, then it will retrieve the root DSE entry that provides information about the server’s capabilities and data. If you use a different scope, then it will automatically consider the null DN to be the immediate parent of each of the naming contexts.
So in your case, if you have a base DN of “DC=test,DC=company,DC=local” and perform a subtree search with a base DN equal to the null DN, then it will automatically search below DC=test,DC=company,DC=local. However, this doesn’t work for DNs subordinate to the null DN but superior to the naming context. For example, if you search with a base DN of “DC=local”, then the correct standard behavior is to get a NO_SUCH_OBJECT result because that entry doesn’t exist. The interceptor that I provided can change that to return a referral to “DC=test,DC=company,DC=local” instead, but that’s not really standards-compliant behavior.
Neil
On Wed, Aug 30, 2017 at 4:16 AM, <g....@au...> wrote:
Hello Neil,
Thanks for your reply.
On the way implementing that interceptor I had to realize that a referral didn't solve my problem.
But I was able to intercept the request which doesn't have a base ("") and reply with an entry which contained the needed information for the client.
And that finally solved my problem. :-)
Regards,
Gerrit
Von: Neil Wilson via ldap-sdk-discuss [mailto:lda...@li...]
Gesendet: Dienstag, 29. August 2017 21:26
An: LDAP SDK Discussions
Cc: Neil Wilson
Betreff: Re: [ldap-sdk-discuss] Adding referral to InMemoryDirectoryServer
Although both the LDAP SDK and the in-memory directory server support referrals, you cannot create referral entries above non-referral entries. You probably don’t really want that anyway, because referral entries generally apply to all types of operations, and you don’t want the server telling the client to send a modify attempt targeting “DC=local” to “DC=test,DC=company,DC=local” instead.
Presumably, what you really want is to have only search operations with a base DN that is superior to “DC=test,DC=company,DC=local” to receive a referral telling them to use a base DN of “DC=test,DC=company,DC=local”. If you want that, you can achieve it with an InMemoryOperationInterceptor that intercepts search requests and throws an LDAPException with a referral result if the request has a base DN that is superior to the desired base DN. The attached ReferSearchesAboveBaseInMemoryOperationInterceptor.java source file does exactly that.
It’s pretty trivial to use the attached interceptor. Just use the InMemoryDirectoryServerConfig.addInMemoryOperationInterceptor method. For example:
final String baseDN = "DC=test,DC=company,DC=local";
final InMemoryDirectoryServerConfig cfg =
new InMemoryDirectoryServerConfig(baseDN);
cfg.addInMemoryOperationInterceptor(
new ReferSearchesAboveBaseInMemoryOperationInterceptor(baseDN));
final InMemoryDirectoryServer ds = new InMemoryDirectoryServer(cfg);
ds.add(
"dn: DC=test,DC=company,DC=local",
"objectClass: top",
"objectClass: domain",
"DC: test");
ds.startListening();
try
{
final LDAPConnectionOptions connectionOptions =
new LDAPConnectionOptions();
connectionOptions.setFollowReferrals(true);
try (LDAPConnection connection = ds.getConnection(connectionOptions))
{
final SearchResult searchResult = connection.search("DC=local",
SearchScope.SUB, Filter.createPresenceFilter("objectClass"));
LDAPTestUtils.assertResultCodeEquals(searchResult, ResultCode.SUCCESS);
LDAPTestUtils.assertEntriesReturnedEquals(searchResult, 1);
LDAPTestUtils.assertEntryReturned(searchResult,
"DC=test,DC=company,DC=local");
}
}
finally
{
ds.shutDown(true);
}
I hope this does what you need, or at least puts you on the right track.
Neil
On Tue, Aug 29, 2017 at 7:36 AM, <g....@au...> wrote:
Hello everyone,
I'm currently "fighting" with the InMemoryDirectoryServer.
So far it works perfectly. I can use SSL/TLS, I can add credentials as well as entries.
But somehow I can't figure out how to add referrals.
My base DN is "DC=test,DC=company,DC=local" and I want referrals on each of the previous levels ("DC=company,DC=local", "DC=local", "") pointing to that base DN.
Regards,
Gerrit
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
ldap-sdk-discuss mailing list
lda...@li...
https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
ldap-sdk-discuss mailing list
lda...@li...
https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
ldap-sdk-discuss mailing list
lda...@li...
https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
|
|
From: Neil W. <nei...@pi...> - 2017-08-31 08:14:44
|
Are you sure that you’re looking for the right attribute? RFC 4511 section 4.2 states that the correct attribute is subschemaSubentry, not subschemeSubentry. The in-memory directory server does correctly return the subschemaSubentry attribute in the root DSE, and in every other entry. Note that it is an operational attribute so you need to explicitly ask for it (or ask for “+”, which indicates that the server should return all operational attributes). Neil On Thu, Aug 31, 2017 at 2:28 AM, <g....@au...> wrote: > Hello Neil, > > > > I wanted to rebuild the more or less exact behavior of a Microsoft Active > Directory LDAP service. > > And at least the Apache Directory Studio does a query on the base DN "" > using filter "(objectClass=*)" asking for attribute "subschemeSubentry". > > The AD LDAP response with an entry having the DN "" and the attribute > "subschemeSubentry". > > That's the reason. > > > > Now I simply intercept that query and reply with the right answer. No > referral needed. > > > > Gruß > > Gerrit > > > > *Von:* Neil Wilson via ldap-sdk-discuss [mailto:ldap-sdk-discuss@ > lists.sourceforge.net] > *Gesendet:* Mittwoch, 30. August 2017 18:00 > *An:* LDAP SDK Discussions > *Cc:* Neil Wilson > *Betreff:* Re: [ldap-sdk-discuss] Adding referral to > InMemoryDirectoryServer > > > > What behavior do you expect? > > > > If you search with a base DN of the empty string (the null base DN), then > the in-memory directory server will exhibit the standard LDAPv3 behavior. > If you use a scope of BASE, then it will retrieve the root DSE entry that > provides information about the server’s capabilities and data. If you use a > different scope, then it will automatically consider the null DN to be the > immediate parent of each of the naming contexts. > > > > So in your case, if you have a base DN of “DC=test,DC=company,DC=local” > and perform a subtree search with a base DN equal to the null DN, then it > will automatically search below DC=test,DC=company,DC=local. However, this > doesn’t work for DNs subordinate to the null DN but superior to the naming > context. For example, if you search with a base DN of “DC=local”, then the > correct standard behavior is to get a NO_SUCH_OBJECT result because that > entry doesn’t exist. The interceptor that I provided can change that to > return a referral to “DC=test,DC=company,DC=local” instead, but that’s not > really standards-compliant behavior. > > > > Neil > > > > > > On Wed, Aug 30, 2017 at 4:16 AM, <g....@au...> wrote: > > Hello Neil, > > > > Thanks for your reply. > > On the way implementing that interceptor I had to realize that a referral > didn't solve my problem. > > But I was able to intercept the request which doesn't have a base ("") and > reply with an entry which contained the needed information for the client. > > And that finally solved my problem. :-) > > > > Regards, > > Gerrit > > > > *Von:* Neil Wilson via ldap-sdk-discuss [mailto:ldap-sdk-discuss@ > lists.sourceforge.net] > *Gesendet:* Dienstag, 29. August 2017 21:26 > *An:* LDAP SDK Discussions > *Cc:* Neil Wilson > *Betreff:* Re: [ldap-sdk-discuss] Adding referral to > InMemoryDirectoryServer > > > > Although both the LDAP SDK and the in-memory directory server support > referrals, you cannot create referral entries above non-referral entries. > You probably don’t really want that anyway, because referral entries > generally apply to all types of operations, and you don’t want the server > telling the client to send a modify attempt targeting “DC=local” to > “DC=test,DC=company,DC=local” instead. > > > > Presumably, what you really want is to have only search operations with a > base DN that is superior to “DC=test,DC=company,DC=local” to receive a > referral telling them to use a base DN of “DC=test,DC=company,DC=local”. If > you want that, you can achieve it with an InMemoryOperationInterceptor > that intercepts search requests and throws an LDAPException with a > referral result if the request has a base DN that is superior to the > desired base DN. The attached ReferSearchesAboveBaseInMemory > OperationInterceptor.java source file does exactly that. > > > > It’s pretty trivial to use the attached interceptor. Just use the > InMemoryDirectoryServerConfig.addInMemoryOperationInterceptor method. For > example: > > > > final String baseDN = "DC=test,DC=company,DC=local"; > > final InMemoryDirectoryServerConfig cfg = > > new InMemoryDirectoryServerConfig(baseDN); > > cfg.addInMemoryOperationInterceptor( > > new ReferSearchesAboveBaseInMemoryOperationInterceptor(baseDN)); > > > > final InMemoryDirectoryServer ds = new InMemoryDirectoryServer(cfg); > > ds.add( > > "dn: DC=test,DC=company,DC=local", > > "objectClass: top", > > "objectClass: domain", > > "DC: test"); > > ds.startListening(); > > > > try > > { > > final LDAPConnectionOptions connectionOptions = > > new LDAPConnectionOptions(); > > connectionOptions.setFollowReferrals(true); > > > > try (LDAPConnection connection = ds.getConnection(connectionOptions)) > > { > > final SearchResult searchResult = connection.search("DC=local", > > SearchScope.SUB, Filter.createPresenceFilter("objectClass")); > > > > LDAPTestUtils.assertResultCodeEquals(searchResult, > ResultCode.SUCCESS); > > LDAPTestUtils.assertEntriesReturnedEquals(searchResult, 1); > > LDAPTestUtils.assertEntryReturned(searchResult, > > "DC=test,DC=company,DC=local"); > > } > > } > > finally > > { > > ds.shutDown(true); > > } > > > > I hope this does what you need, or at least puts you on the right track. > > > > Neil > > > > > > On Tue, Aug 29, 2017 at 7:36 AM, <g....@au...> wrote: > > Hello everyone, > > > > I'm currently "fighting" with the InMemoryDirectoryServer. > > So far it works perfectly. I can use SSL/TLS, I can add credentials as > well as entries. > > But somehow I can't figure out how to add referrals. > > My base DN is "DC=test,DC=company,DC=local" and I want referrals on each > of the previous levels ("DC=company,DC=local", "DC=local", "") pointing to > that base DN. > > > > Regards, > > Gerrit > > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ldap-sdk-discuss mailing list > lda...@li... > https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ldap-sdk-discuss mailing list > lda...@li... > https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ldap-sdk-discuss mailing list > lda...@li... > https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* |
|
From: <g....@au...> - 2017-08-31 07:29:08
|
Hello Neil,
I wanted to rebuild the more or less exact behavior of a Microsoft Active Directory LDAP service.
And at least the Apache Directory Studio does a query on the base DN "" using filter "(objectClass=*)" asking for attribute "subschemeSubentry".
The AD LDAP response with an entry having the DN "" and the attribute "subschemeSubentry".
That's the reason.
Now I simply intercept that query and reply with the right answer. No referral needed.
Gruß
Gerrit
Von: Neil Wilson via ldap-sdk-discuss [mailto:lda...@li...]
Gesendet: Mittwoch, 30. August 2017 18:00
An: LDAP SDK Discussions
Cc: Neil Wilson
Betreff: Re: [ldap-sdk-discuss] Adding referral to InMemoryDirectoryServer
What behavior do you expect?
If you search with a base DN of the empty string (the null base DN), then the in-memory directory server will exhibit the standard LDAPv3 behavior. If you use a scope of BASE, then it will retrieve the root DSE entry that provides information about the server’s capabilities and data. If you use a different scope, then it will automatically consider the null DN to be the immediate parent of each of the naming contexts.
So in your case, if you have a base DN of “DC=test,DC=company,DC=local” and perform a subtree search with a base DN equal to the null DN, then it will automatically search below DC=test,DC=company,DC=local. However, this doesn’t work for DNs subordinate to the null DN but superior to the naming context. For example, if you search with a base DN of “DC=local”, then the correct standard behavior is to get a NO_SUCH_OBJECT result because that entry doesn’t exist. The interceptor that I provided can change that to return a referral to “DC=test,DC=company,DC=local” instead, but that’s not really standards-compliant behavior.
Neil
On Wed, Aug 30, 2017 at 4:16 AM, <g....@au...> wrote:
Hello Neil,
Thanks for your reply.
On the way implementing that interceptor I had to realize that a referral didn't solve my problem.
But I was able to intercept the request which doesn't have a base ("") and reply with an entry which contained the needed information for the client.
And that finally solved my problem. :-)
Regards,
Gerrit
Von: Neil Wilson via ldap-sdk-discuss [mailto:lda...@li...]
Gesendet: Dienstag, 29. August 2017 21:26
An: LDAP SDK Discussions
Cc: Neil Wilson
Betreff: Re: [ldap-sdk-discuss] Adding referral to InMemoryDirectoryServer
Although both the LDAP SDK and the in-memory directory server support referrals, you cannot create referral entries above non-referral entries. You probably don’t really want that anyway, because referral entries generally apply to all types of operations, and you don’t want the server telling the client to send a modify attempt targeting “DC=local” to “DC=test,DC=company,DC=local” instead.
Presumably, what you really want is to have only search operations with a base DN that is superior to “DC=test,DC=company,DC=local” to receive a referral telling them to use a base DN of “DC=test,DC=company,DC=local”. If you want that, you can achieve it with an InMemoryOperationInterceptor that intercepts search requests and throws an LDAPException with a referral result if the request has a base DN that is superior to the desired base DN. The attached ReferSearchesAboveBaseInMemoryOperationInterceptor.java source file does exactly that.
It’s pretty trivial to use the attached interceptor. Just use the InMemoryDirectoryServerConfig.addInMemoryOperationInterceptor method. For example:
final String baseDN = "DC=test,DC=company,DC=local";
final InMemoryDirectoryServerConfig cfg =
new InMemoryDirectoryServerConfig(baseDN);
cfg.addInMemoryOperationInterceptor(
new ReferSearchesAboveBaseInMemoryOperationInterceptor(baseDN));
final InMemoryDirectoryServer ds = new InMemoryDirectoryServer(cfg);
ds.add(
"dn: DC=test,DC=company,DC=local",
"objectClass: top",
"objectClass: domain",
"DC: test");
ds.startListening();
try
{
final LDAPConnectionOptions connectionOptions =
new LDAPConnectionOptions();
connectionOptions.setFollowReferrals(true);
try (LDAPConnection connection = ds.getConnection(connectionOptions))
{
final SearchResult searchResult = connection.search("DC=local",
SearchScope.SUB, Filter.createPresenceFilter("objectClass"));
LDAPTestUtils.assertResultCodeEquals(searchResult, ResultCode.SUCCESS);
LDAPTestUtils.assertEntriesReturnedEquals(searchResult, 1);
LDAPTestUtils.assertEntryReturned(searchResult,
"DC=test,DC=company,DC=local");
}
}
finally
{
ds.shutDown(true);
}
I hope this does what you need, or at least puts you on the right track.
Neil
On Tue, Aug 29, 2017 at 7:36 AM, <g....@au...> wrote:
Hello everyone,
I'm currently "fighting" with the InMemoryDirectoryServer.
So far it works perfectly. I can use SSL/TLS, I can add credentials as well as entries.
But somehow I can't figure out how to add referrals.
My base DN is "DC=test,DC=company,DC=local" and I want referrals on each of the previous levels ("DC=company,DC=local", "DC=local", "") pointing to that base DN.
Regards,
Gerrit
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
ldap-sdk-discuss mailing list
lda...@li...
https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
ldap-sdk-discuss mailing list
lda...@li...
https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
|
|
From: Neil W. <nei...@pi...> - 2017-08-30 16:00:33
|
What behavior do you expect?
If you search with a base DN of the empty string (the null base DN), then
the in-memory directory server will exhibit the standard LDAPv3 behavior.
If you use a scope of BASE, then it will retrieve the root DSE entry that
provides information about the server’s capabilities and data. If you use a
different scope, then it will automatically consider the null DN to be the
immediate parent of each of the naming contexts.
So in your case, if you have a base DN of “DC=test,DC=company,DC=local” and
perform a subtree search with a base DN equal to the null DN, then it will
automatically search below DC=test,DC=company,DC=local. However, this
doesn’t work for DNs subordinate to the null DN but superior to the naming
context. For example, if you search with a base DN of “DC=local”, then the
correct standard behavior is to get a NO_SUCH_OBJECT result because that
entry doesn’t exist. The interceptor that I provided can change that to
return a referral to “DC=test,DC=company,DC=local” instead, but that’s not
really standards-compliant behavior.
Neil
On Wed, Aug 30, 2017 at 4:16 AM, <g....@au...> wrote:
> Hello Neil,
>
>
>
> Thanks for your reply.
>
> On the way implementing that interceptor I had to realize that a referral
> didn't solve my problem.
>
> But I was able to intercept the request which doesn't have a base ("") and
> reply with an entry which contained the needed information for the client.
>
> And that finally solved my problem. :-)
>
>
>
> Regards,
>
> Gerrit
>
>
>
> *Von:* Neil Wilson via ldap-sdk-discuss [mailto:ldap-sdk-discuss@
> lists.sourceforge.net]
> *Gesendet:* Dienstag, 29. August 2017 21:26
> *An:* LDAP SDK Discussions
> *Cc:* Neil Wilson
> *Betreff:* Re: [ldap-sdk-discuss] Adding referral to
> InMemoryDirectoryServer
>
>
>
> Although both the LDAP SDK and the in-memory directory server support
> referrals, you cannot create referral entries above non-referral entries.
> You probably don’t really want that anyway, because referral entries
> generally apply to all types of operations, and you don’t want the server
> telling the client to send a modify attempt targeting “DC=local” to
> “DC=test,DC=company,DC=local” instead.
>
>
>
> Presumably, what you really want is to have only search operations with a
> base DN that is superior to “DC=test,DC=company,DC=local” to receive a
> referral telling them to use a base DN of “DC=test,DC=company,DC=local”. If
> you want that, you can achieve it with an InMemoryOperationInterceptor
> that intercepts search requests and throws an LDAPException with a
> referral result if the request has a base DN that is superior to the
> desired base DN. The attached ReferSearchesAboveBaseInMemory
> OperationInterceptor.java source file does exactly that.
>
>
>
> It’s pretty trivial to use the attached interceptor. Just use the
> InMemoryDirectoryServerConfig.addInMemoryOperationInterceptor method. For
> example:
>
>
>
> final String baseDN = "DC=test,DC=company,DC=local";
>
> final InMemoryDirectoryServerConfig cfg =
>
> new InMemoryDirectoryServerConfig(baseDN);
>
> cfg.addInMemoryOperationInterceptor(
>
> new ReferSearchesAboveBaseInMemoryOperationInterceptor(baseDN));
>
>
>
> final InMemoryDirectoryServer ds = new InMemoryDirectoryServer(cfg);
>
> ds.add(
>
> "dn: DC=test,DC=company,DC=local",
>
> "objectClass: top",
>
> "objectClass: domain",
>
> "DC: test");
>
> ds.startListening();
>
>
>
> try
>
> {
>
> final LDAPConnectionOptions connectionOptions =
>
> new LDAPConnectionOptions();
>
> connectionOptions.setFollowReferrals(true);
>
>
>
> try (LDAPConnection connection = ds.getConnection(connectionOptions))
>
> {
>
> final SearchResult searchResult = connection.search("DC=local",
>
> SearchScope.SUB, Filter.createPresenceFilter("objectClass"));
>
>
>
> LDAPTestUtils.assertResultCodeEquals(searchResult,
> ResultCode.SUCCESS);
>
> LDAPTestUtils.assertEntriesReturnedEquals(searchResult, 1);
>
> LDAPTestUtils.assertEntryReturned(searchResult,
>
> "DC=test,DC=company,DC=local");
>
> }
>
> }
>
> finally
>
> {
>
> ds.shutDown(true);
>
> }
>
>
>
> I hope this does what you need, or at least puts you on the right track.
>
>
>
> Neil
>
>
>
>
>
> On Tue, Aug 29, 2017 at 7:36 AM, <g....@au...> wrote:
>
> Hello everyone,
>
>
>
> I'm currently "fighting" with the InMemoryDirectoryServer.
>
> So far it works perfectly. I can use SSL/TLS, I can add credentials as
> well as entries.
>
> But somehow I can't figure out how to add referrals.
>
> My base DN is "DC=test,DC=company,DC=local" and I want referrals on each
> of the previous levels ("DC=company,DC=local", "DC=local", "") pointing to
> that base DN.
>
>
>
> Regards,
>
> Gerrit
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>
>
--
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you.*
|
|
From: <g....@au...> - 2017-08-30 09:16:15
|
Hello Neil,
Thanks for your reply.
On the way implementing that interceptor I had to realize that a referral didn't solve my problem.
But I was able to intercept the request which doesn't have a base ("") and reply with an entry which contained the needed information for the client.
And that finally solved my problem. :-)
Regards,
Gerrit
Von: Neil Wilson via ldap-sdk-discuss [mailto:lda...@li...]
Gesendet: Dienstag, 29. August 2017 21:26
An: LDAP SDK Discussions
Cc: Neil Wilson
Betreff: Re: [ldap-sdk-discuss] Adding referral to InMemoryDirectoryServer
Although both the LDAP SDK and the in-memory directory server support referrals, you cannot create referral entries above non-referral entries. You probably don’t really want that anyway, because referral entries generally apply to all types of operations, and you don’t want the server telling the client to send a modify attempt targeting “DC=local” to “DC=test,DC=company,DC=local” instead.
Presumably, what you really want is to have only search operations with a base DN that is superior to “DC=test,DC=company,DC=local” to receive a referral telling them to use a base DN of “DC=test,DC=company,DC=local”. If you want that, you can achieve it with an InMemoryOperationInterceptor that intercepts search requests and throws an LDAPException with a referral result if the request has a base DN that is superior to the desired base DN. The attached ReferSearchesAboveBaseInMemoryOperationInterceptor.java source file does exactly that.
It’s pretty trivial to use the attached interceptor. Just use the InMemoryDirectoryServerConfig.addInMemoryOperationInterceptor method. For example:
final String baseDN = "DC=test,DC=company,DC=local";
final InMemoryDirectoryServerConfig cfg =
new InMemoryDirectoryServerConfig(baseDN);
cfg.addInMemoryOperationInterceptor(
new ReferSearchesAboveBaseInMemoryOperationInterceptor(baseDN));
final InMemoryDirectoryServer ds = new InMemoryDirectoryServer(cfg);
ds.add(
"dn: DC=test,DC=company,DC=local",
"objectClass: top",
"objectClass: domain",
"DC: test");
ds.startListening();
try
{
final LDAPConnectionOptions connectionOptions =
new LDAPConnectionOptions();
connectionOptions.setFollowReferrals(true);
try (LDAPConnection connection = ds.getConnection(connectionOptions))
{
final SearchResult searchResult = connection.search("DC=local",
SearchScope.SUB, Filter.createPresenceFilter("objectClass"));
LDAPTestUtils.assertResultCodeEquals(searchResult, ResultCode.SUCCESS);
LDAPTestUtils.assertEntriesReturnedEquals(searchResult, 1);
LDAPTestUtils.assertEntryReturned(searchResult,
"DC=test,DC=company,DC=local");
}
}
finally
{
ds.shutDown(true);
}
I hope this does what you need, or at least puts you on the right track.
Neil
On Tue, Aug 29, 2017 at 7:36 AM, <g....@au...> wrote:
Hello everyone,
I'm currently "fighting" with the InMemoryDirectoryServer.
So far it works perfectly. I can use SSL/TLS, I can add credentials as well as entries.
But somehow I can't figure out how to add referrals.
My base DN is "DC=test,DC=company,DC=local" and I want referrals on each of the previous levels ("DC=company,DC=local", "DC=local", "") pointing to that base DN.
Regards,
Gerrit
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
ldap-sdk-discuss mailing list
lda...@li...
https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
|
|
From: Neil W. <nei...@pi...> - 2017-08-29 19:53:56
|
Although both the LDAP SDK and the in-memory directory server support
referrals, you cannot create referral entries above non-referral entries.
You probably don’t really want that anyway, because referral entries
generally apply to all types of operations, and you don’t want the server
telling the client to send a modify attempt targeting “DC=local” to
“DC=test,DC=company,DC=local” instead.
Presumably, what you really want is to have only search operations with a
base DN that is superior to “DC=test,DC=company,DC=local” to receive a
referral telling them to use a base DN of “DC=test,DC=company,DC=local”. If
you want that, you can achieve it with an InMemoryOperationInterceptor that
intercepts search requests and throws an LDAPException with a referral
result if the request has a base DN that is superior to the desired base
DN. The attached ReferSearchesAboveBaseInMemoryOperationInterceptor.java
source file does exactly that.
It’s pretty trivial to use the attached interceptor. Just use the
InMemoryDirectoryServerConfig.addInMemoryOperationInterceptor method. For
example:
final String baseDN = "DC=test,DC=company,DC=local";
final InMemoryDirectoryServerConfig cfg =
new InMemoryDirectoryServerConfig(baseDN);
cfg.addInMemoryOperationInterceptor(
new ReferSearchesAboveBaseInMemoryOperationInterceptor(baseDN));
final InMemoryDirectoryServer ds = new InMemoryDirectoryServer(cfg);
ds.add(
"dn: DC=test,DC=company,DC=local",
"objectClass: top",
"objectClass: domain",
"DC: test");
ds.startListening();
try
{
final LDAPConnectionOptions connectionOptions =
new LDAPConnectionOptions();
connectionOptions.setFollowReferrals(true);
try (LDAPConnection connection = ds.getConnection(connectionOptions))
{
final SearchResult searchResult = connection.search("DC=local",
SearchScope.SUB, Filter.createPresenceFilter("objectClass"));
LDAPTestUtils.assertResultCodeEquals(searchResult,
ResultCode.SUCCESS);
LDAPTestUtils.assertEntriesReturnedEquals(searchResult, 1);
LDAPTestUtils.assertEntryReturned(searchResult,
"DC=test,DC=company,DC=local");
}
}
finally
{
ds.shutDown(true);
}
I hope this does what you need, or at least puts you on the right track.
Neil
On Tue, Aug 29, 2017 at 7:36 AM, <g....@au...> wrote:
> Hello everyone,
>
>
>
> I'm currently "fighting" with the InMemoryDirectoryServer.
>
> So far it works perfectly. I can use SSL/TLS, I can add credentials as
> well as entries.
>
> But somehow I can't figure out how to add referrals.
>
> My base DN is "DC=test,DC=company,DC=local" and I want referrals on each
> of the previous levels ("DC=company,DC=local", "DC=local", "") pointing to
> that base DN.
>
>
>
> Regards,
>
> Gerrit
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>
>
--
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you.*
|
|
From: <g....@au...> - 2017-08-29 12:49:26
|
Hello everyone,
I'm currently "fighting" with the InMemoryDirectoryServer.
So far it works perfectly. I can use SSL/TLS, I can add credentials as
well as entries.
But somehow I can't figure out how to add referrals.
My base DN is "DC=test,DC=company,DC=local" and I want referrals on each
of the previous levels ("DC=company,DC=local", "DC=local", "") pointing
to that base DN.
Regards,
Gerrit
|
|
From: Neil W. <nei...@un...> - 2017-06-14 22:29:04
|
The UnboundID LDAP SDK for Java version 4.0.0 has been released. It is available for immediate download from the LDAP.com website <https://www.ldap.com/unboundid-ldap-sdk-for-java>, from our GitHub repository <https://github.com/pingidentity/ldapsdk>, from the SourceForge project <https://sourceforge.net/projects/ldap-sdk/>, or from the Maven Central Repository <https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.unboundid%22%20AND%20a%3A%22unboundid-ldapsdk%22> . Some of the most significant changes in this release are: - The LDAP SDK now requires Java SE 7 or later. Java SE 7 and 8 are officially supported. There are known issues when trying to build the LDAP SDK on Java SE 9 early access builds, but builds of the LDAP SDK should run without issues on Java SE 9. Java SE versions 1.5 and 1.6 are no longer supported. - We now provide only a single edition of the LDAP SDK. We used to provide Standard Edition, Commercial Edition, and Minimal Edition versions of the LDAP SDK, but they have been consolidated into a single edition that contains everything that was previously in the Commercial Edition (which was a superset of the Standard Edition, which was itself a superset of the Minimal Edition). That single edition is now called just “UnboundID LDAP SDK for Java” and is still available under the terms of the GNU General Public License version 2 (GPLv2), the GNU Lesser General Public License version 2.1 (LGPLv2.1), and the UnboundID LDAP SDK Free Use License. - The GitHub repository for the LDAP SDK has been moved into the Ping Identity organization. The URL to the repository has changed from https://github.com/unboundid/ldapsdk to https://github.com/pingidentity/ldapsdk, but a redirect is in place to ensure that links to the old URL will be automatically transferred to the new location. - All copyright notices have been updated to reference Ping Identity, and the LDAP SDK documentation now uses Ping Identity branding. - The open source repositories for the LDAP SDK have been updated to become a complete mirror of the internal repository used to create official builds. The biggest change to come from this is that the full set of LDAP SDK unit tests are now publicly available under the same licenses as the rest of the LDAP SDK. - This release fixes a bug in the logic for parsing DNs from a string in which one or more RDN values used a BER encoding by starting the value with the octothorpe (#) character. The LDAP SDK would incorrectly use the entire set of bytes (representing the BER type, length, and value) as the attribute value instead of just the BER element value. - This release fixes a bug in the LDAP connection pool’s connection handling. If the connection pool is configured with createIfNecessary set to false and the replaceDefunctConnection method is called but unable to create a new connection, then the defunct connection could be destroyed without allowing for a replacement. If this happened enough times, the pool could run out of connections and would refuse to create new connections. - This release fixes a bug in processing multi-stage SASL binds. Each bind request in a multi-stage bind should use a different LDAP message ID, but earlier versions of the LDAP SDK would use the same message ID for the later stages that it used for the first stage. - This release fixes a bug in the in-memory directory server’s LDIF import code that prevented it from applying the configured schema to the entries being imported. - This release fixes a bug in the in-memory directory server’s handling of LDAP subentries. The server could incorrectly return entries that are not LDAP subentries in response to a search request that included the subentries request control. - This release fixes bugs various bugs in the ldapsearch and ldapmodify command-line tools, and in the command-line argument parser. - The LDAP SDK documentation now includes a few new LDAP reference documents, including a result code reference guide, an OID reference guide, and an LDAPv3 wire protocol reference guide. - The set of LDAP-related specifications has been updated to include some additional RFCs (including 2926, 2985, 4226, and 6238), and updated versions of IETF drafts (including draft-kille-ldap-xmpp-schema, draft-seantek-ldap-pkcs9, and draft-wibrown-ldapssotoken). - When the LDAP SDK is checked out from a git repository, the build process can now capture information about the state of that repository, including the repository URL and the revision ID. This makes it easier to identify the precise source code revision used to create an LDAP SDK build for troubleshooting purposes. Previously, this information was only available if the LDAP SDK was checked out of a subversion repository. -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* |
|
From: Neil A. W. <nei...@un...> - 2017-02-14 20:17:01
|
I apologize if you have received this message twice. It seems that when I sent this message originally from my pingidentity.com account, it was incorrectly marked as spam for a number of recipients. To try to avoid that, I'm resending it from my unboundid.com email address. We have just released the 3.2.1 version of the UnboundID LDAP SDK for Java. It is available for download from the LDAP.com website [https://www.ldap.com/unboundid-ldap-sdk-for-java], as well as from GitHub [https://github.com/UnboundID/ldapsdk], SourceForge [https://sourceforge.net/projects/ldap-sdk/], or the Maven Central Repository. You can get a full list of changes included in this release from the release notes [https://docs.ldap.com/ldap-sdk/docs/release-notes.html]. The Commercial Edition release notes [https://docs.ldap.com/ldap-sdk/docs/commercial-edition/release-notes.html] also provide information about additional changes only included in the Commercial Edition. Some of the most significant changes in both the Standard Edition and the Commercial Edition include: - Updated the documentation to indicate that, as a result of Ping Identity's acquisition of UnboundID, all non-public feedback, feature enhancements, support requests, and other kinds of communication should now be sent to lda...@pi... instead of lda...@un.... We also now recommend using the GitHub issue tracker over the SourceForge mailing lists and discussion forums for bug reports and feature requests. - Fixed a bug in the RDN parsing code that could cause multiple consecutive spaces in the middle of an attribute value to be condensed down to a single space. The string representation of the RDN was preserved correctly, but the methods used to retrieve attribute values as a string or byte array could return values that were missing spaces. - Provided better handling for InterruptedException. A thread's interrupted state will now be preserved for cases in which the LDAP SDK consumes an InterruptedException without doing something to handle it. - Fixed a bug in the support for the SASL ANONYMOUS mechanism that could cause the trace string to be omitted from the encoded bind request. - Updated the searchrate tool to provide support for generic controls, as well as specific support for the assertion, simple paged results, and server-side sort request controls. - Updated the authrate tool to add a new --bindOnly argument that allows you to indicate that the tool should only perform bind operations, rather than a search to find the entry and then a bind as that user. The base DN pattern will be used to construct the bind DN. - Updated the authrate tool to provided support for generic search and bind controls, as well as specific support for the authorization identity and password policy request controls. - Updated the search-and-modrate tool to provide support for generic search and modify controls, as well as specific support for the assertion, simple paged results, permissive modify, pre-read, and post-read request controls. - Added a Schema.getSchema method that can read schema information in LDIF form from an input stream. - Updated support for the GSSAPI SASL mechanism to make it possible to indicate in the generated configuration file whether the client should act as an initiator or an acceptor. - Updated the identify-unique-attribute-conflicts tool to include a time limit in search requests intended to determine whether a unique attribute value may also be in use in any other entries. This can help limit the effect of running the tool against a server that is not configured with the appropriate indexes needed to ensure that equality searches targeting the unique attributes can be processed efficiently. Some of the additional changes only available in the Commercial Edition include: - Added a new version of the ldapsearch tool that provides a lot of additional functionality over the version provided in the Standard Edition. It includes much better output formatting (including support for alternate output formats like JSON, CSV, and tab-delimited text), support for a number of data transformations, more robust connection handling, support for referrals, support for a large number of search and bind controls, support for administrative sessions, support for unsolicited notifications, the ability to process multiple searches with search criteria provided in filter or LDAP URL files, rate limiting, and the ability to send results to a specified output file (or a separate output file per search). - Implemented caching for the matching rule instance used when requesting the jsonObjectExactMatch matching rule. This matching rule only exists in the Commercial Edition and needs to be loaded via reflection. - Updated the access and error log parsing APIs to include support for the triggeredByConn and triggeredByOp log fields used to indicate that the message is associated with the indicated operation. Neil Wilson Principal Engineer Ping Identity |
|
From: Neil W. <nei...@pi...> - 2017-02-14 17:45:32
|
We have just released the 3.2.1 version of the UnboundID LDAP SDK for Java. It is available for download from the LDAP.com website <https://www.ldap.com/unboundid-ldap-sdk-for-java>, as well as from GitHub <https://github.com/UnboundID/ldapsdk>, SourceForge <https://sourceforge.net/projects/ldap-sdk/>, or the Maven Central Repository. You can get a full list of changes included in this release from the release notes <https://docs.ldap.com/ldap-sdk/docs/release-notes.html>. The Commercial Edition release notes <https://docs.ldap.com/ldap-sdk/docs/commercial-edition/release-notes.html> also provide information about additional changes only included in the Commercial Edition. Some of the most significant changes in both the Standard Edition and the Commercial Edition include - Updated the documentation to indicate that, as a result of Ping Identity's acquisition of UnboundID, all non-public feedback, feature enhancements, support requests, and other kinds of communication should now be sent to lda...@pi... instead of lda...@un.... We also now recommend using the GitHub issue tracker <https://github.com/UnboundID/ldapsdk/issues> over the SourceForge mailing lists and discussion forums for bug reports and feature requests. - Fixed a bug in the RDN parsing code that could cause multiple consecutive spaces in the middle of an attribute value to be condensed down to a single space. The string representation of the RDN was preserved correctly, but the methods used to retrieve attribute values as a string or byte array could return values that were missing spaces. - Provided better handling for InterruptedException. A thread's interrupted state will now be preserved for cases in which the LDAP SDK consumes an InterruptedException without doing something to handle it. - Fixed a bug in the support for the SASL ANONYMOUS mechanism that could cause the trace string to be omitted from the encoded bind request. - Updated the searchrate tool to provide support for generic controls, as well as specific support for the assertion, simple paged results, and server-side sort request controls. - Updated the authrate tool to add a new --bindOnly argument that allows you to indicate that the tool should only perform bind operations, rather than a search to find the entry and then a bind as that user. The base DN pattern will be used to construct the bind DN. - Updated the authrate tool to provided support for generic search and bind controls, as well as specific support for the authorization identity and password policy request controls. - Updated the search-and-modrate tool to provide support for generic search and modify controls, as well as specific support for the assertion, simple paged results, permissive modify, pre-read, and post-read request controls. - Added a Schema.getSchema method that can read schema information in LDIF form from an input stream. - Updated support for the GSSAPI SASL mechanism to make it possible to indicate in the generated configuration file whether the client should act as an initiator or an acceptor. - Updated the identify-unique-attribute-conflicts tool to include a time limit in search requests intended to determine whether a unique attribute value may also be in use in any other entries. This can help limit the effect of running the tool against a server that is not configured with the appropriate indexes needed to ensure that equality searches targeting the unique attributes can be processed efficiently. Some of the additional changes only available in the Commercial Edition include: - Added a new version of the ldapsearch tool that provides a lot of additional functionality over the version provided in the Standard Edition. It includes much better output formatting (including support for alternate output formats like JSON, CSV, and tab-delimited text), support for a number of data transformations, more robust connection handling, support for referrals, support for a large number of search and bind controls, support for administrative sessions, support for unsolicited notifications, the ability to process multiple searches with search criteria provided in filter or LDAP URL files, rate limiting, and the ability to send results to a specified output file (or a separate output file per search). - Implemented caching for the matching rule instance used when requesting the jsonObjectExactMatch matching rule. This matching rule only exists in the Commercial Edition and needs to be loaded via reflection. - Updated the access and error log parsing APIs to include support for the triggeredByConn and triggeredByOp log fields used to indicate that the message is associated with the indicated operation. Neil Wilson Principal Engineer Ping Identity |
|
From: Neil W. <nei...@pi...> - 2017-01-26 18:15:52
|
On Thu, Jan 26, 2017 at 6:43 AM, Nikos Gkotsis <oks...@gm...> wrote:
> Hello,
>
> While using your ldap-sdk, a question came up.
>
> I am thinking of making one ldap entry (one DN) with several attributes,
> key value pair of strings.
> My question is the following:
>
> Is there a way to get attributes using a wildcard, eg all attributes whose
> name starts with a.
> I tried using the following but this attributes parameter does not work as
> i would like to when i passed it as "a*'.
> Filter is just a trivial one that leads me to my one and only entry.
>
> SearchRequest searchRequest = new SearchRequest("uid=aaa", SearchScope.SUB, filter, "a*");
>
>
>
You can’t use a wildcard in exactly the way that you’re trying to use it.
There is no way to request just attribute names that start with “a”.
However, LDAP does support a few different kinds of wildcards for
requesting attributes. They are:
- If you want to request all user attributes (that is, all attributes that
are intended for regular applications to interact with) you can request
“*”. All directory servers that I’m aware of support this feature.
- If you want to request all operational attributes (that is, attributes
that are used internally by the server for maintaining per-entry state or
configuration, for example, when the user last changed their password, the
number of failed authentication attempts since the last successful login,
etc.). This is a standard feature of LDAP, and most directory servers
support it, but last time I checked, Oracle DSEE did not, and there may be
others that don’t.
- If you want to request all attributes that are associated with a
particular object class, you can precede the name of that object class with
the at sign (for example, “@inetOrgPerson” will request all attributes
associated with the inetOrgPerson object class). This capability is
described in RFC 4529, and there may not be that many servers that support
it. However, if a server does support it, then its root DSE should list
“1.3.6.1.4.1.4203.1.5.2” as one of the values of the supportedFeatures
operational attribute.
You can combine these if you want (for example, if you request both “*” and
“+”, then that should return all user attributes and all operational
attributes that you’re allowed to see). But in your case, you probably
just want to use “*”, since you shouldn’t mess with operational attributes
unless you know what you’re doing. And then when the server returns the
entry, you can simply iterate across the attributes and only look at the
ones with names that start with “a”.
Neil
> Thanks
> Nikos
> --
> https://www.mixcloud.com/attuhs/
>
|
|
From: Nikos G. <oks...@gm...> - 2017-01-26 12:43:24
|
Hello,
While using your ldap-sdk, a question came up.
I am thinking of making one ldap entry (one DN) with several attributes,
key value pair of strings.
My question is the following:
Is there a way to get attributes using a wildcard, eg all attributes whose
name starts with a.
I tried using the following but this attributes parameter does not work as
i would like to when i passed it as "a*'.
Filter is just a trivial one that leads me to my one and only entry.
SearchRequest searchRequest = new SearchRequest("uid=aaa",
SearchScope.SUB, filter, "a*");
Thanks
Nikos
--
https://www.mixcloud.com/attuhs/
|
|
From: Neil A. W. <nei...@un...> - 2016-09-27 14:13:06
|
On 09/27/2016 08:35 AM, Kasim Doctor wrote: > Hi Neil, > > When you say * UnboundID Directory Server, *does it imply that the > UnboundId LDAP Java SDK is also guaranteed to return superior entries > before subordinate entries ? > > The reason I am asking is because I am using the UnboundId LDAP Java SDK to > fetch OUs from Microsoft Active Directory. > > As always, your input here is utmost valuable. No, when I say "UnboundID Directory Server", I mean the commercial LDAP server product that UnboundID sells. The LDAP SDK always makes search result entries available in the order that the directory server returns them. The only way that the LDAP SDK can change the order of search results is to include some special control in the search request, like the server-side sort control, that tells the server that you want a special order. As I said before, I do expect that most LDAP servers return results in order of parents before children, but I can't guarantee that for any server other than the one that UnboundID sells because that's the only one I have any control over, and the official LDAP specification does say that entries can be returned in any order. If you think that the server you're using might return entries in an order that allows a child to be returned before its parent, then you might need to have some special handling to avoid that, like sorting the entries on the client side using the EntrySorter class that I mentioned earlier. > > Thanks, > Kasim > > On Tue, Sep 20, 2016 at 1:01 PM, Neil A. Wilson <nei...@un...> > wrote: > >> On 09/20/2016 08:45 AM, Kasim Doctor wrote: >>> Hi Neil, >>> >>> Thanks for your quick reply. >>> >>> >>> >>> *I know that with the UnboundID Directory Server, we do guarantee that >>> superior entries will be returned before any of their subordinates, with >>> only a couple of exceptions (for example, searches including the >>> server-side sort or persistent search request control)* >>> Can you please point me to a spec/Javadoc for the above statement ? >>> >>> Thanks, >>> Kasim >> >> There certainly isn't anything in the LDAP SDK javadoc that would make >> that statement. I'm not sure if that statement appears in the UnboundID >> Directory Server documentation, but that isn't currently publicly >> available. >> >> Nevertheless, I am the lead developer for the UnboundID Directory >> Server, and I can assure you that we do guarantee that the UnboundID >> Directory Server will return superior entries before subordinates unless >> the search request includes something special that would alter the order >> in which those entries are returned. >> >> >> >> >>> >>> On Mon, Sep 19, 2016 at 4:46 PM, Neil A. Wilson < >> nei...@un...> >>> wrote: >>> >>>> On 09/19/2016 12:21 PM, Kasim Doctor wrote: >>>>> Hi there, >>>>> >>>>> I am playing around with the LDAP Java SDK API to get a list of OUs >> from >>>> a >>>>> source directory. >>>>> >>>>> I searched everywhere but can't seem to find the answer to the >> following >>>>> question: >>>>> >>>>> When I get the list of OUs, what guarantee is there that the parent OUs >>>> are >>>>> returned before the child OUs are returned ? >>>>> >>>>> Please let me know if there is a spec somewhere for this >>>>> >>>>> Thanks, >>>>> Kasim >>>> >>>> >>>> There is no specification that requires a superior entry to be returned >>>> in search results before its subordinates. In fact, RFC 4511 section >>>> 4.5.2 states "The SearchResultEntry and SearchResultReference messages >>>> may come in any order.", so it would be legal for subordinate entries to >>>> be returned before their superiors. >>>> >>>> However, I expect that most LDAP servers do try to return superior >>>> entries before subordinates. I know that with the UnboundID Directory >>>> Server, we do guarantee that superior entries will be returned before >>>> any of their subordinates, with only a couple of exceptions (for >>>> example, searches including the server-side sort or persistent search >>>> request control). I can't speak definitively for other directory >>>> servers, but I expect that most servers do try to maintain this ordering >>>> under normal circumstances. >>>> >>>> If you're really paranoid about this, and if you expect that your search >>>> won't return a large number of entries, you can have the LDAP SDK sort >>>> the results for you, and you can specify that the sorting should order >>>> each entry first based on its position in the hierarchy and then based >>>> on its content. See the EntrySorter >>>> (https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html? >>>> com/unboundid/ldap/sdk/EntrySorter.html) >>>> class for more information. However, client-side sorting can only be >>>> done if you can hold all of the entries in memory, so you shouldn't do >>>> this if you think there might be a large number of matching entries. >>>> >>>> >>>> Neil >>>> >>>> >>>> >>> >> >> >> > |
|
From: Kasim D. <kas...@gm...> - 2016-09-27 13:35:59
|
Hi Neil, When you say * UnboundID Directory Server, *does it imply that the UnboundId LDAP Java SDK is also guaranteed to return superior entries before subordinate entries ? The reason I am asking is because I am using the UnboundId LDAP Java SDK to fetch OUs from Microsoft Active Directory. As always, your input here is utmost valuable. Thanks, Kasim On Tue, Sep 20, 2016 at 1:01 PM, Neil A. Wilson <nei...@un...> wrote: > On 09/20/2016 08:45 AM, Kasim Doctor wrote: > > Hi Neil, > > > > Thanks for your quick reply. > > > > > > > > *I know that with the UnboundID Directory Server, we do guarantee that > > superior entries will be returned before any of their subordinates, with > > only a couple of exceptions (for example, searches including the > > server-side sort or persistent search request control)* > > Can you please point me to a spec/Javadoc for the above statement ? > > > > Thanks, > > Kasim > > There certainly isn't anything in the LDAP SDK javadoc that would make > that statement. I'm not sure if that statement appears in the UnboundID > Directory Server documentation, but that isn't currently publicly > available. > > Nevertheless, I am the lead developer for the UnboundID Directory > Server, and I can assure you that we do guarantee that the UnboundID > Directory Server will return superior entries before subordinates unless > the search request includes something special that would alter the order > in which those entries are returned. > > > > > > > > On Mon, Sep 19, 2016 at 4:46 PM, Neil A. Wilson < > nei...@un...> > > wrote: > > > >> On 09/19/2016 12:21 PM, Kasim Doctor wrote: > >>> Hi there, > >>> > >>> I am playing around with the LDAP Java SDK API to get a list of OUs > from > >> a > >>> source directory. > >>> > >>> I searched everywhere but can't seem to find the answer to the > following > >>> question: > >>> > >>> When I get the list of OUs, what guarantee is there that the parent OUs > >> are > >>> returned before the child OUs are returned ? > >>> > >>> Please let me know if there is a spec somewhere for this > >>> > >>> Thanks, > >>> Kasim > >> > >> > >> There is no specification that requires a superior entry to be returned > >> in search results before its subordinates. In fact, RFC 4511 section > >> 4.5.2 states "The SearchResultEntry and SearchResultReference messages > >> may come in any order.", so it would be legal for subordinate entries to > >> be returned before their superiors. > >> > >> However, I expect that most LDAP servers do try to return superior > >> entries before subordinates. I know that with the UnboundID Directory > >> Server, we do guarantee that superior entries will be returned before > >> any of their subordinates, with only a couple of exceptions (for > >> example, searches including the server-side sort or persistent search > >> request control). I can't speak definitively for other directory > >> servers, but I expect that most servers do try to maintain this ordering > >> under normal circumstances. > >> > >> If you're really paranoid about this, and if you expect that your search > >> won't return a large number of entries, you can have the LDAP SDK sort > >> the results for you, and you can specify that the sorting should order > >> each entry first based on its position in the hierarchy and then based > >> on its content. See the EntrySorter > >> (https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html? > >> com/unboundid/ldap/sdk/EntrySorter.html) > >> class for more information. However, client-side sorting can only be > >> done if you can hold all of the entries in memory, so you shouldn't do > >> this if you think there might be a large number of matching entries. > >> > >> > >> Neil > >> > >> > >> > > > > > |
|
From: Sergey K. <skl...@op...> - 2016-09-21 01:17:11
|
Hello,
Could you, please, give more details about setUseSubjectCredentialsOnly method of GSSAPIBindRequestProperties class?
I can't understand functionality from the description:
// Specifies whether to allow the client to use credentials that are outside the current subject.
// If this is false, then a system-specific mechanism may be used in an attempt to obtain credentials from an existing session.
What means current subject?
Is it about cross realm Authentication?
When it should be set to "false"?
And another question. I try to use keytab file and call setUseKeyTab(true) method of GSSAPIBindRequestProperties class. I DON'T call setKeyTabPath("path") method.
But I see the error: "Key for the principal us...@EX... not available in default key tab"
What should be the name of "default key tab" in Windows and Linux/Unix?
Where default keytab file should be located in Windows and Linux/Unix?
Thanks in advance,
Sergey
|
|
From: Neil A. W. <nei...@un...> - 2016-09-20 19:41:19
|
We have just released the UnboundID LDAP SDK for Java version 3.2.0. The release notes, available at https://docs.ldap.com/ldap-sdk/docs/release-notes.html, contain an overview of the changes in this release. New versions of the Standard Edition, Commercial Edition, and Minimal Edition are available for download at https://www.ldap.com/unboundid-ldap-sdk-for-java, from GitHub at https://github.com/UnboundID/ldapsdk/releases/latest, and from SourceForge at https://sourceforge.net/projects/ldap-sdk/. It is also available in the Maven Central Repository. Neil Wilson Principal Engineer UnboundID Corp. |
|
From: Neil A. W. <nei...@un...> - 2016-09-20 17:42:31
|
On 09/20/2016 11:02 AM, Sergey Klyushin wrote: > Hello, > > Does UnboundID LDAP SDK have any plans to implement SASL GSS-SPNEGO bind class? > > What is the best way to implement SASL GSS-SPNEGO mechanism now? > Using GenericSASLBindRequest, I can do successful GSS-SPNEGO bind. > However connection, used in bind request, doesn't use GSS API wrapper. Connection still sends clear search requests. > > Thanks in advance, > Sergey I responded to this at https://sourceforge.net/p/ldap-sdk/discussion/1001257/thread/363a06cc/?limit=25. It's really not necessary to post the same question through multiple avenues. Neil |
|
From: Neil A. W. <nei...@un...> - 2016-09-20 17:37:05
|
On 09/20/2016 10:08 AM, Sergey Klyushin wrote: > Hello, > I do bind to AD with GenericSASLBindRequest, using Kerberos token. > > byte[] kerberosToken = getKerberosToken(user, password); > ASN1OctetString credentials = new ASN1OctetString(kerberosToken); > > GenericSASLBindRequest genericSASLBindRequest = new GenericSASLBindRequest(null, "GSS-SPNEGO", credentials, null); > bindResult = ldapConnection.bind(genericSASLBindRequest); > > Bind succeeds!!! > However, when I try to do search on the same connection, search still goes without any Kerberos and obviously AD doesn't respond. > What should I do to force connection to use Kerberos on search requests? > > Thanks in advance, > Sergey Since you asked the same question on the discussion forum at https://sourceforge.net/p/ldap-sdk/discussion/1001257/thread/cf9a5e72/?limit=25, I went ahead and responded to it there. Neil |
