Limited admin access to Active Directory

S

srp336

We'd like to be able to give certain employees the task of maintain
active directory, but don't really want to allow them to have full
admin rights. Is ther a way to give a limit ability to AD? Is there
anyone doing something like this?

Thanks!
 
C

Cary Shultz

srp336,

With the information that you have provided I would say that you might want
to look into Delegation. There is an Active Directory Delegation Wizard
that can help you. Please note that using this simply changes the
permissions on the objects in question. There will not be any report (
well, maybe a log entry somewhere.....have not really every used it as I do
it manually ) that will 'remind' you of what you have done.

Here is a post from the past that covers five very specific needs:

=======================================================================================

These are AT LEAST permissions!!! Also take a look at the Delegation
of Control white paper.
http://www.microsoft.com/downloads/...a3-79e1-48fa-9730-dae7c0a1d6d3&DisplayLang=en
and
http://www.microsoft.com/downloads/...88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en

################################
1. JOIN COMPUTERS TO THE DOMAIN
---------------------------------
Well, this is possible through the Delegation of Control Wizard. Read
the following first which gives some recommendations.

The User Right "Add workstation to the domain" by default (configured
in the
Default Domain Controllers GPO) grants EVERY AUTHENTICATED USER (even
non-admin
users) in the domain to add/join workstations to the domain. It is
best to
remove "authenticated users" from that user right or set the quota to
0

For true delegation it is better to delegate the right to create
computer
accounts and to join computers as mentioned below

Using the delegation of control wizard you can delegate the creation
of
computer accounts to the domain. This does not mean the same
user/group can
also JOIN the computer to the domain. In the DELEGWIZ.INF file
(%WINDIR%INF)
look at template 6.....
By default the "AppliesToClasses" is set to "domainDNS" (case
sensitive and
without quotes) With this you can only delegate computer account
creation at
domain level. Change that to "domainDNS,organizationalUnit,container"
(case
sensitive and without quotes) and yuo will be able to delegate at OU
level

If you delegate the creation of computer accounts to a group (e.g.
GROUP-CREATE-COMPOBJ), the member of that group that creates the
computer
becomes the owner of the computer account and automatically receives
the right
to join a computer with that name to the domain. The other members of
that
group will not be able to join the computer to the domain. In this
case only
the user that created the computer account will be able to join the
computer.
Lets say you have another group called GROUP-JOIN-COMP that is allowed
to join
(not create computer accounts) to the domain, the user who creates the
computer
account has the possibility to designate which user or group gets the
rights to
join the computer to the domain with the option ("The following group
or user
can join this computer to a domain" and this is by default Domain
Admins group)
The group mentioned in that option will be able to join the computer
to the
domain. In my opinion that is a lot of work just to create a computer
computer
account and join it.

It is however possible to pre-configure the option called "The
following group
or user can join this computer to a domain and this is by default
Domain Admins
group"

Add to the DELEGWIZ.INF file (%WINDIR%INF) a NEW template you can use
to
delegate the task of JOINING COMPUTERS TO THE DOMAIN (not the creation
of
computer accounts) The minimum rights are mentioned below!

REPLACE THE X with a NUMBER!

;----------------------------------------------------------
[templateX]
AppliesToClasses = domainDNS,organizationalUnit,container

Description = "Join a computer to the domain in an OU (computer
account
pre-created)"

ObjectTypes = computer

[template6.computer]
;Right to join computers to domain
CONTROLRIGHT= "Reset Password","Validated write to DNS host
name","Validated
write to service principal name", "Account Restrictions"
;----------------------------------------------------------

This way you can delegate the creation of computer accounts to group1
and the
joining of the computers to group2.

It is also however possible you have a group of people who create
computers
accounts and also join them. To able so everyone in that group can
create a
computer accounts and join the computers to the domain independent who
created
the computer accounts replace TEMPLATE 6 with what is mentioned below
or
perform the delegate twice with the additional task created above! If
you want
to join a computer to the domain in a specific OU and the computer
account has
not been pre-created you cannot use the GUI at the computer. For this
you must
use the tool NETDOM so you can specify the OU the computer account
must reside
in! The latter only is only possible when you at least have the right
to create
a computer object in the designated OU. Joining will also be possible
because
you automatically become the owner of the computer account!

;----------------------------------------------------------
[template6]
AppliesToClasses = domainDNS,organizationalUnit,container

Description = "Add and/or join a computer to the domain in an OU
(computer)"

ObjectTypes = SCOPE, computer

[template6.SCOPE]
;Right to create computer objects
computer=CC

