More on user permissions in a 2K AD domain

Directory >> More on user permissions in a 2K AD domain First, I would like to thank Gautam Anand, Oli Restorick, and Marco for
their feedback that has led to the following hypothesis.

Before I go off and attempt this and end up in a wild goose chase, is it
possible to create a user that has no login privleges, no resource access
and whatnot but can add computers to a domain? What I am wanting is to keep
the Domain Admins off of any workstation. I made the realization that the
computer only needs to be able to join a domain and then a *local* RunAs
Admin privilege combined with normal Domain User permissions is all that is
needed from then on for the remainder of the setup.

... or am I WAY off base?

And while I'm here, what are your feelings about Terminal Services running
on the DC? I'm thinking of not using TS on the DC at all and have only local
console access. (You might have guess by now that I'm one of those
"abstinence is the only sure protection" kind of people.)

Thanks again in advance.
Eric
(cross-posted in: microsoft.public.win2000.active_directory and
microsoft.public.win2000.security due to relevancy.)

Windows OS197

Directory >> More on user permissions in a 2K AD domain Eric H. Vela wrote:
> First, I would like to thank Gautam Anand, Oli Restorick, and Marco
> for their feedback that has led to the following hypothesis.
>
> Before I go off and attempt this and end up in a wild goose chase, is
> it possible to create a user that has no login privleges, no resource
> access and whatnot but can add computers to a domain? What I am
> wanting is to keep the Domain Admins off of any workstation. I made
> the realization that the computer only needs to be able to join a
> domain and then a *local* RunAs Admin privilege combined with normal
> Domain User permissions is all that is needed from then on for the
> remainder of the setup.
>
> ... or am I WAY off base?

Actually, I may be a little confused as to what you're trying to do, but
users themselves by default can join up to 10 computers to the domain.
What's your desired end goal here? You can delegate pretty much anything you
want to an account, but I'm not sure what you're trying to do.

>
> And while I'm here, what are your feelings about Terminal Services
> running on the DC? I'm thinking of not using TS on the DC at all and
> have only local console access. (You might have guess by now that I'm
> one of those "abstinence is the only sure protection" kind of people.)

TS in admin mode is fine - if you mean in application mode, no, don't do it.

>
> Thanks again in advance.
> Eric
> (cross-posted in: microsoft.public.win2000.active_directory and
> microsoft.public.win2000.security due to relevancy.)

Directory >> More on user permissions in a 2K AD domain TS in admin mode is what I was referring to. I'm not sure I particularly
like the idea. But it WOULD make certain aspects of management easier since
the target server is offsite.

The target DC and Domain are in a situation of being only one server in the
domain serving as DC, User, File, DNS and SQL servers. I know this is not
the recommended set up, but my hands are tied on that front so I am setting
up a test situation identical to that and wish to lock down the server
tighter than Ft. Knox with the intention of applying the same to the
server/domain in production. Though I'm out in the middle of nowhere, it
seems this area is a target for server hacking -- either that or the average
sys admin isn't knowledgable enough to protect their systems around these
parts. The current state of the target domain is poor on the security scale
and I intend to fix that as best as I can. Access to knowledgable personnel
locally is limited so I'm pretty much on my own on this one.

As always, the weakest link in the target domain is the users. My hands are
also tied on the local access of the workstations, but I can set the server
to any privilege I desire. Still formerly, the sys admin had used the
primary Domain Admin (was still named Administrator) for all administration
things on the workstations, and I'm aware that Windows 2K caches login
information locally on the workstations, and this information may be hacked
giving information about how to attack the server more easily with higher
access. However, if the Domain Admin logins never happen on the workstation,
the cached information is not created. Right? So my aim is to keep as much
information about the domain and its admins off of the workstations as
possible. The situation may arise where one of the above mentioned,
unrestrictable, workstation users will want to add another computer to the
domain themselves. (Again, not my recommendation, but my hands are tied.)

So essentially, it's a bad situation that I'm trying to make the best of. I
want to protect the server as best as possible if (or rather, when) a
workstation gets hacked. It is the heart of their entire operation.

Eric

