RE: [ActiveDir] RILOE AD Integration
I was all set to introduce these Schema chaneg also, then this article from HP came out saying that the next iLO version (1.80, due mid July) has "Schema-free Active Directory Integration" -Brad From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francis OuelletSent: Wednesday, July 06, 2005 1:05 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] RILOE AD Integration Hi, I used the ADUC with our iLO setup (~50 servers)a while ago and it was flawless. The schema extensions have not caused any issues at all with any upgrades we had to do (Exchange 2003 forestprep) I highly recommend them. Francis From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian DesmondSent: July 5, 2005 8:27 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] RILOE AD Integration Anybody done the schema extensions to support HPQ iLO/RiLOE II integration with AD. Im thinking about it. Were pushing out 50 380s with RiLOE II boards in the next four weeks to all over kingdom come. If you have, hows it work from the ilo standpoint? ADUC extensions work ok? --brian This message has been scanned for viruses by MailControl This email and any attached files are confidential and copyright protected. If you are not the addressee, any dissemination of this communication is strictly prohibited. Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.
RE: [ActiveDir] RILOE AD Integration
And now for the actual link http://h18013.www1.hp.com/products/servers/management/iloadv/index.html From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francis OuelletSent: Wednesday, July 06, 2005 1:05 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] RILOE AD Integration Hi, I used the ADUC with our iLO setup (~50 servers)a while ago and it was flawless. The schema extensions have not caused any issues at all with any upgrades we had to do (Exchange 2003 forestprep) I highly recommend them. Francis From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian DesmondSent: July 5, 2005 8:27 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] RILOE AD Integration Anybody done the schema extensions to support HPQ iLO/RiLOE II integration with AD. Im thinking about it. Were pushing out 50 380s with RiLOE II boards in the next four weeks to all over kingdom come. If you have, hows it work from the ilo standpoint? ADUC extensions work ok? --brian This message has been scanned for viruses by MailControl This email and any attached files are confidential and copyright protected. If you are not the addressee, any dissemination of this communication is strictly prohibited. Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.
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 not setting permissions on mailboxes until I know they have been instantiated in the store. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kern, Tom Sent: Thursday, July 14, 2005 5:44 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] My endless question day continued- Exchange attributes If the box is not instantiated then when you edit that attribute, it doesn't get mirrored back to the mailbox in the store. That's what I've seen and read. Just trying to confirm that. So if I create a mailbox and give another user receive as rights before the first user has opened outlook or received an email, that won't be reflected on the mailbox store after he/she has had the box instantiated. Is that correct? Just curious. Thanks -- Sent from my BlackBerry Wireless Handheld (www.BlackBerry.net) List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] old DCs - alias DNS records enough?
We do that exact thing in our W2K3 environment and it works like a charm. -HTH -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thommes, Michael M. Sent: Thursday, July 14, 2005 5:53 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] old DCs - alias DNS records enough? I am getting ready to install new domain controllers (2003/SP1, same as the old). I want to put up the new DCs with a new names and IPs. We do AD-integrated DNS but a Unix server is our primary DNS. Because of various places were the name/IP of a current DC may be buried (like on Exchange servers with hardcoded GCs or on a non-AD connected TS pointed to the TS License Server, etc), some in my group are worried and think that we can get around these problems by having an alias DNS record for the old DC pointing to the new DC. My gut feeling says this is not going to work. Thoughts/comments? Mike Thommes List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] My endless question day continued- Exchange attributes
Tom, where are you heading with this? Is this just to better understand Exchange permissioning? If so, keep in mind that Exchange store does some conversions on the permissions. It's one of the reasons upgrades are such a PITA as you have to convert from 5.5 permissions structure to NT permissions structure and the store has to do it. Send As permissions is the right of the authenticated entity to Send As that mailstore owner object. Unfortunately, there is no one answer to your question. You'll notice that Microsoft has some confusion around this, at least on their public web page: http://www.microsoft.com/technet/prodtechnol/exchange/guides/WorkingE2k3Store/fe474de0-b0e4-48a0-aec1-dcd9fcb4a53c.mspx (Seems odd to try and figure out how 2003 versions work by looking at the readme files for 2000 but there you have it. ) There is some more information available here, although I haven't read it to know if your exact question has been answered in it. http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/storperm.mspx Al From: [EMAIL PROTECTED] on behalf of Kern, Tom Sent: Fri 7/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 not setting permissions on mailboxes until I know they have been instantiated in the store. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kern, Tom Sent: Thursday, July 14, 2005 5:44 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] My endless question day continued- Exchange attributes If the box is not instantiated then when you edit that attribute, it doesn't get mirrored back to the mailbox in the store. That's what I've seen and read. Just trying to confirm that. So if I create a mailbox and give another user receive as rights before the first user has opened outlook or received an email, that won't be reflected on the mailbox store after he/she has had the box instantiated. Is that correct? Just curious. Thanks -- Sent from my BlackBerry Wireless Handheld (www.BlackBerry.net) List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ winmail.dat
RE: [ActiveDir] My endless question day continued- Exchange attributes
Title: RE: [ActiveDir] My endless question day continued- Exchange attributes I had some free time and I am trying to better understand the 2 headed beast that Exchange makes when married to AD. I'm just trying to figure out how Exchange changes AD perms and how the mailstore perms relate back to the ones in AD and vice versa. I know some tricks are done like listing an "Allow" in the sd's for aDG for the Exchange Domain Servers group before a "Deny" so it can read the hidden memeberships for delivery and it got me curious about other things Exchange does to AD. Sorry. Its a little slow here right now... -Original Message-From: Al Mulnick [mailto:[EMAIL PROTECTED]On Behalf Of Al MulnickSent: Friday, July 15, 2005 3:37 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] My endless question day continued- Exchange attributes Tom, where are you heading with this? Is this just to better understand Exchange permissioning? If so, keep in mind that Exchange store does some conversions on the permissions. It's one of the reasons upgrades are such a PITA as you have to convert from 5.5 permissions structure to NT permissions structure and the store has to do it. Send As permissions is the right of the authenticated entity to Send As that mailstore owner object.Unfortunately,there is noone answer toyour question.You'll notice that Microsoft has some confusion around this, at least on their public web page: http://www.microsoft.com/technet/prodtechnol/exchange/guides/WorkingE2k3Store/fe474de0-b0e4-48a0-aec1-dcd9fcb4a53c.mspx (Seems odd to try and figure out how 2003 versions work by looking at the readme filesfor 2000 but there you have it.) There is some more information available here, although I haven't read it to know if your exact question has been answered in it. http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/storperm.mspx Al From: [EMAIL PROTECTED] on behalf of Kern, TomSent: Fri 7/15/2005 10:20 AMTo: ActiveDir@mail.activedir.orgSubject: 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 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] My endless question day continued- ExchangeattributesReceive As rights would be on the AD Object ACL, not the Exchange mailboxACL. From what I have seen, that won't do anything for you. The only place Ihave seen Receive As do anything is when it is in combination with Send Ason the config container ACLs for Exchange and then the pair are converted toFull Mailbox rights inside of the store.If you set permissions on an non-instantiated mailbox again, the permissionsare set on the msExchMailboxSecurityDescriptor attribute. That is supposedto be used for setting up the initial store permissions, HOWEVER, I haveseen this work pretty flakey through the years so I have gotten in the habitof not setting permissions on mailboxes until I know they have beeninstantiated in the store.-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]] On Behalf Of Kern, TomSent: Thursday, July 14, 2005 5:44 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] My endless question day continued- ExchangeattributesIf the box is not instantiated then when you edit that attribute, it doesn'tget mirrored back to the mailbox in the store.That's what I've seen and read.Just trying to confirm that.So if I "create" a mailbox and give another user "receive as" rights beforethe first user has opened outlook or received an email, that won't bereflected on the mailbox store after he/she has had the box instantiated.Is that correct?Just curious.Thanks--Sent from my BlackBerry Wireless Handheld (www.BlackBerry.net)List info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/List info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/List info : http://www.activedir.org/List.aspxList FAQ :
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 not setting permissions on mailboxes until I know they have been instantiated in the store. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kern, Tom Sent: Thursday, July 14, 2005 5:44 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] My endless question day continued- Exchange attributes If the box is not instantiated then when you edit that attribute, it doesn't get mirrored back to the mailbox in the store. That's what I've seen and read.
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 for
