Re: adminDSholder being over zealous!
From: Joe Richards [MVP] (humorexpress@hotmail.com)
Date: 01/08/03
- Next message: Ella Ng: "High security (password protection) for digital certificates"
- Previous message: Joe Richards [MVP]: "Re: Everyone Group"
- In reply to: rabbit: "Re: adminDSholder being over zealous!"
- Next in thread: Rabbit: "Re: adminDSholder being over zealous!"
- Reply: Rabbit: "Re: adminDSholder being over zealous!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Joe Richards [MVP]" <humorexpress@hotmail.com> Date: Wed, 8 Jan 2003 00:21:39 -0500
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...? > >> > > > >> > > > >> > > >> > > >> > >> > > > > > >. > >
- Next message: Ella Ng: "High security (password protection) for digital certificates"
- Previous message: Joe Richards [MVP]: "Re: Everyone Group"
- In reply to: rabbit: "Re: adminDSholder being over zealous!"
- Next in thread: Rabbit: "Re: adminDSholder being over zealous!"
- Reply: Rabbit: "Re: adminDSholder being over zealous!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|