This article is the fourth in a series that offers a reference point between User account attributes and their associated values as displayed within various interfaces. When I started posting in this series, I really had no idea what I was going to do. It has turned out to simply be a list of attribute mappings and not much more than that. I wasn’t sure if there was any point, but looking at the number of inbound links I am getting for this information (thanks guys :)), it would seem that it is of some use to some one out there so I will continue doing so [I actually use the reference lists all the time myself!]
In this post we look at the Address Tab within the standard Active Directory for Users and Computers interface. If you are looking for a representation of LDAP fields in Outlook, see these posts:
Outlook Attributes
Outlook Address Book General Tab LDAP Attributes Mapping (Part 1)
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 – Account Tab (Part 5)
As mentioned in a previous post, if you’re looking for information or a complete list of User Account Attributes in Active Directory for Users and Computers, a simple search of the web should provide you with what you need.
Active Directory – User Account Attributes – ADUC Address Tab
Here’s the Address Tab within DSA.MSC (expressed in other words, DSA.MSC is the MMC snap-in that opens up ADUC or Active Directory for Users and Computers):
[Move to General Tab][Move to Account Tab]
| Name in ADUC | LDAP Attribute | Format | Attribute-ID |
| Display | displayName | Single | 1.2.840.113556.1.2.13 |
| Street | streetAddress | Single | 1.2.840.113556.1.2.256 |
| P.O. Box | postOfficeBox | Multi | 2.5.4.18 |
| City | L | Single | 2.5.4.7 |
| State | st | Single | 2.5.4.8 |
| Zip/Postal Code | postalCode | Single | 2.5.4.17 |
| Country / Region | c co | Single | 1.2.840.113556.1.2.131 |
Hi
Any plans to do this for the Telephone tab (and organisation tab)
The others have been very helpful
Thanks
Sure thing Linda – As with most things in life, we get busy; I’ve been meaning to come back to complete the series. Thanks for the reminder 🙂
Something that has always bothered me with this dialog (and LDAP) is what if I have a street address and a PO Box, but they have different postal codes? Everything I find on the Internet seems to assume that the postal code is the same for both.
Interesting – I’ve always assumed that it was a “one or the other” type arrangement – have a P.O. Box, fill in that field; have a delivery address – key in the street address.
I agree with you though..
Looking at the telephone section, we seem to have SO MANY options; othermobile, pager, fax, multi-valued fields, etc; yet for address – we have only one.
I think if you look at the original implementation of LDAP, some of the address fields are/were multivalued – it’s a shame they didn’t implement it that way in AD.
That could be their intent. I know where I work, I have a street address for my office, but much of our mail goes to a PO Box. Fortunately here, we have the same postal code. Some places in town might be different depending on the PO though. I would generally assume one or the other myself.
I am in the situation as described, we have an office in one post code and PO Box in another. Thinking i need to leave office address in AD address and put PO Box in custom attributes.
And i’d like to know if anyone has been able to populate all the telephone fields…
Thanks for sharing.
NB: I’ve run some tests on our instance and believe that the address’s COUNTRY field is actually getting its value from C rather than CO.
NB: Though C is a 2 char iso code, whilst the displayed value is the full country name (as with CO), amending the attributes values so that C and CO are out of sync we see that the UI reflects the changes made to C / so the display value is coming from a lookup on the 2 char code.
Thanks John. I’ll have to check this out when I have some time – i do recall running into some confusion with regards to the C and Co fields some years back – maybe it’s time to revisit that.