Terminal services and VB.Net Solution?

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

I created an Access 2007 application for my customer. The application is
shared by three employees on a server. It maintains a contact list including
financial data and social security numbers. Only the office manager
generates reports in Access from this client data.

Now they want to share this Access application with employees at a remote
office. They expect to have a maximum of 30 employees editing the client
list in both the local and remote offices. So, I'm looking for a solution
that will allow for growth -- so that more users can securely edit their
contact list - both locally and remotely.

Do you think the following is a good solution?

1) Convert the Access front-end to .Net by programming it in Visual Basic
2008 Express. This front end will then create a connection to the client
list data as needed -- get the data or save changes -- then drop the
connection.

2) Convert the Access 2007 back-end to SQL Server 2008 Express by using the
Access upsize wizard.

3) Keep the reports in Access 2007. Connect the Access reports to the
client list data in SQL Server 2008 Express. Only the office manager needs
to generate reports. I understand that there are 10 connections available
in SQL Server 2008 Express. So, one seat could be sacrificed for generating
reports.

4) Hire a networking consultant to...
** Buy and set up a second server in their local office (with RAID for
mirroring)
** Install Windows Server 2008 on the new server
** Set up 20 terminal services seats for remote access on the new server.
** Install SQL Server 2008 Express on the new server
** Set up daily backups of the new server.
** Broadband internet connection should be at least 1 meg up or better at
local office where the new server will be located.

Does all of the above software operate smoothly together under .Net
Framework 3.5 ? If yes, is there any software that each terminal services
installation seat needs to drop on?

I will be very grateful to hear any recommendations .

[Andrew Morton]

Dweeberella wrote:

I created an Access 2007 application for my customer. The
application is shared by three employees on a server. It maintains a
contact list including financial data and social security numbers.
Only the office manager generates reports in Access from this client
data.

Now they want to share this Access application with employees at a
remote office. They expect to have a maximum of 30 employees editing
the client list in both the local and remote offices. So, I'm
looking for a solution that will allow for growth -- so that more
users can securely edit their contact list - both locally and
remotely.

Have you considered making it into an ASP.NET application instead? That way
you wouldn't need 20 terminal services seats, or even a new server, if you
have a web server running IIS somewhere already.

Andrew

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you for your input, Andrew. Actually, we were thinking of going with
ASP.Net. But I talked to the owner of a web host who was adamant that
hosting data online is a security risk. He said that hosting online should
only be used for data that you want to share with the world. The purpose of
this application is to maintain a list of social security numbers and other
client financial data. So, security is a big concern.

[Cor Ligthert[MVP]]

And you think your current situation is more save?

Probably that is why most banks, on line shops etc are not using it.

Just my thought reading your message

Cor

"Dweeberell a" <Dw*********@di scussions.micro soft.comwrote in message
news:D6******** *************** ***********@mic rosoft.com...

Thank you for your input, Andrew. Actually, we were thinking of going
with
ASP.Net. But I talked to the owner of a web host who was adamant that
hosting data online is a security risk. He said that hosting online
should
only be used for data that you want to share with the world. The purpose
of
this application is to maintain a list of social security numbers and
other
client financial data. So, security is a big concern.

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you for your response, Cor.

Do you mean that most banks use ASP.Net for remote access to a secure
network? Or do you mean that most banks use terminal services?

I'm trying to plan a secure situation as we expand users of our database and
make the application available to a remote office. So we don't have anything
up yet except a Microsoft Access database used only in one office on a server
-- no remote users yet -- and only 3 users but they want to plan for up to 30
users.

"Cor Ligthert[MVP]" wrote:

And you think your current situation is more save?
Probably that is why most banks, on line shops etc are not using it.
Just my thought reading your message
Cor

[Miro]

i do not want to put words in Cor's mouth but from what I understand:

I understood Cor's answer that when you do online banking, its a stype of
'programming' of ASP.net - not a winforms.

If banks are not worried about security for your banking information - and
thats banking information - you might be a bit 'over worried' about your
data.
Properly setup - your data would be safe online imho.

You can just as well maybe programing it ASP style, and let them run it
through terminal service or perhaps even a vpn, and when the time comes -
just pop it over on the net once they are more comfortable.

Miro

"Dweeberell a" <Dw*********@di scussions.micro soft.comwrote in message
news:EA******** *************** ***********@mic rosoft.com...

Thank you for your response, Cor.

Do you mean that most banks use ASP.Net for remote access to a secure
network? Or do you mean that most banks use terminal services?

I'm trying to plan a secure situation as we expand users of our database
and
make the application available to a remote office. So we don't have
anything
up yet except a Microsoft Access database used only in one office on a
server
-- no remote users yet -- and only 3 users but they want to plan for up to
30
users.

"Cor Ligthert[MVP]" wrote:

>And you think your current situation is more save?
Probably that is why most banks, on line shops etc are not using it.
Just my thought reading your message
Cor

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you to all those that responded to my inquiry. You have influenced me
to propose using ASP.net.

I talked to a networking consultant who proposed forcing remote users to
connect up via VPN before allowing them access to our internal website and
ASP.Net application. Then the ASP.net application will not be exposed
directly to the internet. We will use password authentication and encryption
for the internal website. We will use an SSL certificate for that.

