OpenLDAP Faq-O-Matic : OpenLDAP Software FAQ : Integration : Microsoft Applications :
MS Outlook: How Do LDAP Attributes Map to Address Book Fields?
The following shows the LDAP attribute mappings to Outlook Address Book entry
Properties determined to date. Outlook seems to be oblivious to "objectclass"
when retrieving data from an LDAP server, and simply maps LDAP attributes by
name as shown. In other words, assigning an LDAP entry an "objectclass" of
ResidentialPerson does *not* cause the address information to switch from the
[Business] tab to the [Home] tab.
Refer to FAQ entry "MS Outlook (1): What LDAP Attributes are Recognised?" for a
full list of LDAP attributes that seem to be recognised by Outlook. Not all
apparently-recognised LDAP attributes are shown below. This indicates a
mapping has not yet been determined. Please feel free to share what you
discover.
The mappings described are based on experimenting with Outlook Express 5, and
mainly by inferencing from LDAP lookups. LDIF importing has not been
evaluated. Unless otherwise noted, only a single value is retrieved even if
multiple values exist in the LDAP entry.
Outlook Properties Tab
. Outlook Field - LDAP Attribute(s) (1)
-----------------------------------
Summary
. Name - cn, display-name
. E-Mail Address - mail (2)
. Home Phone - homePhone
. Pager - officePager, pager (3)
. Mobile - mobile
. Personal Web Page
. Business Phone - telephoneNumber
. Business FAX - officeFAX, facsimileTelephoneNumber
. Job Title - title
. Department - department, organizationUnitName, ou (3)
. Office - physicalDeliveryOfficeName
. Company Name - o, organizationName
. Business Web Page - URL
Name
. First - givenName
. Middle - initials
. Last - sn
. Title
. Display - cn, display-name
. Nickname
. E-Mail Address - mail (2)
. Send E-Mail using plain text only
Home
. Street Address - homePostalAddress (4)
. City
. State/Province
. Zip Code
. Country/Region:
. Default
. Web Page
. Phone - homePhone
. Fax - otherFacsimileTelephoneNumber
. Mobile - mobile
Business
. Company Name - o, organizationName (3)
. Street Address - postalAddress, street, streetAddress (4)
. City - l
. State/Province - st
. Zip Code - postalCode
. Country/Region - c, co, countryName (3)
. Default
. Web Page - URL
. Job Title - title
. Department - department, organizationalUnitName, ou (3)
. Office - physicalDeliveryOfficeName
. Phone - telephoneNumber
. Fax - officeFAX, facsimileTelephoneNumber
. Pager - officePager, pager (3)
. IP Phone
Personal
. Spouse
. Children
. Gender
. Birthday
. Anniversary
Other
. Notes - comment, info (3)
. Group Membership
Conferencing
. Conferencing Server - conferenceInformation
. Conferencing Address
Digital IDs
. E-Mail Address - mail
. Digital IDs... - userCertificate;binary (7)
Organisation (8)
. Manager - Manager (5)
. Reports - Reports (5,6)
General (8)
. (white space) - labeledURI (9)
Notes
-----
(1) Where more than one attribute name is given, sometimes the first one
encountered is used, and sometimes one name takes preference over others.
(2) Only the first listed email address is retrieved.
(3) Retrieves from the first-listed attribute that has a value in the order
shown.
(4) Replaces embedded "$"s with line separators, displaying as separate lines
in scrollable region.
(5) DN format, and double-clickable to go to corresponding entry.
(6) Multiple values allowed.
(7) DER encoded X.509.
(8) Tab only appears if an underlying attribute exists!
(9) When specified, URI is retrieved and displayed in the white space on this
tab.
Acknowledgements
----------------
Thanks to the following for help in compiling this information:
. Steven P. Donegan
. Graeme Joyce
NOTE: Author's current email address is
BarryJJ@ATTGlobal.Net
The ...@IBM.Net form expire[s/d] on 1st October, 2000.BarryJJ@IBM.NetOr, reformatting the filter to make the logical structure more clear: (&
(mail=*)
(|
(mail=rqxwe*)
(|
(cn=rqxwe*)
(|
(sn=rqxwe*)
(givenname=rqxwe*)
)
)
)
)The search filter syntax is basically a logical expression in prefix notation (that is, the logical operator appears before its arguments). The above filter shows EXACTLY which fields Outlook requires: (1) The mail attributetype is required by the conjunction operator (2) At least one of the disjunctions must also be true. Note that a mail attribute containing the query string satisfies this condition. Importantly, the fact that the filter uses wildcards also has performance implications. To improve performace for Outlook clients, you should index data appropriately.
Note: I generated this log using (gasp!) the iPlanet Directory Server. A similar test could be performed for other commong LDAP clients, e.g. Outlook Express.
joberwetter@grow.net
spam@warenext.com
Links to relevant object classes are present as well.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/ad/win2k_entry_attributes_all.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/ad/win2k_entry_classes_all.asp
Here is the top of the above link and the one from the previous answer. Links for Classes, Attributes, Syntaxes and Control Access Rights.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/windows_2000_schema.asp
See also: http://www.openldap.org/faq/index.cgi?file=293 and http://www.yo-linux.com/TUTORIALS/LinuxTutorialLDAP-GILSchemaExtension.html
For a more recent visual representation of Outlook to LDAP Attribute mappings, see this article: http://www.jigsolving.com/ad/user-account-attributes-part-1#Outlook-General-Tab-Ldap-Mappings