It's natural to assume that denying a particular user access to an object would mean that the user can't access the object from any application. In practice, however, that isn't the case. Setting ACLs on Active Directory (AD) objects can have different effects on searching and browsing from Outlook, Outlook Web Access (OWA), Outlook Mobile Access (OMA), and Outlook Express.
Microsoft Exchange environments typically use multiple email clients, most of which employ AD when searching for and browsing mail recipients. AD objects, such as users, contacts, and groups, store details such as email addresses in the object attributes, and different email clients use different mechanisms to present these objects and attributes to the end user. ACLs that you apply to AD objects can allow or deny access to individual object attributes as well as to objects themselves. ACLs consist of one or more access control entries (ACEs), each of which can grant or deny different types of access to an object and its attributes.
Understanding how access works with different clients is important when you want to provide a single, consistent view of the directory regardless of which email client is used. It's particularly important in an application service provider (ASP) or ISP scenario if you're trying to limit the view to a particular portion of the directory and have no control over which clients are being used.
Two Access Methods
Lightweight Directory Access Protocol (LDAP) is the protocol that's most frequently used to access AD. LDAP is a good protocol for directly accessing individual objects and searching for objects. However, it isn't very efficient when you require cursor-based browsing (i.e., scrolling through a list of AD objects as you can do with Outlook clients).
When designing Exchange 2000 Server, Microsoft had to find a way to support the browsing needs of Outlook clients in AD. The solution was to natively support the existing Exchange Server 5.5 directory interface (known as Name Service Provider Interface—NSPI) directly on a Global Catalog (GC) server and have Outlook users use NSPI instead of LDAP to access AD. Unlike LDAP, NSPI supports all the Messaging API (MAPI) address-book operations. LDAP's inability to efficiently support a cursor-based browsing mechanism is the primary reason that OWA, OMA, and Outlook Express support searching but not browsing of objects in AD.
A Simple Example
To demonstrate the effect of ACLs, let's consider a sample organization that has three organizational units (OUs). Figure 1 shows the Microsoft Management Console (MMC) Active Directory Users and Computers window for the Gryffindor OU, Figure 2 shows the Hufflepuff OU, and Figure 3 shows the Slytherin OU. Each OU has a couple of mail-enabled users and a security group; the security group in the Slytherin OU is also mail-enabled.
Figure 4 shows the Global Address List (GAL) in the Outlook Address Book. As you'd expect, there are no surprises here. Now, let's see what happens when we apply a Deny ACE at the object and OU levels. I set explicit Deny Read permissions for Harry Potter on the Slytherin OU (Figure 5) and for the Hagrid Rubeus user object (Figure 6).
After applying the ACEs and connecting to the Exchange server as Harry Potter, we see conflicting results depending on whether we use Outlook, OWA, OMA, or Outlook Express. Let's look at each client and the corresponding discrepancies individually.
Outlook
As Figure 7 shows, Outlook's view of the Address Book has gaps and missing attributes. Gaps appear in the GAL where mail users from the Slytherin OU would otherwise appear. You'll also notice that Harry Potter can no longer see Hagrid Rubeus's telephone number, indicating that Harry has been denied access to the attributes of the Hagrid Rubeus user object. Hagrid's name appears when Harry browses the GAL but not when he executes a Find from the same browse window.
Outlook uses Address Lists to browse AD. The NSPI in effect builds a table for the Address List in question (in this case, the GAL) by using the showInAddressBook attribute of AD objects. The showInAddressBook attribute is multivalued and contains a list of the distinguished names (DNs) of all Address Lists of which the object (e.g., user, group, contact) is a member. In fact, the GAL itself is an Address List.
Although the Outlook result doesn't look pleasing because of the gaps, it is correct. The gaps appear because, in Harry Potter's ACE, we deny only the ability to read object attributes—we don't restrict the ability to list the object. (To prevent the object from being listed, you can set the List Object permission to Deny.) The important point is that the Deny ACEs that we set are honored, so Harry can't see details about users who are in the Slytherin OU or about Hagrid Rubeus.
Note that with Outlook, you see details only of mail-enabled AD objects. For example, the security groups that aren't mail-enabled don't appear. Outlook behaves this way because of the LDAP filters on the default Address Lists, which look only for objects that have email addresses. You could, however, modify the default Address Lists or create custom Address Lists that show objects that aren't mail-enabled.
OWA
Because you can't use OWA, OMA, or Outlook Express to browse the GAL, the example for these clients does a search for names that begin with the letter H. As you can see in Figure 8 the OWA results of this search seem to show that the ACEs had no effect: Harry Potter can see full details for Headless Nick, who belongs in the Slytherin OU, and for Hagrid Rubeus. What kind of black magic is behind these results?
You'd think that OWA would do direct LDAP lookups and that the ACEs would be effective. However, OWA is a Web-based application, and the browser client uses the HTTP protocol to communicate with Exchange. When you search for addresses, Exchange converts your HTTP request into an LDAP query, then executes it. From AD's point of view, the query comes from Exchange, not from the end user. Consequently, ACEs that deny access to the end user are ineffectual.
In Exchange Server 2003 and Exchange 2000, the design of OWA doesn't permit the Exchange server to impersonate the user when converting the request from HTTP to LDAP. Thus, the ACEs we applied have no effect because they were specific to Harry Potter. (I expect this limitation to be overcome in a later release, perhaps by using constrained delegation for Kerberos to ensure that the lookup is performed with the calling user's credentials.)
You can mitigate the effect of this OWA constraint by scoping OWA searches of the Address Book or searches done for ambiguous name resolution. Scoping searches doesn't overcome the inability to impersonate a user, but it does let you control which part of AD a search is executed against. Thus, rather than trying to protect areas that the user shouldn't see, you merely execute searches against only the parts the user is allowed to see.
To scope a search, you use the msExchQueryBaseDN attribute on the calling user's user object. To limit the result set to a specific Address List or OU, set this attribute to the DN of the Address List or OU. When you set this attribute, Exchange modifies the LDAP query to scope the search accordingly.
The value you give this attribute depends on what you're trying to achieve and how AD is partitioned and managed. For example, if you're a service provider that uses OUs to organize users from different companies, you'd probably set this attribute to an OU. If you use permissions on Address Lists to group users of different companies, setting this attribute to an Address List makes more sense.
OWA searches (and ambiguous name resolutions) are driven by the presence of the Galfind command in a URL (e.g., http://server/exchange/?cmd=galfind&dn=H). The OWA search performed for Figure 8 actually executes the following HTTP GET method:
GET /exchange/harry?Cmd=galfind& DN=%68
where DN is the display name (not the distinguished name), and 68 is the hexadecimal value for the letter H in ASCII. (This is just one example of using the Galfind command; you can pass many other attributes as parameters for use in the AD lookup.) The Exchange server then translates this call into an LDAP query.
The main components of an LDAP search are the base DN from which you want to start the search, the scope of the search (e.g., whether you want to search the entire tree from your base), the criteria (aka the filter) for the search, and the attributes you want to have returned from the objects that match those criteria. By default, OWA searches the entire forest and returns the displayName, telephoneNumber, physical-DeliveryOfficeName, title, company, mailNickname, and mail attributes. The LDAP search augments the criteria that the user specifies in the search dialog box with criteria that verify that the mail and showInAddressBook attributes are present. These additional criteria ensure that the search results return only mail-enabled objects. (Results that show only mail-enabled objects also reveal whether the Recipient Update Service—RUS—and your own provisioning systems are correctly stamping these attributes.)
When you set the msExchQueryBaseDN attribute on the calling user's User object, the LDAP query changes according to whether the value is that of an OU or an Address List. If the value represents an OU, Exchange sets the base from which to perform the LDAP search accordingly. If the value is that of an Address List, Exchange adjusts the criteria to look only for objects whose showInAddressBook attribute contains that value; the base of the search remains unchanged.
OMA
Like OWA, OMA is a Web application that's built in to Exchange 2003. Unlike OWA, which still uses ASP technology, OMA is built on the Windows .NET Framework and is an ASP.NET application. Nevertheless, OMA also suffers from the inability to impersonate the calling user when performing LDAP queries. As Figure 9 shows, a search for names that begin with H returns Hagrid Rubeus and Headless Nick, and if you were to look at those objects' properties, you'd see the telephone number and other attributes. Because OMA, like OWA, respects the msExchQueryBaseDN attribute and looks only for mail-enabled objects, you can work around this problem by scoping the OMA search using the technique I described earlier to scope the OWA search.
In OMA, the search tries to match the ambiguous name resolution attribute in the AD schema with the value that the user enters and returns objects that match any one of several attributes (e.g., display name, first name, last name, alias). The lDAPDisplayNames for the default list of attributes that are used in an ambiguous name resolution search are
- displayName
- givenName
- legacyExchangeDN
- mailNickname
- physicalDeliveryOfficeName
- proxyAddresses
- name
- sAMAccountName
- sn
For details about ambiguous name resolution support in Windows Server 2003 and Windows 2000 Server, see the Microsoft article "Ambiguous Name Resolution for LDAP in Windows 2000" (http://support.microsoft.com/?kbid=243299) and the documentation of ambiguous name resolution attributes in the Microsoft Platform SDK (http://msdn.microsoft.com/library/en-us/adschema/adschema/attributes_anr.asp).
But why in the world does the result set of a search for names that begin with the letter H include Slytherin Printers? It's because the mailNickname attribute for Slytherin Printers happens to be set to HPPrinters.
Outlook Express
Outlook Express is the only client I discuss that issues native LDAP calls directly from the client application. Because an Outlook Express search uses the credentials of the calling client, the result set omits denied objects. However, this search returns objects that aren't mail-enabled, and that causes a different inconsistency. Outlook Express searches look for either persons (e.g., user, contact) or group objects that match the criteria but don't check whether the objects have a valid email address that can be used as a delivery address for the recipient of an email message.
Like OMA, Outlook Express uses ambiguous name resolution as part of its search criteria and thus suffers from the anomaly I described earlier with regard to the Slytherin Printers object. Yet you'll notice that Slytherin Printers doesn't appear in the search results, which Figure 10 shows. That's because even though the Slytherin Printers AD object matches an ambiguous name resolution search, the underlying ACE is effective. Confused? How do you think end users must feel?
Outlook Express end users can use advanced settings, such as those shown in Figure 11, to set the base of the LDAP search to an OU. However, this setting can contain only an OU and, unlike OWA and OMA, can't leverage the existence of Address Lists. With Outlook Express, you can also specify which LDAP port to use. By default, you query the GC port (port 3268) and the search returns all objects in the forest. However, if you set the port to 389, the search returns only objects within the domain. In fact, selecting the Use simple search filter check box merely changes the port number from 3268 to 389.
Set User Expectations
As you can see, providing a consistent view of the directory to various email clients requires a fair bit of thought and planning. You might not even be able to provide a consistent view across all your clients. But if you understand the reason why, you can at least set end-user expectations accordingly.
