Convert VCF to LDIF: Export vCard Contacts for LDAP Directories

Introduction

LDIF (LDAP Data Interchange Format) is the standard text format for exchanging data with LDAP directory servers. If you have contacts in VCF format and need to import them into an LDAP-based directory such as OpenLDAP, Active Directory, 389 Directory Server, or FreeIPA, converting to LDIF is the necessary intermediate step. Unlike CSV import (which requires custom scripting for each platform), a single LDIF file can be fed directly to any LDAP server’s import tool.

This guide covers the LDIF format structure, the mapping between VCF properties and LDAP attributes, two conversion methods (Univik vCard Converter and Python), and platform-specific import commands for the most common LDAP directories. We also cover the inetOrgPerson object class, which is the standard schema for contact entries across most LDAP implementations.

What Is the LDIF Format?

LDIF is a plain-text format defined in RFC 2849. Each entry in an LDIF file consists of a dn (distinguished name) line identifying where the entry sits in the directory tree, followed by attribute-value pairs (one per line), separated from the next entry by a blank line. The format is human-readable and can be edited in any text editor.

A minimal LDIF contact entry looks like this:

dn: cn=John Smith,ou=contacts,dc=example,dc=com
objectClass: inetOrgPerson
cn: John Smith
sn: Smith
givenName: John
mail: john@example.com
telephoneNumber: +1-555-0100

The dn is the unique identifier for the entry in the directory tree. The objectClass determines which attributes are allowed and required. For contact data, inetOrgPerson is the most widely supported object class across OpenLDAP, 389 DS, and other LDAP implementations. Active Directory uses contact as the object class instead.

VCF to LDIF Field Mapping

Two LDIF-specific details: the sn (surname) attribute is mandatory for inetOrgPerson entries. If a VCF contact has only a single name with no family/given split, use the full name as both cn and sn. LDIF handles multiple values for the same attribute by repeating the attribute line (e.g., two mail: lines for two emails), unlike CSV which requires combining into one cell.

LDIF Entry Structure for Contacts

A complete LDIF contact entry for a standard LDAP server (OpenLDAP, 389 DS) uses the inetOrgPerson object class:

dn: cn=Jane Doe,ou=contacts,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Jane Doe
sn: Doe
givenName: Jane
mail: jane@example.com
mail: jane.doe@company.com
telephoneNumber: +1-555-0100
mobile: +1-555-0200
o: Acme Corp
title: VP Engineering
street: 456 Oak Avenue
l: Springfield
st: IL
postalCode: 62704
description: Primary vendor contact

Notice the four objectClass lines: the inetOrgPerson class hierarchy requires top, person, organizationalPerson, and inetOrgPerson declared in order. The two mail: lines demonstrate multi-valued attributes, which LDIF handles natively. Each LDIF entry must end with a blank line before the next entry begins.

For Active Directory, the entry structure differs: use objectClass: contact instead of inetOrgPerson, add changetype: add after the dn line, and use AD-specific attributes like company instead of o. See our VCF to Active Directory guide for AD-specific details.

Method 1: Univik vCard Converter

Best for: All users. Handles objectClass hierarchy, dn generation, and multi-valued attributes automatically.

Download and open Univik vCard Converter. Load your VCF file (supports vCard 2.1, 3.0, and 4.0, single or multi-contact). Select LDIF as the output format.

Configure the base DN for your directory tree. This is the container where the contacts will be placed, such as ou=contacts,dc=example,dc=com. The converter generates each contact’s full dn by combining cn=Contact Name with your base DN.

The converter maps VCF properties to LDAP attributes using the standard mapping table above. It handles the inetOrgPerson objectClass hierarchy, generates proper dn entries, encodes binary data (photos) in Base64, and separates entries with blank lines. Click Convert to generate the .ldif file.

Method 2: Python Script

Best for: Developers needing custom attribute mapping, non-standard schemas, or pipeline integration.

Install the vobject library (pip install vobject). Write a script that parses each vCard in the VCF file, extracts properties, and outputs LDIF-formatted text. The key steps are: read each vCard, extract cn (from FN), sn (from N or FN), and other fields, construct the dn, write the objectClass hierarchy, and write each attribute as a name:value pair.

For Base64 encoding of binary data (photos), prefix the attribute with a double colon: jpegPhoto:: [base64data]. Long lines (over 76 characters) must be folded by inserting a newline followed by a single space on the continuation line. These LDIF formatting rules are critical for successful import.

The Python approach is useful when you need to transform data during conversion (e.g., reformatting phone numbers, splitting composite address fields, or generating uid attributes from email addresses) or when your LDAP schema uses custom attributes not in the standard mapping.

LDAP Use Cases for VCF-to-LDIF Conversion

