Re: adminDSholder being over zealous!

From: Rabbit (rabbit@the.hutch)
Date: 01/08/03 

From: "Rabbit" <rabbit@the.hutch>
Date: Wed, 8 Jan 2003 19:31:16 -0000

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...?
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> > >.
> > >
>
>