User Rights in TS

[powlaz]

We have an application or two that we run where the manufacturers recommends
that any user be logged in as an administrator on the local PC. Being the
good little lambs that we are we have always followed this rule.

Anyway now that we are set up with a Terminal Server I am seeing, more than
ever, why the need for each user to have local admin rights is such a
concern. It looks to me like every user of the TS needs to be added to the
local Remote Desktop Users group on the TS. In addition it seems I will need
to make these users members of the Administrators group which unfortunately
provides Admin rights to the Domain as well as the local PC.

We don't use Group Policy yet. I'm interested in knowing what I"m supposed
to do now. I certainly don't want these folks to have carte blanche on the
network.

Please help.

MJ

 

[Lanwench [MVP - Exchange]]

Re: User Rights in TS

powlaz <powlaz@discussions.microsoft.com> wrote:
> We have an application or two that we run where the manufacturers
> recommends that any user be logged in as an administrator on the
> local PC. Being the good little lambs that we are we have always
> followed this rule.

Another (better) option, besides walloping the application vendor with a
brickbat, is to find out where in the file system and/or registry their
software expects access, and manually changing the permissions for same.
ProcessMonitor (Sysinternals...now downloadable from MS) will help you do
this.
>
> Anyway now that we are set up with a Terminal Server I am seeing,
> more than ever, why the need for each user to have local admin
> rights is such a concern.

No idding!

> It looks to me like every user of the TS
> needs to be added to the local Remote Desktop Users group on the TS.

Well, it's better to do this with an AD security group. I like to set up one
called TSUsers.

> In addition it seems I will need to make these users members of the
> Administrators group which unfortunately provides Admin rights to the
> Domain as well as the local PC.

Then it sounds like your TS box is a DC - that's a big no-no. Your TS box
should be a member server with no other roles. Don't let users log in to
your DCs, ever.
>
> We don't use Group Policy yet.

You'll want to. You need to lock down a lot.

> I'm interested in knowing what I"m
> supposed to do now. I certainly don't want these folks to have carte
> blanche on the network.

Absolutely!
>
> Please help.
>
> MJ

I'm not a guru, but here's what I've learned along the way -

Basics: you should be running Terminal Services on a dedicated member server
with *no* other roles on the network. It should be set up in its own OU,
with a policy specifically for TS (including loopback processing so that all
users who log in get the same settings, regardless of
their own inherited user policy settings). See KB 278295 for some good
lockdown suggestions. Also see MVP Patrick Rouse's articles at
http://www.sessioncomputing.com/articles.htm


You'll still need to figure out what your rogue apps want access to, of
course.

 

[powlaz]

Re: User Rights in TS

Lanwench - thank you for the great answers. If I may, I have a couple of
follow-up questions.

I am aware of the things that require user permission changes relative to
the two programs we have that require admin access. I wonder if there is a
way to change the permissions of these directories and registry keys in a
login script. Would you know?

My TS server is not a DC. It is nothing other than a TS server. Although
you did address another issue I have with exactly how I'm supposed to set up
a subnet for the VPN that I am using for the TS (I guess making the TS a DC
is out of the question).

Anyway the statement I made about everyone being added to the local Admin
group having full local and domain access is because this is the description
of the group on the server. Seems pretty straight forward - if I add a user
to this local group they will be local/domain admins. What don't I know?

Is there some kind of automatic connection between the Remote Desktop Users
group in AD and the TS server? Otherwise how does the TS Server know to
authenticate the users in the AD group?

Thanks for the reply and the help. Group Policy is the next project I
tackle. Seems like a big one, especially since we've never had it and there
are tons of policies. The sites you referenced should prove to be helpful.

Thanks,

MJ

"Lanwench [MVP - Exchange]" wrote:

> powlaz <powlaz@discussions.microsoft.com> wrote:
> > We have an application or two that we run where the manufacturers
> > recommends that any user be logged in as an administrator on the
> > local PC. Being the good little lambs that we are we have always
> > followed this rule.
>
> Another (better) option, besides walloping the application vendor with a
> brickbat, is to find out where in the file system and/or registry their
> software expects access, and manually changing the permissions for same.
> ProcessMonitor (Sysinternals...now downloadable from MS) will help you do
> this.
> >
> > Anyway now that we are set up with a Terminal Server I am seeing,
> > more than ever, why the need for each user to have local admin
> > rights is such a concern.
>
> No idding!
>
> > It looks to me like every user of the TS
> > needs to be added to the local Remote Desktop Users group on the TS.
>
> Well, it's better to do this with an AD security group. I like to set up one
> called TSUsers.
>
> > In addition it seems I will need to make these users members of the
> > Administrators group which unfortunately provides Admin rights to the
> > Domain as well as the local PC.
>
> Then it sounds like your TS box is a DC - that's a big no-no. Your TS box
> should be a member server with no other roles. Don't let users log in to
> your DCs, ever.
> >
> > We don't use Group Policy yet.
>
> You'll want to. You need to lock down a lot.
>
> > I'm interested in knowing what I"m
> > supposed to do now. I certainly don't want these folks to have carte
> > blanche on the network.
>
> Absolutely!
> >
> > Please help.
> >
> > MJ
>
> I'm not a guru, but here's what I've learned along the way -
>
> Basics: you should be running Terminal Services on a dedicated member server
> with *no* other roles on the network. It should be set up in its own OU,
> with a policy specifically for TS (including loopback processing so that all
> users who log in get the same settings, regardless of
> their own inherited user policy settings). See KB 278295 for some good
> lockdown suggestions. Also see MVP Patrick Rouse's articles at
> http://www.sessioncomputing.com/articles.htm
>
>
> You'll still need to figure out what your rogue apps want access to, of
> course.
>
>
>

 

[Lanwench [MVP - Exchange]]

Re: User Rights in TS