[template6.computer]
;Right to join computers to domain
CONTROLRIGHT= "Reset Password","Validated write to DNS host
name","Validated
write to service principal name", "Account Restrictions"
;----------------------------------------------------------

################################
2. MOVE COMPUTERS BETWEEN OUâ?TS
---------------------------------
In order to move an object in DS, you need the following three
permissions:

1) DELETE_CHILD on the source container or DELETE on the object being
moved
2) WRITE_PROP on the object being moved for two properties: RDN (name)
and
CN (or whatever happens to be the rdn attribute for this class, i.e.
ou for
org units).
3) CREATE_CHILD on the destination container.

This is not available through the delegation of control wizard, thus
you need to customize in the delegation of control wizard by selecting
the correct properties.

################################
3. RESET USER PASSWORDS
---------------------------------
To reset user passwords you need the â?oReset Passwordâ? extended
right on the user object. This is also available through the
delegation of control wizard using the common delegated task â?oReset
a user accountâ?Ts passwordâ?

If you want to reset user passwords and force password change at next
logon you need the â?oReset Passwordâ? extended right on the user
object and you need Read/Write permissions on the attribute
â?opwdLastSetâ?. This is also available through the delegation of
control wizard using the common delegated task â?oReset user passwords
and force password change at next logonâ?

################################
4. CREATE EXCHANGE MAILBOXES
---------------------------------
If you create a user and assign a mailbox you need:
Create User objects, write permissions for the attribute
â?ouserAccountControlâ? of the user object and the extended right
â?oReset Passwordâ? on the user object.
This is also available through the delegation of control wizard using
the common delegated task â?oCreate a user accountâ?

To additionally assign a mailbox to the user you need Exchange View
Only Administrator permissions in Exchange (on ORG level or
administrative Group Level, depending on the scope wanted)

To assign a mailbox to a user account you donâ?Tt have permissions for
you need the permissions mentioned in
http://support.microsoft.com/Default.aspx?id=316792

################################
5. ADD AND REMOVE GROUPS TO USERS
---------------------------------
The permissions to change group membership is controlled through the
group and not through the user. For this you need RP/WP on the
attribute â?omemberâ? of the group you want to add another security
principal to (user, group or computer)
This is also available through the delegation of control wizard using
the common delegated task â?oModify the membership of a groupâ?

=========================================================================================

Jorge was kind enough to post this....

--
Cary W. Shultz
Roanoke, VA 24012

http://www.activedirectory-win2000.com
(soon to be updated!!!)
http://www.grouppolicy-win2000.com
(soon to be updated!!!)
 
H

Herb Martin

We'd like to be able to give certain employees the task of maintain
active directory, but don't really want to allow them to have full
admin rights. Is ther a way to give a limit ability to AD? Is there
anyone doing something like this?

As Cary wrote separately, Delegation of the privileges is the
way to go.

There is a delegation of Control Wizard (create an OU, right click
on it, choose Delegation of control..., and experiment with the results.)

If you needs are similar to those offered by the Delegation of Control
Wizard (most common things MS expects you to delegate) the answer
is almost trivial.

If you have more specific (peculiar?) needs then you must work out
and delegate the actual Permissions on the objects (Advanced View
enabled, properties of OU etc, Security permissions tab etc...)

You can also use the Security to do specific auditing IF you ALSO
enable "DS Object Auditing".
 
J

Jorge_de_Almeida_Pinto

srp336,

With the information that you have provided I would say that
you might want
to look into Delegation. There is an Active Directory
Delegation Wizard
that can help you. Please note that using this simply changes
the
permissions on the objects in question. There will not be any
report (
well, maybe a log entry somewhere.....have not really every
used it as I do
it manually ) that will 'remind' you of what you have done.

Here is a post from the past that covers five very specific
needs:

==============================================================
=========================

These are AT LEAST permissions!!! Also take a look at the
Delegation
of Control white paper.
http://www.microsoft.com/downloads/...a3-79e1-48fa-9730-dae7c0a1d6d3&DisplayLang=en
and
http://www.microsoft.com/downloads/...88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en

################################
1. JOIN COMPUTERS TO THE DOMAIN
---------------------------------
Well, this is possible through the Delegation of Control
Wizard. Read
the following first which gives some recommendations.

The User Right "Add workstation to the domain" by default
(configured
in the
Default Domain Controllers GPO) grants EVERY AUTHENTICATED
USER (even
non-admin
users) in the domain to add/join workstations to the domain.
It is
best to
remove "authenticated users" from that user right or set the
quota to
0

