Re: [ActiveDir] My endless question day continued- Exchange attri butes
Thanks everybody for your input! Regards, Mylo joe wrote: As Rick said, it is tight security or ease of use. These things tend to be mutually exclusive. Good security is rarely easy. You are balancing between locked down and useability. But yes, in answer to your original question, it is not possible to have a completely locked down separation of duties between DAs and Exchange Admins in a single forest deployment. Yes, impossible. Microsoft did not build the products so this was possible. AD is specifically designed so that DAs can take control of anything. The permissions in Exchange and how they are layed out are such that you have to put a painful number of ACEs (including a bunch of denies) that are generally not good AD Practices for SD handling. The bare minimum would be like a 5.5 deployment. You have a NOS forest and you have an Exchange forest, the GAL data goes directly into the Exchange forest and it trusts the NOS forest for security principals. The more data you want in the NOS forest the more syncing that has to start happening. IMO, the Exchange forest should be completely locked down, and all provisioning should be done through good provisioning tools that log everything and people don't do things natively in the domain. As to the other questions, yes, you need to set up a complete test environment. This should exist anyway, you should be testing all changes in it because any change could blow out any aspect of the functionality. While MS is generally pretty good about not blowing your functionality out of the water, it isn't unheard of and it is best to find that in the QA environment or test environment versus production. Further, IMO, anyone who allows auto updates to servers, especially servers with truly critical business functions should NEVER autoupdate for ANYTHING. Everything should be manually pushed after it is fully tested and known to be good and that way you can watch over the server as it updates and reboots or continues on its ways. If after doing 20 or 30 servers of one type and they are going well, you can lighten up a little and mass blast them to the same type of servers but anything else is a bit reckless in my opinion. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, August 12, 2005 4:30 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] My endless question day continued- Exchange attri butes Rick, Thanks for the response and of course you're right. The difficulty though lies with the complexity you refer to. Case in point Exchange Resource Forests. There's a lack of detailed documentation on the MS site. I've been looking at a dual forest solution with an E2k3 forest having an external trust to an account forest and I'm trying to establish what functionality, if any, Exchange-wise, is lost (compared to a normal single forest deployment). I know it's not a particularly common deployment scenario (unless maybe MCS are involved) and that this is an AD group ;-)... but I suspect, short of building a PoC environment or answers from the group, finding out things like mailbox delegation...whether FE/BE topology works etc, means test test test :-) Mylo Rick Kingslan wrote: Mylo, I'll answer this, and when joe gets back online later, I'm sure that he'll correct me. j/k joe! In my mind, you have two choices - a secure and workable solution with separation with a potential of added complexity, or a much less secure, combined environment. I have a saying that goes with this: Security != Easy, or Security and ease of use are diametrically opposed Everyone has to make decisions based upon what their sensitivity to risk is. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, August 12, 2005 11:55 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] My endless question day continued- Exchange attri butes Apologies for jumping into a semi-dead thread with some OT questions .. Joe, you mentioned the following: Exchange never would have been brought into the main production forest, it would have been in a dedicated single domain resource forest that was entirely managed by the Exchange admins. Are you saying that the Resource (Exchange) Forest is the only workable solution in your mind that provides the necessary separation? I can see it from the whole service autonomy and isolation argument, but the fact that you need to throw provisioning into the equation, issues such as potential single points of failure with MIIS/IIFP, added complexity etc surely that single AD forest/domain is more preferable :-) Cheers, Mylo joe wrote: In my last job we sort of did. I say sort of because you get the point where you are going against AD best practices in how many ACEs you are sticking in the directory. The mechanisms we were thinking
RE: [ActiveDir] My endless question day continued- Exchange attri butes
As Rick said, it is tight security or ease of use. These things tend to be mutually exclusive. Good security is rarely easy. You are balancing between locked down and useability. But yes, in answer to your original question, it is not possible to have a completely locked down separation of duties between DAs and Exchange Admins in a single forest deployment. Yes, impossible. Microsoft did not build the products so this was possible. AD is specifically designed so that DAs can take control of anything. The permissions in Exchange and how they are layed out are such that you have to put a painful number of ACEs (including a bunch of denies) that are generally not good AD Practices for SD handling. The bare minimum would be like a 5.5 deployment. You have a NOS forest and you have an Exchange forest, the GAL data goes directly into the Exchange forest and it trusts the NOS forest for security principals. The more data you want in the NOS forest the more syncing that has to start happening. IMO, the Exchange forest should be completely locked down, and all provisioning should be done through good provisioning tools that log everything and people don't do things natively in the domain. As to the other questions, yes, you need to set up a complete test environment. This should exist anyway, you should be testing all changes in it because any change could blow out any aspect of the functionality. While MS is generally pretty good about not blowing your functionality out of the water, it isn't unheard of and it is best to find that in the QA environment or test environment versus production. Further, IMO, anyone who allows auto updates to servers, especially servers with truly critical business functions should NEVER autoupdate for ANYTHING. Everything should be manually pushed after it is fully tested and known to be good and that way you can watch over the server as it updates and reboots or continues on its ways. If after doing 20 or 30 servers of one type and they are going well, you can lighten up a little and mass blast them to the same type of servers but anything else is a bit reckless in my opinion. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, August 12, 2005 4:30 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] My endless question day continued- Exchange attri butes Rick, Thanks for the response and of course you're right. The difficulty though lies with the complexity you refer to. Case in point Exchange Resource Forests. There's a lack of detailed documentation on the MS site. I've been looking at a dual forest solution with an E2k3 forest having an external trust to an account forest and I'm trying to establish what functionality, if any, Exchange-wise, is lost (compared to a normal single forest deployment). I know it's not a particularly common deployment scenario (unless maybe MCS are involved) and that this is an AD group ;-)... but I suspect, short of building a PoC environment or answers from the group, finding out things like mailbox delegation...whether FE/BE topology works etc, means test test test :-) Mylo Rick Kingslan wrote: Mylo, I'll answer this, and when joe gets back online later, I'm sure that he'll correct me. j/k joe! In my mind, you have two choices - a secure and workable solution with separation with a potential of added complexity, or a much less secure, combined environment. I have a saying that goes with this: Security != Easy, or Security and ease of use are diametrically opposed Everyone has to make decisions based upon what their sensitivity to risk is. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, August 12, 2005 11:55 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] My endless question day continued- Exchange attri butes Apologies for jumping into a semi-dead thread with some OT questions .. Joe, you mentioned the following: Exchange never would have been brought into the main production forest, it would have been in a dedicated single domain resource forest that was entirely managed by the Exchange admins. Are you saying that the Resource (Exchange) Forest is the only workable solution in your mind that provides the necessary separation? I can see it from the whole service autonomy and isolation argument, but the fact that you need to throw provisioning into the equation, issues such as potential single points of failure with MIIS/IIFP, added complexity etc surely that single AD forest/domain is more preferable :-) Cheers, Mylo joe wrote: In my last job we sort of did. I say sort of because you get the point where you are going against AD best practices in how many ACEs you are sticking in the directory. The mechanisms we were thinking about to get around some of the issues such as modifying property sets had PSS looking at us and shaking
Re: [ActiveDir] My endless question day continued- Exchange attri butes
Apologies for jumping into a semi-dead thread with some OT questions .. Joe, you mentioned the following: Exchange never would have been brought into the main production forest, it would have been in a dedicated single domain resource forest that was entirely managed by the Exchange admins. Are you saying that the Resource (Exchange) Forest is the only workable solution in your mind that provides the necessary separation? I can see it from the whole service autonomy and isolation argument, but the fact that you need to throw provisioning into the equation, issues such as potential single points of failure with MIIS/IIFP, added complexity etc surely that single AD forest/domain is more preferable :-) Cheers, Mylo joe wrote: In my last job we sort of did. I say sort of because you get the point where you are going against AD best practices in how many ACEs you are sticking in the directory. The mechanisms we were thinking about to get around some of the issues such as modifying property sets had PSS looking at us and shaking their heads indicating that doing so could certainly impact their thoughts on how supportable we were. Basically we granted I think one property set and a few more attributes to the Exchange Service Admins but didn't do any of the denies to remove some property set rights they shouldn't have had, say like ability to modify UPNs etc. The specific details are lost to me now on what exactly we did but I wasn't thrilled with the options. If I had it all over to do again for that company, Exchange never would have been brought into the main production forest, it would have been in a dedicated single domain resource forest that was entirely managed by the Exchange admins. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rascher, Raymond Sent: Friday, July 15, 2005 7:41 PM To: 'ActiveDir@mail.activedir.org' Subject: RE: [ActiveDir] My endless question day continued- Exchange attri butes Did you implement a Split permissions model for exchange? If so I would like to hear how you ACL'd the directory. Also, if anyone has experience creating and using permission sets and can point me in the right direction that would be appreciated. Thanks, Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, July 15, 2005 6:12 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] My endless question day continued- Exchange attributes Strictly according to Microsoft, Full Mailbox access given to a user should NOT give the ability to send a message as that user. However, this has been broken I think more than it has worked; broken meaning users with Full Mailbox access on a mailbox but not Send As rights can send as that user. I don't even recall right now if the latest functionality in E2K3 is broken or it works. I think it is actually broken but it depends on HOW you try to send the email. I do know that it has flipped back and forth. Receive as from everything I have seen is ONLY used in the config container. When applied to a user object in the domain partition it doesn't seem to impart anything. I could easily be wrong, but that has been my experience. Permissions written to the config partition can impact an entire DB, an entire store, an entire server, an entire SG, or an entire AG, or all of Exchange, it really depends on what level you put it. You certainly can't set user level perms there. The perms set in the config are the ones you see that show inherited when you look at the actual mailbox permissions. Again when modifying the ACL on a mailbox in the supported way (i.e. through mailboxrights), you have to understand that if the mailbox is instantiated, you are actually writing permissions to the store via MAPI. These are then later shipped out and stamped on the msExchMailboxSecurityDescriptor. If the mailbox isn't instantiated, then you will be writing to the AD attribute directly and you will quickly notice that no inherited permissions are listed, it should be, and it has been a bit since I looked, simply SELF with access on the ACL. Permissions for Exchange are extremely convoluted and weird to say the least. nTSecurityDescriptor permissions applied to config Exchange service objects come into play, permissions in msExchMailboxSecurityDescriptor come into play, permissions set in the store for the mailbox itself come into play, MAPI properties which are actually just fields in the mailbox pretend to be permissions (or roles) and come into play at the calendar and other folder level, and even permissions set on the nTSecurityDescriptor attribute of the user objects comes into play. Specifically in the last case is Send As which is the permission for someone to send a message as someone and have it look like it came directly from the person. It doesn't stop there though, you also have publicDelegates attribute which grants permissions to Send
RE: [ActiveDir] My endless question day continued- Exchange attri butes
If this is something that you find of interest, I can look around and see if I can find either public docs that might be a little buried, or docs that can be sanitized and released to you. We've done numerous TechEd presentations on this - more in the 2000 - 2002 timeframe, IIRC. So, I know that the docs exist - many times, it's finding it. Rick [MCS] ;o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, August 12, 2005 3:30 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] My endless question day continued- Exchange attri butes Rick, Thanks for the response and of course you're right. The difficulty though lies with the complexity you refer to. Case in point Exchange Resource Forests. There's a lack of detailed documentation on the MS site. I've been looking at a dual forest solution with an E2k3 forest having an external trust to an account forest and I'm trying to establish what functionality, if any, Exchange-wise, is lost (compared to a normal single forest deployment). I know it's not a particularly common deployment scenario (unless maybe MCS are involved) and that this is an AD group ;-)... but I suspect, short of building a PoC environment or answers from the group, finding out things like mailbox delegation...whether FE/BE topology works etc, means test test test :-) Mylo Rick Kingslan wrote: Mylo, I'll answer this, and when joe gets back online later, I'm sure that he'll correct me. j/k joe! In my mind, you have two choices - a secure and workable solution with separation with a potential of added complexity, or a much less secure, combined environment. I have a saying that goes with this: Security != Easy, or Security and ease of use are diametrically opposed Everyone has to make decisions based upon what their sensitivity to risk is. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, August 12, 2005 11:55 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] My endless question day continued- Exchange attri butes Apologies for jumping into a semi-dead thread with some OT questions .. Joe, you mentioned the following: Exchange never would have been brought into the main production forest, it would have been in a dedicated single domain resource forest that was entirely managed by the Exchange admins. Are you saying that the Resource (Exchange) Forest is the only workable solution in your mind that provides the necessary separation? I can see it from the whole service autonomy and isolation argument, but the fact that you need to throw provisioning into the equation, issues such as potential single points of failure with MIIS/IIFP, added complexity etc surely that single AD forest/domain is more preferable :-) Cheers, Mylo joe wrote: In my last job we sort of did. I say sort of because you get the point where you are going against AD best practices in how many ACEs you are sticking in the directory. The mechanisms we were thinking about to get around some of the issues such as modifying property sets had PSS looking at us and shaking their heads indicating that doing so could certainly impact their thoughts on how supportable we were. Basically we granted I think one property set and a few more attributes to the Exchange Service Admins but didn't do any of the denies to remove some property set rights they shouldn't have had, say like ability to modify UPNs etc. The specific details are lost to me now on what exactly we did but I wasn't thrilled with the options. If I had it all over to do again for that company, Exchange never would have been brought into the main production forest, it would have been in a dedicated single domain resource forest that was entirely managed by the Exchange admins. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rascher, Raymond Sent: Friday, July 15, 2005 7:41 PM To: 'ActiveDir@mail.activedir.org' Subject: RE: [ActiveDir] My endless question day continued- Exchange attri butes Did you implement a Split permissions model for exchange? If so I would like to hear how you ACL'd the directory. Also, if anyone has experience creating and using permission sets and can point me in the right direction that would be appreciated. Thanks, Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, July 15, 2005 6:12 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] My endless question day continued- Exchange attributes Strictly according to Microsoft, Full Mailbox access given to a user should NOT give the ability to send a message as that user. However, this has been broken I think more than it has worked; broken meaning users with Full Mailbox access on a mailbox but not Send As rights can send as that user
RE: [ActiveDir] My endless question day continued- Exchange attri butes
Did you implement a Split permissions model for exchange? If so I would like to hear how you ACL'd the directory. Also, if anyone has experience creating and using permission sets and can point me in the right direction that would be appreciated. Thanks, Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, July 15, 2005 6:12 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] My endless question day continued- Exchange attributes Strictly according to Microsoft, Full Mailbox access given to a user should NOT give the ability to send a message as that user. However, this has been broken I think more than it has worked; broken meaning users with Full Mailbox access on a mailbox but not Send As rights can send as that user. I don't even recall right now if the latest functionality in E2K3 is broken or it works. I think it is actually broken but it depends on HOW you try to send the email. I do know that it has flipped back and forth. Receive as from everything I have seen is ONLY used in the config container. When applied to a user object in the domain partition it doesn't seem to impart anything. I could easily be wrong, but that has been my experience. Permissions written to the config partition can impact an entire DB, an entire store, an entire server, an entire SG, or an entire AG, or all of Exchange, it really depends on what level you put it. You certainly can't set user level perms there. The perms set in the config are the ones you see that show inherited when you look at the actual mailbox permissions. Again when modifying the ACL on a mailbox in the supported way (i.e. through mailboxrights), you have to understand that if the mailbox is instantiated, you are actually writing permissions to the store via MAPI. These are then later shipped out and stamped on the msExchMailboxSecurityDescriptor. If the mailbox isn't instantiated, then you will be writing to the AD attribute directly and you will quickly notice that no inherited permissions are listed, it should be, and it has been a bit since I looked, simply SELF with access on the ACL. Permissions for Exchange are extremely convoluted and weird to say the least. nTSecurityDescriptor permissions applied to config Exchange service objects come into play, permissions in msExchMailboxSecurityDescriptor come into play, permissions set in the store for the mailbox itself come into play, MAPI properties which are actually just fields in the mailbox pretend to be permissions (or roles) and come into play at the calendar and other folder level, and even permissions set on the nTSecurityDescriptor attribute of the user objects comes into play. Specifically in the last case is Send As which is the permission for someone to send a message as someone and have it look like it came directly from the person. It doesn't stop there though, you also have publicDelegates attribute which grants permissions to Send On Behalf of someone else. You also have basically a hack to allow for hidden membership on DLs. There are other things. Every time I dig more into Exchange I tend to bang my forehead a lot. Consquently my forehead is 8.63% (+/- .005%) flatter than it was prior to me having to worry at all about Exchange. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kern, Tom Sent: Friday, July 15, 2005 10:20 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] My endless question day continued- Exchange attributes I've read(haven't tested) in the Exchange Server Cookbook that giving Full mailbox access in ADUC on the user attrib, that doen't automatically give Send As perm. Also, excuse me for being clueless, but I always thought Receive As gave you the right to open a mailbox and view it, when set on the mailbox via ADUC? Is that wrong? When you write on the config container ACLs..., thats setting that right on the enitre store not just one mailbox. Aside from editing the msFxchMailboxSecurityDescriptor, is there any other way to modify the ACLs on just one mailbox? Thanks -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Thursday, July 14, 2005 9:19 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] My endless question day continued- Exchange attributes Receive As rights would be on the AD Object ACL, not the Exchange mailbox ACL. From what I have seen, that won't do anything for you. The only place I have seen Receive As do anything is when it is in combination with Send As on the config container ACLs for Exchange and then the pair are converted to Full Mailbox rights inside of the store. If you set permissions on an non-instantiated mailbox again, the permissions are set on the msExchMailboxSecurityDescriptor attribute. That is supposed to be used for setting up the initial store permissions, HOWEVER, I have seen this work pretty flakey through the years so I have gotten in the habit of
RE: [ActiveDir] My endless question day continued- Exchange attri butes
In my last job we sort of did. I say sort of because you get the point where you are going against AD best practices in how many ACEs you are sticking in the directory. The mechanisms we were thinking about to get around some of the issues such as modifying property sets had PSS looking at us and shaking their heads indicating that doing so could certainly impact their thoughts on how supportable we were. Basically we granted I think one property set and a few more attributes to the Exchange Service Admins but didn't do any of the denies to remove some property set rights they shouldn't have had, say like ability to modify UPNs etc. The specific details are lost to me now on what exactly we did but I wasn't thrilled with the options. If I had it all over to do again for that company, Exchange never would have been brought into the main production forest, it would have been in a dedicated single domain resource forest that was entirely managed by the Exchange admins. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rascher, Raymond Sent: Friday, July 15, 2005 7:41 PM To: 'ActiveDir@mail.activedir.org' Subject: RE: [ActiveDir] My endless question day continued- Exchange attri butes Did you implement a Split permissions model for exchange? If so I would like to hear how you ACL'd the directory. Also, if anyone has experience creating and using permission sets and can point me in the right direction that would be appreciated. Thanks, Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, July 15, 2005 6:12 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] My endless question day continued- Exchange attributes Strictly according to Microsoft, Full Mailbox access given to a user should NOT give the ability to send a message as that user. However, this has been broken I think more than it has worked; broken meaning users with Full Mailbox access on a mailbox but not Send As rights can send as that user. I don't even recall right now if the latest functionality in E2K3 is broken or it works. I think it is actually broken but it depends on HOW you try to send the email. I do know that it has flipped back and forth. Receive as from everything I have seen is ONLY used in the config container. When applied to a user object in the domain partition it doesn't seem to impart anything. I could easily be wrong, but that has been my experience. Permissions written to the config partition can impact an entire DB, an entire store, an entire server, an entire SG, or an entire AG, or all of Exchange, it really depends on what level you put it. You certainly can't set user level perms there. The perms set in the config are the ones you see that show inherited when you look at the actual mailbox permissions. Again when modifying the ACL on a mailbox in the supported way (i.e. through mailboxrights), you have to understand that if the mailbox is instantiated, you are actually writing permissions to the store via MAPI. These are then later shipped out and stamped on the msExchMailboxSecurityDescriptor. If the mailbox isn't instantiated, then you will be writing to the AD attribute directly and you will quickly notice that no inherited permissions are listed, it should be, and it has been a bit since I looked, simply SELF with access on the ACL. Permissions for Exchange are extremely convoluted and weird to say the least. nTSecurityDescriptor permissions applied to config Exchange service objects come into play, permissions in msExchMailboxSecurityDescriptor come into play, permissions set in the store for the mailbox itself come into play, MAPI properties which are actually just fields in the mailbox pretend to be permissions (or roles) and come into play at the calendar and other folder level, and even permissions set on the nTSecurityDescriptor attribute of the user objects comes into play. Specifically in the last case is Send As which is the permission for someone to send a message as someone and have it look like it came directly from the person. It doesn't stop there though, you also have publicDelegates attribute which grants permissions to Send On Behalf of someone else. You also have basically a hack to allow for hidden membership on DLs. There are other things. Every time I dig more into Exchange I tend to bang my forehead a lot. Consquently my forehead is 8.63% (+/- .005%) flatter than it was prior to me having to worry at all about Exchange. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kern, Tom Sent: Friday, July 15, 2005 10:20 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] My endless question day continued- Exchange attributes I've read(haven't tested) in the Exchange Server Cookbook that giving Full mailbox access in ADUC on the user attrib, that doen't automatically give Send As perm. Also, excuse me