"Lanwench [MVP - Exchange]"
<EMail@HideDomain.com> wrote in message
news:EMail@HideDomain.com...
> Eric H. Vela wrote:
>> First, I would like to thank Gautam Anand, Oli Restorick, and Marco
>> for their feedback that has led to the following hypothesis.
>>
>> Before I go off and attempt this and end up in a wild goose chase, is
>> it possible to create a user that has no login privleges, no resource
>> access and whatnot but can add computers to a domain? What I am
>> wanting is to keep the Domain Admins off of any workstation. I made
>> the realization that the computer only needs to be able to join a
>> domain and then a *local* RunAs Admin privilege combined with normal
>> Domain User permissions is all that is needed from then on for the
>> remainder of the setup.
>>
>> ... or am I WAY off base?
>
> Actually, I may be a little confused as to what you're trying to do, but
> users themselves by default can join up to 10 computers to the domain.
> What's your desired end goal here? You can delegate pretty much anything
> you
> want to an account, but I'm not sure what you're trying to do.
>
>>
>> And while I'm here, what are your feelings about Terminal Services
>> running on the DC? I'm thinking of not using TS on the DC at all and
>> have only local console access. (You might have guess by now that I'm
>> one of those "abstinence is the only sure protection" kind of people.)
>
> TS in admin mode is fine - if you mean in application mode, no, don't do
> it.
>
>>
>> Thanks again in advance.
>> Eric
>> (cross-posted in: microsoft.public.win2000.active_directory and
>> microsoft.public.win2000.security due to relevancy.)
>
>

Directory >> More on user permissions in a 2K AD domain Eric H. Vela wrote:
> TS in admin mode is what I was referring to. I'm not sure I
> particularly like the idea. But it WOULD make certain aspects of
> management easier since the target server is offsite.
>
> The target DC and Domain are in a situation of being only one server
> in the domain serving as DC, User, File, DNS and SQL servers. I know
> this is not the recommended set up, but my hands are tied on that
> front so I am setting up a test situation identical to that and wish
> to lock down the server tighter than Ft. Knox with the intention of
> applying the same to the server/domain in production.

Yes - if you're nervous about using TS just over the Internet, what about
using VPN to connect first & then use TS?

> Though I'm out
> in the middle of nowhere, it seems this area is a target for server
> hacking -- either that or the average sys admin isn't knowledgable
> enough to protect their systems around these parts. The current state
> of the target domain is poor on the security scale and I intend to
> fix that as best as I can. Access to knowledgable personnel locally
> is limited so I'm pretty much on my own on this one.

What kind of firewall protection do they have? Are they kept current on
patches?
>
> As always, the weakest link in the target domain is the users. My
> hands are also tied on the local access of the workstations, but I
> can set the server to any privilege I desire.

Why can't you get rid of user's local admin rights?

> Still formerly, the sys
> admin had used the primary Domain Admin (was still named
> Administrator) for all administration things on the workstations, and
> I'm aware that Windows 2K caches login information locally on the
> workstations, and this information may be hacked giving information
> about how to attack the server more easily with higher access.

Well...it's not like the password is just sitting there in clear text. Use
complex passwords, rename administrator to something else, force users to
use complex passwords & force regular pw changes.

> However, if the Domain Admin logins never happen on the workstation,
> the cached information is not created. Right?

Not really relevant, I think.

> So my aim is to keep as
> much information about the domain and its admins off of the
> workstations as possible. The situation may arise where one of the
> above mentioned, unrestrictable, workstation users will want to add
> another computer to the domain themselves. (Again, not my
> recommendation, but my hands are tied.)

They can, without having admin rights - users can add up to 10 PCs to the
domain.
>
> So essentially, it's a bad situation that I'm trying to make the best
> of. I want to protect the server as best as possible if (or rather,
> when) a workstation gets hacked. It is the heart of their entire
> operation.