powlaz <powlaz@discussions.microsoft.com> wrote:
> Lanwench - thank you for the great answers. If I may, I have a
> couple of follow-up questions.
>
> I am aware of the things that require user permission changes
> relative to the two programs we have that require admin access. I
> wonder if there is a way to change the permissions of these
> directories and registry keys in a login script. Would you know?

Highly doubtful, as your users wouldn't have rights to make those changes,
and the login script runs as the user. You'd need to make the file system &
registry changes only once on the server anyway.
>
> My TS server is not a DC. It is nothing other than a TS server.

That's good.

> Although you did address another issue I have with exactly how I'm
> supposed to set up a subnet for the VPN that I am using for the TS (I
> guess making the TS a DC is out of the question).

Yes, that's a bad idea. Why do you need a separate subnet, and VPN?
>
> Anyway the statement I made about everyone being added to the local
> Admin group having full local and domain access is because this is
> the description of the group on the server.

If it's the local administrators group, no.

> Seems pretty straight
> forward - if I add a user to this local group they will be
> local/domain admins. What don't I know?

That would be true of the *domain* administrators group. A DC has no local
groups, but a member server does.
>
> Is there some kind of automatic connection between the Remote Desktop
> Users group in AD

There isn't one by default

> and the TS server? Otherwise how does the TS
> Server know to authenticate the users in the AD group?

The TS server needs to belong to the domain, and you would add the domain
group "TS Users" (or whatever you create) to the *local* Remote Desktop
Users group on the server.
>
> Thanks for the reply and the help. Group Policy is the next project I
> tackle. Seems like a big one, especially since we've never had it
> and there are tons of policies. The sites you referenced should
> prove to be helpful.

Definitely. Don't deploy this server til you've got that under your belt.
>
> Thanks,
>
> MJ
>
> "Lanwench [MVP - Exchange]" wrote:
>
>> powlaz <powlaz@discussions.microsoft.com> wrote:
>>> We have an application or two that we run where the manufacturers
>>> recommends that any user be logged in as an administrator on the
>>> local PC. Being the good little lambs that we are we have always
>>> followed this rule.
>>
>> Another (better) option, besides walloping the application vendor
>> with a brickbat, is to find out where in the file system and/or
>> registry their software expects access, and manually changing the
>> permissions for same. ProcessMonitor (Sysinternals...now
>> downloadable from MS) will help you do this.
>>>
>>> Anyway now that we are set up with a Terminal Server I am seeing,
>>> more than ever, why the need for each user to have local admin
>>> rights is such a concern.
>>
>> No idding!
>>
>>> It looks to me like every user of the TS
>>> needs to be added to the local Remote Desktop Users group on the TS.
>>
>> Well, it's better to do this with an AD security group. I like to
>> set up one called TSUsers.
>>
>>> In addition it seems I will need to make these users members of the
>>> Administrators group which unfortunately provides Admin rights to
>>> the Domain as well as the local PC.
>>
>> Then it sounds like your TS box is a DC - that's a big no-no. Your
>> TS box should be a member server with no other roles. Don't let
>> users log in to your DCs, ever.
>>>
>>> We don't use Group Policy yet.
>>
>> You'll want to. You need to lock down a lot.
>>
>>> I'm interested in knowing what I"m
>>> supposed to do now. I certainly don't want these folks to have
>>> carte blanche on the network.
>>
>> Absolutely!
>>>
>>> Please help.
>>>
>>> MJ
>>
>> I'm not a guru, but here's what I've learned along the way -
>>
>> Basics: you should be running Terminal Services on a dedicated
>> member server with *no* other roles on the network. It should be set
>> up in its own OU, with a policy specifically for TS (including
>> loopback processing so that all users who log in get the same
>> settings, regardless of
>> their own inherited user policy settings). See KB 278295 for some
>> good lockdown suggestions. Also see MVP Patrick Rouse's articles at
>> http://www.sessioncomputing.com/articles.htm
>>
>>
>> You'll still need to figure out what your rogue apps want access to,
>> of course.

 

[powlaz]

Re: User Rights in TS

OK - as far as setting those permissions goes, enabling full rights for the
TSClients group on each directory is a piece of cake. However, granting
those rights ito the registry keys is going to need to be done one user at a
time, right? Or will it. Is it the entire registry that is created for each
TS user or only the user-specific hives that are created? If the affected
registry keys are Machine based this may be equally as easy.

I am being instructed in multiple other forums to set my VPN up on a
separate subnet from the LAN subnet because VPN clients are generally
considered hostile. I am using the VPN because it is understood to be very
secure, because my SonicWall Pro 2040 has it and because I have 10 free
clients. I didn't bother reading about setting up an RDC session outside
of a VPN so I have no idea how secure or reliable it is. I'm trying to get
as close to the "Best Practices" way of doing things that I can. I'm
certainly interested in anything you can contribute to this.

Regarding the local Administrators group. I totally understand what you are
saying. But I'm confused by the entry here:
Computer Management > Local Users and Groups> Groups
Administrator: Administrators have complete and unrestricted access to the
computer/domain.

It reads like everyone who is added to this group will have full domain
access. Scares the bejesus out of me. Your saying that because they are not
designated as Domain Admins on my DC then this is not the case, right?
Microsoft should change the description.

Regarding the TS server and AD link - thanks for your reply about adding
TSClients group from AD to the local Remote Desktop User group. Brain fart .
.. .

Regarding deploying the server without Group Policy active. We currently
don't use GP and have been OK. That's not to say we can't be better, but
we've been OK. Will letting users work on the TS w/out GP in place be any
different or worse than having evey other user on the LAN unrestricted by
GPOs?

To conclude this post I'd just like to comment about my qualifications for
setting up TS and otherwise administering to the network. I don't have any.
Business is down and there's a freeze on spending that includes paying the
consultants who usually help with this stuff. I'm muddling through and I
truly appreciate your guidance.

