Remote access to member server

[Al Williams]

We have a contractor who needs remote access to a Windows 2003 member server
in our SBS 2003 Premium network to do some short-term maintenance on a LOB
application we run on it. I know I can get him remote access via the remote
web workplace (access server desktops) but is there anyway to just give him
access to just the member server directly without using RWW? I don't really
want to expose the RWW interface to our entire system to them if I don't
have to.

Thanks.

--
Allan Williams

[Merv Porter [SBS-MVP]]

Hi Al,

Unfortunately, per user restrictions can't be done within RWW. Now, if you
want to always restrict access for that user (both when on the LAN and when
using RWW), you can use:

Server Management | Standard Management | Users | (rt click) the user
account | Properties | Account (tab) | Log On To... | The Following
Computers...

Then add the target member server to the list AND also add the SBS server.
You need the SBS server specified so that the user can authenticate to the
server when logging into RWW (however, he will not be able to log onto the
SBS server itself).

The user will "see" all workstations (and the member server) in the RWW list
of computers, but will only be able to log onto the member server itself.

--
Merv Porter [SBS-MVP]
============================

"Al Williams" <donotrep...@usenewsgroup.com> wrote in message
news:e5htnBo3...@TK2MSFTNGP06.phx.gbl...

[Al Williams]

What about outside of RWW - does anything exist to just goto the remote
login for that server?

The member server is a terminal server, so I suppose I should be able to set
it up for remote users to login to directly but I'm not sure how (currently
it is for internal LAN use only).

Thx

--
Allan Williams

"Merv Porter [SBS-MVP]" <mwport@no_spam_hotmail.com> wrote in message
news:OLhuCdp3...@TK2MSFTNGP06.phx.gbl...

[Merv Porter [SBS-MVP]]

Take a look at this thread Al...

SBS 2003 and ISA 2004, publish TS Server
http://groups.google.com/group/microsoft.public.windows.server.sbs/browse_thread/thread/f6e4d5e6ad382c4f/6d6db9c2395c8fc8?lnk=st&q=rww+isa+2004+terminal+server&rnum=1&hl=en#6d6db9c2395c8fc8

--
Merv Porter [SBS-MVP]
============================

"Al Williams" <donotrep...@usenewsgroup.com> wrote in message

news:uYTsJJq3...@TK2MSFTNGP04.phx.gbl...

[Larry Struckmeyer at dot]

Hi:

Did not read the thread that Merv posted, so this may have been covered.

First, seems to me that once the LOB person is connected to anything on your
LAN, you have exposed your entire network to him. Browse Network
Neighborhood???

Second, he will need access, so either he is a 'user' or he is an
administrator. If he poses as one of the existing users, you won't need a
license for him, but you will want to change password after he is done?

Third: have not tried this with SBS2003 as the front end, but for years we
VPN'd to the SBS 2000 servers, then RDP to the ip of our choice, either the
ip of the SBS or the IP of the TS. You might could keep the LOB guy from
logon to any system but the TS with policies for that user?

Larry

"Merv Porter [SBS-MVP]" <mwport@no_spam_hotmail.com> wrote in message

news:Oc5xfcq3...@TK2MSFTNGP03.phx.gbl...

[SuperGumby [SBS MVP]]

nitpicky correction to Merv: The contractor would not see workstations
(unless he took the wrong choice at the RWW front page).

Does someone accessing 'purely for administrative purposes' (therefore not
requiring a CAL) have to use either the 500 account or pose as an existing
user or can a specific account be set up for that use? I believe the latter.

"Larry Struckmeyer" <lstruckmeyer(at)mis-wizards(dot)com> wrote in message
news:%23JtDTqq...@TK2MSFTNGP05.phx.gbl...

[Larry Struckmeyer at dot]

can a specific account be set up for that use? I believe the latter.

Hi Super:

Where is the "setup specific account for that use" Wizard?

I think I was asleep during that portion of class.

:-)

Larry

[SuperGumby [SBS MVP]]

Well, now that you raise the issue, I see no reason why the contractor
should be anything but a 'normal' user, subject him to the same restrictions
as your standard users. Like many things SBS such a ruling (whether he is
performing admin only) would be a legal distinction the system doesn't know
about and cannot track, _you_ define whether he is 'performing admin only'.

If forced to I'd make him a normal user but local admin on the TS. I'd be
reluctant to though, means some things may work for him but not my normal
users, same as them, if he wants something 'system wide' done, I do it for
him.

If the account requires wider admin privelages I would probably NOT create
the account using the wiz, I would do a manual domain user creation and
elevated membership. (same as I do for my 'backdoor' account, an account
having more complex than normal user/pass and Domain Admin rights. The
user/pass are not recorded by me, they are put into an envelope (preferably
2) in a safe place in case the client wants to lock me out.)

