Re: adminDSholder being over zealous!

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

From: "Rabbit" <rabbit@the.hutch>
Date: Sun, 19 Jan 2003 16:24:48 -0000

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