Terminal Server: Enough included w/MSDN?

[(Pete Cresswell)]

I'd like to dabble in Terminal Server enough to see if I can get some of my MS
Access apps to run through it.

I've got the MSDN subscription. Is there enough there for a real-world
implementation?
--
PeteCresswell

[Alan Webb]

Pete Cresswell,
I run an Access .adp connected to SQL Server 2000 through Terminal Services
on my server and have no problems. If you plan on supporting more than a
couple concurrent users you have to make sure Terminal Services is in
Application Server mode and buy the appropriate licenses, but other than
that, you should be fine. And, yes, guys, I know that I could connect to my
SQL Server instance over port 1433 and don't need Terminal Services but I am
a poor Access developer and even worse Systems Admin.

"(Pete Cresswell)" <x@y.z> wrote in message
news:81********************************@4ax.com...

I'd like to dabble in Terminal Server enough to see if I can get some of my MS Access apps to run through it.

I've got the MSDN subscription. Is there enough there for a real-world
implementation?
--
PeteCresswell

[Trevor Best]

Alan Webb wrote:

And, yes, guys, I know that I could connect to my
SQL Server instance over port 1433 and don't need Terminal Services but I am
a poor Access developer and even worse Systems Admin.

Besides which, the last thing you want is port 1433 open to all and
sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[PeteCresswell]

> Besides which, the last thing you want is port 1433 open to all and

sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

I don't even know what port 1433 is.... but could it be open by
default on a PC that's running SQL Server/Developer? The PC that has
that on it seems to attract a steady stream of SQL Server Worm
Propogation attempts.

[Trevor Best]

PeteCresswell wrote:

Besides which, the last thing you want is port 1433 open to all and
sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

I don't even know what port 1433 is.... but could it be open by
default on a PC that's running SQL Server/Developer? The PC that has
that on it seems to attract a steady stream of SQL Server Worm
Propogation attempts.

Port 1433 is what SQL server uses so yes. I trust your PC is firewalled?

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[David W. Fenton]

Go**********@FatBelly.com (PeteCresswell) wrote in
news:74**************************@posting.google.c om:

Besides which, the last thing you want is port 1433 open to all
and sundry. If it's open on the net, it's not a matter of if, it
*will* be hacked.
I don't even know what port 1433 is.... but could it be open by
default on a PC that's running SQL Server/Developer? . . .

One of the problems there is that many users don't know SQL Server
is running. If you install the MSDE you might have port 1433 wide
open.
. . . The PC that
has that on it seems to attract a steady stream of SQL Server Worm
Propogation attempts.

It accepts connections from outside your local network?

Your firewall doesn't block port 1433 at the network boundary?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Tony Toews]

Trevor Best <nospam@localhost> wrote:

And, yes, guys, I know that I could connect to my
SQL Server instance over port 1433 and don't need Terminal Services but I am
a poor Access developer and even worse Systems Admin.

Besides which, the last thing you want is port 1433 open to all and
sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

I've read this elsewhere as well. But if you have the latest patches installed, and
assuming there aren't unknown exploits out there, how can it hurt? Please be more
specific.

Thanks, Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Rick Brandt]

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:cg********************************@4ax.com...

Trevor Best <nospam@localhost> wrote:

And, yes, guys, I know that I could connect to my
SQL Server instance over port 1433 and don't need Terminal Services but I am a poor Access developer and even worse Systems Admin.
Besides which, the last thing you want is port 1433 open to all and
sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

I've read this elsewhere as well. But if you have the latest patches

installed, and assuming there aren't unknown exploits out there, how can it hurt? Please be more specific.

I've often wondered about this myself. The conventional wisdom seems to
be...

1) If you need real security use a database engine like SQL Server instead
of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Alan Webb]

Rick Brandt, et al.
To get back to the point--Terminal Services seems fine as a means of working
with Access databases across a network. For those that really want to go
whole hog and make sure the server being connected to behaves as if it was
connected to an actual PC, Virtual PC is a great product that takes the
Terminal Services idea much further and emulates a complete PC in software.
As for doing it the more typical way and letting SQL Server answer on port
1433 to db client software--that would require a dba & sys admin that
actually knew what they were doing--something I've yet to become.

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:2m************@uni-berlin.de...

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:cg********************************@4ax.com...

