Of the various processes for logging into a POP3/IMAP4 service of the Exchange server, the most commonly used is Basic Authentication through an SSL encrypted session. When choosing this method, each client is asked to provide a username and password. While this process may seem relatively strait forward in a simple, 1 domain topology, there are issues that can arise when organizations become complex (such as through a merger or acquisition, or when companies are using Exchange in a hosted environment.) Therefore, understanding the process by which a user’s credentials are mapped to an Exchange mailbox can help answer many questions.
While the logon process is transparent to a user using an email client (such as Outlook Express), the process of Basic Authentication involves a client connecting to the server, waiting for a response, and then sending the username and password combo for logging in. This process can be tested by using a telnet application, and manually issuing commands to the server. For POP3, this is a 2-step process with the client sending the username using the USER command, waiting for a response, and then issuing a password using the PASS command. For IMAP4 the process is done with one command, the LOGIN command, where the username and password are supplied in one request.
telnet exchangeserver 110Server:> +OK Microsoft Exchange Server 2003 POP3 server version 6.5.7217.0 (secundapin.corpdomain.extest.microsoft.com) ready.Client:> user johndoeServer:> +OKClient:> pass j0hnsPa$$wordServer:> +OK User successfully logged on.
telnet exchangeserver 143Server:> * OK Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7217.0 (secundapin.corpdomain.extest.microsoft.com) ready.Client:>. login johndoe j0hnsPa$$wordServer>. OK LOGIN completed.
In both examples, the positive response from the server indicates that the user has authenticated to the server, and that their default mailbox is open for them to being operations against.
Using this simple method of operations, there are a great deal of ‘assumptions’ that are made. First, the server assumes that ‘johndoe’ exists within the current domain of the Exchange server. This may not always be the case, and if this is not the case, then it is necessary for the user to preface their username with a domain entry, and forward ‘/’ indicating the domain from which they are a part of.
. login corpdomain/johndoe j0hnsPa$$word
Another assumption made is that the user’s mailbox matches the users username. The ‘mailbox’ can be thought of as the container in the Mailbox Storage database that holds the users data. In the Active Directory Users and Computers snap-in, this is referred to as the “Alias”, and can be seen by navigating to the user, right click -> Properties -> Exchange General. Additionally, if you are familiar with the Lightweight Directory Access Protocol (LDAP), then this property exists on the user as ‘mailNickname’. To specify a particular mailbox, append the mailbox to the username string using a trailing ‘/’ and then the ‘Alias”
. login corpdomain/johndoe/johnsMailbox j0hnsPa$$word
In order to specify a mailbox, the complete domain/username/mailbox string is required. Should the server see only a 2 item entry, (I.E. username/mailbox) then it will be interpreted as domain/username, not as username/mailbox.
Appending a mailbox entry to the username is also useful for accessing a mailbox that is not the users ‘default’ mailbox, such as the mailbox of another user to which the person has access too.
. login corpdomain/johndoe/marysMailbox j0hnsPa$$word
Finally, I noted that the users ‘mailbox’ need not match the users ‘username’ (and in the previous example, it did in fact, not.) If this is the case, then the mailbox must be appended to the username string, otherwise the login attempt will fail with an “unknown user name or bad password” error message. (Essentially, the server is replying “unable to access a mailbox named “johndoe” using these credentials.) Once the mailbox alias is appended, the login will succeed.
Client:> . login corpdomain/johndoe j0hnsPa$$wordServer:> . NO Logon failure: unknown user name or bad password.Client:> . login corpdomain/johndoe/johnsMailbox j0hnsPa$$wordServer:> . OK LOGIN completed.
Using the User Principal Name (UPN logon)
Due to issues that can occur with users sharing the same ‘username’ between domains in an organization, the Active Directory system implements a second type of ‘username’ known as the “User Principal Name”. This property is the joining of the users ‘username’ and the Fully Qualified Domain Name (FQDN) of the users domain. For example, our user John Doe is a member of the corporate domain known as “Corpdomain”, this domain has an FQDN of ‘corpdomain.com’. Therefore, John’s UPN is ‘email@example.com’
The UPN property is very similar to a users primary-SMTP address, and in many cases, the two are similar. (However, with nearly all of the properties described in this article, they need not be similar, and it is when these properties are altered from their original state that login’s fail) The UPN can be viewed through the Active Directory Users and Computers snap-in by navigating to the user, right click -> Properties -> Account, it will be listed here under User logon name. In this dialog, the User Logon Name is actually referring to the combination of 2 text boxes, not just the 1 text box the header is above.
Using a UPN logon is the same as using a simplified username
Client:> . login firstname.lastname@example.org j0hnsPa$$wordServer:> . OK LOGIN completed.
The rules for appending a mailbox alias still apply as well
Client:> . login email@example.com/marysMailbox j0hnsPa$$wordServer:> . OK LOGIN completed.
Since the FQDN of the domain is present in the UPN logon, there is no need for the user to ever preface the username string with the domain. In fact, doing so will cause the login to be denied.
Client:> . login firstname.lastname@example.org j0hnsPa$$wordServer:> . NO Logon failure: unknown user name or bad password
One big advantage of using the UPN logon, is that the mailbox alias need not match any particular part of the username string for there to be a successful login. Such as in the case of where ‘. login corpdomain/johndoe’ would fail in the case that john’s Mailbox alias was ‘johnsMailbox’, using ‘. login email@example.com’ will succeed. This is because of the guaranteed uniqueness of the UPN for the user, and therefore the server doesn’t have to make as many assumptions when determining which mailbox the user wishes to access.
- Benjamin Spain