joe - no need to apologize. You're absolutely correct. Once I read your
e-mail, I had doubts, but knowing joe, and knowing what joe knows, I had to
go look to satisfy my curiosity.
Honestly, what I saw scared me to a great degree. AO does have full and
complete access to any user object and property - period. AO may not be
able to manipulate it through the easy mechanisms (i.e. the GUI ADUC or the
scripted CDOEXM, but any other interface that will allow manipulation of the
objects *IS*possible - and that revelation is quite shocking, to say the
least.
For anyone that wants to duplicate what I did - make use of a resource that
is right at your finger tips. Don't go poking around your production
systems. And, even if you don't have Exchange, you can still check this
out. Make use of the TechNet Virtual Labs for checking things out and
determining if an idea will work - with no setup costs at all. Find a lab
that has the components that you need, and party on. The labs are not
restricted to allowing you to do only what the lab is designed for. You can
do practically anything you want - sometimes including adding in extra
Windows and Server System components.
Find the Virtual Servers at:
http://microsoft.demoservers.com
Thanks, joe - for calling this to my attention and correcting my 'rosy
security' view of separation of duties when it comes to Exchange. It's not
as it appears - or as many writers have written.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Friday, August 12, 2005 12:00 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] account operators
Sorry Rick, I have to correct you on this one.
An account operator absolutely has enough rights to mailbox enable a user.
AccOps by default have FC over user objects, they can do ANYTHING to a user
they want to. The key is they have to know how to. You could for instance
use admod or ldifde or adsiedit or anything that allows you to update
mailnickname and homemdb. Or for that matter mailnickname and homeMTA. Also
I think you can do mailNickname and msExchHomeServerName.
The reason an AccOp can not use ADUC or CDOEXM to mailbox enable a user is
because the tools are written to enumerate Exchange config info which an
AccOp doesn't have access to. I don't know if it was intended as a security
feature or not but it is how it works. I wouldn't be surprised if it was a
security feature because it aligns with some other silly tool bases security
MS did before like for instance being unable to view the admins group from
usermgr if you weren't an admin but if you knew other mechanisms you could
still do it... Or the GUI not listing hidden shares even though the server
sends that info back to the clients requesting the info.
<RANT>
The permissioning model of Exchange, especially in AD, quite frankly, sucks
ass. It does almost everything it can to make it a pain in the butt to
separate administration between AD/NOS stuff and Exchange stuff. Instead of
using the mail property set or creating their own they glommed onto the base
property sets. In order to do any separation you either have to change the
property sets and hear cries of unsupported from PSS or you have to put in a
ton of ACEs or a half a ton of ACEs including a bunch of denies.
Most admins haven't the foggiest clue how much access they have given away
in AD to people. I have fielded many a question on how come some admin can
send mail as someone or get access to read mail for other users or mailbox
enable users, or how can so and so change mailbox quotes, etc etc. A common
delegation in AD is to give full control over user objects or allow low
level admins to create users. This is fine (well not really fine...) in a
NOS directory, but once you add Exchange to it those folks have a lot more
power, probably unintended power, over the mail system than was probably
intended.
The best answer from a permission standpoint of protecting Exchange from AD
folks or protecting AD from Exchange folks is the dedicated Exchange
Resource Forest. If you do that and keep to a single domain in that forest
you also get away from all of the nasty DSACCESS issues to boot around user
and group updates from outlook.
</RANT>
joe
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Thursday, August 11, 2005 12:30 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] account operators
why can't they create a mailbox for a regular user?
Simply, the Account Operator is designed to work as a principal that allows
work on accounts as they are BY DEFAULT out of Windows Server.
The real reason is that there is typically, in most medium to large
organizations, there is a mail admin team and a server admin team (at least
it was VERY much this way with Exch 5.5).
Separation of the functions was a goal to carry forward - but it could only
be done by Group membership / permissions on attributes.
If you take a look at the Advanced Security properties of a user, and drill
in to the permissions granted to the AO, you're going to find that the
permission for the Exchange functions are not granted.
Rick
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern
Sent: Thursday, August 11, 2005 10:51 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] account operators
thats what i thought but then it would make sense that AO group would be
able to set that attrib on a user they have full control over.
why can't they create a mailbox for a regular user?
thanks as always, rick
On 8/11/05, Rick Kingslan <[EMAIL PROTECTED]> wrote:
No, not the store - it's a bit of a misnomer that to create a mailbox
you need to have permissions to the store.
If you can create the mailbox attributes on the user account, the
first
time
that a mail message is delivered to the newly mailbox-enabled user,
the actual storage area on the store is created.
Rick
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern
Sent: Thursday, August 11, 2005 9:57 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] account operators
I thought AO had complete rights to the user object which would
include exchange attribs.
i guess they still need rights to the store?
is that it?
thanks
On 8/11/05, Coleman, Hunter <[EMAIL PROTECTED]> wrote:
I expect they lack Exchange View Only Admin permissions (or higher).
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern
Sent: Thursday, August 11, 2005 8:27 AM
To: activedirectory
Subject: [ActiveDir] account operators
is there any reason an account operator could create a user but not
a mailbox for that user?
thanks
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/
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/
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/