There will be multiple levels of security...
1) Remote users first need to login via VPN to the local server.
2)Then, remote users need to startup the correct internal URL to get my
ASP.Net app started.
3)Then, remote users need to enter the correct login and password to
actually get into my app.

ASP.net puts less of a drain on the server than Access does. So, there
should be no need to get a second server.

I'll keep the reporting functions in Access -- since there is only one user
for the reports. So, the Access reports will only take up one of the 10
concurrent connections offered in SQL Server 2008 Express.

How does this solution sound?

[Mr. Arnold]

"Dweeberell a" <Dw*********@di scussions.micro soft.comwrote in message
news:52******** *************** ***********@mic rosoft.com...

Thank you to all those that responded to my inquiry. You have influenced
me
to propose using ASP.net.

I talked to a networking consultant who proposed forcing remote users to
connect up via VPN before allowing them access to our internal website and
ASP.Net application. Then the ASP.net application will not be exposed
directly to the internet. We will use password authentication and
encryption
for the internal website. We will use an SSL certificate for that.

There will be multiple levels of security...
1) Remote users first need to login via VPN to the local server.
2)Then, remote users need to startup the correct internal URL to get my
ASP.Net app started.
3)Then, remote users need to enter the correct login and password to
actually get into my app.

ASP.net puts less of a drain on the server than Access does. So, there
should be no need to get a second server.

I'll keep the reporting functions in Access -- since there is only one
user
for the reports. So, the Access reports will only take up one of the 10
concurrent connections offered in SQL Server 2008 Express.

How does this solution sound?

Myself, I would use IIS, Windows Communication Foundation Web service on IIS
with the security protocols that WCF uses, SQL Server on the back-end and
using a Windows Desktop VB.net client solution.

The Windows Desktop solution would be deployed to a terminal server such as
Citrix Terminal server using the Cirtix VPN Web browser client session on
the client side in communications with the Citrix terminal server that would
allow multiple user sessions to run the Windows Desktop solution, as if they
were at their desktop running the solution.

1) User has to login to the Citrix terminal server using NT authentication.
2) The client application would be using a possible role based security for
each user that would be using SQL Server to hold user credentials.
3) The user would be in a Citrix VPN terminal session using a Citrix Web
browser VPN client side software at the their workstation.

It's bank. Doesn't the bank have MS SQL Server a server on the network.

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you Mr. Arnold for your proposed security solution.

My network consultant proposed activating VPN which he says is already
available in Windows server. Why is Citrix VPN better than that?

You propose using VB.Net rather than ASP.Net. For VB.Net, we don't need
IIS activated, right? It sounds to me like a more secure solution is to keep
IIS deactivated and use VB.Net rather than ASP.Net. What do you think?

How does SSL fit in with this? We don't need an SSL certificate if we use
VB.Net rather than ASP.Net, right?

[Mr. Arnold]

"Dweeberell a" <Dw*********@di scussions.micro soft.comwrote in message
news:13******** *************** ***********@mic rosoft.com...

Thank you Mr. Arnold for your proposed security solution.

My network consultant proposed activating VPN which he says is already
available in Windows server. Why is Citrix VPN better than that?

<http://74.125.45.104/search?q=cache: 1DFCgafThkwJ:ww w.seceidos.de/fileadmin/media/documents/Citrix_Access_G ateway_7-0_Enterprise_Ed ition_-_Technical_Pres entation__engli sch_.ppt+citrix +vpn+session+wi th+browser&hl=e n&ct=clnk&cd=4& gl=us>

The client on the other end is using a *browser session* to login into the
Citrix Terminal server with a VPN connection and using NT authentication to
login to the NT based O/S server running Citrix Terminal server. I would
assume that the NT server O/S machine running Citrix Terminal server would
be on a local NT domain.

That means the user uses a Citrix browser VPN client session to login to the
Citrix terminal server desktop to run your Windows Desktop solution, with
your desktop solution using a user-id and psw to log into your Windows
desktop solution using .Net role-based security to authentication the user
logging into the desktop solution, after he or she logged into the Citrix
Terminal server.

>
You propose using VB.Net rather than ASP.Net. For VB.Net, we don't need
IIS activated, right? It sounds to me like a more secure solution is to
keep
IIS deactivated and use VB.Net rather than ASP.Net. What do you think?

ASP.NET Active Server Pages is using IIS and VB.Net or C#.Net as the Code
Behind file solution language.

With a VB.NET Windows Desktop solution running on a terminal server such as
Citrix or other VPN solution is a more secure solution for your internal
company solution that must be run by other users outside of your local NT
domain, and your desktop solution doesn't need IIS.

>
How does SSL fit in with this? We don't need an SSL certificate if we
use
VB.Net rather than ASP.Net, right?

With Citrix software, one can be in a SSL session with a client Web browser
and the Citrix terminal server.

The thing you should recognize is that the user is using a browser session
to access the Citrix Terminal server and running the solution on the Citrix
Terminal server desktop as if the user was running it from his workstation
desktop, with the connection between the Citrix Terminal server and the
user's Citrix terminal client session being in a secure connection.

I am just giving you more options. However, I have seen Citrix being used
internally across multiple company NT domains, and by users in remote
locations using dial-up, BB, and DSL within the same company infrastructure
to access a solution on a global wide bases used by internal company users.
It just happened that the solution was running on 20 Citrix terminal servers
in a Citrix terminal server farm. You may not get to that capacity. :)