Trevor Best <nospam@localhost> wrote:

> And, yes, guys, I know that I could connect to my
> SQL Server instance over port 1433 and don't need Terminal Services but I am> a poor Access developer and even worse Systems Admin.

Besides which, the last thing you want is port 1433 open to all and
sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

I've read this elsewhere as well. But if you have the latest patches

installed, and

assuming there aren't unknown exploits out there, how can it hurt?

Please be more

specific.

I've often wondered about this myself. The conventional wisdom seems to
be...

1) If you need real security use a database engine like SQL Server instead
of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[(Pete Cresswell)]

RE/

Your firewall doesn't block port 1433 at the network boundary?

Dunno if it blocks it or where, but it does appear to catch a lot of what it
calls W32_SQLEXP_Worm_Propogation.

Norton Personal Firewall.
--
PeteCresswell

[david epsom dot com dot au]

Note: you can change the port. 1433 is just the default value.
1433 is fine if you WANT everybody to be able to assume the default
value.

(david)

"Trevor Best" <nospam@localhost> wrote in message
news:40**********************@auth.uk.news.easynet .net...

PeteCresswell wrote:

Besides which, the last thing you want is port 1433 open to all and
sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

I don't even know what port 1433 is.... but could it be open by
default on a PC that's running SQL Server/Developer? The PC that has
that on it seems to attract a steady stream of SQL Server Worm
Propogation attempts.

Port 1433 is what SQL server uses so yes. I trust your PC is firewalled?

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[David W. Fenton]

"(Pete Cresswell)" <x@y.z> wrote in
news:8j********************************@4ax.com:

RE/

Your firewall doesn't block port 1433 at the network boundary?

Dunno if it blocks it or where, but it does appear to catch a lot
of what it calls W32_SQLEXP_Worm_Propogation.

Norton Personal Firewall.

The default state for any firewall should be 100% of incoming ports
closed. Then you may need to open up a few for specific tasks.

If you have a proper software firewall you can control who can
connect. For SQL Server, you could limit it to your local LAN's IP
address space, and then external machines wouldn't be able to
connect.

Of course, if the worm connection is coming from a machine on your
LAN, that won't get you anything.

Another thing to do is to use a non-standard port for SQL Server.
You'll have to specify it in your connection strings, but that
shouldn't be that big of a deal.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:2m************@uni-berlin.de:

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:cg********************************@4ax.com...

Trevor Best <nospam@localhost> wrote:

>> And, yes, guys, I know that I could connect to my
>> SQL Server instance over port 1433 and don't need Terminal
>> Services but I am >> a poor Access developer and even worse Systems Admin.
>
>Besides which, the last thing you want is port 1433 open to all
>and sundry. If it's open on the net, it's not a matter of if, it
>*will* be hacked.

I've read this elsewhere as well. But if you have the latest
patches

installed, and

assuming there aren't unknown exploits out there, how can it
hurt?

Please be more

specific.

I've often wondered about this myself. The conventional wisdom
seems to be...

1) If you need real security use a database engine like SQL Server
instead of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?

Well, one of the problems is that, out of the box, the SA account
has no password (or maybe it's a password that everyone knows), so
anybody can connect as administator to any default installation.
Maybe recent SQL Server patches undo that. I don't know.

But I would do several things if I needed to run SQL Server on my
network:

1. set a strong password on the SA account.

2. run it on a non-standard port.

3. control who can connect to it.

The latter may be most easily done with a proxy server, or via VPN
connections. Either of those solutions would mean that the random
worm would not be able to connect.

Of course, you alsc can't really depend on a patched machine staying
in a "safe" condition. We all know perfectly well that repairing or
re-installation an application can revert you back to unpatched
versions of the software.

So, depending on the "security" of knowing that you've patched your
machine without doing something to prevent that "security" from
being tested is unwise.

Besides, there are probably plenty of vulnerabilities yet to be
found, and you'll still be vulnerable to those. Doing those 3 steps
will probably prevent any of them from getting you.

Probably.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Trevor Best]

david epsom dot com dot au wrote:

Note: you can change the port. 1433 is just the default value.
1433 is fine if you WANT everybody to be able to assume the default
value.

