ldap-sdk-discuss — Discussions related to the LDAP SDK for Java

Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

[<nei...@un...>]

It's not really clear what you're asking.  Could you provide a specific example that illustrates what you're trying to do?  And could you please use LDAP terminology, since LDAP doesn't have primary keys or tables.  Do you mean DNs and entries?


Neil


-----Original Message-----
From: "SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)" <him...@al...>
To: "lda...@li..." <lda...@li...>
Sent: Mon, 28 Sep 2015 9:05 AM
Subject: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

Hello LDAP SDK teams,

I am trying to implement a multi-join using the SDK.
My problem is that I have a "master" entry with 4 different attributes.
All 4 of them refer to the PK attribute of 4 other tables.
These other tables are not directly related to each other.

I have to implement a join on all 5 tables in a single search request.

The nestedJoin feature of the JoinRequestControl comes close but cannot completely solve this problem.

Any ideas??


-    Himanshu

[ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

[SINGH, H. K. (H. KUMAR) <him...@al...>]

Hello LDAP SDK teams,

I am trying to implement a multi-join using the SDK.
My problem is that I have a "master" entry with 4 different attributes.
All 4 of them refer to the PK attribute of 4 other tables.
These other tables are not directly related to each other.

I have to implement a join on all 5 tables in a single search request.

The nestedJoin feature of the JoinRequestControl comes close but cannot completely solve this problem.

Any ideas??


-    Himanshu

Re: [ldap-sdk-discuss] Reuse existing kerberos ticket

[Eric B. <eri...@pl...>]

Thank you Neil, as you mentioned this was a misconfiguration issue.

On Tue, Aug 25, 2015 at 2:14 PM, Neil A. Wilson <nei...@un...>
wrote:

> The "Server not found in Kerberos database (7)" message that you're
> getting in the error suggests that you might not be providing the
> correct address for the target directory server when establishing the
> LDAPConnection.  Kerberos is very picky about name resolution and
> generally requires that you use the fully-qualified name for the server.
>
> If you're providing an IP address or an unqualified name for the
> directory server when establishing the LDAPConnection, try providing the
> fully-qualified name instead.  If you're providing a fully-qualified
> name, make sure that it's the same name used to identify that server in
> the KDC, and not an alternate name that resolves to the same address.
> And make sure that the fully-qualified name can be resolved in DNS.
>
> It doesn't look like the issue you're having is directly related to the
> desire to make use of an existing Kerberos session (rather than allowing
> the application to create a new session), and the options you have
> provided look like they should work once you have gotten past this
> problem (assuming that the specified ticket cache file has the
> appropriate content).
>
>
> On 08/25/2015 10:50 AM, Eric Barre wrote:
> > Hi,
> >
> > We are trying to reuse an existing ticket within our application to avoid
> > having to pass a password. Here are the properties that we set:
> >
> > gssapiProperties.setAuthenticationID("krbtgt/MYR...@MY...");
> >
> > gssapiProperties.setRealm("MYREALM.NET");
> >
> > gssapiProperties.setConfigFilePath("/etc/krb5.conf");
> >
> > gssapiProperties.setKDCAddress("xxxx.net");
> >
> > gssapiProperties.setRequireCachedCredentials(true);
> >
> > gssapiProperties.setTicketCachePath("/tmp/krb5cc_48127");
> >
> > gssapiProperties.setUseTicketCache(true);
> >
> > (The authentication id comes from the klist -A. The others are coming
> from
> > the conf file)
> >
> > GSSAPIBindRequest krbr = new GSSAPIBindRequest(gssapiProperties);
> >
> > BindResult auth = ldapConnection.bind(krbr);
> >
> >
> > We are getting the following error:
> >
> > LDAPException(resultCode=82 (local error), errorMessage='The GSSAPI
> > authentication attempt failed:  java.security.PrivilegedActionException:
> > LDAPException(resultCode=82 (local error), errorMessage='Unable to create
> > the initial GSSAPI SASL request:  javax.security.sasl.SaslException: GSS
> > initiate failed [Caused by GSSException: No valid credentials provided
> > (Mechanism level: Server not found in Kerberos database (7) -
> > UNKNOWN_SERVER)] caused by GSSException: No valid credentials provided
> > (Mechanism level: Server not found in Kerberos database (7) -
> > UNKNOWN_SERVER) caused by KrbException: Server not found in Kerberos
> > database (7) - UNKNOWN_SERVER caused by KrbException: Identifier doesn't
> > match expected value (906).')
> >
> >
> > Could anybody tell me what is going on? And also do we need to set up any
> > of those properties if we set the "setUserTicketCache" property?
> >
> > Thank you,
> >
> > Eric
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > ldap-sdk-discuss mailing list
> > lda...@li...
> > https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
> >
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>
>

Re: [ldap-sdk-discuss] Reuse existing kerberos ticket

[Neil A. W. <nei...@un...>]

The "Server not found in Kerberos database (7)" message that you're
getting in the error suggests that you might not be providing the
correct address for the target directory server when establishing the
LDAPConnection.  Kerberos is very picky about name resolution and
generally requires that you use the fully-qualified name for the server.

If you're providing an IP address or an unqualified name for the
directory server when establishing the LDAPConnection, try providing the
fully-qualified name instead.  If you're providing a fully-qualified
name, make sure that it's the same name used to identify that server in
the KDC, and not an alternate name that resolves to the same address.
And make sure that the fully-qualified name can be resolved in DNS.

It doesn't look like the issue you're having is directly related to the
desire to make use of an existing Kerberos session (rather than allowing
the application to create a new session), and the options you have
provided look like they should work once you have gotten past this
problem (assuming that the specified ticket cache file has the
appropriate content).


On 08/25/2015 10:50 AM, Eric Barre wrote:
> Hi,
> 
> We are trying to reuse an existing ticket within our application to avoid
> having to pass a password. Here are the properties that we set:
> 
> gssapiProperties.setAuthenticationID("krbtgt/MYR...@MY...");
> 
> gssapiProperties.setRealm("MYREALM.NET");
> 
> gssapiProperties.setConfigFilePath("/etc/krb5.conf");
> 
> gssapiProperties.setKDCAddress("xxxx.net");
> 
> gssapiProperties.setRequireCachedCredentials(true);
> 
> gssapiProperties.setTicketCachePath("/tmp/krb5cc_48127");
> 
> gssapiProperties.setUseTicketCache(true);
> 
> (The authentication id comes from the klist -A. The others are coming from
> the conf file)
> 
> GSSAPIBindRequest krbr = new GSSAPIBindRequest(gssapiProperties);
> 
> BindResult auth = ldapConnection.bind(krbr);
> 
> 
> We are getting the following error:
> 
> LDAPException(resultCode=82 (local error), errorMessage='The GSSAPI
> authentication attempt failed:  java.security.PrivilegedActionException:
> LDAPException(resultCode=82 (local error), errorMessage='Unable to create
> the initial GSSAPI SASL request:  javax.security.sasl.SaslException: GSS
> initiate failed [Caused by GSSException: No valid credentials provided
> (Mechanism level: Server not found in Kerberos database (7) -
> UNKNOWN_SERVER)] caused by GSSException: No valid credentials provided
> (Mechanism level: Server not found in Kerberos database (7) -
> UNKNOWN_SERVER) caused by KrbException: Server not found in Kerberos
> database (7) - UNKNOWN_SERVER caused by KrbException: Identifier doesn't
> match expected value (906).')
> 
> 
> Could anybody tell me what is going on? And also do we need to set up any
> of those properties if we set the "setUserTicketCache" property?
> 
> Thank you,
> 
> Eric
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
> 

[ldap-sdk-discuss] Reuse existing kerberos ticket

[Eric B. <eri...@pl...>]

Hi,

We are trying to reuse an existing ticket within our application to avoid
having to pass a password. Here are the properties that we set:

gssapiProperties.setAuthenticationID("krbtgt/MYR...@MY...");

gssapiProperties.setRealm("MYREALM.NET");

gssapiProperties.setConfigFilePath("/etc/krb5.conf");

gssapiProperties.setKDCAddress("xxxx.net");

gssapiProperties.setRequireCachedCredentials(true);

gssapiProperties.setTicketCachePath("/tmp/krb5cc_48127");

gssapiProperties.setUseTicketCache(true);

(The authentication id comes from the klist -A. The others are coming from
the conf file)

GSSAPIBindRequest krbr = new GSSAPIBindRequest(gssapiProperties);

BindResult auth = ldapConnection.bind(krbr);


We are getting the following error:

LDAPException(resultCode=82 (local error), errorMessage='The GSSAPI
authentication attempt failed:  java.security.PrivilegedActionException:
LDAPException(resultCode=82 (local error), errorMessage='Unable to create
the initial GSSAPI SASL request:  javax.security.sasl.SaslException: GSS
initiate failed [Caused by GSSException: No valid credentials provided
(Mechanism level: Server not found in Kerberos database (7) -
UNKNOWN_SERVER)] caused by GSSException: No valid credentials provided
(Mechanism level: Server not found in Kerberos database (7) -
UNKNOWN_SERVER) caused by KrbException: Server not found in Kerberos
database (7) - UNKNOWN_SERVER caused by KrbException: Identifier doesn't
match expected value (906).')


Could anybody tell me what is going on? And also do we need to set up any
of those properties if we set the "setUserTicketCache" property?

Thank you,

Eric

Re: [ldap-sdk-discuss] [build] opt-out the svnkit usage

[Alon Bar-L. <alo...@gm...>]

On 12 June 2015 at 00:50, Neil A. Wilson <nei...@un...> wrote:
>
> On 06/11/2015 12:02 AM, Alon Bar-Lev wrote:
> > Hello Neil,
> >
> > It is great you publish the code in github now, we finally have source
> > tarball as github publishes a tarball for each tag.
> >
> > One issue to resolve, build is now using svnkit which is binary dependency
> > committed into the source tree.
> >
> > Can you please make it optional as we have done with the checkstyle?
> >
> > If svn.version is defined skip the subversion task, this will enable use to
> > remove the ext directory and bypass the two using:
> >
> > $ ant -Dcheckstyle.enabled=false -Dsvn.version=0
>
> I just committed a change that will skip the use of svnkit if the
> svn.version property is set at build time.  You can also set svn.path if
> you want, but a default value of "{not-applicable}" will be used if that
> is not done.
>

Thanks!

>
>
> > Please note that git revisions are strings, you may consider to modify
> > Version::REVISION_NUMBER to string, so the following will be possible:
> >
> > $ ant -Dcheckstyle.enabled=false -Dsvn.version=$(git rev-parse --short HEAD)
> >
> > You may consider to modify svn.version to scm.version to make it generic
> > term.
>
> We will not change the data type for the REVISION_NUMBER value because
> that would break backward compatibility.  The authoritative repository
> for the LDAP SDK (the repository used to create the official builds that
> get published) is a Subversion repository and there aren't any plans to
> change that.
>

OK.

>
> >
> > I would have sent some patches, but I know you will reject them, please
> > consider the above these are minor changes that will help us publish this
> > package without modifications in fedora.
> >
> > Thanks,
> > Alon
> >
> >
> >
> > ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > ldap-sdk-discuss mailing list
> > lda...@li...
> > https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
> >
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>

Re: [ldap-sdk-discuss] [build] opt-out the svnkit usage

[Neil A. W. <nei...@un...>]

On 06/11/2015 12:02 AM, Alon Bar-Lev wrote:
> Hello Neil,
> 
> It is great you publish the code in github now, we finally have source
> tarball as github publishes a tarball for each tag.
> 
> One issue to resolve, build is now using svnkit which is binary dependency
> committed into the source tree.
> 
> Can you please make it optional as we have done with the checkstyle?
> 
> If svn.version is defined skip the subversion task, this will enable use to
> remove the ext directory and bypass the two using:
> 
> $ ant -Dcheckstyle.enabled=false -Dsvn.version=0

I just committed a change that will skip the use of svnkit if the
svn.version property is set at build time.  You can also set svn.path if
you want, but a default value of "{not-applicable}" will be used if that
is not done.



> Please note that git revisions are strings, you may consider to modify
> Version::REVISION_NUMBER to string, so the following will be possible:
> 
> $ ant -Dcheckstyle.enabled=false -Dsvn.version=$(git rev-parse --short HEAD)
> 
> You may consider to modify svn.version to scm.version to make it generic
> term.

We will not change the data type for the REVISION_NUMBER value because
that would break backward compatibility.  The authoritative repository
for the LDAP SDK (the repository used to create the official builds that
get published) is a Subversion repository and there aren't any plans to
change that.



> 
> I would have sent some patches, but I know you will reject them, please
> consider the above these are minor changes that will help us publish this
> package without modifications in fedora.
> 
> Thanks,
> Alon
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
> 

[ldap-sdk-discuss] [build] opt-out the svnkit usage

[Alon Bar-L. <alo...@gm...>]

Hello Neil,

It is great you publish the code in github now, we finally have source
tarball as github publishes a tarball for each tag.

One issue to resolve, build is now using svnkit which is binary dependency
committed into the source tree.

Can you please make it optional as we have done with the checkstyle?

If svn.version is defined skip the subversion task, this will enable use to
remove the ext directory and bypass the two using:

$ ant -Dcheckstyle.enabled=false -Dsvn.version=0

Please note that git revisions are strings, you may consider to modify
Version::REVISION_NUMBER to string, so the following will be possible:

$ ant -Dcheckstyle.enabled=false -Dsvn.version=$(git rev-parse --short HEAD)

You may consider to modify svn.version to scm.version to make it generic
term.

I would have sent some patches, but I know you will reject them, please
consider the above these are minor changes that will help us publish this
package without modifications in fedora.

Thanks,
Alon

Re: [ldap-sdk-discuss] LDAPSearchException(resultCode=82 (local error), numEntries=0, numReferences=0, errorMessage='Search processing was interrupted while waiting for a response from server 172.52.8.134:160.')

[Neil A. W. <nei...@un...>]

On 06/08/2015 10:57 AM, Harit Himanshu wrote:
> Hello there
> 
> I have recently used ldap-dk(unboundid) for my project and was very happy
> using it. However, ver recently I started observing issues in my logs as
> following. I tried looking up in Sourceforge forum but could not find
> anything. Also, I do not have permission to post there
> 
> Can some one please help me understand what's going on?
> 
> Thank you
> + Harit

From the stack trace below, it appears that something is calling
Thread.interrupt() on the thread that is being used to perform the
search.  Since the stack trace also suggests that the search is invoked
by a FutureTask, then my guess is that something is calling
FutureTask.cancel(true), which can call Thread.interrupt() behind the
scenes.



> 
> 02 Jun 2015 13:02:19,288 [ERROR] [LDAP Fetch Thread]
> LdapUnboundidUsersIterator|
> Exception while getting LDAP entries
> LDAPSearchException(resultCode=82 (local error), numEntries=0,
> numReferences=0, errorMessage='Search processing was interrupted while
> waiting for a response from server 172.52.8.134:160.')
> at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3404)
> at
> com.shn.ldap.LdapUnboundidUsersIterator$UserLoaderTask.call(LdapUnboundidUsersIterator.java:187)
> at
> com.shn.ldap.LdapUnboundidUsersIterator$UserLoaderTask.call(LdapUnboundidUsersIterator.java:169)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: LDAPException(resultCode=82 (local error), errorMessage='Search
> processing was interrupted while waiting for a response from server
> 172.52.8.134:160.')
> at com.unboundid.ldap.sdk.SearchRequest.process(SearchRequest.java:1173)
> at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3394)
> ... 6 more
> Caused by: java.lang.InterruptedException
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(Unknown
> Source)
> at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(Unknown
> Source)
> at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
> at com.unboundid.ldap.sdk.SearchRequest.process(SearchRequest.java:1162)

[ldap-sdk-discuss] LDAPSearchException(resultCode=82 (local error), numEntries=0, numReferences=0, errorMessage='Search processing was interrupted while waiting for a response from server 172.52.8.134:160.')

[Harit H. <har...@gm...>]

Hello there

I have recently used ldap-dk(unboundid) for my project and was very happy
using it. However, ver recently I started observing issues in my logs as
following. I tried looking up in Sourceforge forum but could not find
anything. Also, I do not have permission to post there

Can some one please help me understand what's going on?

Thank you
+ Harit

02 Jun 2015 13:02:19,288 [ERROR] [LDAP Fetch Thread]
LdapUnboundidUsersIterator|
Exception while getting LDAP entries
LDAPSearchException(resultCode=82 (local error), numEntries=0,
numReferences=0, errorMessage='Search processing was interrupted while
waiting for a response from server 172.52.8.134:160.')
at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3404)
at
com.shn.ldap.LdapUnboundidUsersIterator$UserLoaderTask.call(LdapUnboundidUsersIterator.java:187)
at
com.shn.ldap.LdapUnboundidUsersIterator$UserLoaderTask.call(LdapUnboundidUsersIterator.java:169)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: LDAPException(resultCode=82 (local error), errorMessage='Search
processing was interrupted while waiting for a response from server
172.52.8.134:160.')
at com.unboundid.ldap.sdk.SearchRequest.process(SearchRequest.java:1173)
at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3394)
... 6 more
Caused by: java.lang.InterruptedException
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(Unknown
Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at com.unboundid.ldap.sdk.SearchRequest.process(SearchRequest.java:1162)
... 7 more

Re: [ldap-sdk-discuss] Having issues saving a photo to thumbnailPhoto in AD

[Lucas R. <lu...@me...>]

Hi Neil,

Thank you very much for the detailed response and sample code! I will give this a try and see what happens. I have it feeling it might just be a simple JRuby to Java issue that I can fix with an explicit cast to a Java byte array.

-lucas

On May 22, 2015, at 1:46 PM, Neil A. Wilson <nei...@un...> wrote:

> On 05/22/2015 05:51 AM, Lucas Rockwell wrote:
>> Hello,
>> 
>> I am trying to save a photo to the thumbnailPhoto attribute in AD, and the bytes that make it to AD are not the valid image. I know that the bytes just before creating the com.unboundid.ldap.sdk.Attribute are indeed valid, because if I write them to a file, I can view the image.
>> 
>> I am using ImageVoodoo for JRuby, and this is the (slightly psudo) code:
>> 
>>    img = ImageVoodoo.with_bytes(Base64.decode64(incoming_image))
>>    attribute = Attribute.new('thumbnailPhoto', cropped.bytes('png'))
>>    entry.setAttribute(attribute)
>> 
>> When I save, and then view the image in AD, it is not a valid image. But if I write the image to a file like the following, it works:
>> 
>>    open('/tmp/img.png', 'w') do |f|
>>        f << cropped.bytes('png')
>>    end
>> 
>> When I view /tmp/img.png, it works fine. thumbnailPhoto is supposed to work with JPEG or PNG (I have tried JPEG, too, and that does not work, either), so I am wondering if there is something special I have to do to tell the SDK that I have binary data when I create or set an Attribute?
>> 
>> Many thanks.
>> 
>> -lucas
> 
> There shouldn't be anything that you need to do in order to make the
> LDAP SDK treat binary data properly.  LDAP (and therefore the LDAP SDK)
> actually transfers data in binary form behind the scenes.  If you
> provide a value as a byte array, then those are exactly the bytes that
> will be sent to the server.  If you provide a value as a string, then
> the LDAP SDK will send the UTF-8 representation of that string to the
> server.  For an image, you should obviously provide the value as a byte
> array.
> 
> I have access to an Active Directory instance that I can interact with
> over LDAP, but not to any kind of console that I could use to try to
> look at an image.  However, I wrote a simple test program (in Java
> rather than Ruby) to try to store a photo and then retrieve it again.  I
> verified that the entry I got back had exactly the same bytes for the
> thumbnailPhoto attribute that I sent to the server.  Assuming that the
> bytes I originally put in are for a valid image that AD can handle, then
> I expect that it should work.
> 
> The relevant code from that test program is as follows:
> 
> 
> final String thumbnailPath = "/tmp/thumbnail-photo.png";
> final FileInputStream inputStream = new FileInputStream(thumbnailPath);
> final ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
> 
> final byte[] buffer = new byte[100*1024];
> while (true)
> {
>  final int bytesRead = inputStream.read(buffer);
>  if (bytesRead < 0)
>  {
>    break;
>  }
>  outputStream.write(buffer, 0, bytesRead);
> }
> inputStream.close();
> outputStream.close();
> final byte[] imageBytes = outputStream.toByteArray();
> 
> final Entry entryToAdd = new Entry(
>     "cn=Test User," + baseDN,
>      new Attribute("objectClass", "top", "person",
>           "organizationalPerson", "inetOrgPerson",
>           "user"),
>      new Attribute("givenName", "Test"),
>      new Attribute("sn", "User"),
>      new Attribute("cn", "Test User"),
>      new Attribute("thumbnailPhoto", imageBytes));
> connection.add(entryToAdd);
> 
> final Entry retrievedEntry = connection.getEntry(
>     "cn=Test User," + baseDN, "thumbnailPhoto");
> 
> final byte[] retrievedImageBytes =
>     retrievedEntry.getAttribute("thumbnailPhoto").getValueByteArray();
> if (Arrays.equals(retrievedImageBytes, imageBytes))
> {
>  System.out.println("The image bytes read from the server " +
>       "exactly match was originally stored");
> }
> else
> {
>  System.out.println("The image bytes read from the server " +
>       "are different from was originally stored");
> }
> 
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss

Re: [ldap-sdk-discuss] Having issues saving a photo to thumbnailPhoto in AD

[Neil A. W. <nei...@un...>]

On 05/22/2015 05:51 AM, Lucas Rockwell wrote:
> Hello,
> 
> I am trying to save a photo to the thumbnailPhoto attribute in AD, and the bytes that make it to AD are not the valid image. I know that the bytes just before creating the com.unboundid.ldap.sdk.Attribute are indeed valid, because if I write them to a file, I can view the image.
> 
> I am using ImageVoodoo for JRuby, and this is the (slightly psudo) code:
> 
>     img = ImageVoodoo.with_bytes(Base64.decode64(incoming_image))
>     attribute = Attribute.new('thumbnailPhoto', cropped.bytes('png'))
>     entry.setAttribute(attribute)
> 
> When I save, and then view the image in AD, it is not a valid image. But if I write the image to a file like the following, it works:
> 
>     open('/tmp/img.png', 'w') do |f|
>         f << cropped.bytes('png')
>     end
> 
> When I view /tmp/img.png, it works fine. thumbnailPhoto is supposed to work with JPEG or PNG (I have tried JPEG, too, and that does not work, either), so I am wondering if there is something special I have to do to tell the SDK that I have binary data when I create or set an Attribute?
> 
> Many thanks.
> 
> -lucas

There shouldn't be anything that you need to do in order to make the
LDAP SDK treat binary data properly.  LDAP (and therefore the LDAP SDK)
actually transfers data in binary form behind the scenes.  If you
provide a value as a byte array, then those are exactly the bytes that
will be sent to the server.  If you provide a value as a string, then
the LDAP SDK will send the UTF-8 representation of that string to the
server.  For an image, you should obviously provide the value as a byte
array.

I have access to an Active Directory instance that I can interact with
over LDAP, but not to any kind of console that I could use to try to
look at an image.  However, I wrote a simple test program (in Java
rather than Ruby) to try to store a photo and then retrieve it again.  I
verified that the entry I got back had exactly the same bytes for the
thumbnailPhoto attribute that I sent to the server.  Assuming that the
bytes I originally put in are for a valid image that AD can handle, then
I expect that it should work.

The relevant code from that test program is as follows:


final String thumbnailPath = "/tmp/thumbnail-photo.png";
final FileInputStream inputStream = new FileInputStream(thumbnailPath);
final ByteArrayOutputStream outputStream = new ByteArrayOutputStream();

final byte[] buffer = new byte[100*1024];
while (true)
{
  final int bytesRead = inputStream.read(buffer);
  if (bytesRead < 0)
  {
    break;
  }
  outputStream.write(buffer, 0, bytesRead);
}
inputStream.close();
outputStream.close();
final byte[] imageBytes = outputStream.toByteArray();

final Entry entryToAdd = new Entry(
     "cn=Test User," + baseDN,
      new Attribute("objectClass", "top", "person",
           "organizationalPerson", "inetOrgPerson",
           "user"),
      new Attribute("givenName", "Test"),
      new Attribute("sn", "User"),
      new Attribute("cn", "Test User"),
      new Attribute("thumbnailPhoto", imageBytes));
connection.add(entryToAdd);

final Entry retrievedEntry = connection.getEntry(
     "cn=Test User," + baseDN, "thumbnailPhoto");

final byte[] retrievedImageBytes =
     retrievedEntry.getAttribute("thumbnailPhoto").getValueByteArray();
if (Arrays.equals(retrievedImageBytes, imageBytes))
{
  System.out.println("The image bytes read from the server " +
       "exactly match was originally stored");
}
else
{
  System.out.println("The image bytes read from the server " +
       "are different from was originally stored");
}

[ldap-sdk-discuss] Having issues saving a photo to thumbnailPhoto in AD

[Lucas R. <lu...@me...>]

Hello,

I am trying to save a photo to the thumbnailPhoto attribute in AD, and the bytes that make it to AD are not the valid image. I know that the bytes just before creating the com.unboundid.ldap.sdk.Attribute are indeed valid, because if I write them to a file, I can view the image.

I am using ImageVoodoo for JRuby, and this is the (slightly psudo) code:

    img = ImageVoodoo.with_bytes(Base64.decode64(incoming_image))
    attribute = Attribute.new('thumbnailPhoto', cropped.bytes('png'))
    entry.setAttribute(attribute)

When I save, and then view the image in AD, it is not a valid image. But if I write the image to a file like the following, it works:

    open('/tmp/img.png', 'w') do |f|
        f << cropped.bytes('png')
    end

When I view /tmp/img.png, it works fine. thumbnailPhoto is supposed to work with JPEG or PNG (I have tried JPEG, too, and that does not work, either), so I am wondering if there is something special I have to do to tell the SDK that I have binary data when I create or set an Attribute?

Many thanks.

-lucas

[ldap-sdk-discuss] Restricting the returned naming contexts

[Sathish A. <SAn...@sk...>]

We currently use Ubound LDAP SDK to authenticate and manage users programmatically from our applications. Recently, we upgraded our development environment from OpenLDAP 2.3 to OpenLDAP 2.4 to take advantage of high availability features.

After the upgrade, our applications are encountering "LDAPSearchException(resultCode=32 (no such object) exception" while invoking any LDAP operations. Upon further troubleshooting, we found that our application uses the value returned from  connection.getRootDSE().getNamingContextDNs() method as the DN to search for a given user. This method is currently returning two naming context - first cn=accesslog and second the context housing our application users, while in the earlier version it returned the context housing our application users only. Our application used the first naming context returned from this call to locate the user. Since the upgraded version returns cn=accesslog as the first context, the application tries to locate the user within this context causing it to throw the above exception.

We have a common jar file that contains all the code to access OpenLDAP using the Ubound SDK. I see that one solution is to modify the code to filter the new context or hardcode the search dn. However, this jar file is being referenced in multiple applications, and a change in this jar file would require a huge regression test cycle. Hence, I am looking to find out if there are any alternate solutions or configuration in LDAP that would filter cn=accesslog entry from the getNamingContextDNs() call to avoid code changes in the jar.

Your help is greatly appreciated!

Thanks.

Re: [ldap-sdk-discuss] Restricting the returned naming contexts

[Neil A. W. <nei...@un...>]

On 05/14/2015 03:50 PM, Sathish Anickode wrote:
> We currently use Ubound LDAP SDK to authenticate and manage users programmatically from our applications. Recently, we upgraded our development environment from OpenLDAP 2.3 to OpenLDAP 2.4 to take advantage of high availability features.
> 
> After the upgrade, our applications are encountering "LDAPSearchException(resultCode=32 (no such object) exception" while invoking any LDAP operations. Upon further troubleshooting, we found that our application uses the value returned from  connection.getRootDSE().getNamingContextDNs() method as the DN to search for a given user. This method is currently returning two naming context - first cn=accesslog and second the context housing our application users, while in the earlier version it returned the context housing our application users only. Our application used the first naming context returned from this call to locate the user. Since the upgraded version returns cn=accesslog as the first context, the application tries to locate the user within this context causing it to throw the above exception.
> 
> We have a common jar file that contains all the code to access OpenLDAP using the Ubound SDK. I see that one solution is to modify the code to filter the new context or hardcode the search dn. However, this jar file is being referenced in multiple applications, and a change in this jar file would require a huge regression test cycle. Hence, I am looking to find out if there are any alternate solutions or configuration in LDAP that would filter cn=accesslog entry from the getNamingContextDNs() call to avoid code changes in the jar.
> 
> Your help is greatly appreciated!
> 
> Thanks.

It sounds like you're asking about a way to call
LDAPConnection.getRootDSE but have something filter out the entry before
it is returned to the caller.  The LDAP SDK doesn't currently offer any
good way to accomplish that.

I could look into some kind of interface that would automatically get
invoked to transform search result entries as soon as they're read from
the server and before they're returned to whatever method is expecting
them, but there isn't an option to do that at present.


Neil

Re: [ldap-sdk-discuss] Access base64Values of an attribute

[Lucas R. <lu...@me...>]

On Apr 20, 2015, at 1:37 PM, Neil A. Wilson <nei...@un...> wrote:

> On 04/20/2015 12:25 PM, Lucas Rockwell wrote:
>> Hello,
>> 
>> I need to access the base64Values of an Attribute as returned by the SDK. For instance:
>> 
>>    Attribute(name=thumbnailPhoto, base64Values={'...'})
>> 
>> Is there any way to access this value without the SDK decoding it? Or do I need to pull back the bytes and do some "magic" with them?
>> 
>> Thanks.
>> 
>> -lucas
> 
> In general, values don't get stored in base64.  That's just a format
> that's used in the LDIF representation for values that might not be safe
> to treat as regular strings (e.g., values that start or end with spaces,
> values that have line breaks, values that start with or contain certain
> special characters, etc.).  And as you've discovered, the
> Attribute.toString method will base64-encode values for the same reason.
> But they're actually transferred to the client as the raw bytes that
> comprise the value.

Ah, thanks for the explanation!

> If you want the base64-encoded representation of the value, you can use
> the com.unboundid.util.Base64 class to encode the raw value.

That will work for me. Thanks!

-lucas

Re: [ldap-sdk-discuss] Access base64Values of an attribute

[Neil A. W. <nei...@un...>]

On 04/20/2015 12:25 PM, Lucas Rockwell wrote:
> Hello,
> 
> I need to access the base64Values of an Attribute as returned by the SDK. For instance:
> 
>     Attribute(name=thumbnailPhoto, base64Values={'...'})
> 
> Is there any way to access this value without the SDK decoding it? Or do I need to pull back the bytes and do some "magic" with them?
> 
> Thanks.
> 
> -lucas

In general, values don't get stored in base64.  That's just a format
that's used in the LDIF representation for values that might not be safe
to treat as regular strings (e.g., values that start or end with spaces,
values that have line breaks, values that start with or contain certain
special characters, etc.).  And as you've discovered, the
Attribute.toString method will base64-encode values for the same reason.
 But they're actually transferred to the client as the raw bytes that
comprise the value.

If you want the base64-encoded representation of the value, you can use
the com.unboundid.util.Base64 class to encode the raw value.


Neil

[ldap-sdk-discuss] Access base64Values of an attribute

[Lucas R. <lu...@me...>]

Hello,

I need to access the base64Values of an Attribute as returned by the SDK. For instance:

    Attribute(name=thumbnailPhoto, base64Values={'...'})

Is there any way to access this value without the SDK decoding it? Or do I need to pull back the bytes and do some "magic" with them?

Thanks.

-lucas

Re: [ldap-sdk-discuss] 2.3.8 tag

[Alon Bar-L. <alo...@gm...>]

On 13 April 2015 at 19:34, Neil A. Wilson <nei...@un...> wrote:
>
> On 04/13/2015 08:33 AM, Alon Bar-Lev wrote:
> > Hi,
> >
> > I see that 2.3.8 was released[1], but no tag[2], it will be great if you
> > tag it.
> >
> > It would also be great if you can release a source tarball[3], the released
> > files are binary and not source, it can be simple svn export with or
> > preferably without the ext directory.
> >
> > Thanks,
> > Alon
> >
> > [1] https://docs.ldap.com/ldap-sdk/docs/release-notes.html
> > [2] http://sourceforge.net/p/ldap-sdk/code/HEAD/tree/tags/
> > [3] http://sourceforge.net/projects/ldap-sdk/files/
>
> I actually did tag the release when I created it, but inadvertently gave
> it the wrong version number.  That problem has been fixed.

Thanks!

>
> As for the source, there is a src.zip file included in the LDAP SDK
> download that contains a snapshot of the source code for that release.
> In addition, the Maven Central Repository includes a sources.jar file
> for the release.  I don't see any reason to provide additional version
> on top of that when the repository itself is available.

As far as I can see the build system is missing, so source tree cannot
be used to build the package.

Source tarball of release is source only distribution media that
contains only sources and everything required to build the binaries.

Regards,
Alon

Re: [ldap-sdk-discuss] 2.3.8 tag

[Neil A. W. <nei...@un...>]

On 04/13/2015 08:33 AM, Alon Bar-Lev wrote:
> Hi,
> 
> I see that 2.3.8 was released[1], but no tag[2], it will be great if you
> tag it.
> 
> It would also be great if you can release a source tarball[3], the released
> files are binary and not source, it can be simple svn export with or
> preferably without the ext directory.
> 
> Thanks,
> Alon
> 
> [1] https://docs.ldap.com/ldap-sdk/docs/release-notes.html
> [2] http://sourceforge.net/p/ldap-sdk/code/HEAD/tree/tags/
> [3] http://sourceforge.net/projects/ldap-sdk/files/

I actually did tag the release when I created it, but inadvertently gave
it the wrong version number.  That problem has been fixed.

As for the source, there is a src.zip file included in the LDAP SDK
download that contains a snapshot of the source code for that release.
In addition, the Maven Central Repository includes a sources.jar file
for the release.  I don't see any reason to provide additional version
on top of that when the repository itself is available.


Neil

[ldap-sdk-discuss] 2.3.8 tag

[Alon Bar-L. <alo...@gm...>]

Hi,

I see that 2.3.8 was released[1], but no tag[2], it will be great if you
tag it.

It would also be great if you can release a source tarball[3], the released
files are binary and not source, it can be simple svn export with or
preferably without the ext directory.

Thanks,
Alon

[1] https://docs.ldap.com/ldap-sdk/docs/release-notes.html
[2] http://sourceforge.net/p/ldap-sdk/code/HEAD/tree/tags/
[3] http://sourceforge.net/projects/ldap-sdk/files/

Re: [ldap-sdk-discuss] Finding NULL Characters

[Neil A. W. <nei...@un...>]

On 03/23/2015 09:57 AM, Jim Willeke wrote:
> Well, our scenario is in a large LDAP instance (>25M), where they (against
> my advice) allow the user to make up the RDN.
> 
> When the user returns to the site and provides "valuewithnulls" as the
> userid (We assume they did not mean to enter the nulls) a LDAP search is
> done for the user, (uid=valuewithnulls), which fails.
> 
> Our objective is to identify these "value\00with\00nulls" and rename them
> to "valuewithnulls".
> 
> -jim

OK.  So the issue is trying to use a value with nulls in a search filter
rather than in a DN or RDN.  In that case, the LDAP SDK makes it easy to
construct the filter.  If you have "value\u0000with\u0000nulls" as a
string or as a byte array, then the best way to construct a filter in
which the string representation has the appropriate spacing is to use:

     Filter searchFilter = Filter.createEqualityFilter("uid",
          "value\u0000with\u0000nulls");

If you call the toString() method on this filter, then you will get the
properly-escaped filter (uid=value\00with\00nulls).  However, it is
important to note that LDAP filters aren't transferred between the
client and the server as strings but rather as binary values and in that
case no escaping is required.

At any rate, the best way to create any kind of filter in an
LDAP-enabled application is to use the Filter.create* methods instead of
trying to construct a filter yourself using the string representation.
This is true for two reasons:

- The LDAP SDK will always perform the appropriate escaping for any
special characters contained in the assertion value.  This can help
thwart attacks from clients trying to use the LDAP equivalent of an SQL
injection (e.g., by trying to trick the application into performing a
substring or presence search when the intent was to perform an equality
search).

- It is faster.  The LDAP SDK doesn't have to parse the string
representation in order to get the components to use in the binary encoding.



> 
> 
> ᐧ
> 
> --
> -jim
> Jim Willeke
> 
> On Thu, Mar 19, 2015 at 4:17 PM, Neil A. Wilson <nei...@un...>
> wrote:
> 
>> On 03/19/2015 01:39 PM, Jim Willeke wrote:
>>> Trying to find a method to obtain RDN value which contain null values.
>>>
>>> If I use,
>>>
>>> byte[] uidBytes = entry.getAttributeValueBytes("uid");
>>>
>>> It appears the nulls appears as "." (periods)
>>>
>>> What am I missing?
>>>
>>> --
>>> -jim
>>> Jim Willeke
>>> ᐧ
>>
>> From the context of your question, it sounds like you're talking about
>> values that contain the null character (whose UTF-8 representation is a
>> single byte with all bits set to zero, and is represented with the
>> Unicode escape sequence \u0000), rather than attributes that don't have
>> values at all or attributes with zero-length values.  For example, the
>> Java string "value\u0000with\u0000nulls".
>>
>> If you use this in a DN, then the correct encoding is to escape the
>> hexadecimal representation of each byte in the UTF-8 representation.  So
>> if you have an RDN with an attribute type of uid and a value that is
>> "value\u0000with\u0000nulls", then the correct string representation of
>> that would be "uid=value\00with\00nulls".  If you create a DN like:
>>
>>      ByteStringBuffer valueBuffer = new ByteStringBuffer();
>>      valueBuffer.append("value");
>>      valueBuffer.append((byte) 0x00);
>>      valueBuffer.append("with");
>>      valueBuffer.append((byte) 0x00);
>>      valueBuffer.append("nulls");
>>
>>      DN dn = new DN(
>>           new RDN("uid", valueBuffer.toByteArray()),
>>           new RDN("ou", "People"),
>>           new RDN("dc", "example"),
>>           new RDN("dc", "com"));
>>
>> then calling dn.toString() will result in:
>>
>>      uid=value\00with\00nulls,ou=People,dc=example,dc=com
>>
>>
>> But if you're talking about the attribute as it appears in the entry,
>> then no special encoding is required for LDAP communication (the LDIF
>> representation would require the value to be base64-encoded).  For
>> example, if you create an entry like:
>>
>>      Entry e = new Entry(dn,
>>           new Attribute("objectClass", "top", "person",
>>                "organizationalPerson", "inetOrgPerson"),
>>           new Attribute("uid", valueBuffer.toByteArray()),
>>           new Attribute("givenName", "Test"),
>>           new Attribute("sn", "User"),
>>           new Attribute("cn", "Test User"));
>>
>> then calling e.getAttributeValueByte("uid") will return a byte array
>> with the following contents:
>>
>>      76 61 6c 75 65 00 77 69 74 68 00 6e 75 6c 6c 73
>>
>> In this case, the nulls are properly represented as bytes of 0x00.
>>
>> This is also the case for an entry retrieved from a directory server
>> over LDAP rather than one that is constructed in Java code.
>>
>> Could you provide an example of the behavior that you're seeing?
>>
>>
>>
>> Neil
>>
>>
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> 
> 
> 
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
> 

Re: [ldap-sdk-discuss] Finding NULL Characters

[Jim W. <ji...@wi...>]

Well, our scenario is in a large LDAP instance (>25M), where they (against
my advice) allow the user to make up the RDN.

When the user returns to the site and provides "valuewithnulls" as the
userid (We assume they did not mean to enter the nulls) a LDAP search is
done for the user, (uid=valuewithnulls), which fails.

Our objective is to identify these "value\00with\00nulls" and rename them
to "valuewithnulls".

-jim


ᐧ

--
-jim
Jim Willeke

On Thu, Mar 19, 2015 at 4:17 PM, Neil A. Wilson <nei...@un...>
wrote:

> On 03/19/2015 01:39 PM, Jim Willeke wrote:
> > Trying to find a method to obtain RDN value which contain null values.
> >
> > If I use,
> >
> > byte[] uidBytes = entry.getAttributeValueBytes("uid");
> >
> > It appears the nulls appears as "." (periods)
> >
> > What am I missing?
> >
> > --
> > -jim
> > Jim Willeke
> > ᐧ
>
> From the context of your question, it sounds like you're talking about
> values that contain the null character (whose UTF-8 representation is a
> single byte with all bits set to zero, and is represented with the
> Unicode escape sequence \u0000), rather than attributes that don't have
> values at all or attributes with zero-length values.  For example, the
> Java string "value\u0000with\u0000nulls".
>
> If you use this in a DN, then the correct encoding is to escape the
> hexadecimal representation of each byte in the UTF-8 representation.  So
> if you have an RDN with an attribute type of uid and a value that is
> "value\u0000with\u0000nulls", then the correct string representation of
> that would be "uid=value\00with\00nulls".  If you create a DN like:
>
>      ByteStringBuffer valueBuffer = new ByteStringBuffer();
>      valueBuffer.append("value");
>      valueBuffer.append((byte) 0x00);
>      valueBuffer.append("with");
>      valueBuffer.append((byte) 0x00);
>      valueBuffer.append("nulls");
>
>      DN dn = new DN(
>           new RDN("uid", valueBuffer.toByteArray()),
>           new RDN("ou", "People"),
>           new RDN("dc", "example"),
>           new RDN("dc", "com"));
>
> then calling dn.toString() will result in:
>
>      uid=value\00with\00nulls,ou=People,dc=example,dc=com
>
>
> But if you're talking about the attribute as it appears in the entry,
> then no special encoding is required for LDAP communication (the LDIF
> representation would require the value to be base64-encoded).  For
> example, if you create an entry like:
>
>      Entry e = new Entry(dn,
>           new Attribute("objectClass", "top", "person",
>                "organizationalPerson", "inetOrgPerson"),
>           new Attribute("uid", valueBuffer.toByteArray()),
>           new Attribute("givenName", "Test"),
>           new Attribute("sn", "User"),
>           new Attribute("cn", "Test User"));
>
> then calling e.getAttributeValueByte("uid") will return a byte array
> with the following contents:
>
>      76 61 6c 75 65 00 77 69 74 68 00 6e 75 6c 6c 73
>
> In this case, the nulls are properly represented as bytes of 0x00.
>
> This is also the case for an entry retrieved from a directory server
> over LDAP rather than one that is constructed in Java code.
>
> Could you provide an example of the behavior that you're seeing?
>
>
>
> Neil
>
>
>

Re: [ldap-sdk-discuss] Finding NULL Characters

[Neil A. W. <nei...@un...>]

On 03/19/2015 01:39 PM, Jim Willeke wrote:
> Trying to find a method to obtain RDN value which contain null values.
> 
> If I use,
> 
> byte[] uidBytes = entry.getAttributeValueBytes("uid");
> 
> It appears the nulls appears as "." (periods)
> 
> What am I missing?
> 
> --
> -jim
> Jim Willeke
> ᐧ

From the context of your question, it sounds like you're talking about
values that contain the null character (whose UTF-8 representation is a
single byte with all bits set to zero, and is represented with the
Unicode escape sequence \u0000), rather than attributes that don't have
values at all or attributes with zero-length values.  For example, the
Java string "value\u0000with\u0000nulls".

If you use this in a DN, then the correct encoding is to escape the
hexadecimal representation of each byte in the UTF-8 representation.  So
if you have an RDN with an attribute type of uid and a value that is
"value\u0000with\u0000nulls", then the correct string representation of
that would be "uid=value\00with\00nulls".  If you create a DN like:

     ByteStringBuffer valueBuffer = new ByteStringBuffer();
     valueBuffer.append("value");
     valueBuffer.append((byte) 0x00);
     valueBuffer.append("with");
     valueBuffer.append((byte) 0x00);
     valueBuffer.append("nulls");

     DN dn = new DN(
          new RDN("uid", valueBuffer.toByteArray()),
          new RDN("ou", "People"),
          new RDN("dc", "example"),
          new RDN("dc", "com"));

then calling dn.toString() will result in:

     uid=value\00with\00nulls,ou=People,dc=example,dc=com


But if you're talking about the attribute as it appears in the entry,
then no special encoding is required for LDAP communication (the LDIF
representation would require the value to be base64-encoded).  For
example, if you create an entry like:

     Entry e = new Entry(dn,
          new Attribute("objectClass", "top", "person",
               "organizationalPerson", "inetOrgPerson"),
          new Attribute("uid", valueBuffer.toByteArray()),
          new Attribute("givenName", "Test"),
          new Attribute("sn", "User"),
          new Attribute("cn", "Test User"));

then calling e.getAttributeValueByte("uid") will return a byte array
with the following contents:

     76 61 6c 75 65 00 77 69 74 68 00 6e 75 6c 6c 73

In this case, the nulls are properly represented as bytes of 0x00.

This is also the case for an entry retrieved from a directory server
over LDAP rather than one that is constructed in Java code.

Could you provide an example of the behavior that you're seeing?



Neil

[ldap-sdk-discuss] Finding NULL Characters

[Jim W. <ji...@wi...>]

Trying to find a method to obtain RDN value which contain null values.

If I use,

byte[] uidBytes = entry.getAttributeValueBytes("uid");

It appears the nulls appears as "." (periods)

What am I missing?

--
-jim
Jim Willeke
ᐧ