Archive for March, 2012

Dude, what is my UPN… or wait… is it an email address?

On several several several occasions I have been asked by confused customers about UPN renames and email address changes during initial Office 365 ADFS farm setup and directory clean-up effort. Today’s question produced a little story, which I wanted to share in attempt to demystify email and UPN correlation when ADFS is in the mix

Let’s start with defining constants

User Principal Name (UPN) is a single-value attribute [in AD attribute name is ‘userPrincipalName’] and to confuse you even further in ADUC UI is it not presented as a single-field attribute, but rather split into two parts with a drop-down to select the ‘right’ part, which is your AD domain name and possible additional suffixes, and string value that you can enter manually on the left. ADUC often “suggests” to use value of sAMAccountName that is listed in ADUC UI as “pre-Windows 2000 logon name”, yet you are free to type whatever you wish to type or leave that field/attribute blank all together.

Proxy Addresses is a multi-valued attribute [AD attribute name is ‘proxyAddresses’] . It is an extended attribute, which you will only have if you have extended AD schema while installing Exchange Server. Some version of ADUC UI can display it, some can’t, however it’s easy enough to use PowerShell or ADSI editor to see/edit the value of that and other attributes. Of course, you also have an option to use Exchange 2007/2010 console, which exposes many Exchange-related attributes as well.

Note
that proxyAddresses attribute contain more than just SMTP addresses and that formatting (including capitalization) is important for values of that attribute. For example capitalized prefix 'SMTP:' signifies that address is “primary”, and non-capitalize value 'smtp:' signifies that address is an additional address. You can only have one primary address, and as many secondary addresses as you wish. Since it is an Exchange attribute, Exchange Management Console is taking care of uniqueness verification when you set values for that attribute with the console. However, if and when you will modify that attribute directly in AD (outside of Exchange Management Console) you will need to ensure that uniqueness and formatting of that attribute is preserved. Failure to do so will likely to result in NDRs. Active Directory by itself will be happy to accept any values to store in the attribute, since it defined simply as multi-valued string. In other words, AD will not save you from being negligent.

Confusion of those attributes (along with ‘mail‘, ‘targetAddress‘ and sometimes mail alias aka ‘mailNickName‘ and ‘sAMAccountName‘) is relatively common occurrence, as the value of those attributes is often (but not necessarily) the same

UPN and Office 365 Federation

Organizations need to update their user’s UPN to be publicly “routable” in order to establish federated partnership with Office 365. There is no “adding” of a secondary value possible, since userPrinciplaName is a single-value attribute [attribute definition].

Simple PowerShell script can replace user’s UPNs in a few minutes, if/when desired.

Note:

Some of your existing applications could use UPN to tie-in to a user account in AD, which is a theoretical possibility; therefore changing UPN _could_ break that/those application(s), and therefore you should perform some analysis/testing of internal infrastructure to see whether UPN rename will work with all of your key applications without re-configuration of dependencies. If no dependencies identified the rename of UPN is fast and easy operation to perform. Quick Bing search will provide you with more PowerShell scripts on your hands that than you care to have. 🙂

Proxy Addresses

Aforementioned “ProxyAddresses” attribute could come into play if and when old UPN value was ALSO one of the routable email addresses. That is where confusion most often occurs.

Example

Bear with me, since it is a long story:

  • Let’s say that I am working for Contoso where my UPN is dmitry@contoso.com AND my primary email address is also happens to have the value of dmitry@contoso.com
  • At one fine day Contoso was purchased by Fabrikam (my heart goes out for those laid-off Contoso employees) and Fabrikam’s IT decided to go to the cloud and got themselves an Office 365 with ADFS deal
  • To “normalize” their joined AD infrastructure they’ve added @fabrikam.com” as one of the available suffixes to an existing Contoso’s AD and now they want to rename every account in Contoso’s AD to have UPN suffix @fabrikam.com. So they performed the actual rename of existing UPNs with the PowerShell script…
  • The Fabrikam’s half of the company needs no change – they will likely to have their UPN and their primary SMTP match. It will look something like username@fabrikam.com
  • The ex-Contoso half is not so lucky. I have my UPN renamed from dmitry@contoso.com to dmitry@fabrikam.com however my primary SMTP remained to be dmitry@contoso.com
  • Technically, there is nothing wrong with that scenario. As an ex-Contoso employee I still can login into my dmitry@contoso.com mailbox with my dmitry@fabrikam.com UPN; It just so happened that UPN value is _formatted_ the same way as an email address value; it doesn’t have to be equal to my email address. In fact, by itself UPN have nothing to do with my email at all. Yet, I have to use it to login into my new Office 365 mailbox via ADFS. Will I be confused about it? You bet! I’ll be screaming at those IT people who can’t stop changing things on me. Damn you IT department, why can’t you leave me alone?
  • So, naturally, Fabrikam’s IT will want to rename my ex-Contoso employee primary SMTPs to match to my new Fabrikam UPN value. Therefore my mailbox will become dmitry@fabrikam.com; Generally IT folks will provide an explanation like “you will be logging-in into Office 365 mailbox with your email address” which technically is a complete lie, since users are logging-in with their UPN value which just happen to be the same as their primary SMTP address/email.
  • Now we have arrived to “adding a value” part of the story:
  • Since I was giving my Contoso business cards to every person I’ve met at every cocktail party for the last 20 years with my email address being dmitry@contoso.com, this unfortunate acquisition by Fabrikam and consequential rename of my login information (UPN) to something else besides my old email address value, just so I can remember how to login into the new system… yes, all that jumbo-mambo IT folks was trying to explain to me — is simply not gonna work for me. I can’t afford to lose all those contacts and future invites to cocktail parties, nor you can expect me to remember how to login into this new cloud thing. Not after the cocktail party, anyways…
  • So I’ll be demanding that Fabrikam’s IT do something about incoming messages to my existing dmitry@contoso.com email address. Since they have renamed my primary SMTP to be dmitry@fabrikam.com, all new outgoing emails will be seen as “from” that address, however they [The IT folks]will need to add my ‘dmitry@contoso.com‘ email address as a secondary smtp: address into the proxyAddresses collection. By saving my old email address into proxyAddresses they will preserve routablity. That will allow me to continue to drop my old business cards with my old email address into those jars in the hotel lobbies with hopes to win an exuberant amount of points and have an awesome vacation somewhere where I don’t need to login into email account at all. Problem solved.

I hope that make some sense