Not much defense against a port scanner, it'll find the open port.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

Tony Toews wrote:

Trevor Best <nospam@localhost> wrote:

And, yes, guys, I know that I could connect to my
SQL Server instance over port 1433 and don't need Terminal Services but I am
a poor Access developer and even worse Systems Admin.

Besides which, the last thing you want is port 1433 open to all and
sundry. If it's open on the net, it's not a matter of if, it *will* be
hacked.

I've read this elsewhere as well. But if you have the latest patches installed, and
assuming there aren't unknown exploits out there, how can it hurt? Please be more
specific.

Erm... Hacked. As in some unauthorised person now has access to your
data, can read confidential information, blow your data away, etc. A
patch isn't going to stop that.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

David W. Fenton wrote:

1) If you need real security use a database engine like SQL Server
instead of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?

Well, one of the problems is that, out of the box, the SA account
has no password (or maybe it's a password that everyone knows), so
anybody can connect as administator to any default installation.
Maybe recent SQL Server patches undo that. I don't know.

SP3 strongly recommends a password, but doesn't enforce it.
But I would do several things if I needed to run SQL Server on my
network:

1. set a strong password on the SA account.
Or disable it, SQL Server has two security holes^h^h^h^h^h methods,
Windows Authentication and Standard, you can disable standard so any
brute force attacks on the sa account will be futile. You cannot disable
the Windows integrated authentication but to get into SQL Server would
require someone to log onto your domain.
2. run it on a non-standard port.
This will only fool a casual cracker, if there is such a thing. A
determined one will use a port scanner, if you say put SQL Server on
port 80 (usually http) then the cracker will notice that no web service
is running on port 80 and may try something else.
3. control who can connect to it.
By far the best method.
Besides, there are probably plenty of vulnerabilities yet to be
found, and you'll still be vulnerable to those. Doing those 3 steps
will probably prevent any of them from getting you.

Probably.

Bit like any security, what did Qui-gon Jinn say in Ep1? There's always
a bigger fish.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

Rick Brandt wrote:

I've often wondered about this myself. The conventional wisdom seems to
be...

1) If you need real security use a database engine like SQL Server instead
of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?

No. Do banks have their vault doors inside or outside the building?

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Rick Brandt]

"Trevor Best" <nospam@localhost> wrote in message
news:40***********************@auth.uk.news.easyne t.net...

Rick Brandt wrote:

I've often wondered about this myself. The conventional wisdom seems to be...

1) If you need real security use a database engine like SQL Server instead of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?

No. Do banks have their vault doors inside or outside the building?

Bad analogy. No bank is going to claim that the reason your money is safe
is because of the lock on the front door. Either the vault is secure or it
isn't.

If server-based engines provide "real" security then open ports should not
matter. If they matter then they don't provide real security either, just
security that is "somewhat better".

Following the argument that accessible ports are a security hazard then my
data is vulnerable to anyone who is allowed access to the LAN. Perhaps
that is the technical reality, but I just wonder if the people selling
these databases pitch it that way. "As long as you close ports to the
outside world only your employees will be able to break our security".
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

Trevor Best <nospam@localhost> wrote in
news:40***********************@auth.uk.news.easyne t.net:

David W. Fenton wrote:

2. run it on a non-standard port.

This will only fool a casual cracker, if there is such a thing. A
determined one will use a port scanner, if you say put SQL Server
on port 80 (usually http) then the cracker will notice that no web
service is running on port 80 and may try something else.

Why would anyone be silly enough to put it on port 80??!

No, using a non-standard port won't help with exploits that scan all
ports, but *most worms don't do that* -- they scan a small number of
ports, so you're at least protecting yourself from the dumb worms,
and I think that's worth something.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Rick Brandt" <ri*********@hotmail.com> wrote in
news:2m************@uni-berlin.de:

Following the argument that accessible ports are a security hazard
then my data is vulnerable to anyone who is allowed access to the
LAN. Perhaps that is the technical reality, but I just wonder if
the people selling these databases pitch it that way. "As long as
you close ports to the outside world only your employees will be
able to break our security".

That's pretty much a standard part of my Access database application
security pitch. I don't believe in undertaking superhuman efforts to
secure an Access application because the greatest danger is from the
people who are *supposed* to have full access to the application and
its data.

