Re: User Rights in TS

powlaz <powlaz@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx> 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.



.

Relevant Pages

  • Re: Demoting administrator to reader does not work!
    ... Local Administrators on the server also get admin rights ... Microsoft MVP - Sharepoint Portal Server ...
    (microsoft.public.sharepoint.portalserver)
  • Re: Giving user / group ability to logoff user
    ... Tell the administrators to logoff and not lock the computer. ... > as these select users can log in to the server. ... > operators (whom have no admin privilages)are stuck. ...
    (microsoft.public.win2000.security)
  • Re: User Rights in TS
    ... follow-up questions. ... It is nothing other than a TS server. ... Anyway the statement I made about everyone being added to the local Admin ... Group Policy is the next project I ...
    (microsoft.public.windows.terminal_services)
  • Re: Start menu -> Shutdown
    ... On 2003, if you don't have Administrators rights, you don't get the ... will see the option to shutdown the server. ... I found the Group Policy path you mentioned (Computer ...
    (microsoft.public.windows.terminal_services)
  • Re: Restrict to 1 program
    ... If I were to try to change these setting remotely (gpo changes maybe too) ... On the Terminal Server, go to Start menu - Administrative ... apply to everyone, and that includes Administrators. ... If I didn't want to use a group policy, ...
    (microsoft.public.windows.terminal_services)
Quantcast