MJ

"Lanwench [MVP - Exchange]" wrote:

> powlaz <powlaz@discussions.microsoft.com> wrote:
> > Lanwench - thank you for the great answers. If I may, I have a
> > couple of follow-up questions.
> >
> > I am aware of the things that require user permission changes
> > relative to the two programs we have that require admin access. I
> > wonder if there is a way to change the permissions of these
> > directories and registry keys in a login script. Would you know?
>
> Highly doubtful, as your users wouldn't have rights to make those changes,
> and the login script runs as the user. You'd need to make the file system &
> registry changes only once on the server anyway.
> >
> > My TS server is not a DC. It is nothing other than a TS server.
>
> That's good.
>
> > Although you did address another issue I have with exactly how I'm
> > supposed to set up a subnet for the VPN that I am using for the TS (I
> > guess making the TS a DC is out of the question).
>
> Yes, that's a bad idea. Why do you need a separate subnet, and VPN?
> >
> > Anyway the statement I made about everyone being added to the local
> > Admin group having full local and domain access is because this is
> > the description of the group on the server.
>
> If it's the local administrators group, no.
>
> > Seems pretty straight
> > forward - if I add a user to this local group they will be
> > local/domain admins. What don't I know?
>
> That would be true of the *domain* administrators group. A DC has no local
> groups, but a member server does.
> >
> > Is there some kind of automatic connection between the Remote Desktop
> > Users group in AD
>
> There isn't one by default
>
> > and the TS server? Otherwise how does the TS
> > Server know to authenticate the users in the AD group?
>
> The TS server needs to belong to the domain, and you would add the domain
> group "TS Users" (or whatever you create) to the *local* Remote Desktop
> Users group on the server.
> >
> > Thanks for the reply and the help. Group Policy is the next project I
> > tackle. Seems like a big one, especially since we've never had it
> > and there are tons of policies. The sites you referenced should
> > prove to be helpful.
>
> Definitely. Don't deploy this server til you've got that under your belt.
> >
> > Thanks,
> >
> > MJ
> >
> > "Lanwench [MVP - Exchange]" wrote:
> >
> >> powlaz <powlaz@discussions.microsoft.com> wrote:
> >>> We have an application or two that we run where the manufacturers
> >>> recommends that any user be logged in as an administrator on the
> >>> local PC. Being the good little lambs that we are we have always
> >>> followed this rule.
> >>
> >> Another (better) option, besides walloping the application vendor
> >> with a brickbat, is to find out where in the file system and/or
> >> registry their software expects access, and manually changing the
> >> permissions for same. ProcessMonitor (Sysinternals...now
> >> downloadable from MS) will help you do this.
> >>>
> >>> Anyway now that we are set up with a Terminal Server I am seeing,
> >>> more than ever, why the need for each user to have local admin
> >>> rights is such a concern.
> >>
> >> No idding!
> >>
> >>> It looks to me like every user of the TS
> >>> needs to be added to the local Remote Desktop Users group on the TS.
> >>
> >> Well, it's better to do this with an AD security group. I like to
> >> set up one called TSUsers.
> >>
> >>> In addition it seems I will need to make these users members of the
> >>> Administrators group which unfortunately provides Admin rights to
> >>> the Domain as well as the local PC.
> >>
> >> Then it sounds like your TS box is a DC - that's a big no-no. Your
> >> TS box should be a member server with no other roles. Don't let
> >> users log in to your DCs, ever.
> >>>
> >>> We don't use Group Policy yet.
> >>
> >> You'll want to. You need to lock down a lot.
> >>
> >>> I'm interested in knowing what I"m
> >>> supposed to do now. I certainly don't want these folks to have
> >>> carte blanche on the network.
> >>
> >> Absolutely!
> >>>
> >>> Please help.
> >>>
> >>> MJ
> >>
> >> I'm not a guru, but here's what I've learned along the way -
> >>
> >> Basics: you should be running Terminal Services on a dedicated
> >> member server with *no* other roles on the network. It should be set
> >> up in its own OU, with a policy specifically for TS (including
> >> loopback processing so that all users who log in get the same
> >> settings, regardless of
> >> their own inherited user policy settings). See KB 278295 for some
> >> good lockdown suggestions. Also see MVP Patrick Rouse's articles at
> >> http://www.sessioncomputing.com/articles.htm
> >>
> >>
> >> You'll still need to figure out what your rogue apps want access to,
> >> of course.
>
>
>
>

 

[Lanwench [MVP - Exchange]]

Re: User Rights in TS

powlaz <powlaz@discussions.microsoft.com> wrote:
> OK - as far as setting those permissions goes, enabling full rights
> for the TSClients group on each directory is a piece of cake.

Sure, although I'd set it to the built-in local Users group, probably

> However, granting those rights ito the registry keys is going to need
> to be done one user at a time, right? Or will it.

Depends on where in the registry it is. If its HKCU, yes.

> Is it the entire
> registry that is created for each TS user or only the user-specific
> hives that are created?

It's the same as a workstation. The most important ones will be, HKLM, HKU,
and HKCU. This depends entirely on the app.

> If the affected registry keys are Machine
> based this may be equally as easy.

Yes.
>
> I am being instructed in multiple other forums to set my VPN up on a
> separate subnet from the LAN subnet because VPN clients are generally
> considered hostile.
]
Eh?

> I am using the VPN because it is understood to
> be very secure, because my SonicWall Pro 2040 has it and because I
> have 10 free clients.

Sure, although I'd probably use a Sonicwall SSL-VPN appliance if I wanted
VPN for TS.

> I didn't bother reading about setting up an
> RDC session outside of a VPN so I have no idea how secure or reliable
> it is.

Pretty darned secure and very reliable.

