Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

An application stores the objectGUID of a user's MSAD entry internally as:

msad://OBJECTGUID=\5c\78\33\6d\77\d8\df\44\80\07\d2\77\da\d5\c5\69?USER 

Below are the Uids I see when I pull the user's details using ldapsearch command:

...
objectGUID:: XHgzbXfY30SAB9J32tXFaQ==
ibm-entryUuid: {base64binary}XHgzbXfY30SAB9J32tXFaQ==
objectSid:: AQUAAAAAAAUVAAAAJnYeL8CFOF0H5TsrNU0lAA==
employeeNumber: 502075089
...

Does anyone have an idea how the application is encoding the MSAD's objectGUID into msad://OBJECTGUID=\5c\78\33\6d\77\d8\df\44\80\07\d2\77\da\d5\c5\69?USER?

I basically have to decode the applications encoding of objectGUID.. to identify the corresponding MSAD entries.

share|improve this question

1 Answer 1

up vote 2 down vote accepted

It is exactly the same data displayed in hexadecimal instead of Base64.


In the LDIF format, which ldapsearch outputs, two colons means the following value is base64-encoded (usually because it has binary data). For example, these are equivalent:

greeting: Hello

greeting:: SGVsbG8=

So if you run XHgzbXfY30SAB9J32tXFaQ== (the value of objectGUID) through a base64 decoder, you will get:

$ echo XHgzbXfY30SAB9J32tXFaQ== | base64 -d | xxd
0000000: 5c78 336d 77d8 df44 8007 d277 dad5 c569  \x3mw..D...w...i

In your msad:// URI, the same GUID is stored in hexadecimal, each byte prefixed with a \.

share|improve this answer
    
Awesome ! Thanks grawity –  Kent Pawar Jul 24 '13 at 17:58

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.