"Larry Struckmeyer" <lstruckmeyer(at)mis-wizards(dot)com> wrote in message

news:e3TmcAt...@TK2MSFTNGP05.phx.gbl...

[kj [SBS MVP]]

SuperGumby [SBS MVP] wrote:
> Well, now that you raise the issue, I see no reason why the contractor
> should be anything but a 'normal' user, subject him to the same
> restrictions as your standard users. Like many things SBS such a
> ruling (whether he is performing admin only) would be a legal
> distinction the system doesn't know about and cannot track, _you_
> define whether he is 'performing admin only'.

I've been watching and waiting for justification for even creating a domain
user account. So far, unless I missed it, I haven't seen it. Not much detail
about what the vendor needs to do on this 'member server' or just what the
application or purpose, but a local user account, member of local
administrators, and remote desktop group should handle what I've digested so
far. Just a thought a wee bit outside the box.

--
/kj

[SuperGumby [SBS MVP]]

I do not want him using an existing account, there is no reason he should
pretend to be me, Mary from accounts or Sam the secretary. If he wishes to
access the system he gets an account he is responsible for the actions of.

As a standardly defined user he should see any problem my other standard
users encounter, hence my wish that he does not have any form of elevated
privelege.

Another aspect of 'elevated privelege' is that I _don't_ want him installing
KB3c4a678ds, which I have 'declined' in WSUS because it breaks my 'other'
LOB application. If he needs it he talks to me, and we attempt to resolve
the conflict or find an alternate resolution.

The 'member server' is, according to the original post, also TS Apps mode.
Any action by this external party _may_ take my _many_ users offline. If he
can't deal with it I will return his employer's software as 'unfit for
purpose' and find an alternate method.

"kj [SBS MVP]" <Kevin...@SPAMFREE.gmail.com> wrote in message
news:eWzvlLu3...@TK2MSFTNGP02.phx.gbl...

[Al Williams]

He needs to have administrator rights on the member terminal server to run
some LOB utilities - nothing else (ie: no access to the SBS server or the
user desktops). The problem is I can't figure out how a way to let him use
RWW/Connect to Server Desktops without giving him full domain access.

--
Allan Williams

"Larry Struckmeyer" <lstruckmeyer(at)mis-wizards(dot)com> wrote in message
news:%23JtDTqq...@TK2MSFTNGP05.phx.gbl...

[Larry Struckmeyer at dot]

Hi Al:

Given the restrictions you need / want to apply to this user, I am thinking
along these lines.

Give the user Local Admin Rights and Log On Remotely Rights on the TS. Deny
Logon Remotely on the SBS.

Then:

What would happen if there were two nics in the TS, the second connect to
and pointed to the router, and you opened the VPN ports on your router and
point them to the second nic in the TS to keep him from passing though the
SBS? Probably requires you to configure RRAS on the TS?

He could then RDP to the TS without touching the SBS.

Or, perhaps, you could just deny this account logon remotely rights on the
SBS server. but allow him those rights on the TS?.

He could then RDP to the TS, but he would be denied if he tried to RDP to
the SBS.

Larry

"Al Williams" <donotrep...@usenewsgroup.com> wrote in message

news:%23qK3a20...@TK2MSFTNGP05.phx.gbl...

[Al Williams]

As this is just a short-term issue (once the upgrades are done I will turn
off access) I kind of wanted to avoid making too many changes.

In the end this worked:

1) Create a new "mobile" user for the contractor, no email.
2) Remove the "Domain User" group from the user (leave others for now).
3) Restrict the new users "Log On To... " rights to just SBS (for RWW) and
the member TS.
4) Add this user as an administrator on the member TS server.

With this setup the contractor uses the RWW screen and logs in with their
login. They then use the "Connect to my company's application-sharing
server" link to logon to the member terminal server with the same login. On
this setup the HISERVER isn't shown and they can't use their login to login
to any other PC's so I think it's fairly secure. I do trust this contractor
(you are all trustworthy, right? ;-) , so I'm not too worried. Once the job
is done I'll disable the user until it's needed again.

--
Allan Williams

"Larry Struckmeyer" <lstruckmeyer(at)mis-wizards(dot)com> wrote in message

news:ezAb2U6...@TK2MSFTNGP06.phx.gbl...

[berniem]

Hi all, I had to do exactly this type of thing awhile back (about 2 years ago
- so forgive me if I don't have all the details correct) and heres what
worked for me:
1) setup ISA on SBS2003 to listen on new additional port (i.e 9999) and
forward that port to IP address of member (terminal) server.
2) reconfigure member (terminal) server to listen for incoming terminal
service requests on 9999 (theres a kb article that shows the registry entry)
3) to connect to memebr (terminal) server i rdp to external_fqdn:9999

hth
bernie