For true delegation it is better to delegate the right to
create
computer
accounts and to join computers as mentioned below

Using the delegation of control wizard you can delegate the
creation
of
computer accounts to the domain. This does not mean the same
user/group can
also JOIN the computer to the domain. In the DELEGWIZ.INF file
(%WINDIR%INF)
look at template 6.....
By default the "AppliesToClasses" is set to "domainDNS" (case
sensitive and
without quotes) With this you can only delegate computer
account
creation at
domain level. Change that to
"domainDNS,organizationalUnit,container"
(case
sensitive and without quotes) and yuo will be able to delegate
at OU
level

If you delegate the creation of computer accounts to a group
(e.g.
GROUP-CREATE-COMPOBJ), the member of that group that creates
the
computer
becomes the owner of the computer account and automatically
receives
the right
to join a computer with that name to the domain. The other
members of
that
group will not be able to join the computer to the domain. In
this
case only
the user that created the computer account will be able to
join the
computer.
Lets say you have another group called GROUP-JOIN-COMP that is
allowed
to join
(not create computer accounts) to the domain, the user who
creates the
computer
account has the possibility to designate which user or group
gets the
rights to
join the computer to the domain with the option ("The
following group
or user
can join this computer to a domain" and this is by default
Domain
Admins group)
The group mentioned in that option will be able to join the
computer
to the
domain. In my opinion that is a lot of work just to create a
computer
computer
account and join it.

It is however possible to pre-configure the option called "The
following group
or user can join this computer to a domain and this is by
default
Domain Admins
group"

Add to the DELEGWIZ.INF file (%WINDIR%INF) a NEW template you
can use
to
delegate the task of JOINING COMPUTERS TO THE DOMAIN (not the
creation
of
computer accounts) The minimum rights are mentioned below!

REPLACE THE X with a NUMBER!

;----------------------------------------------------------
[templateX]
AppliesToClasses = domainDNS,organizationalUnit,container

Description = "Join a computer to the domain in an OU
(computer
account
pre-created)"

ObjectTypes = computer

[template6.computer]
;Right to join computers to domain
CONTROLRIGHT= "Reset Password","Validated write to DNS host
name","Validated
write to service principal name", "Account Restrictions"
;----------------------------------------------------------

This way you can delegate the creation of computer accounts to
group1
and the
joining of the computers to group2.

It is also however possible you have a group of people who
create
computers
accounts and also join them. To able so everyone in that group
can
create a
computer accounts and join the computers to the domain
independent who
created
the computer accounts replace TEMPLATE 6 with what is
mentioned below
or
perform the delegate twice with the additional task created
above! If
you want
to join a computer to the domain in a specific OU and the
computer
account has
not been pre-created you cannot use the GUI at the computer.
For this
you must
use the tool NETDOM so you can specify the OU the computer
account
must reside
in! The latter only is only possible when you at least have
the right
to create
a computer object in the designated OU. Joining will also be
possible
because
you automatically become the owner of the computer account!

;----------------------------------------------------------
[template6]
AppliesToClasses = domainDNS,organizationalUnit,container

Description = "Add and/or join a computer to the domain in an
OU
(computer)"

ObjectTypes = SCOPE, computer

[template6.SCOPE]
;Right to create computer objects
computer=CC

[template6.computer]
;Right to join computers to domain
CONTROLRIGHT= "Reset Password","Validated write to DNS host
name","Validated
write to service principal name", "Account Restrictions"
;----------------------------------------------------------

################################
2. MOVE COMPUTERS BETWEEN OUâ?TS
---------------------------------
In order to move an object in DS, you need the following three
permissions:

1) DELETE_CHILD on the source container or DELETE on the
object being
moved
2) WRITE_PROP on the object being moved for two properties:
RDN (name)
and
CN (or whatever happens to be the rdn attribute for this
class, i.e.
ou for
org units).
3) CREATE_CHILD on the destination container.

This is not available through the delegation of control
wizard, thus
you need to customize in the delegation of control wizard by
selecting
the correct properties.

################################
3. RESET USER PASSWORDS
---------------------------------
To reset user passwords you need the â?oReset Passwordâ?
extended
right on the user object. This is also available through the
delegation of control wizard using the common delegated task
â?oReset
a user accountâ?Ts passwordâ?

If you want to reset user passwords and force password change
at next
logon you need the â?oReset Passwordâ? extended right on the
user
object and you need Read/Write permissions on the attribute
â?opwdLastSetâ?. This is also available through the
delegation of
control wizard using the common delegated task â?oReset user
passwords
and force password change at next logonâ?