Most people think the danger is out there somewhere, in the wilds of
the Internet. I inform them that perimeter maintenance is important,
but the people who are most dangerous are the ones in whom you've
placed the most trust, not the other way around.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Trevor Best]

David W. Fenton wrote:

Trevor Best <nospam@localhost> wrote in
news:40***********************@auth.uk.news.easyne t.net:

David W. Fenton wrote:

2. run it on a non-standard port.

This will only fool a casual cracker, if there is such a thing. A
determined one will use a port scanner, if you say put SQL Server
on port 80 (usually http) then the cracker will notice that no web
service is running on port 80 and may try something else.

Why would anyone be silly enough to put it on port 80??!

What is your problem in understanding hypothetical examples?
No, using a non-standard port won't help with exploits that scan all
ports, but *most worms don't do that* -- they scan a small number of
ports, so you're at least protecting yourself from the dumb worms,
and I think that's worth something.

Again your understanding is very limited, I was clearly talking about
crackers, not worms.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Tony Toews]

"Rick Brandt" <ri*********@hotmail.com> wrote:

Bad analogy. No bank is going to claim that the reason your money is safe
is because of the lock on the front door. Either the vault is secure or it
isn't.

Well, not quite. You can open a bank vault using a drill. However this requires
48-72 hours of continuous drilling in the exact spot. With such tools as a floor
mount drill capable of keep a constant pressure on the drill bit and bit sharpeners
near by as you are going to use a lot of bits.

So a bank vault is secure against all reasonable threats and most unreasonable
threats.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Trevor Best]

Rick Brandt wrote:

No. Do banks have their vault doors inside or outside the building?

Bad analogy. No bank is going to claim that the reason your money is safe
is because of the lock on the front door. Either the vault is secure or it
isn't.

Point taken but my point is SQL Server security is as strong as it's
password, which can be cracked, if it's not open on the net then it
cannot be cracked by anyone outside the LAN, they would have to get into
the LAN first.
If server-based engines provide "real" security then open ports should not
matter. If they matter then they don't provide real security either, just
security that is "somewhat better".
Real security? I know of a guy who "secured" his Ducati 916 by use of a
disk lock, horseshoe lock, ground anchor, alarm, immobiliser, locked
garage, also alarmed (we're talking Thatcham approved, Abus locks, etc,
not cheap sh1te). His bedroom was above the garage. Who wouldn't
consider that "real security"? You probably guessed by now he went to
bed one night and got up in the morning to find his pride and joy gone.

The only "real security" on a network, is to not be on the network, that
is what a firewall does to an extent, not 100% fool proof, it stops bad
people pushing bad things onto you but then most people have IE to do
that job for them.
Following the argument that accessible ports are a security hazard then my
data is vulnerable to anyone who is allowed access to the LAN. Perhaps
that is the technical reality, but I just wonder if the people selling
these databases pitch it that way. "As long as you close ports to the
outside world only your employees will be able to break our security".

You can go back to the bank analogy, the staff are handling loads of
other people's cash all day long. The customers, on the other side of
the secure screens, unless dextrous in the art of dipping are only ever
handling their own money, no point in pinching that. "I mugged myself on
the way to the shops, made a fiver out of it" (Eddie Hitler, Bottom) :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[david epsom dot com dot au]

SQL Server has twice almost brought the internet to it's (metaphorical)
knees. Jet hasn't. The two statements listed miss the most important
rule zero:

0) If you need real security, you need to pay a DBA with security
experience.

Jet security is like putting your money in your shoe.

SQL Server without a DBA is like putting your money in an open
bank vault, so that people know where to find it.

(david)

"Trevor Best" <nospam@localhost> wrote in message
news:40***********************@auth.uk.news.easyne t.net...

Rick Brandt wrote:

I've often wondered about this myself. The conventional wisdom seems to be...

1) If you need real security use a database engine like SQL Server instead of Jet.
2) Don't leave your SQL Server port exposed or you'll get hacked.

One of the above statements must be wrong, no?

No. Do banks have their vault doors inside or outside the building?

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Alan Webb]