Yes - so, firewall, patches, centralized AV, no local admin rights, no
"visitor" laptops, and good password policies will help mitigate this. I
would happily use TS in admin mode - with or without VPN as you choose.
Sticking another cheap & cheerful box to run as another DC would be a VERY
good idea, however.
>
> Eric
>
> "Lanwench [MVP - Exchange]"
> <EMail@HideDomain.com> wrote in
> message news:EMail@HideDomain.com...
>> Eric H. Vela wrote:
>>> First, I would like to thank Gautam Anand, Oli Restorick, and Marco
>>> for their feedback that has led to the following hypothesis.
>>>
>>> Before I go off and attempt this and end up in a wild goose chase,
>>> is it possible to create a user that has no login privleges, no
>>> resource access and whatnot but can add computers to a domain? What
>>> I am wanting is to keep the Domain Admins off of any workstation. I
>>> made the realization that the computer only needs to be able to
>>> join a domain and then a *local* RunAs Admin privilege combined
>>> with normal Domain User permissions is all that is needed from then
>>> on for the remainder of the setup.
>>>
>>> ... or am I WAY off base?
>>
>> Actually, I may be a little confused as to what you're trying to do,
>> but users themselves by default can join up to 10 computers to the
>> domain. What's your desired end goal here? You can delegate pretty
>> much anything you
>> want to an account, but I'm not sure what you're trying to do.
>>
>>>
>>> And while I'm here, what are your feelings about Terminal Services
>>> running on the DC? I'm thinking of not using TS on the DC at all and
>>> have only local console access. (You might have guess by now that
>>> I'm one of those "abstinence is the only sure protection" kind of
>>> people.)
>>
>> TS in admin mode is fine - if you mean in application mode, no,
>> don't do it.
>>
>>>
>>> Thanks again in advance.
>>> Eric
>>> (cross-posted in: microsoft.public.win2000.active_directory and
>>> microsoft.public.win2000.security due to relevancy.)

Directory >> More on user permissions in a 2K AD domain If you disable use of LM hashing of passwords via group policy
and you use a long, strong pass phrase for the admin accounts then
you really should not be concerned about caching left on uplevel
workstations due to a login (I assume admin accounts do not have
roaming profiles).

As the Lanwench has indicated, users by default can add computers
to the domain up to ten times. If this is insufficent, adding computers
to the domain can be delegated so that they have no ten limit. As you
say you have no choice in this, you may want to make the best of it.
You may want to make sure that you either have basic sanity policy
settings for workstations in a domain linked GPO, or that you change
the default location for newly added computers so they end up in an
OU to which such a GPO is linked. With this, when a user adds a
workstation it will be subjected to your basic sanity policies right
from the start. Without either of these, a new computer ends up in
the Computers container to which only domain linked (assuming no
site linked) GPOs apply, and in the default, there are very few policy
settings made at the domain level.

As far as remote management of your server, there are those that
advocate managing the domain only when logged in at the physical
console (i.e. no TS). Given you are remote from the server and it
runs so much, it may be difficult for you to adjust to such a tight
practice. Notice that you can use the configuration settings of the
Tcp RDP connectoid within the TS Mgmt UI to configure exactly
which accounts are allowed to connect (as opposed to all admins
as is the default), and that there are quite a few policies that may
be used via GPO in the TS adm template which allow you to set
heightened security aspects, like encryption strength, etc..

As to your initial question, whether such an account can be defined,
if I understand you correctly, then the answer is no, it cannot. In
order of an account to be of any use at all it must have access to
a fair amount of binaries in the Windows directory, to a profile,
etc.. So, not being too sure what you are envisioning, it sounds as
if you want an account that is so severely crippled that it would not
be allowed a login session and/or network connection. But then
again, I do not see what is the need given that users can add computers
to the domain. What thus you really need to do is to protect user accounts
from being misappropriated.

