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

[joe]

:oP   I personally think the issue is that MS didn't know they were depending on Authenticated Users / Everyone rights for reading info out of the GCs with the Exchange Servers...   <eg>   ------------- http://www.joeware.net   (download joeware) http://www.cafeshops.com/joewarenet  (wear joeware)       From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Thursday, March 18, 2004 11:36 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Slightly OT] Exchange anyone? Aka Exchange's use of DLGs and GCs This is one of the issues whenever you have a concept of security context scope. The UG idea is a good one, assuming you like UGs. :) I�ve seen other things like it, but anything that spans the DNC boundry can be hit with something like this.   <aside> �carte blanche� is actually used as a noun in French. So you wouldn�t give �carte blanche access� you would give �carte blanche�. That is, it is the item being given, not the descriptor for the item that has been given. A literal translation of �carte blanche� is actually �white card�. </aside>   ~Eric     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, March 18, 2004 9:56 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Slightly OT] Exchange anyone? Aka Exchange's use of DLGs and GCs   :o)   Guido, did you get that advice from MS or was it something you went off and just did? KB perhaps?   True on the converting all of them...   We don't use DLs except for these 2. All other bulk mail / DLs are done outside of Exchange. However, you can use (according to MS Docs) DLGs as long as the scope of the users and use is a single domain.   Overall, I really dislike how permissions are done in Exchange. The running assumption is that anyone running Exchange should have pretty much carte blanche access across the entire forest (or at least where you run domainprep for exchange servers). No real ability to subdelegate by domain or whatever.     ------------- http://www.joeware.net   (download joeware) http://www.cafeshops.com/joewarenet  (wear joeware)         From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Thursday, March 18, 2004 2:53 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Slightly OT] Exchange anyone? Aka Exchange's use of DLGs and GCs which is why I have an "All Exchange Enterprise Servers" UG that contains all "Exchange Domain Server" GGs (just like the DLGs) - I left the other "Exchange Enterprise Servers" DLGs as they are, as you can't convert all of them to UGs (only one could keep the name) and the ACE is used by default for many things in E2K (e.g. when a new Exchange Server is added etc.).    BTW, are you using any of your other DLGs as distribution groups?  If so, how do you avoid similar issues (here it's enumeration) with these?    /Guido   From: joe [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 18. M�rz 2004 04:29 To: [EMAIL PROTECTED] Subject: [ActiveDir] [Slightly OT] Exchange anyone? Aka Exchange's use of DLGs and GCs 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)