通过使用ldapsearch的objectGUID获取对象

这个脚本为我工作; 我把它张贴在这里，以防它可能帮助别人

 #!/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 xycom -b "${SEARCH_BASE}" "${QUERY}" ${ATTRIBUTES} 

 # 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]}" 

我使用了上面的答案，并在testing过程中遇到了一些微妙的错误。

1）BASE64_DECODED设置为二进制数据，可以包含任何可能的字节值。 作为回应，没有引号会导致一些字节值被shell解释。 标签和换行符（也许更多）将被转换为空格，这会破坏您的输出数据。

2）默认情况下，hexdump将抑制重复的字符，并用星号和换行符replace它们。 所以，如果你的GUID有两个连续的字节，你会得到一些奇怪的输出：

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

以下是修复这些问题的更正的代码：

 # 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]}" 

主要的问题是objectGUID是一个二进制字段，某些ldapsearch构build不具备直接查询这种字段的能力。 当searchobjectGUID的输出显示时，它假定数据是base64，这就是你在searchobjectGUID时所看到的。 我的树中一个对象上的实际数据长度是32字节，但是linux ldapsearch给了我一个22字节的返回值。

看起来，ldapsearch的Sun构build能够处理二进制数据，但是Linux版本没有。