[ActiveDir] [Slightly OT] Exchange anyone? Aka Exchange's use of DLGs and GCs

[joe]

Ok so I wanted to write down some fun I have recently had with some Exchange 2K / AD interactions...   First off, we don't really use Universal Groups. However we do have a couple, the builtin ones such as schema and enterprise admins, plus we have two DLs for executives for securing conference room calendars. Everyone else in the company is forced to use DLs that are managed through a mainframe (don't ask).   So one of the requirements as you may imagine for these DLs that were going to contain email addresses for Executives and Board members is that it had to have membership that could not be seen by normal users unless they were the "right" people, and those right people weren't even the people on the list...   So I had to work out a scheme to make this work and the people doing the management weren't account operators and absolutely were NOT going to become account operators. The way MS hides membership is to write a really dorked up misordered ACL on the group where only account operators and Exchange Servers can see membership. Basically they throw an everyone Deny Read of Member attribute into the ACL and then above that in the chain they add groups for the Exchange Servers and for Account Ops. This of course is a nightmare to deal with with other programs and why ADUC just throws it hands up and says no (now that they updated it) when it encounters a group with hidden membership like that.   So anyway, I figure out a method of locking down an OU sufficiently so that normal users can't see into it to get membership but they can at least enumerate the groups so the GAL doesn't have "holes" in it. We found that if the group existed and Exchange could see it but people couldn't see it then Exchange would present a GAL with blank spots where the groups should be. Not only that, but if you select one of those blank spots with O2K, you actually crash O2K.   The set up was this. One OU, call it NAEX. Within that OU you have three groups call them ConfRooms-NAEX-Admins (gg), ConfRooms-NAEX-Reviewers (ug), ConfRooms-NAEX-Editors (ug) (note the naming scheme folks!). The OU has inheritence blocked (with perm copy). Then entries for everything but Ent Admins, Dom Admins, Admins, System, and Exchange Enterprise Servers are deleted. Then added is authenticated users LC on this and all children objects. ConfRooms-NAEX-Admins gets LC, READ PROPERTY for this and all children. It also gets Write Prop for member attribute on groups....   This all works stellar in test. Works great in production in limited pilot testing.   Then it breaks when we try to go live for real with it... Seems you try to assign the DLs to a calendar or other Role on a folder and you either get an error saying the client can't apply the permission or the DL just disappears from the list when you click apply. You click enough times and the change eventually will occur and sticks on the mailbox just fine... Very inconsistent was the only thing we could say. Now this is all confusing because the permission is set on the store and the client can read the group or else it couldn't display it to even set it. We have had issues with updating values in AD because of bad GC selection on the part of the client but since this is the store, the GCs shouldn't come into it...   Well after chasing through the issue it finally becomes apparent that the Exchange Servers don't have permissions to read the group attributes for some reason. I go in and force an Exchange server to use a specific GC, one its domain, and voila everything works. I force it to use a GC in another domain and voila, it breaks. It works, it break, it works, it breaks. Ok that proved out a GC connection...   To cut it short [1], you see, the Exchange Enterprise Servers groups are DLGs. They are what give Exchange rights to read/write things, if they aren't in working then it is whatever is granted by Everyone (pre-windows 2000...) or by Authenticated Users. The mail server was hitting a GC that was in a domain other than where the groups were defined and the mail server was a member of. This means that the Exchange Enterprise Server DLGs from the other domain were worthless for granting access and the Exchange servers could only access what was granted to Everyone or Authenticated Users... Since we were locking this OU down from those groups, Exchange had no permissions to read the attributes of the groups it needed to read.   The solution ended up being adding ACEs for LC and Read Property for this and all children for the Exchange Domain Server global groups of the domains that had mailbox servers onto the secure OU. Another possible solution would have been to convert the Exchange Enterprise Server groups to UGs.   This was tremendous fun to figure out... heh.   So anyway, ANYONE who is looking to lock their directories down to prevent users from casual browsing of their directory needs to keep this in mind if they have multiple domains and Exchange. A single domain exchange deployment would never see this problem. Yet another reason, in my opinion, for a separate single domain forest Exchange deployment to folks with multiple user domains...   Hope this helps at least one person out there at some point.       [1]  This was 18 hours of troubleshooting all told, more if you count the 3 PSS guys and the other company guy besides me working through the problem.   ------------- http://www.joeware.net   (download joeware) http://www.cafeshops.com/joewarenet  (wear joeware)