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@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: Ownsership and Rights
    ... Full Controll set up for bothe the NTFS and for the share. ... Also, when I am logged into the server as Administrator, and I check the ... Effective Permissions does not work as well. ... That I'm working on has share rights of Everyone, ...
    (microsoft.public.windows.server.sbs)
  • Re: Problem sending emails
    ... you may want to review the security you've put into place and undo it to see ... The 5.7.1 event you're seeing is usually a permissions related issue on the ... SMTP virtual server. ... This posting is provided "AS IS" with no warranties, and confers no rights. ...
    (microsoft.public.exchange.connectivity)
  • Re: Windows 2003 DC Demotion / Promotion
    ... Windows Server 2003 SP1 introduces rights that give an administrator ... control over local and remote permissions for starting COM servers, ...
    (microsoft.public.windows.server.active_directory)
  • Re: project manager cannot connect with MS Project Pro
    ... "Gary L. Chefetz " wrote: ... >> New project manager cannot connect to the Project server with MS Project ... >> He has the same rights and permissions as other project managers. ...
    (microsoft.public.project.pro_and_server)
  • Re: Please Help! I screwed something up!
    ... the user you used to open ESM is member of Administrators Group. ... I had been running the Microsoft Exchange Best Practices Analyzer 2.6 ... lone Exchange 2003 server. ... It kept coming back with a permissions error. ...
    (microsoft.public.exchange.admin)