> I'm trying to get as close to the "Best Practices" way of
> doing things that I can. I'm certainly interested in anything you
> can contribute to this.

You can use VPN, but you don't have to...
>
> Regarding the local Administrators group. I totally understand what
> you are saying. But I'm confused by the entry here:
> Computer Management > Local Users and Groups> Groups
> Administrator: Administrators have complete and unrestricted access
> to the computer/domain.

Ah. Well, domain admins *can*. A local user or group has *no* network
privileges whatsoever.
>
> It reads like everyone who is added to this group will have full
> domain access.

No, these are local groups.

> Scares the bejesus out of me. Your saying that
> because they are not designated as Domain Admins on my DC then this
> is not the case, right? Microsoft should change the description.

That's the case. The group Administrators, as a word, could include domain
administrators.
>
> Regarding the TS server and AD link - thanks for your reply about
> adding TSClients group from AD to the local Remote Desktop User
> group. Brain fart . . .

No prob.
>
> Regarding deploying the server without Group Policy active. We
> currently don't use GP and have been OK. That's not to say we can't
> be better, but we've been OK. Will letting users work on the TS
> w/out GP in place be any different or worse than having evey other
> user on the LAN unrestricted by GPOs?

You're running a huge risk by not locking down this server by group policy,
because if you have multiple users logged in, and one user screws up
something, it screws everyone. A workstation used by one user at a time is
less of a concern. Read the docs & do set up policies to protect this server
before you let people use it - it's important, and not that hard. You could
also get a consultant in to help you out with it.
>
> To conclude this post I'd just like to comment about my
> qualifications for setting up TS and otherwise administering to the
> network. I don't have any.

No worries ;-)

> Business is down and there's a freeze on
> spending that includes paying the consultants who usually help with
> this stuff.

You might remind your company management that it costs significantly more to
re-do things that blow up, than to do them right the first time. How much
would it cost for a couple of hours of expert consuling time for all this?
$300? Seems like money well spent to me. Even if I have a limited budget for
auto repair, and can change my own oil, I'm not going to attempt to rebuild
my own transmission. I'm just saying.
'

> I'm muddling through and I truly appreciate your
> guidance.

No problem. Download & install the group policy management console (GPMC) on
your domain controller if you don't have it already. It's very handy for
modeling/experimenting with settings. The main thing to do is ensure that
you don't lock yourself (as admin) out when you're trying to lock out your
users!

Try subscribing to microsoft.public.windows.group_policy and perhaps check
out
http://www.amazon.com/Group-Policy-...=sr_1_1?ie=UTF8&s=books&qid=1221689092&sr=1-1.
>
> MJ
>
> "Lanwench [MVP - Exchange]" wrote:
>
>> powlaz <powlaz@discussions.microsoft.com> wrote:
>>> Lanwench - thank you for the great answers. If I may, I have a
>>> couple of follow-up questions.
>>>
>>> I am aware of the things that require user permission changes
>>> relative to the two programs we have that require admin access. I
>>> wonder if there is a way to change the permissions of these
>>> directories and registry keys in a login script. Would you know?
>>
>> Highly doubtful, as your users wouldn't have rights to make those
>> changes, and the login script runs as the user. You'd need to make
>> the file system & registry changes only once on the server anyway.
>>>
>>> My TS server is not a DC. It is nothing other than a TS server.
>>
>> That's good.
>>
>>> Although you did address another issue I have with exactly how I'm
>>> supposed to set up a subnet for the VPN that I am using for the TS
>>> (I guess making the TS a DC is out of the question).
>>
>> Yes, that's a bad idea. Why do you need a separate subnet, and VPN?
>>>
>>> Anyway the statement I made about everyone being added to the local
>>> Admin group having full local and domain access is because this is
>>> the description of the group on the server.
>>
>> If it's the local administrators group, no.
>>
>>> Seems pretty straight
>>> forward - if I add a user to this local group they will be
>>> local/domain admins. What don't I know?
>>
>> That would be true of the *domain* administrators group. A DC has no
>> local groups, but a member server does.
>>>
>>> Is there some kind of automatic connection between the Remote
>>> Desktop Users group in AD
>>
>> There isn't one by default
>>
>>> and the TS server? Otherwise how does the TS
>>> Server know to authenticate the users in the AD group?
>>
>> The TS server needs to belong to the domain, and you would add the
>> domain group "TS Users" (or whatever you create) to the *local*
>> Remote Desktop Users group on the server.
>>>
>>> Thanks for the reply and the help. Group Policy is the next
>>> project I tackle. Seems like a big one, especially since we've
>>> never had it and there are tons of policies. The sites you
>>> referenced should prove to be helpful.
>>
>> Definitely. Don't deploy this server til you've got that under your
>> belt.
>>>
>>> Thanks,
>>>
>>> MJ
>>>
>>> "Lanwench [MVP - Exchange]" wrote:
>>>
>>>> powlaz <powlaz@discussions.microsoft.com> wrote:
>>>>> We have an application or two that we run where the manufacturers
>>>>> recommends that any user be logged in as an administrator on the
>>>>> local PC. Being the good little lambs that we are we have always
>>>>> followed this rule.
>>>>
>>>> Another (better) option, besides walloping the application vendor
>>>> with a brickbat, is to find out where in the file system and/or
>>>> registry their software expects access, and manually changing the
>>>> permissions for same. ProcessMonitor (Sysinternals...now
>>>> downloadable from MS) will help you do this.
>>>>>
>>>>> Anyway now that we are set up with a Terminal Server I am seeing,
>>>>> more than ever, why the need for each user to have local admin
>>>>> rights is such a concern.
>>>>
>>>> No idding!
>>>>
>>>>> It looks to me like every user of the TS
>>>>> needs to be added to the local Remote Desktop Users group on the
>>>>> TS.
>>>>
>>>> Well, it's better to do this with an AD security group. I like to
>>>> set up one called TSUsers.
>>>>
>>>>> In addition it seems I will need to make these users members of
>>>>> the Administrators group which unfortunately provides Admin
>>>>> rights to the Domain as well as the local PC.
>>>>
>>>> Then it sounds like your TS box is a DC - that's a big no-no. Your
>>>> TS box should be a member server with no other roles. Don't let
>>>> users log in to your DCs, ever.
>>>>>
>>>>> We don't use Group Policy yet.
>>>>
>>>> You'll want to. You need to lock down a lot.
>>>>
>>>>> I'm interested in knowing what I"m
>>>>> supposed to do now. I certainly don't want these folks to have
>>>>> carte blanche on the network.
>>>>
>>>> Absolutely!
>>>>>
>>>>> Please help.
>>>>>
>>>>> MJ
>>>>
>>>> I'm not a guru, but here's what I've learned along the way -
>>>>
>>>> Basics: you should be running Terminal Services on a dedicated
>>>> member server with *no* other roles on the network. It should be
>>>> set up in its own OU, with a policy specifically for TS (including
>>>> loopback processing so that all users who log in get the same
>>>> settings, regardless of
>>>> their own inherited user policy settings). See KB 278295 for some
>>>> good lockdown suggestions. Also see MVP Patrick Rouse's articles at
>>>> http://www.sessioncomputing.com/articles.htm
>>>>
>>>>
>>>> You'll still need to figure out what your rogue apps want access
>>>> to, of course.

 

