10.3 User authentication

---

Windows supports multiple authentication protocols. Kerberos V5^[2] is the preferred and default protocol. Clients negotiate with DCs to decide on the authentication protocol to use, based on a common understanding. A DC will always attempt to use Kerberos first, and will revert to a down-level protocol if the client indicates that it cannot understand or support Kerberos. If a server application supports Kerberos, it is said to be "Kerberized." Not all Windows applications have done the work to achieve this status; IIS has, but Exchange 2000 did not. This means that any client connection to an Exchange 2000 mailbox will use NTLM (the NT challenge/ response mechanism), if clients need to authenticate their credentials before being allowed to connect to a mailbox. The situation is different if you run the combination of Exchange 2003 and Outlook 2003, since you can elect to use Kerberos authentication instead of NTLM. Do not rush to update your mailbox profile to specify Kerberos until you are quite sure that all servers, including those that host public folder replicas, are upgraded and can accept your Kerberos credentials.

Windows supports the concept of a single sign-on. This means that users should not have to enter their account and password information every time they wish to access an application or use a resource such as a file share. Instead, their credentials are established when they log on to a domain, and those credentials can be accessed and used by applications as the need arises. When a user logs on to a DC, he or she provides account name and password. In return, if the DC recognizes the credentials, Windows grants the user an access token that contains his or her Security Identifier (SID) and the SIDs of any group the user belongs to.

Every mailbox is associated with a Windows account. Unless you configure Outlook to prompt for a user name and password each time it connects, it will attempt to use the credentials established by your domain logon. You will only see a separate logon dialog for Exchange if the credentials fail. Figure 10.17 illustrates the password dialog that Outlook displays to collect new credentials. Outlook 2000 shows a need to support connections to Windows NT servers by imposing a 15-character restriction on the length of the domain name, a fact that might come as a surprise if you have implemented longer domain names (as is now possible in Windows 2000/2003).

Figure 10.17: Providing a password to log on to Exchange 2000 (Outlook 2000).

By default, Outlook Web Access does not present users with a logon dialog to specify their mailboxes, servers, and domains before connecting to Exchange. Everything proceeds based on the URL specified to access the mailbox, which may already contain the name of the server and the alias for the mailbox. The browser is able to access the cached set of local credentials and pass these to IIS to authenticate when OWA makes the initial connection. If the credentials are invalid or not present, the browser presents a dialog to allow users to provide the necessary information, as shown in Figure 10.18.

Figure 10.18: Providing credentials to OWA.

Figure 10.19: Outlook Express account details.

Outlook Express and other POP3 or IMAP clients do not use profiles in the same way as MAPI. Instead, you specify details about the account you want to use through a client-specific option. In the case of Outlook Express, this is the Tools.Accounts option. Multiple accounts can be set up, so it is quite possible to have one account for business use that accesses Exchange and another that uses a free mail service such as hotmail.com for personal messages.

The account properties specify whether the client uses the POP3 or IMAP protocol to retrieve messages, the name of the server for incoming mail, and the name of the SMTP server that will send messages on your behalf. While they can be different, in most cases the names of the incoming and outgoing server are the same. As you can see in Figure 10.19, you can specify credentials in two ways. The left-hand screen has checked the "Log on using Secure Password Authentication," which means that you are required to provide credentials through a logon dialog (Figure 10.20). On the other hand, the right-hand screen has left the checkbox blank and has inserted some domain information in the account name field. The combination of domain name, account name, and password is enough to log on to the server without filling in any dialog.

Figure 10.20: Secure IMAP logon to Exchange.

MAPI clients access the AD via a pass-through proxy. All other clients use LDAP whenever they need to retrieve information from the directory, and a connection to the AD may require the client to provide password credentials.

^[2] . Microsoft's implementation of Kerberos V5 is based on the definition as laid out in RFC 1510.

---