The Security Bug That Wasn't

As most regular readers know, I spend a lot of time working on various projects oriented around Exchange security, including a new book ("Secure Messaging with Microsoft Exchange Server 2003"--Microsoft Press, 2004), a security-related blog ( ), and a variety of teaching engagements. So, I'm always interested in security problems, especially when those problems have anything to do with Exchange. Thus it was with great interest that I discovered a post on the NTBugtraq mailing list, reporting just such a problem.

The poster claimed that, because of what appeared to be a bug, regular users with no special permissions were able to use Outlook to magically change distribution groups into security groups, and that this capability represents a security problem. This claim is partially true: Users can cause the described change to occur, but it isn't necessarily a security problem. In fact, this conversion ability is present by design, and you'll probably need to use it if you're upgrading from Exchange Server 5.5 to Exchange Server 2003 or Exchange 2000 Server.

First, a little background: Exchange 5.5 maintains its own directory, so Exchange 5.5 mailboxes, public folders, distribution lists (DLs), and custom recipients are maintained separately from Windows NT 4.0 user accounts. This division means that you can't use NT groups to assign permissions to Exchange 5.5 objects. Instead, you use Exchange DLs to grant permissions. You can assign a DL as the owner of a public folder, and you can grant public folder roles and permissions to DLs. So far so good.

Then came Exchange 2000, with its high (and welcome) degree of Active Directory (AD) integration. With AD came new group objects and types, including security groups (which have SIDs and thus can be used to grant permissions) and distribution groups (which are just like Exchange 5.5 DLs). Because of the division between these group types, you can't use a distribution group to assign permissions in Exchange 2003 or Exchange 2000, and all those Exchange 5.5 public folders that have DL owners and permissions will break if used with a later Exchange version.

Microsoft had to make a choice: Find some automated way to fix the problem, or make administrators manually update permissions on their public folder objects. The choice turned out to be easy. Microsoft provided a conversion mechanism: If a public folder's ACL contains an Exchange 5.5 DL, and that public folder is accessed from Exchange 2003 or Exchange 2000, the Exchange Information Store (IS) converts the DL to an AD security group.

The NTBugtraq report was concerned with another aspect of this mechanism. If you add a defined AD distribution group to a public folder's ACL, the IS also converts that distribution group to a security group. This behavior might be unexpected--although considering the distinction between distribution groups and security groups, you might argue that the behavior is predictable--but it's logical given the set of constraints I described above. If you try to use a non-security object to grant permissions, it's reasonable for Exchange to convert that object to one that can act as a security object.

Furthermore, Chapter 10 of the "Microsoft Exchange 2000 Server Resource Kit" thoroughly describes this behavior and gives you a solution if you want to change it. Look for the msExchDisableUDGConversion AD attribute, which is attached to the Exchange organization object in AD. You can use ADSI Edit or a script to set this attribute to one of the following values:

- 0 (the default) allows the distribution group-to-security group conversion to take place whenever requested.

- 1 allows distribution group-to-security group conversion only when requested by the IS. If a user uses Outlook to add a distribution group to a public folder's permissions list, the conversion fails and the user can't save the updated permissions.

- 2 turns off distribution group-to-security group conversion. Microsoft recommends against using this setting, however, because it breaks some types of Exchange 5.5 public folder access.

Several other NTBugtraq readers quickly responded to the original report and explained how the mechanism works and why it shouldn't be considered a security flaw. One moral of this episode is that you need to carefully evaluate reports of security vulnerabilities to determine whether they're credible and how the involved behaviors apply to your environment.

A great way to keep on top of security issues is to subscribe to the Windows & .NET Magazine Security UPDATE email newsletter ( ) or Security Administrator print newsletter ( ). Next week, I'll let you know another way, when I discuss Exchange and the Really Simple Syndication (RSS) standard.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.