Получите объект его objectGUID, использующим ldapsearch
Ya, если у Вас есть гарантия, теперь является временем для призыва ее :-)
Оставьте компьютер некоторое время для проверки не нагреваются и видят, есть ли у Вас та же проблема. Если это - более старый компьютер, можно, вероятно, купить новый, который быстрее для более дешевого, чем сменные детали. Так в основном это не может стоить времени, Вы могли получить другой и пожертвовать этого.
Этот сценарий работал на меня; я отправляю его здесь в случае, если это могло бы помочь кому-то еще
#!/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}
Основная проблема состоит в том, что objectGUID является двоичным полем, и определенные сборки ldapsearch не имеют способности непосредственно запросить такое поле. Как вывод поиска objectGUID шоу, это предполагает, что данные являются base64, и это - то, что Вы видите при поиске objectGUID. Фактические данные по одному объекту в моем дереве 32 байта длиной, но Linux ldapsearch дал мне 22-байтовое возвращаемое значение.
Похоже, что сборка Sun ldapsearch имеет способность обработать двоичные данные, но версия Linux не делает.
# 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]}"
Я использовал приведенный ответ и при тестировании столкнулся с парой тонких ошибок.
1) BASE64_DECODED настроен на бинарные данные, которые могут содержать любое возможное значение байта. эхом, что без кавычек приводит к интерпретации оболочкой некоторых значений байтов. tabs и newline (может быть больше) будут преобразованы в пробелы, что искажает выходные данные.
2) hexdump по умолчанию будет подавлять дублирующиеся символы и заменять их звездочкой и новой строкой. Так что если ваш 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]}"
Если вы используете ldapsearch с параметром -x (чтобы записать все непечатаемые символов в файл), поэтому у вас не может быть строки, декодированной в формате base64, вы можете использовать эту версию:
G=`hexdump -e '1/1 "%02X "' /tmp/ldapsearch-objectGUID-oHJ3rK`
read g0 g1 g2 g3 g4 g5 g6 g7 g8 g9 g10 g11 g12 g13 g14 g15 <<<"$G"
OBJECTGUID="${g3}${g2}${g1}${g0}-${g5}${g4}-${g7}${g6}-${g8}${g9}-${g10}${g11}${g12}${g13}${g14}${g15}"
Если вам нужно заменить имя файла на правильное имя файла, отображаемое в выводе ldapsearch, то есть:
objectGUID:< file:///tmp/ldapsearch-objectGUID-oHJ3rK