[powlaz]

Re: User Rights in TS

Lanwench, thanks to your help I'm moving along. I took care of the file and
registry permission changes that I needed to make. The registry key that I
needed to modify was an HKLM key (yeah!). Everything worked.

Your comment "Eh?" regarding the direction I've been given to set up a
different subnet for VPN clients is intriguing. Will you elaborate? Is it
not a best practice or is it an old logic or an unecessary step to separate
VPN subnets and LAN subnets???

Regarding you comment about one user ruining things for all users if
something goes wrong in their session troubles me. I was working under the
impression that TS on Server 2003 natively prevents one bad session from
crashing or corrupting the others - not that Group Policy puts this
protection into place.

I have the GPO Management tool already installed on my DC. I also plan to
explore the GPO Accelerator that Microsoft puts out because I like the idea
of having 'Best Practices' level security in the click of a button. Is there
such a thing as prepacked GPOs or a GPO exchange? I would love to be able to
just import solid GPOs . . .

I got approval for the book you recommended this morning - much obliged.

MJ

"Lanwench [MVP - Exchange]" wrote:

> powlaz <powlaz@discussions.microsoft.com> wrote:
> > OK - as far as setting those permissions goes, enabling full rights
> > for the TSClients group on each directory is a piece of cake.
>
> Sure, although I'd set it to the built-in local Users group, probably
>
> > However, granting those rights ito the registry keys is going to need
> > to be done one user at a time, right? Or will it.
>
> Depends on where in the registry it is. If its HKCU, yes.
>
> > Is it the entire
> > registry that is created for each TS user or only the user-specific
> > hives that are created?
>
> It's the same as a workstation. The most important ones will be, HKLM, HKU,
> and HKCU. This depends entirely on the app.
>
> > If the affected registry keys are Machine
> > based this may be equally as easy.
>
> Yes.
> >
> > I am being instructed in multiple other forums to set my VPN up on a
> > separate subnet from the LAN subnet because VPN clients are generally
> > considered hostile.
> ]
> Eh?
>
> > I am using the VPN because it is understood to
> > be very secure, because my SonicWall Pro 2040 has it and because I
> > have 10 free clients.
>
> Sure, although I'd probably use a Sonicwall SSL-VPN appliance if I wanted
> VPN for TS.
>
> > I didn't bother reading about setting up an
> > RDC session outside of a VPN so I have no idea how secure or reliable
> > it is.
>
> Pretty darned secure and very reliable.
>
> > I'm trying to get as close to the "Best Practices" way of
> > doing things that I can. I'm certainly interested in anything you
> > can contribute to this.
>
> You can use VPN, but you don't have to...
> >
> > Regarding the local Administrators group. I totally understand what
> > you are saying. But I'm confused by the entry here:
> > Computer Management > Local Users and Groups> Groups
> > Administrator: Administrators have complete and unrestricted access
> > to the computer/domain.
>
> Ah. Well, domain admins *can*. A local user or group has *no* network
> privileges whatsoever.
> >
> > It reads like everyone who is added to this group will have full
> > domain access.
>
> No, these are local groups.
>
> > Scares the bejesus out of me. Your saying that
> > because they are not designated as Domain Admins on my DC then this
> > is not the case, right? Microsoft should change the description.
>
> That's the case. The group Administrators, as a word, could include domain
> administrators.
> >
> > Regarding the TS server and AD link - thanks for your reply about
> > adding TSClients group from AD to the local Remote Desktop User
> > group. Brain fart . . .
>
> No prob.
> >
> > Regarding deploying the server without Group Policy active. We
> > currently don't use GP and have been OK. That's not to say we can't
> > be better, but we've been OK. Will letting users work on the TS
> > w/out GP in place be any different or worse than having evey other
> > user on the LAN unrestricted by GPOs?
>
> You're running a huge risk by not locking down this server by group policy,
> because if you have multiple users logged in, and one user screws up
> something, it screws everyone. A workstation used by one user at a time is
> less of a concern. Read the docs & do set up policies to protect this server
> before you let people use it - it's important, and not that hard. You could
> also get a consultant in to help you out with it.
> >
> > To conclude this post I'd just like to comment about my
> > qualifications for setting up TS and otherwise administering to the
> > network. I don't have any.
>
> No worries ;-)
>
> > Business is down and there's a freeze on
> > spending that includes paying the consultants who usually help with
> > this stuff.
>
> You might remind your company management that it costs significantly more to
> re-do things that blow up, than to do them right the first time. How much
> would it cost for a couple of hours of expert consuling time for all this?
> $300? Seems like money well spent to me. Even if I have a limited budget for
> auto repair, and can change my own oil, I'm not going to attempt to rebuild
> my own transmission. I'm just saying.
> '
>
> > I'm muddling through and I truly appreciate your
> > guidance.
>
> No problem. Download & install the group policy management console (GPMC) on
> your domain controller if you don't have it already. It's very handy for
> modeling/experimenting with settings. The main thing to do is ensure that
> you don't lock yourself (as admin) out when you're trying to lock out your
> users!
>
> Try subscribing to microsoft.public.windows.group_policy and perhaps check
> out
> http://www.amazon.com/Group-Policy-...=sr_1_1?ie=UTF8&s=books&qid=1221689092&sr=1-1.
> >
> > MJ
> >
> > "Lanwench [MVP - Exchange]" wrote:
> >
> >> powlaz <powlaz@discussions.microsoft.com> wrote:
> >>> Lanwench - thank you for the great answers. If I may, I have a
> >>> couple of follow-up questions.
> >>>
> >>> I am aware of the things that require user permission changes
> >>> relative to the two programs we have that require admin access. I
> >>> wonder if there is a way to change the permissions of these
> >>> directories and registry keys in a login script. Would you know?
> >>
> >> Highly doubtful, as your users wouldn't have rights to make those
> >> changes, and the login script runs as the user. You'd need to make
> >> the file system & registry changes only once on the server anyway.
> >>>
> >>> My TS server is not a DC. It is nothing other than a TS server.
> >>
> >> That's good.
> >>
> >>> Although you did address another issue I have with exactly how I'm
> >>> supposed to set up a subnet for the VPN that I am using for the TS
> >>> (I guess making the TS a DC is out of the question).
> >>
> >> Yes, that's a bad idea. Why do you need a separate subnet, and VPN?
> >>>
> >>> Anyway the statement I made about everyone being added to the local
> >>> Admin group having full local and domain access is because this is
> >>> the description of the group on the server.
> >>
> >> If it's the local administrators group, no.
> >>
> >>> Seems pretty straight
> >>> forward - if I add a user to this local group they will be
> >>> local/domain admins. What don't I know?
> >>
> >> That would be true of the *domain* administrators group. A DC has no
> >> local groups, but a member server does.
> >>>
> >>> Is there some kind of automatic connection between the Remote
> >>> Desktop Users group in AD
> >>
> >> There isn't one by default
> >>
> >>> and the TS server? Otherwise how does the TS
> >>> Server know to authenticate the users in the AD group?
> >>
> >> The TS server needs to belong to the domain, and you would add the
> >> domain group "TS Users" (or whatever you create) to the *local*
> >> Remote Desktop Users group on the server.
> >>>
> >>> Thanks for the reply and the help. Group Policy is the next
> >>> project I tackle. Seems like a big one, especially since we've
> >>> never had it and there are tons of policies. The sites you
> >>> referenced should prove to be helpful.
> >>
> >> Definitely. Don't deploy this server til you've got that under your
> >> belt.
> >>>
> >>> Thanks,
> >>>
> >>> MJ
> >>>
> >>> "Lanwench [MVP - Exchange]" wrote:
> >>>
> >>>> powlaz <powlaz@discussions.microsoft.com> wrote:
> >>>>> We have an application or two that we run where the manufacturers
> >>>>> recommends that any user be logged in as an administrator on the
> >>>>> local PC. Being the good little lambs that we are we have always
> >>>>> followed this rule.
> >>>>
> >>>> Another (better) option, besides walloping the application vendor
> >>>> with a brickbat, is to find out where in the file system and/or
> >>>> registry their software expects access, and manually changing the
> >>>> permissions for same. ProcessMonitor (Sysinternals...now
> >>>> downloadable from MS) will help you do this.
> >>>>>
> >>>>> Anyway now that we are set up with a Terminal Server I am seeing,
> >>>>> more than ever, why the need for each user to have local admin
> >>>>> rights is such a concern.
> >>>>
> >>>> No idding!
> >>>>
> >>>>> It looks to me like every user of the TS
> >>>>> needs to be added to the local Remote Desktop Users group on the
> >>>>> TS.
> >>>>
> >>>> Well, it's better to do this with an AD security group. I like to
> >>>> set up one called TSUsers.
> >>>>
> >>>>> In addition it seems I will need to make these users members of
> >>>>> the Administrators group which unfortunately provides Admin
> >>>>> rights to the Domain as well as the local PC.
> >>>>
> >>>> Then it sounds like your TS box is a DC - that's a big no-no. Your
> >>>> TS box should be a member server with no other roles. Don't let
> >>>> users log in to your DCs, ever.
> >>>>>
> >>>>> We don't use Group Policy yet.
> >>>>
> >>>> You'll want to. You need to lock down a lot.
> >>>>
> >>>>> I'm interested in knowing what I"m
> >>>>> supposed to do now. I certainly don't want these folks to have
> >>>>> carte blanche on the network.
> >>>>
> >>>> Absolutely!
> >>>>>
> >>>>> Please help.
> >>>>>
> >>>>> MJ
> >>>>
> >>>> I'm not a guru, but here's what I've learned along the way -
> >>>>
> >>>> Basics: you should be running Terminal Services on a dedicated
> >>>> member server with *no* other roles on the network. It should be
> >>>> set up in its own OU, with a policy specifically for TS (including
> >>>> loopback processing so that all users who log in get the same
> >>>> settings, regardless of
> >>>> their own inherited user policy settings). See KB 278295 for some
> >>>> good lockdown suggestions. Also see MVP Patrick Rouse's articles at
> >>>> http://www.sessioncomputing.com/articles.htm
> >>>>
> >>>>
> >>>> You'll still need to figure out what your rogue apps want access
> >>>> to, of course.
>
>
>
>

 

