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

[joe]

Ooohhhh. You bad dude. I recall being told "DO NOT EVEN CONSIDER TOUCHING THE PERMISSIONS NOR GROUPS ADPREP/FORESTPREP PUT INTO PLACE, IN FACT, DON'T EVEN LOOK AT THEM...". I actually listened to that because I know what a house of cards is when I see it and didn't want to pull a wall if you know what I mean...   I honestly should go through and tear it all apart and try to understand what it is all doing but I really really don't want to. It will just make me grumpier I think as every time I dig into Exchange I find something else that upsets me.   18 hours was not a happy thing for me... Glad you could find joy in my pain... I'll remember that buddy! Actually if I had been thinking straight I should have looked at how Exchange got permission to do things right off, it was pretty obvious, but as you say, after the fact. I just ASS-U-ME-d that they (MS) would make sure they always had permissions to read what they needed to read. I honestly don't think they ever even realized (and possibly still don't) that they were depending on Authenticated Users / Everyone access to the objects on the GCs.   I agree on the marketing comments... Just as easily for the security of the Servers to access AD they could have used the Universal Domain Local Groups (the ones that can't be used as DLs). That would have worked perfectly as well.   Heh, yes good point on the GCs of multiple domains in a single site with Exchange Servers. This should be fixed within the year though... Also it is another good reason for a separate single domain forest Exchange implementation. :oP   I absolutely agree about your statements about UGs and their use being driven and changed by Exchange. Actually I think MS should be more clear in the AD documentation that if you plan on using Exchange, all of our planning guidance completely changes so go figure out Exchange as well before deploying your AD or else you will be doing some major work to get it all to play well together. Of course one answer to this and many questions is "this is another good reason for a separate single domain forest Exchange implementation". :o))   I have to say that UGs are more palatable with LVR. However I still think unless you have a heavy GC penetration 90%+ or absolutely guaranteed connectivity back to GCs they can be dangerous. Specifically for deny ACEs (WHICH YOU SHOULD ALMOST NEVER USE) but also for the grant ACEs because if you don't get a GC you could have an issue with inconsistent access rights. Yes GC caching should help out but there are still inconsistencies that can pop up.   I have been thinking once we get to K3 on all the DCs at looking at switching our use to UGs... However I would really have to go through the cost/benefit analysis. If we don't also increase our GCs I think the one off weird inconsistency issues could be painful and we could end up chasing ghosts on a frequent basis of the type - On March 3 I couldn't get access to this or that but it worked fine the day before and the day after. This would eventually get to my group and people would be expecting us to solve the problem which couldn't be truly solved without making most if not all DCs GCs. So we would have to explain how it works and how it can possibly be inconsistent, again and again. Most of our support staff is not that strong on deep tech and rolls over a lot so it would be painful.     ------------- 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 4:26 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Slightly OT] Exchange anyone? Aka Exchange's use of DLGs and GCs actually, now that you ask, I should be quite proud of myself: there was no MS advice or KB involved, just a good understanding of AD security and group scopes etc. It only seemed natural to me, having looked rather closely at how the Exchange permissions are setup and noticing their usage of GGs in DLGs to permissions the servers.  I did have to smile a bit when reading it took you and PSS 18 hours to figure out the issue - however, it's always easy to know it better afterwards.   I remember my first thought about the Exchange Groups/ACLs: "I guess they had to do it this way, since they had to make this baby run in mixed mode environments"... However, it really doesn't run well in mixed mode multi-domain environments anyways, since to effectively protect PFs it really comes down to use universal security groups, which aren't available in mixed mode...  So it would have been easier just to say "Exchange 200x requires native mode" and go with a good group model from the start - but this would have been bad for marketing the product.     That said, yes - you can do a lot of things according to the MS docs - but you'll still be bit by DLGs in Exchange (in a multi-domain forest), even when the scope of users and the use of the DL is a single domain => you have to consider your Exchange routing.  If for whatever reason, the eMail with this DL needs to be routed via an Exchange server that uses a GC outside of it's domain (hard to ensure, if you don't have separate sites for your Exchange Servers within each domain), then it won't be able to determine the members and thus can't route the eMail.  But it won't give you an error either, since for this server the DL was simply empty, which is a valid state.   ha, wish I only had 2 DLs in Exchange => think more into the "many hundreds" range...   I don't know if I had said it this clearly before (and you might have guessed): our heavy usage of UGs (even if it's "only" a security group) is actually driven quite a bit due to the implementation of Exchange.  It also needs to be clearly understood, that certain recommendations that apply to a "pure" AD environment are suddenly killed, if Exchange is added to the picture.  Example: in pure AD, you'd try to avoid adding users directly as members to UGs - instead you'd add them to GGs and nest these GGs into UGs so that replication of membership-changes really only happens in the domain (where the GGs originate). Replication would not happen to every GC, since the nesting of the GGs in the UG would usually remain more static.  This concept is simply wrong with Exchange, as Exchange needs to enumerate the contents of a DL to know where to route a message to => if the UG contains various GGs, it could only "explode" membership of the GGs applicaple to the ones in the same domain of the GC being used. Basically this forces you to use UGs all the time (ofcourse these can still be nested, but won't avoid "global" replication to all GCs).   At last, LVR in Win2k3 should lessen the fear of admins to use UGs. But you first have to get there.   /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Donnerstag, 18. M�rz 2004 16:56 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)