User Account Attributes in AD: Part 1 Outlook LDAP Attributes (General Tab)

User Attributes in AD: Outlook LDAP Attributes

Edit: This is a very old post and remains here for Historic reference. Many of the links in this series are old and don’t exist anymore. If you’re keen, run them through the wayback machine, and you can find the referenced content.

This article is one in a series that offers a reference point between LDAP attributes and their associated values as used in various situations. It always suprises me that no one has put together a visual linkage / mapping table to the commonly used Outlook LDAP attributes displayed. If you want to skip the fluff, click here.  If you are looking for a representation of LDAP fields in Outlook, see these posts:

Outlook Attributes
Outlook Address Book Phone/Notes Tab – Ldap Attributes Mapping (Part 2)

ADUC Attributes
Active Directory Users and Computers – General Tab (Part 3)
Active Directory Users and Computers – Address Tab (Part 4)
Active Directory Users and Computers – Account Tab (Part 5)

Administrators are often asked to report on attributes shown within Outlook’s address-book. Whilst the majority of these attributes are sensible and clear, some of the Outlook LDAP attribute names are obscure. For instance, why “sn” for Surname and “givenName” for Firstname? Why is physicalDeliveryOfficeName such a mouthful for an attribute name?!

Perhaps we should look at the Internet x500 standard pilot in 1991, or maybe even take a look at some of the attributes that made it to the x500 Schema (drink anyone?)

If you do decide to visit MSDN’s Drink Attribute page, be sure to review the community additions section at the bottom of the page, as it explains how to deal with the attribute should it be filled with “Bloody Mary”. Sadly, the Drink Attribute is not mapped as one of the Outlook LDAP Attributes.

Showing Thumbnail Photos in E-mails

There are two fields that look like they could store a Photo in AD. These fields are the thumbnailPhoto and jpegPhoto attributes. LDAP standards seem to promote a level of indecisiveness between the use of these fields. Regardless, the thumbnailPhoto attribute has been present since Windows Server 2000, whilst jpegPhoto was added in 2003. Administrators searching for an answer on which field to use will undoubtedly come across an old article that does not appear to be the most effective method anymore:

This is possible using the “jpegPhoto” attribute. In Windows 2000, the jpegPhoto attribute did not exist and there was something called “thumbnailPhoto.”  The jpegPhoto attribute is more LDAP compliant and is the right one to use if you are on Windows 2003 AD.

Both jpegPhoto and ThumbnailPhoto were listed in a draft of the x500 standard in 1997 and jpeg was the suggested format. Regardless as to whether one is more LDAP compliant or not, the correct field to use within the collection of Outlook LDAP attributes available to us is the thumbnailPhoto attribute.

Only thumbnailPhoto is mapped through to the available collection of Outlook LDAP Attributes. By default, neither field is replicated by your trusty Global Catalogs, so you’ll need to turn that on yourself.

Can you implement photos in Outlook running Active Directory 2003?

If you’re still running Active Directory 2003 – you can still get your pictures in Outlook, providing you have the right version of Exchange – A Schema Update is required and a modification to the replication of the thumbnailPhoto attribute is also needed. See this post if you want some more information on getting this going. It is also rumoured to work with good old Exchange 2007 in some capacity. if you need more convincing, see their other post – It definitely does work; just make sure you don’t break anything as it does involve effectively pretending to almost upgrade to AD 2008 – in your test lab first of course.

Can users modify their own thumbnailPhoto Attribute?

In a perfect world, being able to provide an end user the ability to update their own photo would be nice. Currently, this is not possible without external tools. As mentioned earlier, up until recently the photo attribute wasn’t even one of the exposed Outlook LDAP attributes. If anyone is interested, I do have a few ASPx code snippets that provide exactly that functionality – with a few potential issues and limitations – whatever is performing the update requires write access to the thumbnailPhoto attribute of the requested user. Obviously, if the user does not have access to their own thumbnailPhoto attribute, this can be circumvented by using a dedicated service account that has write access to that attribute for all users (some would disagree with this concept for obvious reasons). This particular snippet does not allow a user to directly upload a photo, it only allows a user to “enable” or “disable” their photo based on an existing photo stored somewhere else in the environment (eg; HR Photo, Security Photo, etc). The code could be quite easily modified to allow direct upload – but I’d be careful about doing that. Whilst the code is written in ASPx, an additional component uses PHP to actually display the user’s photo in line – going a little off topic here.

Outlook LDAP Attributes – General Tab

Here’s a mapping for Outlook LDAP attributes listed under the General Tab:

[Move to Phone/Notes Tab]

Street vs StreetAddress

If you’re familiar with other LDAP environments, you may be wondering about the “street” attribute. In AD, there are two “street-looking” attributes; streetAddress and street. To confuse matters, under the hood, streetAddress (one of the exposed Outlook LDAP Attributes) has a Common Name of “Address”, and the street attribute has a Common Name of “Street-Address”! The CN of an LDAP attribute is generally not seen in our daily meanderings around AD – other than the other side of the links above, or a deep dive into the schema directly; thankfully no where near our Outlook LDAP Attributes.

Generally the street attribute is unused in AD. In an effort to confuse you even more, if you are mapping to the streetAddress field in Active Directory from another product, pay close attention to the source. Other products use the street attribute to populate data that would normally be stored under streetAddress in AD. Often, this field is able to be multi-valued, but iin Active Directory it can only contain a single value. In fact, Fedora’s FreeIPA implementation makes reference to this exact issue here.

Assistant vs msExchAssistantName

Do not be fooled – there are two assistant attributes exposed within a user object and only one of those is displayed within the Outlook LDAP Attributes shown in a user contact card. If you want to manipulate the assistant field that is shown on the General tab, you’ll need to access the msExchAssistantName attribute.

To confuse you, there is another assistant attribute – this is not exposed within the GAL. However; there is another field labeled “assistant” exposed within the Phone/Notes tab – this is for the Assistant’s Telephone number.

I thought Alias was mapped directly to sAMAccountName?

Generally speaking the Alias attribute will match a user’s sAMAccountName. This is not always the case. When Exchange is installed, the schema is extended, and a number of additional attributes are exposed. One of these attributes is ms-Exch-Mail-Nickname which maps to the LDAP attribute mailNickname within the collection of available Outlook LDAP attributes. It is normally populated when an account becomes mail-enabled with the user’s samAccountName. A mailNickname should be unique across an entire forest; a samAccountName only needs to be unique at the domain level. Additionally, if a user’s samAccountName is changed the mailNickName attribute is not automatically updated. In short, a casual glance through Outlook might suggest to the ususpecting administrator that the alias field maps to sAMAccountName – it does not. It maps to an exchange attribute known as mailNickname which more often than not resembles the contents of sAMAccountname.

Is the attribute for City “L” or “I”?

The attribute for City is a shortened form of Location-Name, so therefore logic tells us that it is an “L”. Normally, I like to write an attribute name beginning with a lowercase letter (seems to be the norm to do so), however; owing to the confusion between “l” and “I” in some fonts, I’ve used a capital letter to make it clear.

The Thumbnail Photo attribute is binary?

ThumbnailPhoto is stored as a Binary Octet string. Reading it in to a variable will not really do anything useful for you unless you are simply establishing whether or not it is populated with something or you can visualize Octet Binary code.

..More to come – check back later for Part 2 where we talk some more about Outlook LDAP attributes.