Trevor Best,
This is so off-thread it isn't funny. The original question related to
Terminal Services and whether you could run an Access database app in a
Terminal Services session. The answer is, yes, you can and I do. As for
security, Terminal Services will connect to the host machine without an
account name and password but what you get is the Win2K login dialog. You
have to authenticate on the host machine to get to a desktop. So security
in Terminal Services relies on the skill of the systems admin running that
server. If a user can authenticate on the server and get a desktop then he
or she is effectively inside the internal network of the host and then the
rest of the issues related to database security play out. I'd still rather
run MSDE over Access as the back end database because MSDE runs SQL Server's
security model.

"Trevor Best" <nospam@localhost> wrote in message
news:40***********************@auth.uk.news.easyne t.net...

Rick Brandt wrote:

No. Do banks have their vault doors inside or outside the building?

Bad analogy. No bank is going to claim that the reason your money is safe is because of the lock on the front door. Either the vault is secure or it isn't.

Point taken but my point is SQL Server security is as strong as it's
password, which can be cracked, if it's not open on the net then it
cannot be cracked by anyone outside the LAN, they would have to get into
the LAN first.

If server-based engines provide "real" security then open ports should not matter. If they matter then they don't provide real security either, just security that is "somewhat better".

Real security? I know of a guy who "secured" his Ducati 916 by use of a
disk lock, horseshoe lock, ground anchor, alarm, immobiliser, locked
garage, also alarmed (we're talking Thatcham approved, Abus locks, etc,
not cheap sh1te). His bedroom was above the garage. Who wouldn't
consider that "real security"? You probably guessed by now he went to
bed one night and got up in the morning to find his pride and joy gone.

The only "real security" on a network, is to not be on the network, that
is what a firewall does to an extent, not 100% fool proof, it stops bad
people pushing bad things onto you but then most people have IE to do
that job for them.

Following the argument that accessible ports are a security hazard then my data is vulnerable to anyone who is allowed access to the LAN. Perhaps
that is the technical reality, but I just wonder if the people selling
these databases pitch it that way. "As long as you close ports to the
outside world only your employees will be able to break our security".

You can go back to the bank analogy, the staff are handling loads of
other people's cash all day long. The customers, on the other side of
the secure screens, unless dextrous in the art of dipping are only ever
handling their own money, no point in pinching that. "I mugged myself on
the way to the shops, made a fiver out of it" (Eddie Hitler, Bottom) :-)

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[Trevor Best]

Alan Webb wrote:

Trevor Best,
This is so off-thread it isn't funny.
Try not to get motion sickness or vertigo up there on that high horse of
yours.
The original question related to
Terminal Services and whether you could run an Access database app in a
Terminal Services session.

Actually it wasn't.

The original question was whether MSDN subscription had enough in it to
run a terminal server (to which the answer is again yes), he was going
to see for himself whether his Access apps would run in it. You brought
SQL Server and the possibility of running that over the net into the thread.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer

[rkc]

"Alan Webb" <kn*****@hotmail.com> wrote in message
news:S0***************@news.uswest.net...

Trevor Best,
This is so off-thread it isn't funny.

Golly gee. That hardly ever happens.

[Tony Toews]

Trevor Best <nospam@localhost> wrote:

I've read this elsewhere as well. But if you have the latest patches installed, and
assuming there aren't unknown exploits out there, how can it hurt? Please be more
specific.

Erm... Hacked. As in some unauthorised person now has access to your
data, can read confidential information, blow your data away, etc. A
patch isn't going to stop that.

Sure. But so could've my web server. I've been happily running Win 2000 Server and
Win 2003 Server for several years now without being hacked.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Trevor Best]

Tony Toews wrote:

Trevor Best <nospam@localhost> wrote:

I've read this elsewhere as well. But if you have the latest patches installed, and
assuming there aren't unknown exploits out there, how can it hurt? Please be more
specific.

Erm... Hacked. As in some unauthorised person now has access to your
data, can read confidential information, blow your data away, etc. A
patch isn't going to stop that.

Sure. But so could've my web server. I've been happily running Win 2000 Server and
Win 2003 Server for several years now without being hacked.

But it isn't a database server, there's a difference in what information
you could see between hacking a web server and a database server.

--
Error reading sig - A)bort R)etry I)nfluence with large hammer