Discussion:
Account Operators accessing other account operators
(too old to reply)
Matt
2006-02-06 09:22:27 UTC
Permalink
We have a Windows 2003 (SP1) AD domain. Our helpdesk staff our acocunt
operators and they can successfully manage the company's user accounts. They
cannot access builtin accounts such as domain administrators (which I know is
by design and is what I want).

However, and this is my problem, is that they cannot reset passwords or
unlock the accounts of the other account operators. If a helpdesk staff
locks their account the other helpdesk staff cannot unlock it; and they have
to wait for me to do it (I'm a domain admin). I did read an article saying
that this was by design since Windows 2000 SP4. However this is not
particularly helpful to me.

I am being pushed to get this resolved and do not want to give them domain
admin rights. Please can anyone help.
Frederik De Muyter
2006-02-06 11:20:27 UTC
Permalink
What i would do is create a seperate OU in you domain for the Account
operators if possible and delegate the necessary right on this OU.
Create en new security group and use the delegation wizzard to delegate
necesary rights to this group. But all members that needs to reset these
accounts in this group.

Paper about delegation
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/actdid1.mspx

Hope this helps you.
Post by Matt
We have a Windows 2003 (SP1) AD domain. Our helpdesk staff our acocunt
operators and they can successfully manage the company's user accounts. They
cannot access builtin accounts such as domain administrators (which I know is
by design and is what I want).
However, and this is my problem, is that they cannot reset passwords or
unlock the accounts of the other account operators. If a helpdesk staff
locks their account the other helpdesk staff cannot unlock it; and they have
to wait for me to do it (I'm a domain admin). I did read an article saying
that this was by design since Windows 2000 SP4. However this is not
particularly helpful to me.
I am being pushed to get this resolved and do not want to give them domain
admin rights. Please can anyone help.
Joe Richards [MVP]
2006-02-10 05:40:12 UTC
Permalink
That won't work with acc ops by default.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
Post by Frederik De Muyter
What i would do is create a seperate OU in you domain for the Account
operators if possible and delegate the necessary right on this OU.
Create en new security group and use the delegation wizzard to delegate
necesary rights to this group. But all members that needs to reset these
accounts in this group.
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/actdid1.mspx
Hope this helps you.
Post by Matt
We have a Windows 2003 (SP1) AD domain. Our helpdesk staff our acocunt
operators and they can successfully manage the company's user accounts. They
cannot access builtin accounts such as domain administrators (which I know is
by design and is what I want).
However, and this is my problem, is that they cannot reset passwords or
unlock the accounts of the other account operators. If a helpdesk staff
locks their account the other helpdesk staff cannot unlock it; and they have
to wait for me to do it (I'm a domain admin). I did read an article saying
that this was by design since Windows 2000 SP4. However this is not
particularly helpful to me.
I am being pushed to get this resolved and do not want to give them domain
admin rights. Please can anyone help.
Christian Lamparth
2006-02-06 14:30:10 UTC
Permalink
Hi Matt
you can either delegate control to the OU by right click on the OU and
choose delegage or you can assign spefic admin rights to a user/group in the
default domain security settings/user rights assignment tab. good luck
Post by Matt
We have a Windows 2003 (SP1) AD domain. Our helpdesk staff our acocunt
operators and they can successfully manage the company's user accounts. They
cannot access builtin accounts such as domain administrators (which I know is
by design and is what I want).
However, and this is my problem, is that they cannot reset passwords or
unlock the accounts of the other account operators. If a helpdesk staff
locks their account the other helpdesk staff cannot unlock it; and they have
to wait for me to do it (I'm a domain admin). I did read an article saying
that this was by design since Windows 2000 SP4. However this is not
particularly helpful to me.
I am being pushed to get this resolved and do not want to give them domain
admin rights. Please can anyone help.
Joe Richards [MVP]
2006-02-10 05:40:25 UTC
Permalink
Not with acc ops.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
Post by Christian Lamparth
Hi Matt
you can either delegate control to the OU by right click on the OU and
choose delegage or you can assign spefic admin rights to a user/group in the
default domain security settings/user rights assignment tab. good luck
Post by Matt
We have a Windows 2003 (SP1) AD domain. Our helpdesk staff our acocunt
operators and they can successfully manage the company's user accounts. They
cannot access builtin accounts such as domain administrators (which I know is
by design and is what I want).
However, and this is my problem, is that they cannot reset passwords or
unlock the accounts of the other account operators. If a helpdesk staff
locks their account the other helpdesk staff cannot unlock it; and they have
to wait for me to do it (I'm a domain admin). I did read an article saying
that this was by design since Windows 2000 SP4. However this is not
particularly helpful to me.
I am being pushed to get this resolved and do not want to give them domain
admin rights. Please can anyone help.
Jorge de Almeida Pinto [MVP]
2006-02-06 21:30:57 UTC
Permalink
it is better not to use the account operators group, but to use your own
group and delegate the correct permissions on an OU that applies to the
correct objects in that OU. If you go that way, make sure to remove the
account from the account operators group as that is a protected group by AD
(to be more precise adminsdholder). after that reset the admincount
attribute to NOT SET and enable permissions inheritance on the objects.

for more info see:
http://blogs.dirteam.com/blogs/jorge/archive/2005/11/16/86.aspx

ADMINSDHOLDER:
Every hour, the Microsoft Windows domain controller that has the primary
domain controller (PDC) emulator operations master role verifies the ACLs on
members of these administrative groups and compares them to the ACL on the
AdminSDHolder object. If the ACL that is on the AdminSDHolder object is
different, the ACLs on the members of the administrative group are reset to
match the ACL on the AdminSDHolder object.

For more info on the ADMINSDHOLDER object see the following related KB
articles (not all may apply to your situation!)

Description and Update of the Active Directory AdminSDHolder Object
--> MS-KBQ232199 (http://support.microsoft.com/?id=232199)
AdminSDHolder Thread Affects Transitive Members of Distribution Groups
--> MS-KBQ318180 (http://support.microsoft.com/?id=318180)
Delegated permissions are not available and inheritance is automatically
disabled
--> MS-KBQ817433 (http://support.microsoft.com/?id=817433)
AdminSDHolder Object Affects Delegation of Control for Past Administrator
Accounts
--> MS-KBQ306398 (http://support.microsoft.com/?id=306398)
Security tab of the adminSDHolder object does not display all properties
--> MS-KBQ301188 (http://support.microsoft.com/?id=301188)
"You do not have sufficient permissions in the Domain" error message occurs
and Exchange Setup does not respond
--> MS-KBQ319966 (http://support.microsoft.com/?id=319966)
Certification Authority configuration to publish certificates in Active
Directory of trusted domain
--> MS-KBQ281271 (http://support.microsoft.com/?id=281271)
--
Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Windows Server - Directory Services

BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx
-----------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
-----------------------------------------------------------------------------


-----------------------------------------------------------------------------
Post by Matt
We have a Windows 2003 (SP1) AD domain. Our helpdesk staff our acocunt
operators and they can successfully manage the company's user accounts.
They
cannot access builtin accounts such as domain administrators (which I know is
by design and is what I want).
However, and this is my problem, is that they cannot reset passwords or
unlock the accounts of the other account operators. If a helpdesk staff
locks their account the other helpdesk staff cannot unlock it; and they have
to wait for me to do it (I'm a domain admin). I did read an article saying
that this was by design since Windows 2000 SP4. However this is not
particularly helpful to me.
I am being pushed to get this resolved and do not want to give them domain
admin rights. Please can anyone help.
Joe Richards [MVP]
2006-02-10 05:42:35 UTC
Permalink
Bingo.

and I agree, don't use acc ops. It is there for legacy NT4 migrations. Once you
are done with that you should move to fully delegated accounts where the exact
permissions needed are delegated.

In the meanwhile, in one of those articles it will tell you how to disable the
protection of adminsdholder over acc ops.

BTW, if the acc ops are bright enough, they can give themselves Domain and
Enterprise Admin rights anyway. That is why you want to use delegated accounts
for AD data admins.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
Post by Jorge de Almeida Pinto [MVP]
it is better not to use the account operators group, but to use your own
group and delegate the correct permissions on an OU that applies to the
correct objects in that OU. If you go that way, make sure to remove the
account from the account operators group as that is a protected group by AD
(to be more precise adminsdholder). after that reset the admincount
attribute to NOT SET and enable permissions inheritance on the objects.
http://blogs.dirteam.com/blogs/jorge/archive/2005/11/16/86.aspx
Every hour, the Microsoft Windows domain controller that has the primary
domain controller (PDC) emulator operations master role verifies the ACLs on
members of these administrative groups and compares them to the ACL on the
AdminSDHolder object. If the ACL that is on the AdminSDHolder object is
different, the ACLs on the members of the administrative group are reset to
match the ACL on the AdminSDHolder object.
For more info on the ADMINSDHOLDER object see the following related KB
articles (not all may apply to your situation!)
Description and Update of the Active Directory AdminSDHolder Object
--> MS-KBQ232199 (http://support.microsoft.com/?id=232199)
AdminSDHolder Thread Affects Transitive Members of Distribution Groups
--> MS-KBQ318180 (http://support.microsoft.com/?id=318180)
Delegated permissions are not available and inheritance is automatically
disabled
--> MS-KBQ817433 (http://support.microsoft.com/?id=817433)
AdminSDHolder Object Affects Delegation of Control for Past Administrator
Accounts
--> MS-KBQ306398 (http://support.microsoft.com/?id=306398)
Security tab of the adminSDHolder object does not display all properties
--> MS-KBQ301188 (http://support.microsoft.com/?id=301188)
"You do not have sufficient permissions in the Domain" error message occurs
and Exchange Setup does not respond
--> MS-KBQ319966 (http://support.microsoft.com/?id=319966)
Certification Authority configuration to publish certificates in Active
Directory of trusted domain
--> MS-KBQ281271 (http://support.microsoft.com/?id=281271)
Matt
2006-02-10 16:10:29 UTC
Permalink
Thanks for all the reponses. I will have a look at delegation when I get a
chance. Yes our helpdesk users were account operators from our NT days and
it seemed convenient. We have about five OUs at the top level and I was
hoping to avoid having to delegate permissions on each OU (tree) and the
subsequent job of managing and troubleshooting delegation.

I was interested in the comment "if the acc ops are bright enough, they can
give themselves Domain and Enterprise Admin rights anyway. That is why you
want to use delegated accounts for AD data admins." How can they do this?
They do not appear to have access to their own accounts or anything above.
Obviously I do not want them to be able to do this (although I think that I
am safe with our helpdesk) so am interested in how they can do it.

Thanks.
Cary Shultz
2006-02-10 21:24:49 UTC
Permalink
Matt,

I can almost guarantee you that JoeR is N*O*T going to post the 'How to' on
this topic. Pretty much no one will.

Not trying to be rude, but this is the type of stuff that the 'script
kiddies - or, Jr. Sys Admins' get their hands on and then wreck havoc in
their environments. And then it comes out that an MVP posted this 'How to'.
That would not be a good thing.

There are a couple of seemingly good security books on Active Directory that
would probably give you hints along the way. I say 'seemingly' becuase I
have not read them. So, I do not really know for sure.
--
Cary W. Shultz
Roanoke, VA 24012
Post by Matt
Thanks for all the reponses. I will have a look at delegation when I get a
chance. Yes our helpdesk users were account operators from our NT days and
it seemed convenient. We have about five OUs at the top level and I was
hoping to avoid having to delegate permissions on each OU (tree) and the
subsequent job of managing and troubleshooting delegation.
I was interested in the comment "if the acc ops are bright enough, they can
give themselves Domain and Enterprise Admin rights anyway. That is why you
want to use delegated accounts for AD data admins." How can they do this?
They do not appear to have access to their own accounts or anything above.
Obviously I do not want them to be able to do this (although I think that I
am safe with our helpdesk) so am interested in how they can do it.
Thanks.
Joe Richards [MVP]
2006-02-11 04:35:03 UTC
Permalink
As Cary mentioned, I don't tell people how to hack AD, not customers nor
coworkers nor even other MVPs even if people ask me really nice. I let people
work it out that think about it. If you understand how everything is put
together it really isn't all that difficult, it is just a series of escalations
until you are sitting there with Enterprise Admins rights. Luckily, most folks
aren't willing to figure that out, especially script kids. If some worms/viruses
decided to target AD a lot of companies would be in some serious trouble because
people for the most part don't really understand what they are working with and
allow too many people to have too many rights and do admin work in very stupid
ways. Anyone reading this that logs into their workstations with their domain
admin IDs to do their work, yes I am talking to you. Safest way to work is to
always use a normal userid for as much troubleshooting as possible, when you
need to actually change something you use runas to get an admin context command
prompt and do the work. You avoid logging directly into DCs as well either at
the console or through TS, I would say 98% of the admin work anyone has to do in
AD doesn't need local interactive sessions.

The main key that acc ops have is that by default they have interactive access
to the DC which puts them past a majority of the security barriers put into
place. Windows is designed more to keep people outside of the house not so much
to keep those inside the house from getting into the bathroom or top left
dresser drawer where your wife keeps her unmentionables. When I run AD domains,
haven't for a while as I am a consultant now, there are only about 3 native
Admins in the entire forest and no one else has access rights to the DCs. The
last company I did this for had 400 DCs and about 250,000 users. We had 3 admins
across the entire forest and one manager with an admin ID. That is the smoothest
running forest I have ever seen in any company anywhere. Recently I went to
lunch with my old team and we all sat and chatted for about 3.5 hours, their
pagers never went off. They told me that they have very very few issues, all
tickets coming in were primarily implementation of new stuff or deprovisioning
of old stuff. They have one huge possible security hole in terms of WAN based
DCs which are a serious target if someone really wanted to attack but they are
quite aware of DC outages and monitor keys items very closely that would
indicate a possible hack attempt. Plus those guys are some of the most
knowledgeable folks I know in Ops for AD having worked with me for 3 or so
years. It would take a decent hacker to get past them. I actually wouldn't mind
trying to see if I could get by them, I think they could probably catch me, but
I am not sure if they could do it before I did irreparable damage. ;o)

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
Post by Matt
Thanks for all the reponses. I will have a look at delegation when I get a
chance. Yes our helpdesk users were account operators from our NT days and
it seemed convenient. We have about five OUs at the top level and I was
hoping to avoid having to delegate permissions on each OU (tree) and the
subsequent job of managing and troubleshooting delegation.
I was interested in the comment "if the acc ops are bright enough, they can
give themselves Domain and Enterprise Admin rights anyway. That is why you
want to use delegated accounts for AD data admins." How can they do this?
They do not appear to have access to their own accounts or anything above.
Obviously I do not want them to be able to do this (although I think that I
am safe with our helpdesk) so am interested in how they can do it.
Thanks.
Matt
2006-02-14 09:06:29 UTC
Permalink
Thanks for everything. Yes, if I had thought it through I should have known
that nobody would post it here (and rightly so I guess), I was just trying to
think that if there is a hole I should know about it to help prevent it being
exploited. As soon as I get a chance, I will have a look at delegation to
resolve my issues and remove the security hole. And Yes, I know that I
shouldn't have domain admin rights - I have only recently taken over the
administration of our domain and network and already had it on my list to
remove my rights and use Run As as necessary - this was how I worked in my
previous job and this is how I intend to work in this one. It is also hard
to preach about not having too many rights, when I have them all.

Thanks.
Joe Richards [MVP]
2006-03-05 00:59:35 UTC
Permalink
We don't publish how to do it because you can't block against it. Your best bet
is to not give anyone whose job it is to make sure the domain controllers are
running properly any access to them. Plus make sure they are very physically secure.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
Post by Matt
Thanks for everything. Yes, if I had thought it through I should have known
that nobody would post it here (and rightly so I guess), I was just trying to
think that if there is a hole I should know about it to help prevent it being
exploited. As soon as I get a chance, I will have a look at delegation to
resolve my issues and remove the security hole. And Yes, I know that I
shouldn't have domain admin rights - I have only recently taken over the
administration of our domain and network and already had it on my list to
remove my rights and use Run As as necessary - this was how I worked in my
previous job and this is how I intend to work in this one. It is also hard
to preach about not having too many rights, when I have them all.
Thanks.
Continue reading on narkive:
Loading...