################################
4. CREATE EXCHANGE MAILBOXES
---------------------------------
If you create a user and assign a mailbox you need:
Create User objects, write permissions for the attribute
â?ouserAccountControlâ? of the user object and the extended
right
â?oReset Passwordâ? on the user object.
This is also available through the delegation of control
wizard using
the common delegated task â?oCreate a user accountâ?

To additionally assign a mailbox to the user you need Exchange
View
Only Administrator permissions in Exchange (on ORG level or
administrative Group Level, depending on the scope wanted)

To assign a mailbox to a user account you donâ?Tt have
permissions for
you need the permissions mentioned in
http://support.microsoft.com/Default.aspx?id=316792

################################
5. ADD AND REMOVE GROUPS TO USERS
---------------------------------
The permissions to change group membership is controlled
through the
group and not through the user. For this you need RP/WP on the
attribute â?omemberâ? of the group you want to add another
security
principal to (user, group or computer)
This is also available through the delegation of control
wizard using
the common delegated task â?oModify the membership of a
groupâ?

==============================================================
===========================

Jorge was kind enough to post this....

--
Cary W. Shultz
Roanoke, VA 24012

http://www.activedirectory-win2000.com
(soon to be updated!!!)
http://www.grouppolicy-win2000.com
(soon to be updated!!!)



We'd like to be able to give certain employees the task of maintain
active directory, but don't really want to allow them to have full
admin rights. Is ther a way to give a limit ability to AD? Is there
anyone doing something like this?

Thanks!

Hi Cary,

Well... that saves me from answering the question... :D
 
J

Joe Richards [MVP]

Jorge if you are going to bottom post please TRIM THE POST!!!!!

:blush:)

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


Jorge_de_Almeida_Pinto said:
srp336,

With the information that you have provided I would say that
you might want
to look into Delegation. There is an Active Directory
Delegation Wizard
that can help you. Please note that using this simply changes
the
permissions on the objects in question. There will not be any
report (
well, maybe a log entry somewhere.....have not really every
used it as I do
it manually ) that will 'remind' you of what you have done.

Here is a post from the past that covers five very specific
needs:

==============================================================
=========================

These are AT LEAST permissions!!! Also take a look at the
Delegation
of Control white paper.
http://www.microsoft.com/downloads/...a3-79e1-48fa-9730-dae7c0a1d6d3&DisplayLang=en
and
http://www.microsoft.com/downloads/...88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en

################################
1. JOIN COMPUTERS TO THE DOMAIN
---------------------------------
Well, this is possible through the Delegation of Control
Wizard. Read
the following first which gives some recommendations.

The User Right "Add workstation to the domain" by default
(configured
in the
Default Domain Controllers GPO) grants EVERY AUTHENTICATED
USER (even
non-admin
users) in the domain to add/join workstations to the domain.
It is
best to
remove "authenticated users" from that user right or set the
quota to
0

For true delegation it is better to delegate the right to
create
computer
accounts and to join computers as mentioned below

Using the delegation of control wizard you can delegate the
creation
of
computer accounts to the domain. This does not mean the same
user/group can
also JOIN the computer to the domain. In the DELEGWIZ.INF file
(%WINDIR%INF)
look at template 6.....
By default the "AppliesToClasses" is set to "domainDNS" (case
sensitive and
without quotes) With this you can only delegate computer
account
creation at
domain level. Change that to
"domainDNS,organizationalUnit,container"
(case
sensitive and without quotes) and yuo will be able to delegate
at OU
level

If you delegate the creation of computer accounts to a group
(e.g.
GROUP-CREATE-COMPOBJ), the member of that group that creates
the
computer
becomes the owner of the computer account and automatically
receives
the right
to join a computer with that name to the domain. The other
members of
that
group will not be able to join the computer to the domain. In
this
case only
the user that created the computer account will be able to
join the
computer.
Lets say you have another group called GROUP-JOIN-COMP that is
allowed
to join
(not create computer accounts) to the domain, the user who
creates the
computer
account has the possibility to designate which user or group
gets the
rights to
join the computer to the domain with the option ("The
following group
or user
can join this computer to a domain" and this is by default
Domain
Admins group)
The group mentioned in that option will be able to join the
computer
to the
domain. In my opinion that is a lot of work just to create a
computer
computer
account and join it.

It is however possible to pre-configure the option called "The
following group
or user can join this computer to a domain and this is by
default
Domain Admins
group"

