Re: adminDSholder being over zealous!

From: Rabbit (rabbit@the.thutch)
Date: 01/23/03 

From: "Rabbit" <rabbit@the.thutch>
Date: 23 Jan 2003 04:48:54 -0600

Interesting - this has only appeared in the last week or so (judging by the
date).

As stated previously, it doesn't include the whole story as it doesn't mention
Server Operators etc. But at least there's some confirmation there...

Cheers for the help - just gotta figure out how to work with it now...

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote:
>OK I have chased it down. The functionality was changed in KB327709
>
>http://support.microsoft.com/?kbid=327709
>
>All of the fixes you list are after that prima cause "fix" so they would
all
>have the same fix "in them" if the same files or some of the same files
were
>updated. Most likely lsass.exe was updated in all of these.
>
>
>Windows 2000 Account Operators Can Manage Their Own Accounts (327709)
>
>----------------------------------------------------------------------------
>
>----
>
>The information in this article applies to:
>
>
>
>Microsoft Windows 2000 Professional SP1
>
>Microsoft Windows 2000 Professional SP2
>
>Microsoft Windows 2000 Professional SP3
>
>Microsoft Windows 2000 Server SP1
>
>Microsoft Windows 2000 Server SP2
>
>Microsoft Windows 2000 Server SP3
>
>Microsoft Windows 2000 Advanced Server SP1
>
>Microsoft Windows 2000 Advanced Server SP2
>
>Microsoft Windows 2000 Advanced Server SP3
>
>----------------------------------------------------------------------------
>
>----
>
>SYMPTOMS
>
>In Windows 2000, account operators can manage their own accounts or the
>
>accounts of other account operators. In Windows NT 4.0, account operators
>
>cannot do this.
>
>CAUSE
>
>Windows 2000 does not protect members of the Account Operators group from
>
>modifying their own account or the accounts of other account operators.
>
>RESOLUTION
>
>A supported fix is now available from Microsoft, but it is only intended
to
>
>correct the problem that is described in this article. Apply it only to
>
>computers that are experiencing this specific problem. This fix may receive
>
>additional testing. Therefore, if you are not severely affected by this
>
>problem, Microsoft recommends that you wait for the next Windows 2000
>
>service pack that contains this fix.
>
>To resolve this problem immediately, contact Microsoft Product Support
>
>Services to obtain the fix. For a complete list of Microsoft Product Support
>
>Services phone numbers and information about support costs, visit the
>
>following Microsoft Web site:
>
>http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS
>
>NOTE: In special cases, charges that are ordinarily incurred for support
>
>calls may be canceled if a Microsoft Support Professional determines that
a
>
>specific update will resolve your problem. The typical support costs will
>
>apply to additional support questions and issues that do not qualify for
the
>
>specific update in question.
>
>The English version of this fix has the file attributes (or later) that
are
>
>listed in the following table. The dates and times for these files are
>
>listed in coordinated universal time (UTC). When you view the file
>
>information, it is converted to local time. To find the difference between
>
>UTC and local time, use the Time Zone tab in the Date and Time tool in
>
>Control Panel.
>
>Date Time Version Size File name
>
>--------------------------------------------------------
>
>05-Sep-2002 14:47 5.0.2195.5781 123,664 Adsldp.dll
>
>05-Sep-2002 14:47 5.0.2195.5781 131,344 Adsldpc.dll
>
>05-Sep-2002 14:47 5.0.2195.5781 62,736 Adsmsext.dll
>
>05-Sep-2002 14:47 5.0.2195.6033 358,160 Advapi32.dll
>
>05-Sep-2002 14:47 5.0.2195.5855 49,424 Browser.dll
>
>05-Sep-2002 14:47 5.0.2195.6012 135,952 Dnsapi.dll
>
>05-Sep-2002 14:47 5.0.2195.6012 96,016 Dnsrslvr.dll
>
>05-Sep-2002 14:47 5.0.2195.5722 45,328 Eventlog.dll
>
>05-Sep-2002 14:47 5.0.2195.6048 146,704 Kdcsvc.dll
>
>05-Sep-2002 14:18 5.0.2195.6048 200,976 Kerberos.dll
>
>21-Aug-2002 05:27 5.0.2195.6023 71,248 Ksecdd.sys
>
>22-Jul-2002 12:54 5.0.2195.5960 507,152 lsasrv.dll
>
>22-Jul-2002 12:54 5.0.2195.5960 33,552 lsass.exe
>
>27-Aug-2002 11:53 5.0.2195.6034 108,816 Msv1_0.dll
>
>05-Sep-2002 14:47 5.0.2195.5979 307,472 Netapi32.dll
>
>05-Sep-2002 14:47 5.0.2195.5966 360,720 Netlogon.dll
>
>05-Sep-2002 14:47 5.0.2195.6048 918,800 Ntdsa.dll
>
>05-Sep-2002 14:47 5.0.2195.6025 389,392 Samsrv.dll
>
>05-Sep-2002 14:47 5.0.2195.5951 129,296 Scecli.dll
>
>05-Sep-2002 14:47 5.0.2195.5951 302,864 Scesrv.dll
>
>05-Sep-2002 14:47 5.0.2195.5859 48,912 W32time.dll
>
>04-Jun-2002 10:32 5.0.2195.5859 57,104 W32tm.exe
>
>05-Sep-2002 14:47 5.0.2195.6043 125,712 Wldap32.dll
>
>
>
>
>WORKAROUND
>
>To work around this problem, follow these steps:
>
>Change the access control list (ACL) settings for the Account Operators
>
>group to prevent account operators from modifying group membership. To do
>
>this, follow these steps:
>
>Log on as a member of the Administrators group.
>
>Start the Active Directory Users and Computers snap-in (dsa.msc).
>
>On the View menu, click Advanced Features.
>
>Under the Builtin container for the domain, right-click the Account
>
>Operators object, and then click Properties.
>
>Click the Security tab in Account Operators Properties, select the Account
>
>Operators group, and then click Remove.
>
>Prevent account operators from modifying the attributes of other account
>
>operators. To do this, follow these steps:
>
>In the Active Directory Users and Computers snap-in, right-click the
>
>container for the domain (for example, ACME.COM) , point to New, and then
>
>click Organizational Unit. Name the new organizational unit AcctOps.
>
>Right-click the AcctOps organizational unit, and then click Properties.
>
>In AcctOps Properties, click the Security tab, select the Account Operators
>
>group, and then click to select the Deny check box next to the Full Control
>
>permission.
>
>If you want to apply the same restrictions to members of the Print Operators
>
>group, on the Security tab, select the Account Operators group, and then
>
>click to select the Deny check box next to the Full Control permission.
>
>Move all users who are members of the Account Operators group into the new
>
>AcctOps organizational unit. To move a user, right-click the user object
>
>that you want, click Move, and then select the AcctOps organizational unit.
>
>STATUS
>
>Microsoft has confirmed that this is a problem in the Microsoft products
>
>that are listed at the beginning of this article.
>
>MORE INFORMATION
>
>The hotfix that is described in this article makes the following changes:
>
>One time per hour, the Windows 2000 primary domain controller (PDC) compares
>
>the ACL for the user accounts that are in protected groups (for example,
>
>Administrators or Account Operators ) to the ACL for the AdminSDHolder
>
>object. If the ACLs do not match, the security settings for the
>
>AdminSDHolder object overwrite the ACL and turn off ACL inheritance for
the
>
>user object. This prevents an unauthorized user from modifying user accounts
>
>if the accounts are moved to a container or organizational unit in which
the
>
>unauthorized user has the right to modify user accounts.
>
>When you remove a user from a protected group, the user account retains
the
>
>settings that it received from the AdminSDHolder object, and you must
>
>manually change the security settings for that user.
>
>Note: After you apply the hotfix, you must wait as long as one hour for
the
>
>security descriptors to be updated for existing members of the Account
>
>Operators group.
>
>For additional information about Windows 2000 security settings, click the
>
>following article number to view the article in the Microsoft Knowledge
>
>Base:
>
>217050 Description of Default Security Settings in Windows 2000
>
>For additional information about account operators access rights, click
the
>
>following article number to view the article in the Microsoft Knowledge
>
>Base:
>
>245174 Members of Account Operators Group Cannot Manage All User Accounts
>
>For additional information about how to obtain a hotfix for Windows 2000
>
>Datacenter Server, click the article number below to view the article in
the
>
>Microsoft Knowledge Base:
>
>265173 The Datacenter Program and Windows 2000 Datacenter Server Product
>
>For additional information about how to install multiple hotfixes with only
>
>one reboot, click the following article number to view the article in the
>
>Microsoft Knowledge Base:
>
>296861 Use QChain.exe to Install Multiple Hotfixes with Only One Reboot
>
>
>
>----------------------------------------------------------------------------
>
>----
>
>
>--
>Joe Richards
>www.joeware.net
>---
>
>"Rabbit" <rabbit@the.hutch> wrote in message
>news:AjAW9.1115$yV1.6225@newsfep4-gui.server.ntli.net...
>> The ones we know of are:
>>
>> 327825
>> 327536
>> 329420
>>
>> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
>> news:OP7n758vCHA.2916@TK2MSFTNGP09...
>> > If you could give me the fix numbers I will look into them.
>> >
>> > --
>> > Joe Richards
>> > www.joeware.net
>> > ---
>> >
>> > "Rabbit" <rabbit@the.hutch> wrote in message
>> > news:xzvW9.1014$yV1.5494@newsfep4-gui.server.ntli.net...
>> > > The fix doesn't but it includes DLLs that affect this behaviour that
>> have
>> > > been pulled forward from SP4. There are at least three pre-SP4 fixes
>> that
>> > > cause this behaviour that we're aware of...and none of 'em have
>anything
>> > to
>> > > do with adminSDHolder.
>> > >
>> > > "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
>> > > news:efBxz7wvCHA.1132@TK2MSFTNGP12...
>> > > > Interesting, I will have to test that. That fix shouldn't have
>> anything
>> > to
>> > > > do with AdminSDHolder...
>> > > >
>> > > > --
>> > > > Joe Richards
>> > > > www.joeware.net
>> > > > ---
>> > > >
>> > > > "Rabbit" <rabbit@the.hutch> wrote in message
>> > > > news:OI%U9.127$E_3.1558@newsfep4-gui.server.ntli.net...
>> > > > > 327825 does it - or other Pre-SP4 hotfixes. This apparently is
>> going
>> > to
>> > > > be
>> > > > > the behaviour in SP4...
>> > > > >
>> > > > > "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
>> > > > > news:uTKlZ7YuCHA.2124@TK2MSFTNGP12...
>> > > > > > What hotfixes?
>> > > > > >
>> > > > > > --
>> > > > > > Joe Richards
>> > > > > > www.joeware.net
>> > > > > > ---
>> > > > > >
>> > > > > > "Rabbit" <rabbit@the.hutch> wrote in message
>> > > > > > news:01%S9.3462$yi6.78052@newsfep1-gui.server.ntli.net...
>> > > > > > > Tried that - it just comes back on the next run. We've moved
>on
>> > > > > somewhat
>> > > > > > > since previously - the admincount value is also set as 1 on
>the
>> > > actual
>> > > > > > GROUP
>> > > > > > > object as well and clearing that doesn't work either. We've
>> found
>> > > > that
>> > > > > > the
>> > > > > > > problem also exists on the parallel test domain and have
>strong
>> > > > > suspicions
>> > > > > > > (in test at the moment) with regard to two hotfixes that are
>in
>> > > place
>> > > > on
>> > > > > > > these domains, but not on any others, one of which has caused
>> > > problems
>> > > > > in
>> > > > > > > the past. But that's another story...
>> > > > > > >
>> > > > > > > Thanks for your help and suggestions, though...
>> > > > > > >
>> > > > > > > "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in
>message
>> > > > > > > news:ejERKXttCHA.1848@TK2MSFTNGP09...
>> > > > > > > > I don't know why it is happening but note that admincount
is
>> set
>> > > to
>> > > > > 1...
>> > > > > > > > That means the account is supposed to be using the
>> AdminSDHolder
>> > > > ACL.
>> > > > > > > >
>> > > > > > > > >adminCount: 1
>> > > > > > > >
>> > > > > > > > Clear that value with script or ADSIEDIT and fix the ACL
and
>> it
>> > > > should
>> > > > > > > > remain.
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > ---
>> > > > > > > > Joe Richards
>> > > > > > > > www.joeware.net
>> > > > > > > > ---
>> > > > > > > > "rabbit" <rabbit@the.hutch> wrote in message
>> > > > > > > > news:01eb01c2b576$88be81b0$8af82ecf@TK2MSFTNGXA03...
>> > > > > > > > > Also seems to be happening now with Account Operators
>> > > > > > > > > group - sure this wasn't the case last week!
>> > > > > > > > >
>> > > > > > > > > Here's the info (this is after adminSDholder has run):
>> > > > > > > > >
>> > > > > > > > > E:\Support>adfind -b cn=users,dc=xxx,dc=yy,dc=zzz,dc=qqq
-
>> > > > > > > > > f name="t-warren.test5"
>> > > > > > > > >
>> > > > > > > > > AdFind V01.09.00cpp Joe Richards (joe@joeware.net)
>> > > > > > > > > December 2002
>> > > > > > > > >
>> > > > > > > > > Using server: <pdc role holder>.xxx.yyy.zzz.qqq
>> > > > > > > > >
>> > > > > > > > > dn:CN=t-warren.test5,CN=Users,DC=xxx,DC=yy,DC=zzz,DC=qqq
>> > > > > > > > > >memberOf: CN=Print
>> > > > > > > > > Operators,CN=Builtin,DC=xxx,DC=yy,DC=zzz,DC=qqq
>> > > > > > > > > >accountExpires: 9223372036854775807
>> > > > > > > > > >adminCount: 1
>> > > > > > > > > >badPasswordTime: 0
>> > > > > > > > > >badPwdCount: 0
>> > > > > > > > > >codePage: 0
>> > > > > > > > > >cn: t-warren.test5
>> > > > > > > > > >countryCode: 0
>> > > > > > > > > >displayName: t-warren.test5
>> > > > > > > > > >givenName: t-warren.test5
>> > > > > > > > > >instanceType: 4
>> > > > > > > > > >lastLogoff: 0
>> > > > > > > > > >lastLogon: 0
>> > > > > > > > > >logonCount: 0
>> > > > > > > > > >distinguishedName: CN=t-
>> > > > > > > > > warren.test5,CN=Users,DC=xxx,DC=yy,DC=zzz,DC=qqq
>> > > > > > > > > >objectCategory:
>> > > > > > > > > CN=Person,CN=Schema,CN=Configuration,DC=aaa,DC=bbb
>> > > > > > > > > pany,DC=co,DC=uk
>> > > > > > > > > >objectClass: top
>> > > > > > > > > >objectClass: person
>> > > > > > > > > >objectClass: organizationalPerson
>> > > > > > > > > >objectClass: user
>> > > > > > > > > >objectGUID: {527C46C0-5009-44D0-8FD9-8D37E3BC0BF0}
>> > > > > > > > > >objectSid: S-1-5-21-436374069-1637723038-725345543-3744
>> > > > > > > > > >primaryGroupID: 513
>> > > > > > > > > >pwdLastSet: 126863207433690294
>> > > > > > > > > >name: t-warren.test5
>> > > > > > > > > >sAMAccountName: t-warren.test5
>> > > > > > > > > >sAMAccountType: 805306368
>> > > > > > > > > >userAccountControl: 512
>> > > > > > > > > >userPrincipalName: t-warren.test5@yyy.com
>> > > > > > > > > >uSNChanged: 1464151
>> > > > > > > > > >uSNCreated: 1463856
>> > > > > > > > > >whenChanged: 20030106104452.0Z
>> > > > > > > > > >whenCreated: 20030106095903.0Z
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > 1 Objects returned
>> > > > > > > > >
>> > > > > > > > > E:\Support>dsacls cn=t-
>> > > > > > > > > warren.test5,cn=users,DC=xxx,DC=yy,DC=zzz,DC=qqq
>> > > > > > > > > Access list:
>> > > > > > > > > {This object is protected from inheriting permissions
>> > > > > > > > > from the parent}
>> > > > > > > > > Effective Permissions on this object are:
>> > > > > > > > > Allow BUILTIN\Administrators SPECIAL
>> > > > > > > > > ACCESS
>> > > > > > > > > DELETE
>> > > > > > > > > READ
>> > > > > > > > > PERMISSONS
>> > > > > > > > > WRITE
>> > > > > > > > > PERMISSIONS
>> > > > > > > > > CHANGE
>> > > > > > > > > OWNERSHIP
>> > > > > > > > > CREATE
>> > > > > > > > > CHILD
>> > > > > > > > > DELETE
>> > > > > > > > > CHILD
>> > > > > > > > > LIST
>> > > > > > > > > CONTENTS
>> > > > > > > > > WRITE
>> > > > > > > > > SELF
>> > > > > > > > > WRITE
>> > > > > > > > > PROPERTY
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > LIST
>> > > > > > > > > OBJECT
>> > > > > > > > > CONTROL
>> > > > > > > > > ACCESS
>> > > > > > > > > Allow NT AUTHORITY\Authenticated Users SPECIAL
>> > > > > > > > > ACCESS
>> > > > > > > > > READ
>> > > > > > > > > PERMISSONS
>> > > > > > > > > LIST
>> > > > > > > > > CONTENTS
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > LIST
>> > > > > > > > > OBJECT
>> > > > > > > > > Allow xxx\Domain Admins SPECIAL
>> > > > > > > > > ACCESS
>> > > > > > > > > READ
>> > > > > > > > > PERMISSONS
>> > > > > > > > > WRITE
>> > > > > > > > > PERMISSIONS
>> > > > > > > > > CHANGE
>> > > > > > > > > OWNERSHIP
>> > > > > > > > > CREATE
>> > > > > > > > > CHILD
>> > > > > > > > > DELETE
>> > > > > > > > > CHILD
>> > > > > > > > > LIST
>> > > > > > > > > CONTENTS
>> > > > > > > > > WRITE
>> > > > > > > > > SELF
>> > > > > > > > > WRITE
>> > > > > > > > > PROPERTY
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > LIST
>> > > > > > > > > OBJECT
>> > > > > > > > > CONTROL
>> > > > > > > > > ACCESS
>> > > > > > > > > Allow aaa\Enterprise Admins SPECIAL
>> > > > > > > > > ACCESS
>> > > > > > > > > READ
>> > > > > > > > > PERMISSONS
>> > > > > > > > > WRITE
>> > > > > > > > > PERMISSIONS
>> > > > > > > > > CHANGE
>> > > > > > > > > OWNERSHIP
>> > > > > > > > > CREATE
>> > > > > > > > > CHILD
>> > > > > > > > > DELETE
>> > > > > > > > > CHILD
>> > > > > > > > > LIST
>> > > > > > > > > CONTENTS
>> > > > > > > > > WRITE
>> > > > > > > > > SELF
>> > > > > > > > > WRITE
>> > > > > > > > > PROPERTY
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > LIST
>> > > > > > > > > OBJECT
>> > > > > > > > > CONTROL
>> > > > > > > > > ACCESS
>> > > > > > > > > Allow NT AUTHORITY\SYSTEM FULL
>> > > > > > > > > CONTROL
>> > > > > > > > > Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL
>> > > > > > > > > ACCESS
>> > > > > > > > > READ
>> > > > > > > > > PERMISSONS
>> > > > > > > > > LIST
>> > > > > > > > > CONTENTS
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > LIST
>> > > > > > > > > OBJECT
>> > > > > > > > > Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL
>> > > > > > > > > ACCESS for Remote Acce
>> > > > > > > > > ss Information
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL
>> > > > > > > > > ACCESS for General Inf
>> > > > > > > > > ormation
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL
>> > > > > > > > > ACCESS for Group Membe
>> > > > > > > > > rship
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL
>> > > > > > > > > ACCESS for Account Res
>> > > > > > > > > trictions
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > Allow BUILTIN\Pre-Windows 2000 Compatible Access SPECIAL
>> > > > > > > > > ACCESS for Logon Infor
>> > > > > > > > > mation
>> > > > > > > > > READ
>> > > > > > > > > PROPERTY
>> > > > > > > > > Allow Everyone Change
>> > > > > > > > > Password
>> > > > > > > > >
>> > > > > > > > > The command completed successfully
>> > > > > > > > > >-----Original Message-----
>> > > > > > > > > >If you could, get a dump of one of the user accounts
>> > > > > > > > > with a problem with my
>> > > > > > > > > >adfind (www.joeware.net free win32 tools) and also with
>> > > > > > > > > dsacls and post it.
>> > > > > > > > > >
>> > > > > > > > > >--
>> > > > > > > > > >Joe Richards
>> > > > > > > > > >www.joeware.net
>> > > > > > > > > >---
>> > > > > > > > > >
>> > > > > > > > > >"Rabbit" <rabbit@the.hutch> wrote in message
>> > > > > > > > > >news:TiSR9.488$Fm1.11686@newsfep1-gui.server.ntli.net...
>> > > > > > > > > >> Thanks for that - that was my thought and I will
>> > > > > > > > > verify it again.
>> > > > > > > > > >However,
>> > > > > > > > > >> the test accounts are new accounts with no AdminCount
>> > > > > > > > > >> set (checked with RepAdmin). They get secured by
>> > > > > > > > > adminSDHolder (I'll
>> > > > > > > > > >spell
>> > > > > > > > > >> it right this time!) on the first run after the
>> > > > > > > > > account is created and
>> > > > > > > > > >added
>> > > > > > > > > >> to one of the problem groups. The only group that
>> > > > > > > > > they are a member of
>> > > > > > > > > >(or
>> > > > > > > > > >> ever have been a member of) is Domain Users.
>> > > > > > > > > >>
>> > > > > > > > > >> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote
>> > > > > > > > > in message
>> > > > > > > > > >> news:emWwYhCtCHA.1628@TK2MSFTNGP10...
>> > > > > > > > > >> > Try clearing the AdminCount property of the account
>> > > > > > > > > in question that you
>> > > > > > > > > >> > don't want adminSDHolder overwriting.
>> > > > > > > > > >> >
>> > > > > > > > > >> > --
>> > > > > > > > > >> > Joe Richards
>> > > > > > > > > >> > www.joeware.net
>> > > > > > > > > >> > ---
>> > > > > > > > > >> >
>> > > > > > > > > >> > "Rabbit" <rabbit@the.hutch> wrote in message
>> > > > > > > > > >> > news:thBR9.1211$Gn6.18605@newsfep4-
>> > > > > > > > > gui.server.ntli.net...
>> > > > > > > > > >> > > Have just come across a problem with the
>> > > > > > > > > adminDSholder process which
>> > > > > > > > > >is
>> > > > > > > > > >> > > causing me some grief!
>> > > > > > > > > >> > >
>> > > > > > > > > >> > > On our production domain, if I create a new user
>> > > > > > > > > (or copy an existing
>> > > > > > > > > >> one)
>> > > > > > > > > >> > > and add it to either the Server Operators or Print
>> > > > > > > > > Operators builtin
>> > > > > > > > > >> > domain
>> > > > > > > > > >> > > group, the account becomes secured by
>> > > > > > > > > adminDSholder (I have verified
>> > > > > > > > > >> this
>> > > > > > > > > >> > to
>> > > > > > > > > >> > > be case by modifying the permission set on
>> > > > > > > > > adminDSholder and seeing it
>> > > > > > > > > >> > then
>> > > > > > > > > >> > > propogate to the test accounts), along with other
>> > > > > > > > > higher-level admin
>> > > > > > > > > >> > > accounts.
>> > > > > > > > > >> > >
>> > > > > > > > > >> > > According to the (sparse) documentation I can find
>> > > > > > > > > on this,
>> > > > > > > > > >> adminDSholder
>> > > > > > > > > >> > > only secures Administrators, Domain
>> > > > > > > > > Administrators, Enterprise
>> > > > > > > > > >> > > Administrators and Schema Admins. I've tested
>> > > > > > > > > this on a freshly-built
>> > > > > > > > > >> > test
>> > > > > > > > > >> > > domain and the securing of Server Operators and
>> > > > > > > > > Print Operators
>> > > > > > > > > >doesn't
>> > > > > > > > > >> > > occur.
>> > > > > > > > > >> > >
>> > > > > > > > > >> > > This is a big headache for us as we run a custom
>> > > > > > > > > process to secure
>> > > > > > > > > >> > 'medium'
>> > > > > > > > > >> > > level admin accounts with our own ACLs - this is
>> > > > > > > > > now being overwritten
>> > > > > > > > > >> by
>> > > > > > > > > >> > > adminDSholder every hour.
>> > > > > > > > > >> > >
>> > > > > > > > > >> > > Any ideas on why this is occuring and how we can
>> > > > > > > > > fix it...?
>> > > > > > > > > >> > >
>> > > > > > > > > >> > >
>> > > > > > > > > >> >
>> > > > > > > > > >> >
>> > > > > > > > > >>
>> > > > > > > > > >>
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >.
>> > > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
>
> 

---
Rabbit
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
   http://www.newsfeed.com       The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----