Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

If I have the objectGUID attribute as returned by the ldapsearch command, how can I search the whole directory for an object with that objectGUID?

For example, if I search a user getting its objectGUID, I get the following:

ldapsearch -x -D $MyDn -W -h $Host -b "dc=x,dc=y" "(mail=something)" objectGUID

# 7f435ae312a0d8197605, p, Externals, x.y
dn: CN=7f435ae312a0d8197605,OU=p,DC=x,DC=y
objectGUID:: b+bSezFkKkWDmbIZiyE5rg==

Starting from the value b+bSezFkKkWDmbIZiyE5rg==, how can I create a query string to get that object?

share|improve this question

3 Answers 3

up vote 2 down vote accepted

This script worked for me; I'm posting it here in case it might help someone else

#!/bin/bash

# specify as first parameter the object ID as received by an LDAP query; it's base-64 encoded.
OBJECT_ID="${1}"

# we decode it, we hex-dump it and store it in an array to
# re-order it in the format expected by LDAP
BASE64_DECODED=$(echo $OBJECT_ID | base64 -d -i)
G=($(echo ${BASE64_DECODED} | hexdump -e '1/1 " %02X"'))
    OBJECTGUID="${G[3]}${G[2]}${G[1]}${G[0]}-${G[5]}${G[4]}-${G[7]}${G[6]}-${G[8]}${G[9]}-${G[10]}${G[11]}${G[12]}${G[13]}${G[14]}${G[15]}"

BIND_DN="CN=..."

# Note that we use the GUID as the search base
SEARCH_BASE="<GUID=${OBJECTGUID}>"

# we query for any object (the important point here is the search base)
QUERY="(cn=*)"

ATTRIBUTES="objectGUID userPrincipalName sAMAccountName"

ldapsearch -x -D "${BIND_DN}" -W -h x.y.com -b "${SEARCH_BASE}" "${QUERY}" ${ATTRIBUTES}
share|improve this answer

The main problem is that objectGUID is a binary field, and certain ldapsearch builds don't have an ability to directly query that kind of field. As the output of searching for objectGUID shows, it's presuming the data is base64 and that's what you're seeing when searching for objectGUID. The actual data on one object in my tree is 32 bytes long, but linux ldapsearch gave me a 22 byte return value.

It looks like the Sun build of ldapsearch has the ability to handle binary data, but the Linux version does not.

share|improve this answer
# we decode it, we hex-dump it and store it in an array to
# re-order it in the format expected by LDAP
BASE64_DECODED=$(echo $OBJECT_ID | base64 -d -i)
G=($(echo ${BASE64_DECODED} | hexdump -e '1/1 " %02X"'))
OBJECTGUID="${G[3]}${G[2]}${G[1]}${G[0]}-${G[5]}${G[4]}-${G[7]}${G[6]}-${G[8]}${G[9]}-${G[10]}${G[11]}${G[12]}${G[13]}${G[14]}${G[15]}"

I used the above answer and ran into a couple of subtle errors during testing.

1) BASE64_DECODED is set to binary data which can contain any possible byte value. echoing that without quotes causes some byte values to be interpreted by the shell. tabs and newlines (maybe more) will be converted to spaces, which corrupts your output data.

2) hexdump by default will suppress duplicate characters and replace them with an asterisk and newline. So if your GUID ever has two consecutive bytes the same you will get some strange looking output:

OBJECT_ID = Qdicy5qc3kOqtrZ3dYswgw==
OBJECTGUID = CB9CD841-9C9A-43DE-AAB6*-77758B30830A

Here is the corrected code that fixes these problems:

# we decode it, hex-dump it and store it in an array
G=($(echo -n $object_id | base64 -d -i | hexdump -v -e '1/1 " %02X"'))
OBJECTGUID="${G[3]}${G[2]}${G[1]}${G[0]}-${G[5]}${G[4]}-${G[7]}${G[6]}-${G[8]}${G[9]}-${G[10]}${G[11]}${G[12]}${G[13]}${G[14]}${G[15]}"
share|improve this answer
    
Just for the sake of pointing it out, on this site, the order of answers is not preserved - they are ordered by net votes. –  Falcon Momot Oct 5 '14 at 6:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.