[Lanwench [MVP - Exchange]]

Re: User Rights in TS

powlaz <powlaz@discussions.microsoft.com> wrote:
> Lanwench, thanks to your help I'm moving along. I took care of the
> file and registry permission changes that I needed to make. The
> registry key that I needed to modify was an HKLM key (yeah!).
> Everything worked.

That's wonderful - now you can do the same thing on your workstations &
revoke the admin rights there, too.
>
> Your comment "Eh?" regarding the direction I've been given to set up a
> different subnet for VPN clients is intriguing. Will you elaborate?
> Is it not a best practice or is it an old logic or an unecessary step
> to separate VPN subnets and LAN subnets???

I guess I'm asking why use VPN at all.
>
> Regarding you comment about one user ruining things for all users if
> something goes wrong in their session troubles me. I was working
> under the impression that TS on Server 2003 natively prevents one bad
> session from crashing or corrupting the others - not that Group
> Policy puts this protection into place.

Nope. It's a big fat shared workstation. Someone buggers up your software,
it's a mess for everyone.
>
> I have the GPO Management tool already installed on my DC. I also
> plan to explore the GPO Accelerator that Microsoft puts out because I
> like the idea of having 'Best Practices' level security in the click
> of a button. Is there such a thing as prepacked GPOs or a GPO
> exchange? I would love to be able to just import solid GPOs . . .

