To create an account that can be used to create/delete child domains in a
forest, but cannot be used to log on.

I run a training network with a large forest. Currently when students are
tought domain structure they create their own mini tree in the forest. At
the moment yhey need to be issued with an account with enterprise rights.
This is not good at all.

What i need is an account that cannot be used to log on access drives etc.
But be able to be used when creating child/new domains in my forest.

Enterprise is in Native Mode all 2k SP4 machines.

Deny the log on locally right using group policy for this group of accounts.

"Paul Landregan" wrote in message
news:2goqd4F556dqU1@uni-berlin.de...
> To create an account that can be used to create/delete child domains in a
> forest, but cannot be used to log on.
>
> I run a training network with a large forest. Currently when students are
> tought domain structure they create their own mini tree in the forest. At
> the moment yhey need to be issued with an account with enterprise rights.
> This is not good at all.
>
> What i need is an account that cannot be used to log on access drives etc.
> But be able to be used when creating child/new domains in my forest.
>
> Enterprise is in Native Mode all 2k SP4 machines.
>
>

You could use a training forest that is separate from your regular forest if you
are not doing that already and have a one way trust between that forest and your
regular forest so that students can logon to it. They could be enterprise
administrators in that forest but not have any powers in the regular non trustng
forest if the training forest is the only trusting forest.

You can also use the user right for "deny access to this computer from the
network" and add the students accounts group that are enterperise administrators
to it for all computers other than domain controllers [or they can not logon].
However you can not realistically restrict an administrator as they ultimately
can grant themselves denied permissions/rights and create new administrator
accounts. If you have jokesters or malicious users, enabling auditing of account
logon and logon events may help track that down if they do not clear the
security log. Otherwise consider having them all build their own forests --
Steve

"Paul Landregan" wrote in message
news:2goqd4F556dqU1@uni-berlin.de...
> To create an account that can be used to create/delete child domains in a
> forest, but cannot be used to log on.
>
> I run a training network with a large forest. Currently when students are
> tought domain structure they create their own mini tree in the forest. At
> the moment yhey need to be issued with an account with enterprise rights.
> This is not good at all.
>
> What i need is an account that cannot be used to log on access drives etc.
> But be able to be used when creating child/new domains in my forest.
>
> Enterprise is in Native Mode all 2k SP4 machines.
>
>

"Steven Umbach" wrote in message
news:bhTpc.11503$gr.1009906@attbi_s52...
> You could use a training forest that is separate from your regular forest
if you
> are not doing that already and have a one way trust between that forest
and your
> regular forest so that students can logon to it. They could be enterprise
> administrators in that forest but not have any powers in the regular non
trustng
> forest if the training forest is the only trusting forest.
>
> You can also use the user right for "deny access to this computer from the
> network" and add the students accounts group that are enterperise
administrators
> to it for all computers other than domain controllers [or they can not
logon].
> However you can not realistically restrict an administrator as they
ultimately
> can grant themselves denied permissions/rights and create new
administrator
> accounts. If you have jokesters or malicious users, enabling auditing of
account
> logon and logon events may help track that down if they do not clear the
> security log. Otherwise consider having them all build their own
forests --
> Steve
>

Yes the way we have gone is that they create their own forests, then set up
trusts between some of them. Any software for install is located in the main
forest, they then have to authenticate as they are not trusted. This is fine
because any basic account can access the software for read only.

This arrangment has gone down well with the instructors, especially those
teaching Exchange, as they can set up connectors to a real forest to send
real mail.


Thanks to all who have suggested variuos methods.

I like the deny logon locally to an enterprise user idea, will keep that one
in mind for another project.