Obtém um objeto pelo seu objectGUID usando ldapsearch

1

Se eu tiver o atributo objectGUID como retornado pelo comando ldapsearch , como posso pesquisar em todo o diretório por um objeto com esse objectGUID?

Por exemplo, se eu pesquisar um usuário recebendo seu objectGUID, obtenho o seguinte:

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==

A partir do valor b+bSezFkKkWDmbIZiyE5rg== , como posso criar uma string de consulta para obter esse objeto?

    
por Paolo Tedesco 11.05.2010 / 17:02

4 respostas

3

Esse script funcionou para mim; Estou postando aqui caso possa ajudar alguém

#!/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}
    
por 11.05.2010 / 18:13
2
# 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]}"

Eu usei a resposta acima e encontrei alguns erros sutis durante o teste.

1) BASE64_DECODED é definido como dados binários que podem conter qualquer valor de byte possível. ecoar isso sem aspas faz com que alguns valores de byte sejam interpretados pelo shell. guias e novas linhas (talvez mais) serão convertidas em espaços, o que corrompe seus dados de saída.

2) hexdump por padrão irá suprimir caracteres duplicados e substituí-los por um asterisco e nova linha. Portanto, se o seu GUID tiver dois bytes consecutivos, você obterá uma saída de aparência estranha:

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

Aqui está o código corrigido que corrige esses problemas:

# 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]}"
    
por 05.10.2014 / 06:59
1

O principal problema é que objectGUID é um campo binário e certas compilações ldapsearch não têm a capacidade de consultar diretamente esse tipo de campo. Como mostra a saída da pesquisa por objectGUID, presume-se que os dados sejam base64 e é isso que você está vendo ao procurar por objectGUID. Os dados reais em um objeto na minha árvore têm 32 bytes, mas o linux ldapsearch me deu um valor de retorno de 22 bytes.

Parece que a versão Sun do ldapsearch tem a capacidade de manipular dados binários, mas a versão do Linux não.

    
por 11.05.2010 / 18:03
0

Caso você esteja usando ldapsearch com a opção -x (para gravar todos os caracteres não imprimíveis no arquivo), para que você não possa ter a string decodificada base64, você pode usar esta versão:

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

Onde você precisa substituir o nome do arquivo pelo nome correto exibido na saída do ldapsearch, ou seja:

objectGUID:< file:///tmp/ldapsearch-objectGUID-oHJ3rK
    
por 01.11.2018 / 13:57

Tags