Re: adminDSholder being over zealous!

From: Bruce Robertson (amoususer@hotmail.com)
Date: 02/20/03 

From: amoususer@hotmail.com (Bruce Robertson)
Date: 20 Feb 2003 08:46:47 -0800

Joe and Rabbit,

I have experienced the same problems, where users in members of groups
other than Administrators, Domain Admins, Enterprise Admins, and
Schema Admins are having their ACLs re-ACL'd by adminSDHolder. After
researching this for the past 2 days, I am happy to inform you that I
believe I have found the solution to the problem. Here are some
articles which helped me in my investigation:

http://support.microsoft.com/?kbid=251343

http://www.jsifaq.com/SUBK/tip5000/rh5030.htm

http://support.microsoft.com/default.aspx?scid=kb;en-us;232199

We had 3 global groups which had been delegated rights to 3 different
OUs. Our site administrators were members of these 3 groups, however
they were not a member of Administrators, Domain Admins, Enterprise
Admins, and Schema Admins. I had set the AdminCount value on these
users' accounts to 0, which means that the adminSDHolder process
should not apply to these accounts any longer. Unfortunately, I found
KB article 251343, which describes the SP Propagator Thread
(FixUpInheritance), which can be kicked off manually (see the first
link above), but also indicated that it periodically runs
automatically. When I manually kicked this process off, it reset
AdminCount to 1 for these users. I therefore concluded that changing
AdminCount was not a solution that would work for long. The
breakthrough came later, when further investigation showed that the
AdminCount value was present on the groups of which these site
administrators were a member.

My conclusion was this: The AdminCount attribute being higher than 0
tells the adminSDHolder process to overwrite the ACL (see the
JSIfaq.com link above). When the SD Propagator runs, it looks for
groups that have the AdminCount value higher than 1, and then applies
this value to the AdminCount attribute of all of that groups members.
By clearing the AdminCount value from the group, the members no longer
inherit this value. I cleared this value from the group AND the users
that had already been affected, and then kicked off the SD Propagator
Thread (FixUpInheritance process) again. This time the members
retained the <not set> blank value, and I could re-ACL the user
accounts or set them to inherit the permissions of the parent OU
without the account ACLs reverting to match AdminSDHolder.

Hope this helps. Thanks for your posts, they helped me in my
investigation as well.

Bruce Robertson
MCSE Win2K & NT4

"Rabbit" <rabbit@the.thutch> wrote in message news:<3e2fc896$1@binarykiller.newsgroups.com>...
> 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 =-----