--
Roger Abell
Microsoft MVP (Windows Server System: Security)
MCSE (W2k3,W2k,Nt4) MCDBA
"Eric H. Vela" <EMail@HideDomain.com> wrote in message
news:EMail@HideDomain.com...
> TS in admin mode is what I was referring to. I'm not sure I particularly
> like the idea. But it WOULD make certain aspects of management easier
since
> the target server is offsite.
>
> The target DC and Domain are in a situation of being only one server in
the
> domain serving as DC, User, File, DNS and SQL servers. I know this is not
> the recommended set up, but my hands are tied on that front so I am
setting
> up a test situation identical to that and wish to lock down the server
> tighter than Ft. Knox with the intention of applying the same to the
> server/domain in production. Though I'm out in the middle of nowhere, it
> seems this area is a target for server hacking -- either that or the
average
> sys admin isn't knowledgable enough to protect their systems around these
> parts. The current state of the target domain is poor on the security
scale
> and I intend to fix that as best as I can. Access to knowledgable
personnel
> locally is limited so I'm pretty much on my own on this one.
>
> As always, the weakest link in the target domain is the users. My hands
are
> also tied on the local access of the workstations, but I can set the
server
> to any privilege I desire. Still formerly, the sys admin had used the
> primary Domain Admin (was still named Administrator) for all
administration
> things on the workstations, and I'm aware that Windows 2K caches login
> information locally on the workstations, and this information may be
hacked
> giving information about how to attack the server more easily with higher
> access. However, if the Domain Admin logins never happen on the
workstation,
> the cached information is not created. Right? So my aim is to keep as much
> information about the domain and its admins off of the workstations as
> possible. The situation may arise where one of the above mentioned,
> unrestrictable, workstation users will want to add another computer to the
> domain themselves. (Again, not my recommendation, but my hands are tied.)
>
> So essentially, it's a bad situation that I'm trying to make the best of.
I
> want to protect the server as best as possible if (or rather, when) a
> workstation gets hacked. It is the heart of their entire operation.
>
> Eric
>
> "Lanwench [MVP - Exchange]"
> <EMail@HideDomain.com> wrote in
message
> news:EMail@HideDomain.com...
> > Eric H. Vela wrote:
> >> First, I would like to thank Gautam Anand, Oli Restorick, and Marco
> >> for their feedback that has led to the following hypothesis.
> >>
> >> Before I go off and attempt this and end up in a wild goose chase, is
> >> it possible to create a user that has no login privleges, no resource
> >> access and whatnot but can add computers to a domain? What I am
> >> wanting is to keep the Domain Admins off of any workstation. I made
> >> the realization that the computer only needs to be able to join a
> >> domain and then a *local* RunAs Admin privilege combined with normal
> >> Domain User permissions is all that is needed from then on for the
> >> remainder of the setup.
> >>
> >> ... or am I WAY off base?
> >
> > Actually, I may be a little confused as to what you're trying to do, but
> > users themselves by default can join up to 10 computers to the domain.
> > What's your desired end goal here? You can delegate pretty much anything
> > you
> > want to an account, but I'm not sure what you're trying to do.
> >
> >>
> >> And while I'm here, what are your feelings about Terminal Services
> >> running on the DC? I'm thinking of not using TS on the DC at all and
> >> have only local console access. (You might have guess by now that I'm
> >> one of those "abstinence is the only sure protection" kind of people.)
> >
> > TS in admin mode is fine - if you mean in application mode, no, don't do
> > it.
> >
> >>
> >> Thanks again in advance.
> >> Eric
> >> (cross-posted in: microsoft.public.win2000.active_directory and
> >> microsoft.public.win2000.security due to relevancy.)
> >
> >
>
>

Directory >> More on user permissions in a 2K AD domain You can give any user or group the ability to join computers to the domain
by delegating the appropriate rights in AD.
To finish a build they would need to be local admins of the PC. You can
achieve that by using Group Policy Restricted Groups to make a group a
member of the Local Admins group. No need to have Domain Admin rights at all
in building or supporting PC's.
Console access only on the DC is fine, but that means the server must be
accessible. Maybe someone will power it off or knock the LAN cable out.
Locked in a server room with TS access in Administration mode gives you more
physical security.
Anthony

"Eric H. Vela" <EMail@HideDomain.com> wrote in message
news:%EMail@HideDomain.com...
> First, I would like to thank Gautam Anand, Oli Restorick, and Marco for
> their feedback that has led to the following hypothesis.
>
> Before I go off and attempt this and end up in a wild goose chase, is it
> possible to create a user that has no login privleges, no resource access
> and whatnot but can add computers to a domain? What I am wanting is to
keep
> the Domain Admins off of any workstation. I made the realization that the
> computer only needs to be able to join a domain and then a *local* RunAs
> Admin privilege combined with normal Domain User permissions is all that
is
> needed from then on for the remainder of the setup.
>
> ... or am I WAY off base?
>
> And while I'm here, what are your feelings about Terminal Services running
> on the DC? I'm thinking of not using TS on the DC at all and have only
local
> console access. (You might have guess by now that I'm one of those
> "abstinence is the only sure protection" kind of people.)
>
> Thanks again in advance.
> Eric
> (cross-posted in: microsoft.public.win2000.active_directory and
> microsoft.public.win2000.security due to relevancy.)
>
>