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.
Prev. page
[1]
2
next page 
