Re: Changes to ACL disappear
From: pdx (pdx_at_discussions.microsoft.com)
Date: 09/24/04
- Next message: Eric Graham: "Folder Security"
- Previous message: Manoj Menon: "Re: how to make https"
- In reply to: Tim Springston [MS]: "Re: Changes to ACL disappear"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 24 Sep 2004 09:45:03 -0700
Implementing Method 2 did allow inheritance on all "protected groups" but it
didn't stop the ACL of adminSDHolder from overwriting the ACL of anyone in
one of the protected groups (all domain users in my case due to "Domain
Users" being in "Print Operators" which is protected. As it stands now I have
weakened security and no solution to my problem.
I believe the "Domain Users" group is a member of the "Print Operators"
group by default and if this is true the method for adding "Send As" access
as described in KB 327000 is guaranteed not to work.
Is there any actual solution?
Any input on my question as to what the implications are of changing the
AdminCount attribute from 1 to 0 for administrative accounts (which the
script in KB 817433 would do)?
Is there a method available - besides re-writing the script - for changing
the AdminCount attribute on a account by account basis?
Since the KBs I have found don't seem to jibe and since weeks of searching
haven't yet located a way to successfully do what should be the simple act of
granting "Send As" access on a target account/mailbox, I'm thinking that I'll
have to remove "Domain Users" from "Print Operators" and reset the AdminCount
attribute on those accounts which are to be involved in the Send As rights
scenario.
Since, this behavior seems to be design is there a Microsoft number I can
call to open a ticket for a possible solution without paying. I definitely
shouldn't have to pay for a solution. In fact, I have devoted hours and hours
of my company's time in trying to find a way to grant a simple access right.
Thanks.
"Tim Springston [MS]" wrote:
> Sounds like method 2 would work best for your situation. Please repost if
> we can help further.
>
> --
> Tim Springston
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "pdx" <pdx@discussions.microsoft.com> wrote in message
> news:E88C9DEA-53F6-4FFA-806B-236B3A703B25@microsoft.com...
> > Thanks for the info. Since "Domain Users" in my domain are members of
> > "Print
> > Operators", a reading of KB 817433 gave me an understanding of why my ACE
> > changes are "disappearing". Every hour the entries are replaced by the ACL
> > for adminSDHolder.
> >
> > I'm still a bit unclear on a solution.
> >
> > Method 2 seems to be the way to go for me; the way I read it enabling
> > inheritance on the adminSDHolder container will stop the ACE entries from
> > being overwritten. I will no longer have inheritance protection for
> > administrative users but since I'm the only admin in my domain - and I'm
> > relatively safe from myself - this shouldn't be a problem.
> >
> > The implications of Method 1 were unclear to me. Running the ldifde
> > command
> > showed that all accounts in my domain have the AdminCount attribute set to
> > 1
> > (as the result of "Print Operators" membership ?).
> > I don't know what the implications would be for administrative/Exchange
> > service accounts to set the AdminCount to 0. Plus, I would have to remove
> > "Domain Users' from "Print Operators" for this to work. I inherited this
> > set
> > up and removing the group from Print Operators would take away access
> > users
> > have had for a long time (and add extra admin work for me). If I removed
> > Domain Users and added individual accts - or a group - to Print Operators
> > the
> > AdminCount attribute would still be set to 1 and my problem would still
> > exist
> > for the accounts in question.
> >
> > Method 3 seems to mean that I would have to - in effect - give everybody
> > "Send As" access to everyone else's mailbox.
> >
> > Sorry about the lengthy question. As far as you can see does Method 2 seem
> > to offer a solution to my problem?
> >
> >
> >
> >
> > "Tim Springston [MS]" wrote:
> >
> >> The article they provided to you may still be the culprit. There is
> >> enhanced
> >> functionality for the AdminSDHolder feature that will re-ACL based on
> >> transitive group membership in protected security groups.
> >>
> >> Here's an additional article or two regarding that:
> >>
> >> 817433 Delegated permissions are not available and inheritance is
> >> automatically
> >> http://support.microsoft.com/?id=817433
> >>
> >> 318180 AdminSDHolder Thread Affects Transitive Members of Distribution
> >> Groups
> >> http://support.microsoft.com/?id=318180
> >>
> >> Please repost if that does not help, or if you have any additional
> >> questions
> >> or concerns.
> >>
> >> --
> >> Tim Springston
> >> Microsoft Corporation
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >> "pdx" <pdx@discussions.microsoft.com> wrote in message
> >> news:D1D579EF-E1A0-47EB-ADED-7EF230FEB42D@microsoft.com...
> >> > When I use ADUC and give a user "Send As" rights in the ACL of the
> >> > target
> >> > user's account, the ACE that I added eventually disappears. I was
> >> > pointed
> >> > to
> >> > KB 232199 by someone on the Exchange 2000 newsgroup but that doesn't
> >> > seem
> >> > to
> >> > apply and running "dsacls" came back with the proper permissions.
> >> >
> >> > I need the ability to give users "Send As" rights and I'm at a loss so
> >> > any
> >> > ideas will be appreciated.
> >> >
> >> >
> >>
> >>
> >>
>
>
>
- Next message: Eric Graham: "Folder Security"
- Previous message: Manoj Menon: "Re: how to make https"
- In reply to: Tim Springston [MS]: "Re: Changes to ACL disappear"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
