LDIFDE Format

Hi,
I am writing a program that exports data from Active Directory that will save the data in LDIFDE format. The problem I an having is some times using LDIFDE it knows to encode the field in Base64 eg info:: . However it only seems to do it under certain circumstances. So what are the conditions (rules) which goven when this will and won't happed so I don't create invalid data when I export. (So at the moment sometimes I put invalid characters in there and don't know I should of encoded the field).

Hope this makes sense hard to explain :)

Thanks,

Ward
LVL 1
whorsfallAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

PFoeckelerCommented:
Hi Ward,

LDIFDE always uses the base64 encoding when

- there are binary data to be exported, for example in the attribute "objectGUID" or "objectSID"
- a string attribute has to be exported which contains a non-7-bit-ASCII character.

So if you have "info", "displayname" or even "DN" with "ä", "ö", "ü" and so on, LDIFDE will encode these data to base64, the line is always marked with a double "::"

So to be exact, you should always encode to base64 if you have some kind of special characters (ASCII code <32 or >127) in a string. This is done by converting first the string to UTF-8, then encode it to base64. In .NET Visual BAsic you would to this:

    Public Function string_to_base64(ByVal s As String) As String
        Dim bytes As Byte() = Encoding.UTF8.GetBytes(s)
        string_to_base64 = Convert.ToBase64String(bytes)
    End Function

By the way: This is what LDIFDE does, and what te LDIF specification in http://tools.ietf.org/html/rfc2849 demands. But an Active Directory domain controller under 2003 and newer also can handle LDIF files for directory imports where special characters are NOT encoded into base64 - the  LDIF file just have to be saved as UTF-8 text!!  :)

Philipp
0
whorsfallAuthor Commented:
Hi,

Thanks for your response. However based on what you have
said I have found the following

See the comments next to the hash sign I have written.
A ":" will Base64 encode (ASCII 58) does encode but
"a:b" does not. The colon characte falls within the
normal ASCII range..

# PC4 - Users and Computers - Description: : (A single colon)

dn: CN=PC4,OU=TestOU,DC=acme,DC=net
changetype: add
description:: Og==
name: PC4
sAMAccountName: PC4$

# PC3 - Users and Computers - Description a:b
# So why does PC4 encode to Base64 and this field does not
# as it contains a colon?

dn: CN=PC3,OU=TestOU,DC=acme,DC=net
changetype: add
description: a:b
name: PC3
sAMAccountName: PC3$

Thanks,

Ward.

0
PFoeckelerCommented:
Hey,

you discovered a very special case ;)

I egree that a colon is truly not a special character, but: If an attribute consists ONLY of a single colon, without the base64 encoding, you would have this output in you LDIF file:

description: :

An LDIF import mechanism cuts out the blanks between the first colon and the attribute value (in this case ":"), so we get

description::

And this have  special meaning: It says: The value in this line is a base64 encoded value (which is not true in our case.....) So this is a kind of deadlock which forces the LDIF output generating process to encode a single colon in base64 although it is a 7bit ASCII !

Thanks a lot to draw my attention into this, because i'm a developper of a commercial LDAP client (http://www.ldapexplorer.com) which does LDIF exports and i haven't  consider this case yet!!! :)

Philipp
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
whorsfallAuthor Commented:
Hi,

Thanks for your response no problems.

I actually found this article which I believe will give me some more clues:

http://www.ietf.org/rfc/rfc2849.txt

Thanks,
Ward
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.