I'm not sure, honestly. Subscribe to m.p.windows.group_policy and ask there.
>
> I got approval for the book you recommended this morning - much
> obliged.

Glad to hear it. Have fun storming the castle!
>
> MJ
>
> "Lanwench [MVP - Exchange]" wrote:
>
>> powlaz <powlaz@discussions.microsoft.com> wrote:
>>> OK - as far as setting those permissions goes, enabling full rights
>>> for the TSClients group on each directory is a piece of cake.
>>
>> Sure, although I'd set it to the built-in local Users group, probably
>>
>>> However, granting those rights ito the registry keys is going to
>>> need to be done one user at a time, right? Or will it.
>>
>> Depends on where in the registry it is. If its HKCU, yes.
>>
>>> Is it the entire
>>> registry that is created for each TS user or only the user-specific
>>> hives that are created?
>>
>> It's the same as a workstation. The most important ones will be,
>> HKLM, HKU, and HKCU. This depends entirely on the app.
>>
>>> If the affected registry keys are Machine
>>> based this may be equally as easy.
>>
>> Yes.
>>>
>>> I am being instructed in multiple other forums to set my VPN up on a
>>> separate subnet from the LAN subnet because VPN clients are
>>> generally considered hostile.
>> ]
>> Eh?
>>
>>> I am using the VPN because it is understood to
>>> be very secure, because my SonicWall Pro 2040 has it and because I
>>> have 10 free clients.
>>
>> Sure, although I'd probably use a Sonicwall SSL-VPN appliance if I
>> wanted VPN for TS.
>>
>>> I didn't bother reading about setting up an
>>> RDC session outside of a VPN so I have no idea how secure or
>>> reliable it is.
>>
>> Pretty darned secure and very reliable.
>>
>>> I'm trying to get as close to the "Best Practices" way of
>>> doing things that I can. I'm certainly interested in anything you
>>> can contribute to this.
>>
>> You can use VPN, but you don't have to...
>>>
>>> Regarding the local Administrators group. I totally understand what
>>> you are saying. But I'm confused by the entry here:
>>> Computer Management > Local Users and Groups> Groups
>>> Administrator: Administrators have complete and unrestricted access
>>> to the computer/domain.
>>
>> Ah. Well, domain admins *can*. A local user or group has *no* network
>> privileges whatsoever.
>>>
>>> It reads like everyone who is added to this group will have full
>>> domain access.
>>
>> No, these are local groups.
>>
>>> Scares the bejesus out of me. Your saying that
>>> because they are not designated as Domain Admins on my DC then this
>>> is not the case, right? Microsoft should change the description.
>>
>> That's the case. The group Administrators, as a word, could include
>> domain administrators.
>>>
>>> Regarding the TS server and AD link - thanks for your reply about
>>> adding TSClients group from AD to the local Remote Desktop User
>>> group. Brain fart . . .
>>
>> No prob.
>>>
>>> Regarding deploying the server without Group Policy active. We
>>> currently don't use GP and have been OK. That's not to say we can't
>>> be better, but we've been OK. Will letting users work on the TS
>>> w/out GP in place be any different or worse than having evey other
>>> user on the LAN unrestricted by GPOs?
>>
>> You're running a huge risk by not locking down this server by group
>> policy, because if you have multiple users logged in, and one user
>> screws up something, it screws everyone. A workstation used by one
>> user at a time is less of a concern. Read the docs & do set up
>> policies to protect this server before you let people use it - it's
>> important, and not that hard. You could also get a consultant in to
>> help you out with it.
>>>
>>> To conclude this post I'd just like to comment about my
>>> qualifications for setting up TS and otherwise administering to the
>>> network. I don't have any.
>>
>> No worries ;-)
>>
>>> Business is down and there's a freeze on
>>> spending that includes paying the consultants who usually help with
>>> this stuff.
>>
>> You might remind your company management that it costs significantly
>> more to re-do things that blow up, than to do them right the first
>> time. How much would it cost for a couple of hours of expert
>> consuling time for all this? $300? Seems like money well spent to
>> me. Even if I have a limited budget for auto repair, and can change
>> my own oil, I'm not going to attempt to rebuild my own transmission.
>> I'm just saying. '
>>
>>> I'm muddling through and I truly appreciate your
>>> guidance.
>>
>> No problem. Download & install the group policy management console
>> (GPMC) on your domain controller if you don't have it already. It's
>> very handy for modeling/experimenting with settings. The main thing
>> to do is ensure that you don't lock yourself (as admin) out when
>> you're trying to lock out your users!
>>
>> Try subscribing to microsoft.public.windows.group_policy and perhaps
>> check out
>> http://www.amazon.com/Group-Policy-...=sr_1_1?ie=UTF8&s=books&qid=1221689092&sr=1-1.
>>>
>>> MJ
>>>
>>> "Lanwench [MVP - Exchange]" wrote:
>>>
>>>> powlaz <powlaz@discussions.microsoft.com> wrote:
>>>>> Lanwench - thank you for the great answers. If I may, I have a
>>>>> couple of follow-up questions.
>>>>>
>>>>> I am aware of the things that require user permission changes
>>>>> relative to the two programs we have that require admin access. I
>>>>> wonder if there is a way to change the permissions of these
>>>>> directories and registry keys in a login script. Would you know?
>>>>
>>>> Highly doubtful, as your users wouldn't have rights to make those
>>>> changes, and the login script runs as the user. You'd need to make
>>>> the file system & registry changes only once on the server anyway.
>>>>>
>>>>> My TS server is not a DC. It is nothing other than a TS server.
>>>>
>>>> That's good.
>>>>
>>>>> Although you did address another issue I have with exactly how I'm
>>>>> supposed to set up a subnet for the VPN that I am using for the TS
>>>>> (I guess making the TS a DC is out of the question).
>>>>
>>>> Yes, that's a bad idea. Why do you need a separate subnet, and
>>>> VPN?
>>>>>
>>>>> Anyway the statement I made about everyone being added to the
>>>>> local Admin group having full local and domain access is because
>>>>> this is the description of the group on the server.
>>>>
>>>> If it's the local administrators group, no.
>>>>
>>>>> Seems pretty straight
>>>>> forward - if I add a user to this local group they will be
>>>>> local/domain admins. What don't I know?
>>>>
>>>> That would be true of the *domain* administrators group. A DC has
>>>> no local groups, but a member server does.
>>>>>
>>>>> Is there some kind of automatic connection between the Remote
>>>>> Desktop Users group in AD
>>>>
>>>> There isn't one by default
>>>>
>>>>> and the TS server? Otherwise how does the TS
>>>>> Server know to authenticate the users in the AD group?
>>>>
>>>> The TS server needs to belong to the domain, and you would add the
>>>> domain group "TS Users" (or whatever you create) to the *local*
>>>> Remote Desktop Users group on the server.
>>>>>
>>>>> Thanks for the reply and the help. Group Policy is the next
>>>>> project I tackle. Seems like a big one, especially since we've
>>>>> never had it and there are tons of policies. The sites you
>>>>> referenced should prove to be helpful.
>>>>
>>>> Definitely. Don't deploy this server til you've got that under your
>>>> belt.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> MJ
>>>>>
>>>>> "Lanwench [MVP - Exchange]" wrote:
>>>>>
>>>>>> powlaz <powlaz@discussions.microsoft.com> wrote:
>>>>>>> We have an application or two that we run where the
>>>>>>> manufacturers recommends that any user be logged in as an
>>>>>>> administrator on the local PC. Being the good little lambs
>>>>>>> that we are we have always followed this rule.
>>>>>>
>>>>>> Another (better) option, besides walloping the application vendor
>>>>>> with a brickbat, is to find out where in the file system and/or
>>>>>> registry their software expects access, and manually changing the
>>>>>> permissions for same. ProcessMonitor (Sysinternals...now
>>>>>> downloadable from MS) will help you do this.
>>>>>>>
>>>>>>> Anyway now that we are set up with a Terminal Server I am
>>>>>>> seeing, more than ever, why the need for each user to have
>>>>>>> local admin rights is such a concern.
>>>>>>
>>>>>> No idding!
>>>>>>
>>>>>>> It looks to me like every user of the TS
>>>>>>> needs to be added to the local Remote Desktop Users group on the
>>>>>>> TS.
>>>>>>
>>>>>> Well, it's better to do this with an AD security group. I like to
>>>>>> set up one called TSUsers.
>>>>>>
>>>>>>> In addition it seems I will need to make these users members of
>>>>>>> the Administrators group which unfortunately provides Admin
>>>>>>> rights to the Domain as well as the local PC.
>>>>>>
>>>>>> Then it sounds like your TS box is a DC - that's a big no-no.
>>>>>> Your TS box should be a member server with no other roles. Don't
>>>>>> let users log in to your DCs, ever.
>>>>>>>
>>>>>>> We don't use Group Policy yet.
>>>>>>
>>>>>> You'll want to. You need to lock down a lot.
>>>>>>
>>>>>>> I'm interested in knowing what I"m
>>>>>>> supposed to do now. I certainly don't want these folks to have
>>>>>>> carte blanche on the network.
>>>>>>
>>>>>> Absolutely!
>>>>>>>
>>>>>>> Please help.
>>>>>>>
>>>>>>> MJ
>>>>>>
>>>>>> I'm not a guru, but here's what I've learned along the way -
>>>>>>
>>>>>> Basics: you should be running Terminal Services on a dedicated
>>>>>> member server with *no* other roles on the network. It should be
>>>>>> set up in its own OU, with a policy specifically for TS
>>>>>> (including loopback processing so that all users who log in get
>>>>>> the same settings, regardless of
>>>>>> their own inherited user policy settings). See KB 278295 for some
>>>>>> good lockdown suggestions. Also see MVP Patrick Rouse's articles
>>>>>> at http://www.sessioncomputing.com/articles.htm
>>>>>>
>>>>>>
>>>>>> You'll still need to figure out what your rogue apps want access
>>>>>> to, of course.