Corporate directory population. Organizations migrating from phone-based or email-based contact management to a centralized LDAP directory can bulk-import VCF contacts as inetOrgPerson entries. Once in the LDAP directory, contacts are searchable from any LDAP-aware application.

Thunderbird address book import. Mozilla Thunderbird uses LDIF as one of its native address book import formats. Converting VCF to LDIF allows importing contacts into Thunderbird when direct VCF import fails (which is a known issue with large or complex VCF files containing vCard 2.1 formatted entries).

OpenLDAP and 389 Directory Server seeding. When deploying a new LDAP directory, administrators often need to seed it with existing contact data. Converting phone exports, CRM exports, or email client exports (all commonly available as VCF) into LDIF provides a clean import path.

FreeIPA user provisioning. FreeIPA uses 389 Directory Server as its backend. Contact data from VCF files can be converted to LDIF and imported to populate the directory with external contacts that are searchable alongside internal users.

LDAP-to-LDAP migration. When migrating between LDAP vendors (e.g., from Novell eDirectory to OpenLDAP), exporting the source as LDIF, adjusting the schema, and re-importing is the standard approach. If the source provides VCF export but not LDIF, the VCF-to-LDIF conversion bridges the gap.

Importing LDIF into LDAP Directories

OpenLDAP: ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f contacts.ldif

The -x flag uses simple authentication, -D specifies the bind DN (your admin account), -W prompts for the password, and -f specifies the LDIF file. For TLS connections, add -ZZ before -x.

389 Directory Server: ldapmodify -a -D "cn=Directory Manager" -W -f contacts.ldif

The -a flag indicates add mode. Alternatively, use the 389 DS web console (Cockpit) to import LDIF files through the browser interface.

Active Directory: ldifde -i -f contacts.ldif -j C:\logs

The -i flag sets import mode. Ensure the LDIF uses AD’s contact objectClass instead of inetOrgPerson, and include changetype: add after each dn line.

Thunderbird: Open Thunderbird, go to the Address Book, click Import, select LDIF as the file type, and choose the converted .ldif file. Thunderbird creates a new address book from the imported data.

Common Problems and Fixes

Frequently Asked Questions

What is the difference between LDIF and VCF?

VCF (vCard) is a contact card format designed for sharing individual contacts between people and applications. LDIF is a directory interchange format designed for bulk loading entries into LDAP servers. VCF uses property:value pairs within BEGIN:VCARD/END:VCARD blocks; LDIF uses attribute:value pairs under a dn (distinguished name) with blank lines between entries. LDIF supports multi-valued attributes natively and includes objectClass declarations that VCF does not have.

Which objectClass should I use for contacts?

For OpenLDAP, 389 DS, and most standard LDAP servers, use inetOrgPerson (with the full hierarchy: top, person, organizationalPerson, inetOrgPerson). For Active Directory, use contact. For Thunderbird’s local address book, inetOrgPerson works correctly.

Can LDIF store contact photos?

Yes. Use the jpegPhoto attribute with Base64-encoded image data. In LDIF, prefix the attribute with a double colon to indicate Base64 encoding: jpegPhoto:: /9j/4AAQ.... Large photos increase the LDIF file size significantly, so consider whether photos are needed for your directory use case.

Can I convert LDIF back to VCF?

Yes. Tools like ldif2vcf (Python script) and commercial LDIF converters can reverse the conversion. The mapping is similar in reverse: cn maps to FN, sn/givenName to N, mail to EMAIL, telephoneNumber to TEL, and so on. Univik vCard Converter can also be used to convert between formats bidirectionally.

How do I handle contacts with multiple email addresses?

LDIF supports multi-valued attributes natively. Simply include multiple mail: lines in the same entry, one per email address. This is a key advantage over CSV, which requires combining multiple emails into a single cell or using separate columns.

Conclusion

Last verified: February 2026. LDIF import tested on OpenLDAP 2.6, 389 Directory Server 2.4, Active Directory on Windows Server 2022, and Mozilla Thunderbird 128. Field mapping validated against the inetOrgPerson schema (RFC 2798) and Active Directory contact schema.

Converting VCF to LDIF bridges the gap between personal contact management and enterprise directory services. Univik vCard Converter handles the conversion automatically, generating proper dn entries, objectClass hierarchies, multi-valued attributes, and Base64-encoded binary data. The resulting LDIF file can be imported directly into OpenLDAP (ldapadd), 389 Directory Server (ldapmodify -a), Active Directory (ldifde), or Thunderbird (Address Book > Import). For the 17-row mapping table in this guide, the key requirement is that every entry has a unique cn and a populated sn attribute to satisfy the inetOrgPerson schema.