Grrr. Exchange Split Permissions model... The name for that should something a lot more vulgar I think. The Exchange folks tell you to do what MS has told the AD Admins the whole time NOT to do and that is to not have a crapload of ACE's. Yet the way the model was built for Exchange you either give them god rights or at least too many rights or you add a bunch of ACE's.
Be careful with the doc I saw, it was wrong because it had you giving write property access to nTSecurityDescriptor... If you do that, you might as well make the Exchange Admins Account Ops or whatever else over the user objects or to whatever you apply that write prop access to. We ended up giving a little more access than we wanted (no choice because of the horrible way the property sets were used by MS for E2K)but it isn't incredibly bad. Mostly the bad part is that the Exchange Admins have access to change SPN's and UPN's which they shouldn't be able to get near to but again, we hate Deny ACEs. It took a while to work out the "REAL" permissions needed to do mailbox reconnects/adds/deletes/moves but we have that now. The fun part of that one was that there is a permission that has to be applied to users that isn't even a property for users, so basically a garbage ACE that is only useful for E2K. Our provisioning of users mostly comes out of an automated web based provisioning system written in house so the E2K Admins don't need many user rights. The Exchange Admins mostly only do work on the Servers though since MS doesn't have an easy way to do reconnects from the command line (looking for source code to MBCONN...) for W2K so the Exchange Admins have to go through the manual GUI (blech) processes to do reconnects. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Coleman, Hunter Sent: Monday, August 25, 2003 4:28 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] [SOT] Scripting ACEs Your script confirmed what I was getting when I checked the ACEs using a Vbscript, and what you said earlier about having the same number of ACEs regardless of how the permissions are set. I'd rather avoid setting the Deny ACEs, but there doesn't seem to be much alternative in implementing the Exchange "split permissions" model. Which gets back to one of the other threads here recently..... -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, August 23, 2003 8:37 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [SOT] Scripting ACEs LOL. No problem. My new lab here at home is definitely in the experiment stage. The only part that is set up in a semi-permanent way is my Onkyo TX-SR601/JVC XL-F215 and Bose 701's so I have music to help set up the rest. As for the computer stuff I have network cables strung about the room so it looks like I am having a limbo contest (looking for wire wraps so I can run them right...). :o) To add to the madness I added a new WAP (G type) to add to my B-Type and my other switches/hubs. It was getting too easy otherwise. :op To bring this slightly back on topic here is a copy of the perl script. Not sure if this is the latest version but seems to produce a good amount of output. :op Very raw output, if you don't have some idea of ACL and ACE's oh my already then it may be a trifle overwhelming. Verbose and debug modes more so but gives people values for GUIDs and such so if they want to generate their own ACE's they can use this tool to dump one to see what values they need to pump in. Here is snippet of a sample: F:\temp>perl perlchksec.pl cn=anon,d,dc=joehome,dc=com PerlChkSec V01.00.00pl Joe Richards ([EMAIL PROTECTED]) June 2002 <snip> -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, August 16, 2003 8:42 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Scripting ACEs The way ACE's work you should have two ACE's either way, it is simply how the GUI is interpreting. If you look at the ACE and ACL structures in MSDN you will see that each ace can only have a single Principal, access type, and attribute specified. More than likely the way the ACE's are being ordered when the GUI does it matches a profile it sets up for decoding them. If you do it from the GUI and then dump from a script you should be able to duplicate the ordering if that is what you would like to do. I believe I posted a perl script to ms.public.adsi.general once or twice that will dump out the ACE's for the ACL of an object specifically to help determine the ACE's and ordering put together by the GUI. Google that group for it if you want it, otherwise you can send me a separate email and I will try to go dig it up at some point for you. I am a bit in a disarray right now as I we just went through the power outage plus I am in the middle of moving and at work am buried in E2K "stuff". I don't know where anything is right now. :op joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Coleman, Hunter Sent: Thursday, August 14, 2003 12:44 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Scripting ACEs I'm seeing a discrepancy between setting ACEs through the GUI (Security tab on an object) and setting them through a script. If I go into the Security Tab on an OU and set a Deny ACE for some global group on "Change Password" and "Reset Password" for User objects, I end up with a single Deny ACE for those two operations. However, if I script it, I seem to end up with two Deny ACEs, one for "Change Password" and a second, separate one for "Reset Password." I'm only setting a single objectType on the scripted ACE at this point, and having to repeat that code to set the second objectType. Is there a way to specify multiple objectTypes, or am I stuck with a larger DACL if I script the ACEs? Thanks, Hunter List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
