User Rights in TS

[Guest 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

[Guest 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.

[Guest 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.

>

>

>

[Guest 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.

[Guest 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.

>

>

>

>

[Guest 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-Fundamentals-Security-Troubleshooting/dp/0470275898/ref=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.

[Guest 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-Fundamentals-Security-Troubleshooting/dp/0470275898/ref=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.

>

>

>

>

[Guest 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-Fundamentals-Security-Troubleshooting/dp/0470275898/ref=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.