Add to the DELEGWIZ.INF file (%WINDIR%INF) a NEW template you
can use
to
delegate the task of JOINING COMPUTERS TO THE DOMAIN (not the
creation
of
computer accounts) The minimum rights are mentioned below!

REPLACE THE X with a NUMBER!

;----------------------------------------------------------
[templateX]
AppliesToClasses = domainDNS,organizationalUnit,container

Description = "Join a computer to the domain in an OU
(computer
account
pre-created)"

ObjectTypes = computer

[template6.computer]
;Right to join computers to domain
CONTROLRIGHT= "Reset Password","Validated write to DNS host
name","Validated
write to service principal name", "Account Restrictions"
;----------------------------------------------------------

This way you can delegate the creation of computer accounts to
group1
and the
joining of the computers to group2.

It is also however possible you have a group of people who
create
computers
accounts and also join them. To able so everyone in that group
can
create a
computer accounts and join the computers to the domain
independent who
created
the computer accounts replace TEMPLATE 6 with what is
mentioned below
or
perform the delegate twice with the additional task created
above! If
you want
to join a computer to the domain in a specific OU and the
computer
account has
not been pre-created you cannot use the GUI at the computer.
For this
you must
use the tool NETDOM so you can specify the OU the computer
account
must reside
in! The latter only is only possible when you at least have
the right
to create
a computer object in the designated OU. Joining will also be
possible
because
you automatically become the owner of the computer account!

;----------------------------------------------------------
[template6]
AppliesToClasses = domainDNS,organizationalUnit,container

Description = "Add and/or join a computer to the domain in an
OU
(computer)"

ObjectTypes = SCOPE, computer

[template6.SCOPE]
;Right to create computer objects
computer=CC

[template6.computer]
;Right to join computers to domain
CONTROLRIGHT= "Reset Password","Validated write to DNS host
name","Validated
write to service principal name", "Account Restrictions"
;----------------------------------------------------------

################################
2. MOVE COMPUTERS BETWEEN OUâ?TS
---------------------------------
In order to move an object in DS, you need the following three
permissions:

1) DELETE_CHILD on the source container or DELETE on the
object being
moved
2) WRITE_PROP on the object being moved for two properties:
RDN (name)
and
CN (or whatever happens to be the rdn attribute for this
class, i.e.
ou for
org units).
3) CREATE_CHILD on the destination container.

This is not available through the delegation of control
wizard, thus
you need to customize in the delegation of control wizard by
selecting
the correct properties.

################################
3. RESET USER PASSWORDS
---------------------------------
To reset user passwords you need the â?oReset Passwordâ?
extended
right on the user object. This is also available through the
delegation of control wizard using the common delegated task
â?oReset
a user accountâ?Ts passwordâ?

If you want to reset user passwords and force password change
at next
logon you need the â?oReset Passwordâ? extended right on the
user
object and you need Read/Write permissions on the attribute
â?opwdLastSetâ?. This is also available through the
delegation of
control wizard using the common delegated task â?oReset user
passwords
and force password change at next logonâ?

################################
4. CREATE EXCHANGE MAILBOXES
---------------------------------
If you create a user and assign a mailbox you need:
Create User objects, write permissions for the attribute
â?ouserAccountControlâ? of the user object and the extended
right
â?oReset Passwordâ? on the user object.
This is also available through the delegation of control
wizard using
the common delegated task â?oCreate a user accountâ?

To additionally assign a mailbox to the user you need Exchange
View
Only Administrator permissions in Exchange (on ORG level or
administrative Group Level, depending on the scope wanted)

To assign a mailbox to a user account you donâ?Tt have
permissions for
you need the permissions mentioned in
http://support.microsoft.com/Default.aspx?id=316792

################################
5. ADD AND REMOVE GROUPS TO USERS
---------------------------------
The permissions to change group membership is controlled
through the
group and not through the user. For this you need RP/WP on the
attribute â?omemberâ? of the group you want to add another
security
principal to (user, group or computer)
This is also available through the delegation of control
wizard using
the common delegated task â?oModify the membership of a
groupâ?

==============================================================
===========================

Jorge was kind enough to post this....

--
Cary W. Shultz
Roanoke, VA 24012

http://www.activedirectory-win2000.com
(soon to be updated!!!)
http://www.grouppolicy-win2000.com
(soon to be updated!!!)



We'd like to be able to give certain employees the task of maintain
active directory, but don't really want to allow them to have full
admin rights. Is ther a way to give a limit ability to AD? Is there
anyone doing something like this?

Thanks!

Hi Cary,

Well... that saves me from answering the question... :D
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top